[Coco] expanding the boot track

[William Astle]

On 2015-10-10 11:28, Dave Philipsen wrote:
> As I mentioned before I've already actually booted the FPGA from SD card. It's just that the bootfile contained the standard modules that continue booting NitrOS9 (2nd stage) using Drivewire. For me, the Boot module is the missing link.  I think I could fit the low level sector read stuff within the 768 bytes but it might be tough to get the initialization code in as well with that limitation.  It is for that reason that I was also thinking about a way to enlarge the Boot file slightly.  Since we are booting from an SD card and new code had to be written for DECB to boot from that card I didn't see the track 34, 18 sectors, and size of Boot module issues so much as hard and fast limitations anymore.

Actually, I think you're missing a simpler solution which doesn't 
require major surgery to DECB/HDB-DOS/etc. and the disk layouts already 
in use. It would still require some minor changes to the Nitros9 
REL/Boot modules.[1][2]

Instead of launching directly into REL when control is transferred to 
the boot track by DECB, it would be trivial to add a few bytes of code 
that load a few additional sectors from, say, track 33. Say you loaded 
an additional 9 sectors at $3800. We can ignore cases where people are 
using DECB 1.0 in this case.[3]

Then, modify REL to probe the area after the boot track and see if there 
is a helper module there. If it finds it, it relocates that module to 
just below where REL itself was loaded and records that fact somewhere. 
Presumably, such a boot module would be expecting the helper module so 
it could easily deal with the relatively small change in memory layout 
it causes.

That would only add a fairly small number bytes to the standard boot 
track header and a bit of code to REL which will certainly not explode 
the boot track.

[1] Of course, properly encapsulating the boot process in Nitros9 so it 
isn't an incestuous relationship between three modules having to know 
exactly where they are in memory would be better. But that's not 
required for this.

[2] Or maybe use Brett's CocoBoot project which would need a driver for 
the SD card, but otherwise should be able to handle it. See 
https://sites.google.com/site/cocoboot2/home for more info.

[3] Nobody with this sort of hardware is likely to be using the old 1.0 
Disk Basic which doesn't have the DOS command.