[no subject]

- The boot sector code takes a copy of the Disk ][ controller firmware
and patches it to create a "read block" subroutine, effectively
synthesizing a read-only ProDOS block driver for the Disk ][ controller.

- The Disk ][ controller firmware doesn't support seeking (apart from
recalibrating to track 0). The seek code comes from the ProDOS boot
block, possibly in the second half as it is not needed until the PRODOS
file is to be loaded.

- If booting from a device with a ProDOS block driver in firmware, the
Disk ][ support code is not needed. I expect a stub block driver is set
up in the same location, so the rest of the code just needs to call a
"read block" subroutine, which deals with the specifics of the boot
device.

Through experimentation, I found that the boot code only supports a
PRODOS file which has the "sapling" structure, with a single index
block. I tried creating a dummy PRODOS file which was 512 bytes or
shorter, and it didn't work. 513 bytes was sufficient (which made it 3
blocks instead of 1).

It still amuses me how much functionality a good assembly language
programmer can fit into a small amount of space, compared to modern
behemoths.

(I have a fair amount of experience in this area, having written or
patched firmware in I/O cards, written a ProDOS clock driver, heavily
tweaked Birds Better Bye to add more features while still fitting within
768 bytes, and my job used to consist of assembly language programming
in relatively tight spaces.)

-- 
David Empson
dempson@actrix.gen.nz