[Coco] Nitr0S-9 question

[Bob Devries]

As far as I'm aware, OS9Gen cannot write a boot track to a hard disk (or an 
image of a hard disk). Even the B&B system used a special program for this 
If I remeber correctly.

--
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: "Becker, Gary" <Gary.Becker at amd.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Wednesday, August 15, 2007 1:16 PM
Subject: Re: [Coco] Nitr0S-9 question


>
> 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
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco