Pico MZ-80K floppy disks (2)

The quest continues! The disk images I found a couple of days ago turned out not to be MZ-80K compatible ones (at least, not with the original drives and SP-6015 BASIC configuration) so I ended up back at square 1.

Reading the SP-6015 Disk BASIC manual (the link goes to a copy from the sharpmz.net site, but without the zip wrapper) it became “clear” that the boot disk was provided with a program to initialise a standard disk.1 I really didn’t think that I was going to ever find anything as poorly translated into English from Japanese as the SP-5025 BASIC manual, but here we are.

The maxim in the Disk Basic world says, ” A glass does not always accept fruit juice.” Well, I suppose so …

Hunting around in the depths of the sharpmz.net site, I found three programs – one to initialise a standard disk, another to change the volume label and one to convert a standard disk into a boot disk.

The boot disk creator initialises track 0 – the bootstrap code that needs to be run after the FD ROM has selected a boot disk, but it doesn’t write any bootable software to tracks 4-14 for the bootstrap program to copy into memory and run.

However, it didn’t take long to write a quick and dirty C program on a Raspberry Pi to copy the tape file of SP-6015 into these sectors.

And …

It didn’t work. The disk started to boot, didn’t copy tracks 4-14 to memory and then printed a corrupt directory listing to the screen.

Further tinkering with the volume number change program (the smallest and simplest program I could find) reveals that some kind of CRC check is performed after a write. This program eventually fails after a number of write attempts with an ER 41, because the CRC check fails. The data has definitely been written to the microSD card ok, but the volume number change program thinks that it hasn’t.

Depending on how I hack the floppy handling code, I can also get it to fail earlier with an ER 54 (disk unformatted) when the volume number is attempting to be read off the disk.

Lots of lovely error messages

Next step – disassembly of the programs I have, to see if I can figure out how the CRC is being generated and checked after a write, and to see what else I’m missing. Probably lots of subtle stuff. For example, track 0 handling seems to be rather different to the way other tracks are managed. Not that surprising I suppose.

Lots more lovely software archaeology and reverse engineering is required!

  1. The SP-6015 manual and other contemporary programs and documentation refer to them as master and slave disks which is somewhat jarring to my 2024 sensibilities. I’m therefore going to adopt the terms boot and standard instead. ↩︎