[Coco] Nitr0S-9 question

[Bob Devries]

Gene,

OS9Gen can't be hard coded for $1200 for the boot track, or else you 
couldn't write a boot file to a double-sided disk. OS9Gen must take into 
account whether the disk is double-sided or not, and at the very least, 
double the $1200 to still writte to track 34.

If OS9Gen will write to a hard disk (does it? In the assembler source file I 
have there's a compile-time switch to turn that on or off), then it still 
may get it wrong because the emulator disk image says that the disk format 
(DD.FMT) is $03, which according to my manual means Double-density, and 
Double-sided. This would mean that OS9Gen is likely to try to write the boot 
track starting at $2400. However, it may simply *not* write the boot track, 
if it decides that it isn't writing to a floppy drive, based on the value of 
IT.TYP.

--
Regards, Bob Devries, Dalby, Queensland, Australia

Isaiah 50:4 The sovereign Lord has given me
the capacity to be his spokesman,
so that I know how to help the weary.

website: http://www.home.gil.com.au/~bdevasl
my blog: http://bdevries.invigorated.org/

----- Original Message ----- 
From: "Gene Heskett" <gene.heskett at verizon.net>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Wednesday, August 15, 2007 12:16 PM
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