[Coco] NitrOS9 build errors

Tue Jan 21 17:02:02 EST 2014

On Tuesday 21 January 2014 15:43:45 Tormod Volden did opine:

> On Tue, Jan 21, 2014 at 3:55 PM, Gene Heskett wrote:
> > 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.
> 
> So the options set up in the OS9FORMAT macros are wrong? We should
> drop the -dd? A patch would help matters considerably :p

If I could get at a format help file or error screen I could answer that 
but AFAIK, the -dd means the disk is double density encoded, this has 
nothing to do with this track density switch we're beating like a dead 
horse.

However, in the last hour I've managed to get my coco to boot, but its 
without drivewire, the bit banger port is still dead.  So I logged in with 
minicom, typed help format, and got this:

{t2|08}/DD:help format    
Syntax: Format <devname> 
Usage : Initializes a NitrOS-9 diskette
Opts  :
  R   - Ready
  L   - Logical format only
  "disk name"       
  1/2 - number of sides
  'No. of cylinders'   (in decimal)
  :Interleave value:   (in decimal)
  /Cluster size/       (in decimal)

Now that, as a help screen is so close to worthless as to be comparable the 
the teat like appendages on a boar hogs belly.  Where the hell are all the 
switches it has described on a -switch by -switch basis?  And I have no 
clue who last put footprints in format.asm, but I guess we'll have to read 
it to find out.  And that is not on my agenda for today, I need to get DW 
working first.

> > 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.
> 
> Are you talking about a problem that is still there? If this is what I
> think you are talking about it is how the ITDRV number which can be
> specified at build time now actually means the drive number, and not
> an encoded only-one-bit-set value as per below. So everything is fine
> then, isn't it?

I believe it is now. At least for descriptors using the TC^3 controller.  
Not having an IDE controller, I haven't investigated the I0 and I1 
situation for correctness, but since there are probably 10 IDE controllers 
out there for every TC^3, if it was wrong I would have expected to hear a 
few more oxen being gored, but I haven't heard it from here if there was.

But the current discussion is about double track density, which ONLY 
applies to a 5.25" 96 tpi (80 track) drive.  That and only that particular 
disk format should have bit d2 set in LSN0 offset $10.  ISTR there is a 
carryover to offset $42 also, which is that area of LSN0 copied into the 
drive tables, ISTR theres a bit there that comes and goes.  Check the level 
2 docs, under PD.OPT's for the final word since I'm a bit long time hazy.

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

This is how the address byte on the scsi _bus_ is formatted.  Taking the 
original superdesc.asm docs at its word, I spent 5 or 6 years 
intermittently attempting to build a hard drive boot to replace the bare 
bones and worthless boot that Mark put on the drive when I couldn't make 
the thing work originally after buying the tc^3 controller.  So I sent it 
to him.  He made it work, but only enough to boot the bare, OOTB coco3 but 
I was still DIW for any of my hardware. So I resigned myself to booting 
from floppies that switched to the HD via the init modules chd & chx calls.

It was a good 5 or 6 years later, when I was trolling thru the boottrack 
that Mark installed, with ded and discovered that in the one he built and 
installed, the last byte before the modules crc was a 1.  That little tour 
was triggered by my adding a second, identical 1Gb drive to the system and 
tried to make a boot work from it, setting that byte to a $01 since drive 
numbers are base 0, and found that it then booted to the original boot on 
drive 0.  The lights finally came on that this wasn't the drive number, but 
the byte actually put on the bus as a drive address.  Duh.  So much for 
that bit of Documentation taken literally.

Like the shooters lament I have seen on the handloaders list, the thought 
never occurred to me that I might miss. And I can count the miss's out in 
the deer woods on 1 finger, but the next 2 did the job.  I wasn't 
'stretching' the barrel much, it was only 640 yards.  The 2nd and 3rd shots 
went through his liver about 2" apart.  Too bad good barrels don't last 
forever, but I burned that one out at the range in 1978.  Its replacement 
has never shot quite that well, and is about burned out itself now.

Back to patches.

I had a working patch that took that byte as a decimal value that actually 
represented the drive number, translated it into scsi-bus speak about an 
hour later.  And its been committed to boot_tc3.asm now for several years.  
Now you CAN take those docs at their word and set it to the actual drive 
number by conventional drive counting protocol, starting with drive 0.

Double checking the above statement against what is now boot_scsi.asm, my 
patch is is still there.

======
scsival        FCB       $80+1,$80+2,$80+4,$80+8,$80+16,$80+32,$80+64,$80
later:
               lda       WhichDrv,pcr        get SCSI ID
               leax      <scsival,pcr        point to SCSI value table
               lda       a,x                 get appropriate bitmask
               sta       SCSIDATA,y          put on SCSI bus
======

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/>
<joeyh> netgod: er, are these 2.2.0 packages 2.0.0pre9 or do you have a
        direct line with the gods?
<netgod> joeyh: i have the direct line
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.