Floppy Emulation for the C1P/C4P
Posted: Sat Jul 01, 2017 8:56 pm
There has been some discussion of how to handle floppies drives in the thread on FPGA implementations. I have actually given this a fair amount of thought (although I'm sure there is also a lot I haven't thought of). I have done a bit of digging into the ROM and OS65D code, but not as much as I need to. The main thing that keeps me from digging out my C4P MF at this point is a concern about the floppies and not wanting to burn through their remaining life without some kind of Plan B.
To me, there are a couple of ways to go about this:
1. "Drive" Emulation
One approach would be a solution where the existing floppy drive ribbon cable connects to some other type of device that could accept and provide the I/O of the floppy drive itself.
2. "Board" Emulation
Another approach would be to emulate both the controller board and the drive. This might be easier because you could add some "abstraction" between the emulated floppy controller chip and the emulated drive. The disadvantage is it means hardware, but the advantage would be that even people using systems without floppies could implement the solution on their machines.
3. Patched OS65D Software
I like the DriveWire solution the CoCo users have come up with. It is basically based on a serial interface approach where the drive is emulated on a PC. This makes file transfer to the PC world easier. It also lets you do some creative things. One example would be you could always have a file named "TIME" and one named "DATE" that return the current time and date in what looks like a file on a floppy to the OSI machine. You could also have something like a file named "POUT" that would accept raw text and print it out. You could also handle sound and other things in the same solution framework. This would require patching OS65D, but could probably be done in a way where that was largely invisible--except for the issue of the bootstrap...
4. Hybrid "Floppy" Emulation with Serial Patch
So the boot process is fairly straight forward. Things check to see if the "Track Zero" flag is set by the floppy. If not, it sends the signal to step back down a track and checks again. Once at Track Zero, it waits for a pulse from the index hole and then (after a short pause) reads the track. The first two bytes indicate where the track is to be loaded in memory and once it is loaded control is passed to it. (There is loading the head and some timing details glossed over in that.) If you think about it, that is pretty easy to emulate--always show you are on Track Zero, send an index hole pulse and then a stream of data over an over again until something else happens. The Track Zero image you load could be a modified version of OS65D patched to use a serial port for file storage (similar to DriveWire). Basically you would just keep repeating the sending of the index pulse and your new Track Zero over and over again until the bootstrap was run and sent you some type of response that said it was ready for you to change from "Boot Mode" to "Run Mode".
My thinking started with #1 and then moved to #3 and quickly (from there) to #4. (I have given some thought to how to handle a machine that currently doesn't have a drive controller. I think you could probably figure out a way to do it without resorting to a new ROM, but having a modified ROM would have the advantage of giving you a way of also dealing with a failed drive control chip. If you went down a path similar to DriveWire, I really think a patched ROM would save a lot of time dealing with the "how do I boot?" issue and let you focus on the storage solution itself instead.)
Setting that aside for a minute, I've also thought about the hardware needed.
1. A PC "Server" Solution
This is how DriveWire does it and it offers a lot of advantages. You can control the loading and unloading of disk images on the PC if you want. You can (as mentioned earlier) draw on resources the PC has like a clock or even the Ethernet port or Internet access. The disadvantage is it does likely mean a patched OS on the OSI and having to boot your PC every time you want to use the OSI.
2. Dedicated "Board" Part 1: Raspberry-ish...
Something like a Raspberry Pi could replace the PC in a server type solution. It is small and could even be mounted inside one of the C4P MF drive enclosures while leaving the drive in place (but disconnected--and maybe with a smaller power supply if you didn't want to use a wallwart). My problem is that I can do 8-bit assembly and a bit of PIC assembly or BASIC. I'm comfortable with Linux, but not with C or some of the other programming options. But it feels like the "Track Zero" stuff could be coded without too much trouble.
3. Dedicated "Board" Part 2: FPGA...
I've also thought about an FPGA-based approach. I'll admit that this seems non-trival to me. (But seeing how Leslie can crank out HDL code to emulate a C4P, that is very likely more of a problem with me than with the approach.) For me, this feels like a path I might start down but I'm not comfortable I could finish before frustration overtook me.
What about storage media? SD cards? I've also thought about that. For something PC based, it is a moot point. (You use the computer's hard drive.) But a SS/SD floppy only stored (once overhead was removed) a maximum of 40 tracks with 2 kilobyte each--a total of 80 kilobytes. 1 Megabyte of storage would be about a dozen floppies, so talking about something like a gigabyte just seems to be huge overkill. I'm thinking that 10 Megabytes or so is probably going to be enough for anything I do.
(As an aside, I did a lot of work under OS65U on a machine with around 20 Megabytes and I had split the disk into three areas--the production system most people used (it was a multiuser machine running payroll, AR, AP, and GL), two backups of the production system that I alternated between doing regular backups (once a week at a minimum), and a development system that was pretty much just for me to use. We never came close to running out of space.)
So here is what I've been thinking...
Develop something like DriveWire on a PC using BASIC (cringe if you want), develop a patched boot ROM, and then a patched version of OS65D. I am thinking of something like a set of BIOS calls I could define with the C4P just sending simple commands over a serial link. (The commands could be things like go to a track number, load a track & sector to an address in memory, store from an address in memory to a track & sector, etc.. Probably also some extension like being able to retrieve time and date info, mount a volume (you could always "fake" a file that had a list of off disk volumes and also "fake" a file that was part of all of them that you could load and run to be menu driven on the C4P), etc..
That just "feels" achievable to me--some assembly language programming to patch the ROM and OS65D, some BASIC coding on the PC side, and then probably some BASIC coding back on the C4P side for the utility programs that could leverage a more powerful set of BIOS calls without forcing legacy programs to be aware that they even existed.
Once that was working, it would be logical to try to migrate it to something like a Raspberry Pi to get the PC out of the equation. It would also make sense to try the "emulated" Track Zero boot approach with some hardware to allow the system to boot without having to patch the ROM.
I like the "Have a big vision, but allow for modest victories." approach.
I will add two other things.
The first is that the FPGA implementation of a C4P is changing my thinking some. With it, patching the ROM is trivial. It offers a way for new users who never owned an OSI machine to have one to play with. An entire DriveWire-like solution could be implemented behind the scenes and just leverage a serial port for I/O between the FPGA-based computer and the storage solution.
I will also admit that whoever takes the time to do the first bit of hardware or coding work is the one who ultimately decides on the path. As much as I think I have a good idea, I don't expect anyone else to take and code /build my idea for me. Everyone has different skills (coding in different languages, a comfort with building hardware, knowledge of FPGAs, etc.) and different goals. (As a proof point, I've ordered the same FPGA board Leslie is using for development in part because I know that even migrating his project to another board would take effort and time that I would rather invest in something else.)
Once I have the FPGA machine running, I will probably start tinkering with OS65D as time allows. My initial thought is to have it load via the monitor as a memory load file along with the patches needed so it doesn't hang when it can't discover a disk drive. I'd like to get that to the point of having OS65D BASIC running (without the disk functions).
(A warped part of me wants to also get the editor, assembler, monitor that was part of OS65D running for the sake of nostalgia.)
The idea is to get some discussion going, so I'd be interested in hearing feedback, other thoughts, etc..
Thanks,
Jim
To me, there are a couple of ways to go about this:
1. "Drive" Emulation
One approach would be a solution where the existing floppy drive ribbon cable connects to some other type of device that could accept and provide the I/O of the floppy drive itself.
2. "Board" Emulation
Another approach would be to emulate both the controller board and the drive. This might be easier because you could add some "abstraction" between the emulated floppy controller chip and the emulated drive. The disadvantage is it means hardware, but the advantage would be that even people using systems without floppies could implement the solution on their machines.
3. Patched OS65D Software
I like the DriveWire solution the CoCo users have come up with. It is basically based on a serial interface approach where the drive is emulated on a PC. This makes file transfer to the PC world easier. It also lets you do some creative things. One example would be you could always have a file named "TIME" and one named "DATE" that return the current time and date in what looks like a file on a floppy to the OSI machine. You could also have something like a file named "POUT" that would accept raw text and print it out. You could also handle sound and other things in the same solution framework. This would require patching OS65D, but could probably be done in a way where that was largely invisible--except for the issue of the bootstrap...
4. Hybrid "Floppy" Emulation with Serial Patch
So the boot process is fairly straight forward. Things check to see if the "Track Zero" flag is set by the floppy. If not, it sends the signal to step back down a track and checks again. Once at Track Zero, it waits for a pulse from the index hole and then (after a short pause) reads the track. The first two bytes indicate where the track is to be loaded in memory and once it is loaded control is passed to it. (There is loading the head and some timing details glossed over in that.) If you think about it, that is pretty easy to emulate--always show you are on Track Zero, send an index hole pulse and then a stream of data over an over again until something else happens. The Track Zero image you load could be a modified version of OS65D patched to use a serial port for file storage (similar to DriveWire). Basically you would just keep repeating the sending of the index pulse and your new Track Zero over and over again until the bootstrap was run and sent you some type of response that said it was ready for you to change from "Boot Mode" to "Run Mode".
My thinking started with #1 and then moved to #3 and quickly (from there) to #4. (I have given some thought to how to handle a machine that currently doesn't have a drive controller. I think you could probably figure out a way to do it without resorting to a new ROM, but having a modified ROM would have the advantage of giving you a way of also dealing with a failed drive control chip. If you went down a path similar to DriveWire, I really think a patched ROM would save a lot of time dealing with the "how do I boot?" issue and let you focus on the storage solution itself instead.)
Setting that aside for a minute, I've also thought about the hardware needed.
1. A PC "Server" Solution
This is how DriveWire does it and it offers a lot of advantages. You can control the loading and unloading of disk images on the PC if you want. You can (as mentioned earlier) draw on resources the PC has like a clock or even the Ethernet port or Internet access. The disadvantage is it does likely mean a patched OS on the OSI and having to boot your PC every time you want to use the OSI.
2. Dedicated "Board" Part 1: Raspberry-ish...
Something like a Raspberry Pi could replace the PC in a server type solution. It is small and could even be mounted inside one of the C4P MF drive enclosures while leaving the drive in place (but disconnected--and maybe with a smaller power supply if you didn't want to use a wallwart). My problem is that I can do 8-bit assembly and a bit of PIC assembly or BASIC. I'm comfortable with Linux, but not with C or some of the other programming options. But it feels like the "Track Zero" stuff could be coded without too much trouble.
3. Dedicated "Board" Part 2: FPGA...
I've also thought about an FPGA-based approach. I'll admit that this seems non-trival to me. (But seeing how Leslie can crank out HDL code to emulate a C4P, that is very likely more of a problem with me than with the approach.) For me, this feels like a path I might start down but I'm not comfortable I could finish before frustration overtook me.
What about storage media? SD cards? I've also thought about that. For something PC based, it is a moot point. (You use the computer's hard drive.) But a SS/SD floppy only stored (once overhead was removed) a maximum of 40 tracks with 2 kilobyte each--a total of 80 kilobytes. 1 Megabyte of storage would be about a dozen floppies, so talking about something like a gigabyte just seems to be huge overkill. I'm thinking that 10 Megabytes or so is probably going to be enough for anything I do.
(As an aside, I did a lot of work under OS65U on a machine with around 20 Megabytes and I had split the disk into three areas--the production system most people used (it was a multiuser machine running payroll, AR, AP, and GL), two backups of the production system that I alternated between doing regular backups (once a week at a minimum), and a development system that was pretty much just for me to use. We never came close to running out of space.)
So here is what I've been thinking...
Develop something like DriveWire on a PC using BASIC (cringe if you want), develop a patched boot ROM, and then a patched version of OS65D. I am thinking of something like a set of BIOS calls I could define with the C4P just sending simple commands over a serial link. (The commands could be things like go to a track number, load a track & sector to an address in memory, store from an address in memory to a track & sector, etc.. Probably also some extension like being able to retrieve time and date info, mount a volume (you could always "fake" a file that had a list of off disk volumes and also "fake" a file that was part of all of them that you could load and run to be menu driven on the C4P), etc..
That just "feels" achievable to me--some assembly language programming to patch the ROM and OS65D, some BASIC coding on the PC side, and then probably some BASIC coding back on the C4P side for the utility programs that could leverage a more powerful set of BIOS calls without forcing legacy programs to be aware that they even existed.
Once that was working, it would be logical to try to migrate it to something like a Raspberry Pi to get the PC out of the equation. It would also make sense to try the "emulated" Track Zero boot approach with some hardware to allow the system to boot without having to patch the ROM.
I like the "Have a big vision, but allow for modest victories." approach.
I will add two other things.
The first is that the FPGA implementation of a C4P is changing my thinking some. With it, patching the ROM is trivial. It offers a way for new users who never owned an OSI machine to have one to play with. An entire DriveWire-like solution could be implemented behind the scenes and just leverage a serial port for I/O between the FPGA-based computer and the storage solution.
I will also admit that whoever takes the time to do the first bit of hardware or coding work is the one who ultimately decides on the path. As much as I think I have a good idea, I don't expect anyone else to take and code /build my idea for me. Everyone has different skills (coding in different languages, a comfort with building hardware, knowledge of FPGAs, etc.) and different goals. (As a proof point, I've ordered the same FPGA board Leslie is using for development in part because I know that even migrating his project to another board would take effort and time that I would rather invest in something else.)
Once I have the FPGA machine running, I will probably start tinkering with OS65D as time allows. My initial thought is to have it load via the monitor as a memory load file along with the patches needed so it doesn't hang when it can't discover a disk drive. I'd like to get that to the point of having OS65D BASIC running (without the disk functions).
(A warped part of me wants to also get the editor, assembler, monitor that was part of OS65D running for the sake of nostalgia.)
The idea is to get some discussion going, so I'd be interested in hearing feedback, other thoughts, etc..
Thanks,
Jim