Disk BlitzThere has been a lot of buzz around the Nabu PC from Canada recently. Being that I had never heard of it before, I wasn't particularly interested. Then I saw some chatter about being able to image the disks, but they couldn't be written back to disk successfully. So of course being the masochist I am, this suddenly became very interesting to me. So I poked @MrGoodBits who was seemingly in the middle of the Nabu investigation and that had access to working disks, a Nabu, and an Applesauce.
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.
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.
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.
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.
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?
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?
crazyc@diskblitz That has a wd179x fdc right? Could never do with with a upd765.
@crazyc Yup, a WD1797 I believe.