[Coco] NitrOS9 build errors

[Gene Heskett]

On Tuesday 21 January 2014 09:18:15 Robert Gault did opine:

> Tormod Volden wrote:
> > Let me ask again, all of you floppy disk fans. What is the useful
> > information you need when you look at that disk image listing? How do
> > you normally classify those floppies and drives? TPI? Or tracks?
> > Capacity?
> > 
> > See the refreshed http://nitros9.sourceforge.net/latest/ where I have
> > calculated a number of tracks from the "os9 id" output. Would it be an
> > idea to replace or complement the TPI with this?
> > 
> > Tormod
> 
> You can follow the example of MESS when handling Coco floppies. Any
> floppy labeled .dsk is assumed to be single sided, have 18 sector
> tracks, 256 byte sectors, and a multiple of 35 tracks per disk;
> basically the JVC format. Any disk labeled .os9, means that the format
> must be taken from LSN0; permitting double sided disks of any size.
> Regards tpi and other info, that is a function of OS-9 and the drive in
> use and should be transparent to the user.
> 
> At the moment, NitrOS-9 does not handle adequately issues related to tpi
> and in some cases hard drives. Mark Marlette (because Cloud-9 is
> selling drive hardware) and Gene Heskett (because he seems to find bugs
> more than anyone else do to his extensive drive collection) should be
> queried to see what is needed for their hardware.
> 
> Robert
 
And if people would just read carefully, the descriptions in the 
superdesc.asm file, about 98% of the questions would be answered.

All we need to do people, is to get all of us on the same, _correct_ page.

The broken makefiles in the repo are NOT helping matters when they build 
both the 5.25" 80 track descriptors and the 3.5" 80 track descriptors from 
the same specs.  The only time we need that double track density flag which 
shows up as a set d2 in offset $10 of the disks LSN0, is for the 5.25 disk. 
DW doesn't care, ever that I know of, but once the error is on the disk 
surface as data, the only way I know about how to fix it is dEd.

As for hard drives, the only problem thing I am aware of, and it took me 
years to find it, is how the boot drive is actually specified at build time 
(or later with dEd) in the boot_tc3 boottrack module. There was room in the 
module to do it sensibly, so I patched it several years ago now.  Now you 
can specify drive 0, and actually get drive 0, where before, with the 
woefully inadequate description, a zero failed.  And it failed by not 
stating that it was _the_ byte actually put on the scsi bus to address the 
drive so drive zero in scsi nomenclature is actually a set d0 in the byte 
used for drive address.

Drive 1 would be a set d1, drive 2=set d2 etc. Drive 7, set d7 is the 
controller itself intended to facilitate more than one drive talking to the 
controller at a time since the full scsi specs say that you can tell the 
controller to do a copy operation between 2 drives, the controller tells 
the drives, they coordinate between themselves and the controller and the 
controller then tells the computer the results of the copy operations 
success or failure when its finished.  Neat, the computer can go do other 
things in the meantime.  But its something that has never been attempted on 
a coco that I'm aware of.

The scsi specs, as supplied in manual accompanying the very first maxtor 
drive I ever bought, something in the area of 20 years ago, a 7120s, is a 
very interesting document. We use maybe 5% of that capability on the 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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Required reading: 
<http://culturalslagheap.wordpress.com/2014/01/12/elemental/>
There is no TRUTH.  There is no REALITY.  There is no CONSISTENCY.
There are no ABSOLUTE STATEMENTS.   I'm very probably wrong.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.