[Coco] Back to my COCO's again

[Gene Heskett]

On Tuesday 11 December 2018 08:00:22 Bill Gunshannon wrote:

> OK, moving on.
>
>
> I have my development system running.  I have the latest NitrOS9
>
> sources.  I can successfully build the usual images.  However... I
>
> have (re)added entries into the makefiles for the TC3 but the image
>
> created will not boot.  It gets to the third entry on the boot display
>
> and then fails.  I basically used copies of existing entries in the
> makefile
>
> only changing the TC3 specific stuff.  Is there something simple I am
>
> missing?  Is there any documentation that would help with building
>
> new systems from scratch?  I hope eventually to  have a system with
>
> SCSI, IDE, DW and Floppies but for now I would be happy with just
> SCSI.
>
>
> bill

There is a 2 part boot. The boot in track 34 must be for the booting 
device. And in the case of the tc3, there are 2 versions of how to 
specify the device address in that byte. First there was a simple 
statement in the docs that said that byte in front of the modules crc, 
was the address, but it did not say address BYTE. So on my system I 
added a couple lines of code to translate the address into the address 
BYTE. What the original meant was that the byte there WAS the address, 
picked up and directly put on the scsi bus as the drives address. Drive 
0 then needs a BYTE as 10000000, drive 1 needs a 01000000, and that 
single 1 bit marches across that byte until it gets to d6, with d7 
addressing the controller itself. I didn't understand it other than I 
did know about the marching bit, but the build never did that 
translation, leaving a 0x00 in that byte. So I was stuck booting from 
drive0 because that boot disk from mark was the only one I had that 
actually had an active bit in that byte. I don't know if my patch was 
ever uploaded to the repo, but if it did, an 0x00 in that byte is legal 
and will use drive0 as my code will translate it to 0x01. If the 
original way and boot.tc3 code, then you must have it in the 1 marching 
bit format in that byte. Where drive 0 is 0x01, drive1 is 0x02, drive 2 
is 0x04, drive3 is 0x08, drive4 is 0x10, drive5 is 0x20, drive6, 0x40, 
being the 7nth and last valid drive number in the scsi-II specs. 0x80 is 
the controller itself.

Fixing this is a pita, because if os9gen finds valid data on track 34, 
and the allocation map shows it as being allocated, it will NOT re-write 
the track. So you cannot os9gen a fixed module to anything but a freshly 
formatted disk. That needs FIXED!

That is what prompted me to write KERNAL_to_DIR, (its on my web page) 
which makes a directory entry for track 34, thus making it available to 
ded so it could be patched. And once patched and working, the only way 
to hide it again is the nuke the name from the root directory of that 
disk with ded. Any other method will also clear the allocation map bits, 
and the next write then over-writes the boot track. Boom!!!

And all this trouble was caused by one missing word or sentence to be 
100% complete, in the docs. Or my literal stupidity, take your pick.

But maybe theres a clue in this rant that will fix your problem?

I hope so, Bill 

-- 
Cheers, Gene Heskett
--
"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>