Great analogies, colleagues!
We need to remember that the 64KB ROMs assume use of a 400KB floppy drive for booting. 64KB ROMs also include a driver for the Lisa Widget drive, which we can ignore -- credit to Mac128 for this particular fact. So the 64KB ROM startup sequence was based around finding 400KB floppy boot blocks. No error checking, no file system checking, just look for blocks at a geometrical point on the disk. Hence the ability to discover boot blocks on an 800KB floppy disk before collapsing in a heap.
When using the HD20, we have to boot from floppy disk, load the HD20 INIT, and then the 512K boots from the HD20. To the best of my knowledge, all third party serial port drives worked in a similar way.
But if designing a disk for the 128K or 512K today, are we stuck with the same limitations? Is it feasible to create a disk controller that emulated a 400KB floppy with appropriate Mac system software, which patched the ROM before booting from a disk with different geometry to a 400KB floppy?
We need to remember that the 64KB ROMs assume use of a 400KB floppy drive for booting. 64KB ROMs also include a driver for the Lisa Widget drive, which we can ignore -- credit to Mac128 for this particular fact. So the 64KB ROM startup sequence was based around finding 400KB floppy boot blocks. No error checking, no file system checking, just look for blocks at a geometrical point on the disk. Hence the ability to discover boot blocks on an 800KB floppy disk before collapsing in a heap.
When using the HD20, we have to boot from floppy disk, load the HD20 INIT, and then the 512K boots from the HD20. To the best of my knowledge, all third party serial port drives worked in a similar way.
But if designing a disk for the 128K or 512K today, are we stuck with the same limitations? Is it feasible to create a disk controller that emulated a 400KB floppy with appropriate Mac system software, which patched the ROM before booting from a disk with different geometry to a 400KB floppy?