[Coco] Nitr0S-9 question

[Gene Heskett]

On Tuesday 14 August 2007, Becker, Gary wrote:
>What I am saying is that OS9boot is being written correctly and the
>hooks in LSN0 for this file (DD.BT and DD.BSZ) are correct. I am not
>saying that these values are for the boot track.
>
Sorry, I must have not been paying attention.

>Also nothing is being written into the boot track and the boot track
>bits in the bit map are unchanged. I believe this is the offending code
>in os9gen.
>
>         leax  sectbuff,u
And this is defined as 1024 bytes someplace?

>         ldy   <lsn0+DD.MAP,u	get number of bytes in device's bitmap
>         lda   <devpath
>         os9   I$Read
>         lbcs  Bye

And this is where it looks for the free space in the FAT?  Hoo boy.

Thinking out loud here, the fix would seem to be in the ldy because if its 
track 34, then its never going to need to exceed sectbuff.

But os9 has the ability to allocate anyplace on the drive, and this boot track 
can be anyplace as long as everybody agrees where it is.  However with 
sectbuff being only 1024 bytes, that does place a limit because its 
allocation must be within that buffer.  Simple math will get you the maximum 
possible track number that will still fit in the first 1024 bytes of the FAT.
That would be the 454th track IF the format is 18 sectors/track, but be aware 
that until it gets to the disk driver innards, all disk access in os9 is by 
the LSN.

In the case where its allocating the boot track, I don't believe that os9 
actually checks to see if its already allocated, but just allocates it 
blindly.

I think what I would do is a cmpy, #1024, and if its greater than 1024, then 
just reload it with 1024, let it blindly set those 18 bits in the FAT that 
represent that track, and do an OS9 I$WRITE of the first 4 sectors of the 
FAT.  That alone would allow the boot track to be up to about track 454 if 
DD.BIT=1

>If DD.MAP is greater than 1024 bytes, the read will overfill sectbuff.

And possibly even crash os9.

>This happens with a disk larger than 1024*8*DD.BIT*256 or 2Meg if DD.BIT
>= 1. This is uncommon for floppies, bit not for hard disks.
>
>Someone must have run into this issue in the past.
>
Makes sense, but I can't say as I have personally encountered that.  Or, maybe 
that's why I gave up ever making my maxtor 7120s bootable, I booted it for 
many years from a floppy that switched to /dd by the time it got around to 
running the startup file.

[huge snip]

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Why use Windows, since there is a door?
(By fachat at galileo.rhein-neckar.de, Andre Fachat)