[Coco] Nitr0S-9 question
Gary.Becker at amd.com
Tue Aug 14 22:42:17 EDT 2007
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.
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
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
byte sectors and 18*256=4608 bytes.
dcheck, unless its been worked on, is I believe hard coded for DD.BIT=1,
may be that anything else is an error. I've not been able to make it
with my newer 1GB seagate drive.
DD.BIT and IT.SAS are two entirely different animals. DD.BIT tells
many sectors equal a 'cluster', and one cluster is represented by one
the allocation map. The size of the allocation map, aka the FAT, does
65535 byte limit, and this is what limits stock os9's ability to handle
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
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
file is opened for writing. You can control file fragmentation with
parameter. With larger drives its quite common to permanently set that
$20, or maybe even to $FF if DD.BIT=1. On larger drives, where DD.BIT
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
file closing routines will correct the FAT to the number of 'clusters'
file actually uses. If for instance, DD.BIT=32 on a larger multigig
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
drive that big.
Describe again, the results you are getting when you run os9gen.
"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
More information about the Coco