(This is a game about greyhound racing (!) which I've never seen in person but there was a dog track in Revere MA near where I grew up, it was called Wonderland, and this game was a fancier sequel to some earlier thing I had made.)

So the disk doesn't boot (crashes into apple monitor), and I think it probably should have been a ProDOS disk, but when I try to catalog it with ProDOS I get:

I wanted to image the disk with the fantastic Applesauce USB disk controller by @DiskBlitz. But first I needed an old Disk II drive that was in calibration with a sync sensor installed.

That was its own journey, but once set up, I could use the Applesauce, shown here, with some Mac software to get a detailed copy (with flux metadata, which is fancier than I need)

Here's the Applesauce visualization of the data. The spiral arms correspond to the soft-sectoring. These are DSDD disks with 35 tracks and 16 sectors per track. There's obviously data on here, especially in that middle bit, but not sure yet how much is trashed.

Here's the map of the disk-- good sectors in green, unreadable in red. (35 columns are tracks. 16 rows are sectors.) In decent shape here-- only 8 sectors are bad and they're all in the first track. Hopefully this means some format stuff got corrupted but the game is OK?

Track 0 Sector 0 looks like maybe code. If I click through the data in some of the other track 0 sectors I can see some text. Here's sector 4. References to "SOS" (the Apple III OS) confirms this is (was) a ProDOS disk

Sector 0xA (10) looks like part of the directory listing. PRODOS and BASIC.SYSTEM are the OS and system files. THEYRE.OFF sounds like one of the game images

This looks like the only sector with directory information in it and it's obviously not complete. No wonder I/O Error on catalog. But I need to back up because I don't really know what these sectors and tracks correspond to... They don't look like they're in order

OK, so 5.25" floppy disks are organized into the 35 tracks, and each track has the 16 physical sectors. Each sector is 256 bytes long, for a total disk size of 35 * 16 * 256 = ~140K.

The sector size is, I think, dictated by the Disk II interface hardware. The Apple uses "soft sectoring" which was some clever Woz thing where the drive creates the sectors, they're not fixed on the physical media. The OS (ProDOS here) has to work with these sectors.

I knew this would come in handy eventually

Ok the disk is a ProDOS volume, which is divided into blocks. A block is 512 bytes. Here is a very weird diagram trying to show how a volume is laid out

Blocks 0 and 1 are the loader code, which is some standard stuff to bootstrap the OS on the disk. I assume some of the trashed data on my disk was just boot loader code along with the directory. But I need to figure out which sectors are which blocks. It's not a direct mapping.

This ProDOS book from Apple is VERY HIGH MINDED and speaks only in ProDOS blocks (logical 512-byte structures), but it say how those map to 5.25" disk 256-byte sectors. "Beneath Apple ProDOS" does, though:

This seems insane. But it turns out that the way the hardware wants to write to 5.25" disks (1) you skip over one physical sector between logically contiguous sectors AND (2) one ProDOS block is two consecutive logical sectors

So basically, ProDOS's "block 0" is the data in sectors 0 and 2 from the raw disk, concatenated. "Block 1" is sectors 4 and 6. And so on. The interleaving is done to allow time for correct disk writes and is not only a ProDOS thing. Now we know how to read the Applesauce data.

(Here is the scan of Beneath Apple ProDOS if you want to know more about this level of data ftp://ftp.apple.asimov.net/pub/apple_II/documentation/os/prodos/Beneath%20Apple%20ProDOS_Alt.pdf )

The bad sectors on my disk are 1,2,3,7,8,B,C,D. That leaves us with only one full prodos block (1), one completely missing block (4), and the rest are all half missing half present. Hm.

The boot loader takes up the first two blocks, of which half of one is missing, which explains why the disk doesn't boot. The volume key block is in block 2, and the first half of that block is gone, which explains the volume corruption!

So what else is missing, and what is present? Here's a description of the standard volume overhead. Basically, blocks 0 and 1 are loader code, 2-5 is the volume directory, 6 is a free-block volume bitmap, and block 7 is the first actual file data block

I can copy the lost sector from the boot loader from another disk. The free-block bitmap has its first half present and that's all that matters-- the second half would be all zero anyway. First 256 bytes of the first file is missing. And the volume directory needs reconstruction.

I think I'll be able to figure out the original directory layout. This disk I recall should hold the BASIC program, several images (of racing dogs, natch) and the system files. I see the start of the BASIC program way out here at track $18 (= 0x18 = 24).

I am lucky to have got this one sector of the volume directory-- the second half of block 2. That gives me maybe half the entries and tells me how big the image files are least are, and since those were BSAVE files, they should be fixed size

Here is the plan for the rest of this project:

• Figure out where the files all start and how big they are.
• Create by hand a minimum viable sector 8 (first half of volume key block and volume directory),.
• Copy over the missing loader stuff from somewhere else.
• Let er rip.

Intermission: Feel free to mute this thread (or mute me personally altogether if you prefer). I'm doing this in the spirit of a @a2_4am or @TubeTimeUS or @Foone thread, but this is not my brand as such, so I apologize for the wordiness!

Here's the data from sector A, the remaining directory data (second half block 2). I see I think 5 filenames in there: THEYRE.OFF, PRODOS, BASIC.SYSTEM, STARTUP, WL2.MLLAND..(?) and maybe SSTARTUP? The first is going to be an image. The others are the game and system

This is what one entry in the directory is formatted as. Using this I can figure out what’s up with these files

I decoded the file entries in this fragment by hand, here are some of the file entries:

Or rather, these are all of the file entries in the snippet. We get the "key block" address for each file, its total block usage count, and the "EOF" (length of valid bytes) in the file. The storage type of "sapling" refers to the structure of the file's data...

ProDOS files come in three botanical flavors. Files that fit entirely within one 512 byte block are called "seedlings", and the "key block" is just the actual data. "Saplings" have one indirecting index block and "tree" files have two layers of indirect blocks.

All these files so far are saplings, and I bet all the others are too. "STARTUP" (aka STARTUP.BAS) is the magic name for a BASIC program that ProDOS will automatically run at boot if it finds one. Let's follow that entry to make sure the theory works. STARTUP's key ptr is 00B2.

Block $B2 (=0xB2) is block 178. There are 16 sectors per track, which means 8 logical blocks per track. So this is block 2 on track $16. We know from earlier that block 2 occupies physical sectors 8 and A. Since this is a sapling file, we expect this to be an index block.

Whaddya know. That sure does look like a sequence of other (nearby!) block pointers. I am a little confused as to why each seems to be one byte long and not the two that the spec says (and logic would suggest).

LOL ok. The reason is because they split the lower and upper bytes of the block numbers into the upper and lower halves of the index block itself because they are maniacs

Anyway, so we can ignore the bottom half of these index blocks, they'll be all zeroes on a floppy-size volume anyway. This says the first data block of STARTUP is $B1, which is track $16 block $1, which is physical sector 4, which is, indeed, the start of the BASIC program. Nice.

Scrobbling through some of the BASIC stuff, I can tease out some useful info. A series of BLOAD/BSAVE to ram of the image files, which tells me their names: LIGHTNING, LUCKY.CHARM, CHAMP, TWENTY.BUCKS, JACKSON, and OLD.MOE. The disk volume name is WONDERLAND2.

These six filenames plus the six I know are in the valid directory sector make for (at least) 12 files on disk. Let's see what we can scout out. We'll need the Key block, total block use, and EOF for each file. The key block will be the scouting work.

The first obvious index block is block $8 (starts track 1, sector 0). You might think it would be block $7, but because of how files "grow" from seedling to sapling as they're being written, the index block is usually the second block in the sequence of the file.

We can see clearly there are 16 block indexes in this chunk, meaning this is a 17 block file (16 + this index block). That's the same as the image file we know about for sure, so this is probably an image, key block $8, $0008 blocks, $002000 EOF.

Going sequentially, the next index block appears to be at track 3 sector 4, which corresponds to block $19. Same here, 16 data blocks, etc. I'll go through the disk like this until I hit the start of the known entry at $6E

The set of index blocks that represent key blocks of missing file entries are: $08, $19, $2A, $3B, $4C, $5D. Those will be our six image files. And beyond the end of the last file, SSTARTUP (some other basic program?) the rest of the disk is zeroes. So we have all we need now!

I hand-coded the missing first half of block 2, which contains the volume directory header, and the first six file entries. I'm guessing at the names, and left timestamps blank, but the other data should be correct. It appears to "match" the start of the second half of the block.

Next I copied in the bytes of the second half of the zero block from a known-good ProDOS disk image:

I'm leaving the remaining volume directory blocks empty (zeroes). The volume bitmap is complete as-is in the first half of block 6. The only known missing data is the first half of block 7, which contains the first 256 bytes of the LIGHTNING image. Need to see what happens.

Time to try the patched up disk image! I edited it as a raw DSK file (which required other sector translations I won't bore you further with). I wrote the game on an Apple IIc+, so I'm going to use an Apple IIe emulator scullinsteel.com/apple/e

I'll be damned.

?SYNTAX ERROR

Well, something's wrong. It could have abandoned the game with a bug in it 30 years ago. Or one of the data files could be a problem. Here's the reconstructed disk catalog from inside the OS:

Oh wait. I think the SYNTAX ERROR comes from literally tab switching away from Safari on my Mac, some stray input is getting into the emulator and confusing the old input parsing. If I don't mess with it, I get the prompt OK. Let's see some dogs! (!)

How well did I match up the image files? (And did that work at all?)

Here's Lightning! He's missing 256 bytes of data which I'm pretty sure is showing up here as the random black stripes

Lucky Charm likes cereal and is pretty cute

Champ

Twenty Bucks is... more than you'd owe for the copyright violation here

Jackson has sunglasses. Maybe a Spuds MacKenzie type

Old Moe lol

The names and pictures matched! That was lucky guessing in the reconstruction of the volume directory. Let's make a bet!

$10 on Lightning, as compensation for losing his sector

Here's that THEYRE.OFF image file! Look at them go!

Ah well!

Anyway, it goes on like this. I don't think there's more to do here! It's not a great game, but I haven't seen it in 30 years, give or take, so that's something. If you followed this thread, you're both a crazy person and I appreciate the hell out of you. /END

P.S. This story has since found its way to a lot of enthusiastic and kind-seeming people. If you've made it this far and want to see Old Moe (my favorite) for yourself, here's the disk image, you can emulate it directly. Enjoy!

archive.org/details/wonder…