A Multi-Format Cross-Platform Floppy for 5.25" Floppy Day
Something I’ve wanted to do for several years is to create a cross-platform 5.25” floppy, one that could be used on two different incompatible computer systems. Not by making a “flippy” disk with data for one system on one side and data for the other on the back, but instead with everything all on a single side. This may seem like it would be trivial, but back when the 5.25” floppy was king every computer system had its own idea of how data would be encoded at a very low level. You couldn’t take a disk written on an Apple II and copy files from it on a Commodore. Back then a computer was an island, and getting off the island and sharing data with other computers wasn't exactly easy. While the technical possibilities of doing such a thing seemed like they were probably within reach of what I could do, I knew that such a project would still take quite a lot of time and so it has remained on my ToDo list of art projects for many years.
Bring in the Victor
A few months ago I got a standing desk and after setting it up and having a completely blank surface to work on, I thought I would tackle another project that had been lamenting in a closet for some time. I didn’t have a lot of hope of making much progress on it, but it seemed like it was a good time to dig into it a little. The project? Seeing if I could make bootable 5.25” media for a somewhat obscure computer known as the Victor 9000 when I have no disks for it at all. Why would making a bootable disk for it be a project? Well I’m glad you asked!
The Victor 9000 was created by Chuck Peddle of MOS and Commodore fame. Because of the heavy Commodore legacy, the Victor borrows a lot of ideas from Commodore. One of them is that it uses variable speed floppy drives that use twice as many tracks as floppy drives found in other computers and can put 600k on a single side of a floppy at a time when others were doing less than 200k. Because of the uniqueness of the drives though, there are pretty much no archives of bootable disks on the internet. And even if you find a copy of one, it’s impossible to write the disk image back out to floppy because of the need for special hardware.
After spending several days learning more about how the floppy drives work in the Victor and finding what seemed like a good dump of one of the DOS disks, I set about seeing what I would need to do to create an actual physical image. The images online are just direct reads of the magnetic patterns on the disk, they haven’t been decoded. To write them back to a real floppy, the data would need to be decoded, and then encoded again into a clean digital waveform. I was able to find software to handle the decoding, but nothing that could do the encoding.
I set about writing an encoder that would take sector images compatible with MAME as input. I chose to have it create files in SuperCard Pro format because of the work done by Mark Blair and being able to build on top of the great Python tool he made. While I was able to test the output with a couple of other Victor decoders, I was unable to test it on real hardware because it turns out my Victor has hardware problems. I ended up having to set the Victor project aside, but I realized that the program I wrote for encoding could be re-used for my multi-format cross-platform floppy project.
Please Pass the Floppy
While I had gained some experience with converting the high level sector information back to magnetic patterns, it was only for one platform, and it hadn't truly been tested. The next step was learning all about how the three computers I wanted to use for my demo encoded disks. And to make it more of a challenge, of course each had a completely different method.
First was figuring out the details of how the Apple II GCR was encoded on floppy. Back when the Apple II+ was the only computer in the house my dad bought both Beneath Apple DOS and Beneath Apple ProDOS so I had the best reference available on Apple II disk encoding. Even so, it took several days to work through why what I was writing to disk couldn't be read by the Apple II. I had issues with not enough sync bytes, the sector number written on the header isn't the number that DOS or ProDOS refers to it as, and even calculating the checksum was tricky. Spent a lot of time writing out disks, trying to get the Apple II to read them, messing around with the hex editor in Copy II Plus to compare what I thought I was writing vs. what I was reading, and even made a lot of use of my Applesauce to examine the physical sectors complete with address marks. It took a working through a lot of mistakes but soon I was able to take a .do image, convert it to SuperCard Pro format, write it to disk, and my Apple II was happy to boot from it.
I chose to tackle the Commodore 1541 encoding next. This was actually not too terribly hard since I had already done the bulk of the work when working on the Victor disks. The 1541 doesn't change the speed of the drive, but does use shorter bit timing on the outer tracks, very much like the Victor. Mostly all I needed to do to get Commodore disk encoding working was change the timing table and the address marks.
Finding documentation on how the Atari encodes disks was a lot harder. I was able to find that it used FM encoding, but finding low level details like I was able to do for both the Apple and Commodore was not so easy. It seems that not as many people were that interested in doing strange things with disks, perhaps because low level disk manipulation isn't as programmable as either the Commodore 1541 or the Apple II?
After much searching through forums I was able to find a program called a8rawconv, which for some reason isn't on any source repository and the latest version is buried deep in a comment thread. With a8rawconv I was able to directly convert a sector image into a physical disk, giving me a known working disk to compare to while I worked on my own program.
To get anywhere with the Atari disks I ended up having to write my own analyzer because I could not figure out why the disks I was making absolutely would not work. When I tried reading in the working disk the checksums all seemed wrong, yet the disk booted fine on my Atari 800. When I tried my own disk, it never worked, even though the checksums were correct. Eventually I figured out that the data bytes had to be inverted before writing to disk by doing an XOR with 0xFF. But only the data bytes were inverted! So very strange.
With the ability to create disks for three different platforms, the next step was figuring out what sectors I would actually need and which tracks they had to be on. Would I run out of room on a track supporting one computer and have to hack the DOS for another one to move things to a non-standard location? Would I need to build more tools to let me shift files around to avoid conflicts from another foreign file system?
Both the Apple II and the Atari 800 are capable of booting from floppy, and both systems expect to find their boostrap sectors on track 0. That meant I was going to have to be able to combine Apple GCR and Atari FM sectors on the same track. The Commodore 64 doesn't need to load bootstrap sectors from floppy, it has the ability to access floppies as soon as it's turned on.
ProDOS uses the bulk of track zero, leaving only about an eighth of the track available for other things. Since I was concerned about how much space I would need for the Atari bootstrap, I worked on whittling down what ProDOS wanted on track zero. First thing to go was block 1, the SOS bootloader, only needed to boot an Apple ///. The next thing I tried removing was the two extra directory blocks. I didn't really need them since I wasn't going to have more than 12 files on the disk. The ProDOS bootloader was hardcoded though to load the extra directory blocks and if I didn't put them on the disk, ProDOS wouldn't load. So I patched the bootloader and changed it to only load the first directory block. I also found that ProDOS didn't need to load the available block bitmap, and I was able to get ProDOS down to using just four sectors on track zero, leaving well over half of track zero for other operating systems.
One thing that all three systems had in common was using a bitmap to specify what areas of a disk are in use. I took advantage of that and used a hex editor to go into the Apple II image and mark track zero as in use, to prevent the 2 spare sectors from getting used as I added files to the disk. For the Atari image I did the same thing, and marked all the tracks that ProDOS and Commodore had already claimed as in use. In the end I only needed to have mixed sector encoding on track zero since I was able to exclude entire tracks from the different systems.
I'm sure you want to try this for yourself to prove it wasn't a trick. The image I made can be downloaded below, you'll need to have a SuperCard Pro in order to write the image.
I also think that there may be other uses for the crazy tool I made, so I've made the source available for that too.