IEC Mass-Storage device

rje · Post by **rje** » Tue Mar 16, 2021 3:30 pm

Since the X16 is not a C64, an IEC mass-storage device need not be cycle-exact: in short, it can patch/monitor the I/O on the device side to deliver data with less fuss than things which require really painful cycle-exactness due to C64 disk copy protection schemes.

Right?

Or perhaps I'm wrong... the X16 is a physical device speaking IEC with the same connector as the later machines...

Or, perhaps it depends on the device being emulated.

* * *

Maybe I'm overthinking this, and I should just expect to use Pi1541.

TomXP411 · Post by **TomXP411** » Tue Mar 16, 2021 9:35 pm

Yes, you're overthinking it. Use an SD2IEC (not a Pi 1541).

Since you don't need cycle exact timing or copy protection, the SD2IEC is actually faster and simpler to use. It also has the advantage of being a real mass storage device (not a floppy emulator) and handling 1541, 1571, and 1581 images.

BruceMcF · Post by **BruceMcF** » Wed Mar 17, 2021 6:14 am

16 hours ago, rje said:

Since the X16 is not a C64, an IEC mass-storage device need not be cycle-exact: in short, it can patch/monitor the I/O on the device side to deliver data with less fuss than things which require really painful cycle-exactness due to C64 disk copy protection schemes.

Right?

Right!

The only reason that there is a benefit for being a cycle exact replica of a 1541 is because of C64 disk based games that run copy protection that requires the disk to be accessed by a 1541.

I believe a version of Pi1541 can be developed for the CX16 which will be much faster, due to not bothering with emulating the 1541. Indeed, even cheaper, it may be that something could be developed to run on a RPi Pico which could be used with a USB Flash Drive (since the RPI Pico can host USB On The Go).

rje · Post by **rje** » Wed Mar 17, 2021 4:24 pm

10 hours ago, BruceMcF said:

I believe a version of Pi1541 can be developed for the CX16 which will be much faster, due to not bothering with emulating the 1541.

I was reading the designer's notes, and I came to the same conclusion:

Quote

Currently when Pi1541 boots it will be in browser mode (or SD2IEC mode)

In this mode Pi1541 will support very minimal SD2IEC commands. Basicaly you can load PRG files and browse folders and images. (Multiple channels and Saving are also supported for sequentual files only)

Once a valid disk image or images have been selected Pi1541 will drop down into emulation mode.

In full emulation mode reading and writing are supported.

If r/w support is added at the SD2IEC level, then running in "SD2IEC mode" would be fine on a Pi Zero without overclocking, I suspect.

rje · Post by **rje** » Wed Mar 17, 2021 7:44 pm

Would it really be faster? Isn't throughput limited by the IEC-Serial bus itself?

Your answer might be "it depends on the device being emulated", which is true and opens up another set of questions.

So maybe the correct next question is "which IEC device should be handled in non-cycle-exact form?". I see no reason to emulate a D64 when the D81 is superior in every way, for example.

BruceMcF · Post by **BruceMcF** » Thu Mar 18, 2021 1:58 pm

18 hours ago, rje said:

Would it really be faster? Isn't throughput limited by the IEC-Serial bus itself?

Your answer might be "it depends on the device being emulated", which is true and opens up another set of questions.

So maybe the correct next question is "which IEC device should be handled in non-cycle-exact form?". I see no reason to emulate a D64 when the D81 is superior in every way, for example.

It might not be massively faster, but it will be faster. EG, reading the directory takes more time if emulating a disk spinning in a 1541.

As far as a flash USB drive reader, an ability to work with .d64 files, .d81 files, and to treat the mass storage hierarchy or a part of it anchored on a main root directory as a CMD hard drive would seem to cover it.

A lot of microcontroller based solutions would have the GPIO to be able to work with either the IEC port or parallel access over the User Port, where the IEC would provide plug and play convenience while the device could also ship with the program and device driver files to support faster access on the User Port.

rje · Post by **rje** » Thu Mar 18, 2021 2:33 pm

Regardless of the speed increase, my bet is that it would take the load off of the Pi, allowing a Pi Zero to run without overclocking.

TomXP411 · Post by **TomXP411** » Thu Mar 18, 2021 5:20 pm

I'm still a bit confused, though... what's the point of all this? To make a faster SD2IEC?

The SD card slot in the Commander is faster than an IEC drive can hope to be, since the IEC drive will always have to use software bit banging, and the SD card slot can deliver data to the computer in parallel. So the SD slot is already 8x faster than any IEC drive can ever hope to be.

(see below) You can get up to around 64KB/sec using IEC, but that seems like a lot of work for something few people will need or use.

TomXP411 · Post by **TomXP411** » Thu Mar 18, 2021 5:52 pm

3 hours ago, BruceMcF said:

It might not be massively faster, but it will be faster. EG, reading the directory takes more time if emulating a disk spinning in a 1541.

The SD2IEC running JiffyDOS is roughly 2x as fast as a 1541 running JiffyDOS. As far as I have been able to test, the SD2IEC is the fastest serial storage device available. So yeah, there can be a pretty big speed boost from not dealing with floppy media.

In fact, based on the 300 RPM rotation speed, the 1541 floppy drive is capable of a maximum of about 26KB/s, but the 10:1 interleave drastically reduces the speed, allowing only two sectors to be read per rotation. If my math is right, this limits 1541 media to around 2.4K per second. Also, if memory serves, this is about what I see when using JiffyDOS. Interestingly, even when using the standard Commodore protocol, the SD2IEC is slightly faster, at 650 bytes/sec, compared to 400 bytes/sec from the 1541.

On the SD2IEC, this is more like 8KB/sec, and this cap is due to the 1MHz speed of the CPU.

So using 8KB/sec as our baseline, we can expect 64KB/sec on the Commander X16 using the JiffyDOS protocol.

The good news there is that most of this work has already been done. There's already an Arduino version of SD2IEC (which is largely compatible with CMD hard drive commands). So it's just a matter of adjusting the SD2IEC code to transfer at 8MHz, instead of 1MHz, and write or adapt any of the existing compatible fastloaders.

Again, I'm not sure why @rje seems to be stuck on using the Pi for this... it's not the ideal solution. An Arduino type device is more appropriate, as most of the features of the Raspberry are simply not needed, and Arduino software is simpler to work with than bare metal Raspberry Pi code.

rje · Post by **rje** » Thu Mar 18, 2021 10:58 pm

Here's an ATMega solution: https://github.com/fachat/XD2031

Or, perhaps what Tom was alluding to: https://github.com/Larswad/sd2iec_mega2560

I have a Mega 2560 and a Nano as well, so that's fine, they're just not as familiar to me.

The Arduino IS probably better; for one thing, the voltage levels are more compatible.

There's also https://www.insentricity.com/a.cl/208/C64PiVideo.

Oh, I'm stuck on the Pi because

(1) I "know" it better than other little platforms and

(2) I have some lying around but also

(3) The Pi Zero is just so cheap and

(4) I get stuck on things.