Commander X16

On 3/16/2022 at 8:23 AM, Lorin Millsap said:

The good news is that even though little work has been done on testing the IEC functionality, on the X16 side it is purely a software issue.  So in theory the various fast loader techniques can all be supported. But yes, since the SD2IEC doesn’t really support running custom code it is the more limited option. 

Hi, Lorin - it's good to see you back. 

Yes, the SD2IEC is limited, in its way, but that is not a limitation for a new system. There's no reason to run arbitrary drive code on the Commander's IEC drive, since we can design the protocol correctly the first time around, and an (hypothetical) 8X JiffyDOS would be more than fast enough to fill main memory in less than 1 second.

I've been experimenting a little with the Raspberry Pi Pico. It's cheap enough in quantity that it would be perfect as the base for an IEC drive, and it shouldn't require too much work to port over the existing SD2IEC codebase. Given the choice between that and having to build a brand new codebase from scratch, this seems like the logical choice.

One appeal of developing C128/1571 burst mode to for the CX16 while adding burst mode to the SD2IEC is the incremental development paths offered ... whether the CX16 implementation is working correctly can be tested by hooking up a 1571, and whether the burst mode implementation for the SD2IEC is working can be tested by hooking it up to a C128. Only when both are known to be working do you hook the firmware-upgraded SD2IEC to the CX16 to see what speed it attains.

And the work on the the firmware-upgraded SD2IEC side can be done without being affected by the bottleneck of real existing CX16's.

As long as the CX16 connects the correct IEC lines to the correct VIA hardware serial port pins, it ought to run as fast as the microcontroller can bit bang the burst mode, so much faster than existing C64 compatible fastloaders like JiffyDOS.

I currently like my "Meta-Plan #3" below.

 

"Less Relevant" Meta-Plan #1.  Build it on something else first.

* Implement IEC controller code on a RPi Zero or Pico or ATMEGA or hardware-of-choice.

* Test it against an SD2IEC or a real Commodore drive.

* Not completely sure what this would accomplish, except for being good practice.

 

"Not Testable" Meta-Plan #2.  Build in the code.  

* Implement IEC in the X16 emulator.  Write a socket adapter layer, loosely coupled, to emulate the lines, perhaps (?).

* Implement an IEC soft-device from VICE or SD2IEC or whatever.

* This would get code into the KERNAL, albeit emulated.

* But this is not testable without heavy lifting on something like VICE.

 

"Not Fast Enough" Meta-Plan #3.  Put the X16 Emulator on a Raspberry Pi.

* Port the X16 emulator to the RPi or equivalent.  https://snapcraft.io/install/x16emu/raspbian

* Write the IEC code on the X16, using a GPIO adapter layer for physical lines.

* Test with SD2IEC or a physical drive etc... if fast enough...

 

^^ I like this one, except for likely speed problems.

 

 

On 3/19/2022 at 7:22 AM, BruceMcF said:

* Whether the CX16 implementation is working correctly can be tested by hooking up a 1571,

* Whether the burst mode implementation for the SD2IEC is working can be tested by hooking it up to a C128.

* [When] both are known to be working, [then] hook the firmware-upgraded SD2IEC to the CX16 to see what speed it attains.

 

The X16emu builds very nicely on the Raspberry Pi Zero.  When I get a free moment, I'll hook the pi up to my monitor and see if it has enough oomph to render the screen.  I suspect I'll have to move to the RPi 3.

 

 

On 3/21/2022 at 9:48 AM, rje said:

...



"Not Fast Enough" Meta-Plan #3.  Put the X16 Emulator on a Raspberry Pi.



* Port the X16 emulator to the RPi or equivalent.  https://snapcraft.io/install/x16emu/raspbian

* Write the IEC code on the X16, using a GPIO adapter layer for physical lines.

* Test with SD2IEC or a physical drive etc... if fast enough...



^^ I like this one, except for likely speed problems.

Yeah ... a working burst mode wouldn't have speed problems, because it adapts to the speed of the slower of the two devices, but burst mode is negotiated over "regular" IEC, which needs to be "fast enough".

Seems like a ZoomFloppy would be a useful starting point for the updraded-SD2IEC side, since from googling around it seems that ZoomFloppy supports burst mode, so it wouldn't be necessary to obtain a Commodore 128 to test whether the burst mode was working correctly on the "IEC storage device" side of the system.

The idea of loading fastloader code into a device seems to be adopting a solution to a different problem ... how to get faster performance between a C64 and a 1541 disk drive. If the device on the other side of the IEC cable is an SD2IEC type device, it makes much more sense to do an incremental extension of its firmware than to have to load fastloader code fresh with every reboot.

End of Week Edit: Over the week, I saw that Shadowolf has already done a burst protocol SD2IEC mod: Fast Serial for µIEC.

I might also just look at pi1541 after all.    If the exact emulation part isn't tightly coupled with the signaling logic then maybe I can rip out the 1541 specifics and have an IEC device there.

Rasbpian on a Zero of course isn't fast enough.  But I'm trying things out.

 

 

On 3/21/2022 at 4:21 PM, rje said:

I might also just look at pi1541 after all.    If the exact emulation part isn't tightly coupled with the signaling logic then maybe I can rip out the 1541 specifics and have an IEC device there.



Rasbpian on a Zero of course isn't fast enough.  But I'm trying things out.



 

Primarily, the pi1541 works by emulating the 1541 hardware and then running the 1541 ROM on top of that, so the signaling is written in 6502 assembly.

Still, you can look at https://github.com/pi1541/Pi1541 to see what is included. There may be some support for non-emulated IEC drives now... I know Steven has enhanced it a lot since its initial release. 

Also, the SD2IEC is the most complete collection of IEC code that I'm aware of, especially since it includes various fast loaders. This really is the place to start for writing IEC code for microcontrollers.

The source is available at https://sd2iec.de/

I've downloaded and started browsing the SD2IEC codebase, and I agree that it's a wealth of goodness.

I'm still wading through it all.  At some point I'll grok it enough to try some things.