[Coco] Nitr0S-9 question

Tue Aug 14 23:16:23 EDT 2007

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.

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

If DD.MAP is greater than 1024 bytes, the read will overfill sectbuff.
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.

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com]
On Behalf Of Gene Heskett
Sent: Tuesday, August 14, 2007 10:00 PM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] Nitr0S-9 question

On Tuesday 14 August 2007, Becker, Gary wrote:
>In the default configuration, I format the drive to just under the 132M
>limit to make sure the cluster size (DD.BIT) is set to 1. This works
>correctly and when I examine the disk with an editor, everything checks
>out as I expect it to be. Then when I run os9gen, it appears to create
>the OS9boot file correctly and sets DD.BT and DD.BSZ correctly. 

Humm, but DD.BT and DD.BSZ are not the initial boot track, they are the 
location, and size of the os9boot file, a different animal again.

If you fire up a copy of dEd, and goto the sector represented by DD.BT,
you 
should see what used to be os9p2 in this sector, I think its now krnl2
or 
some such.  Do you?  It seems to me that a read error (244) would be odd
at 
that point.  You might also look at the root directory, where a link to
the 
os9boot file should also exist if it has been written.  Also, check the
FAT 
to make sure the bits DD.BT and DD.BSZ represent are set.

>But then 
>it gives an error 244 (read error.) When I look at the track 34, there
>is no data and the allocation bit map for this track says it is
>available. So it appears that it fails writing the boot track. I can
get
>os9gen to work just fine with a disk image that is the same size as a
>3.5 inch floppy; but not with the much larger drive.
>
>I do not have a problem using track 34, 68, 128, or 129. I am now
>starting to work on a modified os9gen to handle this issue. I have a
>couple of ideas.
>
>
>-----Original Message-----
>From: coco-bounces at maltedmedia.com
[mailto:coco-bounces at maltedmedia.com]
>On Behalf Of Gene Heskett
>Sent: Tuesday, August 14, 2007 9:16 PM
>To: CoCoList for Color Computer Enthusiasts
>Subject: Re: [Coco] Nitr0S-9 question
>
>On Tuesday 14 August 2007, Becker, Gary wrote:
>>I do not believe it.sas and dd.bit have any connection. But it really
>>does not matter. I am trying to write the boot track to track 34 on a
>>disk image using os9gen. I believe because the allocation bit map is
>>greater than 1024 bytes, os9gen is failing. By using the cluster size
>>option in format when I create the image, dcheck says the drive file
>>system is not valid.
>>
>>I guess I will have to create my own utility to do what I need done.
>
>Personally, I believe you may be barking up the wrong tree.  The boot
>track,
>nominally track 34 on a floppy, or tracks 128 or 129 on a B&B system,
is
>
>absolutely fixed at $1200 bytes for its size, which is a full track of
>18 256
>byte sectors and 18*256=4608 bytes.
>
>dcheck, unless its been worked on, is I believe hard coded for
DD.BIT=1,
>so it
>may be that anything else is an error.  I've not been able to make it
>work
>with my newer 1GB seagate drive.
>
>DD.BIT and IT.SAS are two entirely different animals.  DD.BIT tells
>rbf.mn how
>many sectors equal a 'cluster', and one cluster is represented by one
>bit in
>the allocation map.  The size of the allocation map, aka the FAT, does
>have a
>65535 byte limit, and this is what limits stock os9's ability to handle
>hard
>drives with DD.BIT=1, which in turn limits the drive to a hair over 132
>decimal megabytes.  If DD.BIT=2, then 256 binary megabytes can be
>handled.
>For DD.BIT=4, then 512 megs, 8=a gigabyte etc etc.
>
>IT.SAS is the value, in 'clusters' that will be initially requested
when
>a
>file is opened for writing.  You can control file fragmentation with
>this
>parameter.  With larger drives its quite common to permanently set that
>to
>$20, or maybe even to $FF if DD.BIT=1.  On larger drives, where DD.BIT
>might
>be 8-16-32-64, then this becomes much less important because DD.BIT
will
>
>expand the sector counts in the cluster for you.
>
>But this doesn't mean the file will take up that much storage space as
>the
>file closing routines will correct the FAT to the number of 'clusters'
>the
>file actually uses.  If for instance, DD.BIT=32 on a larger multigig
>hard
>drive, then it is true that a 1 byte file will be assigned 32 sectors
>minimum.  That becomes pretty much a machs nichs point though when you
>have a
>drive that big.
>
>Describe again, the results you are getting when you run os9gen.

-- 
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)
Someday your prints will come.
		-- Kodak

--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco