[Coco] OS9Boot position, what?

[Bob Devries]

Sounds great to me Boisy. That's the way OS9/68K does it. Works very well.
With OS9/68K, the os9gen needs to be *told* to allow a bootfile to be
fragmented. Will you need to rewrite os9gen to do this, too?
--
Regards, Bob Devries. Dalby, Queensland, Australia.
Faith isn't faith until it's all you're holding on to.


----- Original Message ----- 
From: "Boisy G. Pitre" <boisy at boisypitre.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Thursday, August 12, 2004 9:19 AM
Subject: Re: [Coco] OS9Boot position, what?


>
> 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
>
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>