[Coco] Nitr0S-9 question

[Becker, Gary]

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. 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)
Ever notice that even the busiest people are never too busy to tell you
just how busy they are?

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