[Coco] OS9Boot position, what?

[Boisy G. Pitre]

On Aug 11, 2004, at 5:33 PM, Robert Gault wrote:
>>
> This is a question of terminology and it would be confusing for anyone 
> not very familiar with OS-9 disk structures.
>
> Dir -e reports the disk sector where a file entry starts not where the 
> program starts. BUtil reports the start of the code for OS9Boot. Let's 
> see how what seems to be the same thing actually is different.
>
> LSN0 at DD.BT (3 byte address) indicates the lsn where the bootfile 
> code starts. When you go to that lsn, you will see as the first two 
> bytes $87CD, the start of the first module in the file.
>
> Dir -e is interested in the file structure of the disk, not the start 
> of programs. When a directory lists an entry, they are all identical. 
> They consists of 32 bytes per entry starting with the ascii entry name 
> terminated with $80 added to the last character and the last 3 bytes 
> as the lsn of the entry's header, the file descriptor. The file 
> descriptor indicates, amongst other things, whether the directory 
> entry is a subdirectory or a file, what the attributes are, the owner, 
> and the date of creation.
>
> So the short answer is that dir -e indicates the file descriptor while 
> BUtil indicates the start of code for OS9Boot. Since the OS9Boot file 
> is always the first file placed on a disk, the code always follows 
> immediately after the file descriptor and the difference between what 
> dir -e and BUtil report will always be +1.
>
This discussion has me thinking of an idea whose time may have come.

The DD.BT field in LSN0 is, as you pointed out, the LSN of the start of 
the bootfile, and NOT the LSN of the FD sector of the bootfile.  This 
is an important distinction, and points to why bootfiles cannot be 
fragmented.

I propose that for the next release of NitrOS-9, we allow fragmented 
bootfiles, and here's how we do it:

The DD.BTSZ field in LSN0 holds the size of the bootfile, in bytes, 
which is pointed to by the DD.BT field.  In no case should DD.BTSZ be 
zero, but except in this case:  if DD.BTSZ == 0, then DD.BT points to 
the FD sector of the bootfile and NOT to the first sector of the 
bootfile data.  This way, the file descriptor sector could be read, the 
size of the bootfile gathered from there, and the fragment list could 
be walked to read the bootfile no matter if it is fragmented or not.

This would require added code to all booters.  I believe that with some 
clever programming, we could fit this extra code in the current $1D0 
size restriction of the booter.

os9gen and cobbler would both have to be modified to take into 
consideration this new method of referencing a bootfile from LSN0.

Thoughts?  Is it worth it?

Boisy