[Coco] expanding the boot track

[Dave Philipsen]

Just another note: I like your idea about eliminating the 'incestuous relationship' between these three modules too. It's almost like they could be all lumped together or at least linked in some way so that they are all assembled together at the same time and Rel relocates them to exactly the right spot to align the vectors at the end of the 64K memory map.

I think if they were assembled together like that then the assembler would be able to provide the correct references so that each module would know where the others were.

Dave Philipsen

> On Oct 10, 2015, at 1:10 PM, William Astle <lost at l-w.ca> wrote:
> 
>> 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.
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco