[Coco] Glenside IDE booting problems

Fri Dec 3 18:47:28 EST 2010

On Friday, December 03, 2010 05:53:33 pm Don Johnson did opine:

> On 2010-12-03, at 5:00 AM, Robert Gault wrote:
> > Don Johnson wrote:
> >> Okay, so this is good stuff, and useful as well.  I ran the ident
> >> command as you suggested and compared it to my other system disks
> >> that I created that work, but without the hard disk drivers and
> >> descriptors.  The lists were the same except for the CC3HDisk and H0
> >> modules existing in the non-working System Disk, and not there on
> >> the working System Disks.  From other responses I realized that the
> >> DD module was not there before because I did not add it during the
> >> Config process, so I went back and did the same steps over again. 
> >> Here is the list of modules in the newly created OS9Boot file (that
> >> still does not work so for sanity sake at least I'm consistent).
> >> 
> >> 17	$C0		$47B370	.	OS9p2
> >> 12	$C1		$FD1FEA	.	IOMan
> >> 67	$C0		$0B2322	.	Init
> >> 
> >>   5	$11		$1006FE	.	CC3Go
> >>   9	$C1		$D28AFD	.	Clock
> >> 
> >> 28	$D1		$EFBE13	.	RBF
> >> 
> >>   5	$E1		$02BF2A	.	CC3HDisk
> >> 
> >> 82	$F1		$0C9F6C	.	H0
> >> 
> >>   9	$E1		$759161	.	CC3Disk
> >> 
> >> 82	$F1		$FC1918	.	D0
> >> 82	$F1		$9F46Ca	.	D1
> >> 82	$F1		$E6B118	.	DD
> > 
> > OK, while I agree that a switch to NitrOS-9 is advisable, here is what
> > you can start with for testing purposes. Do not place cc3hdisk and H0
> > after RBF. Use the exact order of modules found in your most recent
> > working OS9Boot list with cc3hdisk and h0 AT THE END. This will avoid
> > the "boot order bug" that Gene referred to. Even if there might be a
> > problem with the location of cc3hdisk and h0, you should at least be
> > able to boot from the floppy without hard drive access.
> > 
> > To rephrase, you must do this enhancement step by step so that only
> > one thing is changed at a time or you will never discover the
> > location of the actual problem. So, your new boot disk must be
> > identical to the latest working boot disk but with cc3hdisk and H0 at
> > the end of OS9Boot. Tell us if you can get at least this far and boot
> > OS-9.
> > 
> > It will be crucial that your H0 descriptor match the capabilities of
> > your hard drive. If the descriptor is wrong, you will never get the
> > hard drive to work. What utilities are provided with the Glenside
> > package to read the hard drive capabilities and create a custom
> > descriptor?
> 
> Well the Glenside disk includes a shareware copy of EZGen to help add
> the modules to the OS9Boot file, and a couple other programs that will
> detect the ide drive and recluster it if necessary.  I don't see
> anything that will customize the descriptor.
> 
> However, I did as you suggested and added the CC3HDisk and H0 modules to
> the end of a fresh copy of my favourite System Disk (startup
> modifications and white on blue windows included) that I know works,
> and the OS9 booted up off the floppy just fine, but when I tried to use
> the Glenside disk included lformat program to format the hard drive I
> got a #221 error (module not found).  I then moved the two modules up
> the list to just behind the disk drive descriptors, and once again the
> OS9Boot from the floppy worked.  This time using the lformat program
> found my hard drive and formatted it (4.3 GB hard drive formatted to
> 2062 MB, so not bad).
> 
My guess is that it was not compensated for the sector size diff, using only 
the first 256 bytes of each sector, a common practice since we cannot do the 
low level formatting to any drive newer than MFM required to switch it from 
a 512 byte sector to a 256 byte sector.

> Not believing it actually worked I did a dir /h0 on it and it showed me
> nothing (empty of course but no errors).  I copied a couple files off
> the Glenside Disk to /h0 and another dir  /h0 call showed they were
> there.
> 
> My success was only short lived though.
> 
> After I copied the files over to the hard drive I decided to reboot it
> one more time, and this time it failed.  Now, it always seems to fail
> just when it is going to ask me to enter the date, so maybe it is this
> clock module issue that Gene mentioned.  Also, because I did not adjust
> the h0.dd in any way, and it failed after the hard drive was formatted,
> maybe that is a problem?

Doubtful, since format AIUI, uses that descriptor as its marching orders 
when it formats the disk.  However, you might bear in mind that this is
a high level format only, none of these drives have been capable, without 
extensive factory tooling, of being low level formatted, usually just 
silently returning no error when it is attempted.  So you are stuck doing 
basically nothing but writing the file system data tree to the drive, 
followed possibly by a surface scan to see if every sector it claims (in 
the descriptor) can be read without error.  The read data is thrown away in 
that case as its only interested in a successful read regardless of the 
data read.

However, a 2+GB formatted drive far exceeds os9's limit for 1 sector per 
cluster use accounting in the FAT.  That limit is exceeded at just over 134 
(decimal) megabytes, at which time one can set the cluster size up by a 
power of 2, to 2, 4, 8, 16, 32, 64 etc.

I am currently using a cluster size of 4.  From the minicom screen:
{t2|07}/DD/NITROS9/3.2.9:free /dd       

"Heskett's Big Disk" created on: 2001/09/11
Capacity: 1,948,559 sectors (4-sector clusters) 
1,591,860 free sectors, largest block 1,559,108 sectors 

{t2|07}/DD/NITROS9/3.2.9:

So obviously I have lots of free space, that largest block is 399,131,648 
bytes.

This limitation of the cluster size vs disk size is because the FAT table 
on the drive cannot occupy more than 65,535 bytes.  With each bytes bits 
representing one sector, you are out of space in this table at a partition 
size of 134,215,680 bytes.

> Any suggestions on how I can modify the device descriptor?
> 
Do you have dmode?  If so, dmode may be able to decipher things.
Before it has a chance to die, see what a "demode /h0" returns.
It will not return the cluster size, only the current 'free' does that, but 
the rest of its output will be enlightening.  Please copy that to us if you 
can.

In my trials of the rbf.mn and its ability to handle multi-sector clusters, 
I tested it only on floppies, and only to a cluster size of 8, but in my 
work on rbf.mn at the time about 15 years ago, restoring some functions one 
of Kevin Darlings Christmas presents removed, I saw no reason to think that 
once it worked at 2, 4, and 8, that it would fail with even higher values 
as long as they were a power of 2 value.

In your case, the cluster size would have to be 16, and the resultant FAT 
mapping would occupy 0xCD0A bytes of the available 0xFFFF bytes in the FAT.

This also has interesting side effects on the value of the device 
descriptors 'sas' value.  I have set mine to $20 as it reduces the number 
of entries in the FD.SEG table, preventing overflows there for most file copy 
operations although I will set it to sas=FF if I have a very large file to 
download.  The file closing cleans up after itself in any event, so its no 
biggie compared to the problems when FD.SEG overflows.

The nitros9 cvs tree on sourceforge.net contains, in the 3rdparty tree, the 
most recent drivers for the glenside ide interface, and may make this a 
more enjoyable project.

I have to complement you for your tenacity.

> -Don
> 
> > --
> > 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

-- 
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)
To be successful, a woman has to be much better at her job than a man.
		-- Golda Meir