213 Followers
45 Following
27 Posts

Veteran software engineer that plays with retro computers and air-cooled Porsches. Creator of the Applesauce FDC hardware/software for preserving our digital past.

https://applesaucefdc.com

Patreon: http://patreon.com/diskblitz
Ko-fi: http://ko-fi.com/diskblitz

John Morris' amazing Applesauce floppy disk controller just recovered one of the very first computer programs I ever wrote, from a very old floppy disk. I'm over the moon to see this running!

I've digitized thousands of floppy disks using Applesauce, but am especially grateful for this one.

I have re-opened the Applesauce store after an extended holiday break. Apple 3.5 Sync Sensors are back in stock. And there is a new Naked Mac Drive Adapter (very limited supply) that allows you to connect bare 800K and SuperDrives directly to Applesauce without needing the A9M0106 enclosure. https://applesaucefdc.com/order/
Applesauce Order Form – applesauce

For folks that like pics, here is the magic Nabu PC sequence that allows it to recognize its own disks. See the thread for more details.
Well, we now know what it takes to makes real working Nabu PC disks. But it also leads us to a few problems. There are no current sector-based disk image formats that can properly contain these disks as none of them can deal with the special sequence. All of the current IMD files done with ImageDisk that were thought to be good images are actually missing the sequence because the tool never knew to even look for it. Although I can likely add support for generating the needed sequence for these disk when writing. We currently are going to need to be flux imaging these disks only. And there are a limited set of tools that can handle reading and writing the disks.

Turns out that it isn’t a key to unlock a DPB. It actually is a complete DPB. It is laid out like this:

A1 A1 <4e x 12> <4 bytes that are maybe volume/disk id> 00 <DPB>

And it translates to:

spt = 40 ;Number of 128-byte records per track
bsh = 3 ;Block shift. 3 => 1k, 4 => 2k, 5 => 4k....
blm = 7 ;Block mask. 7 => 1k, 0Fh => 2k, 1Fh => 4k...
exm = 0 ;Extent mask, see later
dsm = 194 ;(no. of blocks on the disc)-1
drm = 95 ;(no. of directory entries)-1
al0 = 224 ;Directory allocation bitmap, first byte
al1 = 0 ;Directory allocation bitmap, second byte
cks = 1800h ;Checksum vector size, 0 or 8000h for a fixed disc.
off = 1 ;Offset, number of reserved tracks
psh = 3 ;Physical sector shift, 0 => 128-byte sectors
phm = 7 ;Physical sector mask, 0 => 128-byte sectors

If you don’t know what any of that means, then just trust me that it matches how the disk structure is organized.

Ok, so what now?

The Nabu runs CP/M and is failing to boot, so what would be needed to successfully boot the disk? CP/M has a LOT of variants. Like a stupid amount of them. They are all organized a bit differently, but have very similar structures. To be able to understand them, you kind of need a key that describes the organization, and that is the DPB (Disk Parameter Block). This isn’t typically stored on disks, but more often in computer firmware. But our disks without the special sequence aren’t being recognized, so could this perhaps be some form of key?

There is a special sequence of data written to track 0 in what would normally be out-of-band data. In checking the 2 known good disk images, the 2 sequences looked like this:

A1A14E4E4E4E4E4E4E4E4E4E4E4E190F2D1A002800030700C2005F00E0000018010003074E
A1A14E4E4E4E4E4E4E4E4E4E4E4E0E0D2F00002800030700C2005F00E0000018010003074E

That is a lot of matching bytes to be a coincidence. So, next was to figure out what the heck this sequence is supposed to mean.

What could this possibly mean? I needed to go one level deeper into the disk encoding. MFM bytes aren’t 8 bits long in reality, but are instead 16 bits. A funky mix of clock and data bits with an added layer of rules that make it a bit weird to look at when compared to FM encoding. When I was analyzing the gaps on track 0, I did notice a weird pattern in the gap between the index and sector 1, but just kind of assumed that it was a bit of mess as can be fairly common. In here I noticed a telltale MFM marker (which is special in that it breaks the MFM rules) that is used to synchronize bit streams so that it can be aligned to proper byte boundaries. And the is when the skies opened up and the sun shone in.
This of course leads us to the assumption that there must be some out-of-band data coming into play in the boot process. Not something you really see very often, but the only thing that made any sense as to why the A2R would work but not the IMD. Since we knew that we could write disks that successfully booted, I built several custom images in order to try to rule out various techniques that could be used to try to detect whether a disk was one format or another without ever involving actual sector data. All of them struck out. I then built an image that preserved all of the out-of-band bytes, fairly confident that it would work. And it also failed.
After getting an A2R flux image of a working disk, I did a bit of looking at the disk and the flux level and it seemed pretty normal. Plain old IBM sectored disk. Double-density MFM disk with 5 x 1024 byte sectors across 40 tracks. Nothing crazy. He had tried writing out an IMD image previously and it failed to be recognized as a Nabu disk, but instead the PC thinks that it is a bad Osborne disk. Really weird, but ok. He then wrote out the A2R file and the disk booted up just fine. I compare the A2R and IMD files and the sectors match 100%. Ok, this is gonna be fun.