[Coco] Back to my COCO's again

[Bill Gunshannon]

On 12/11/18 11:34 AM, Gene Heskett wrote:
> 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
>

That, combined with a lot of fiddling around and I am up to the next

stage.  :-)


I have a system built for my SDC that includes the TC3 devices.

However, whenever I try to access a SCSI disk I get UNIT ERROR.

Other bits of data.  If I have the disk turned off I get NOT READY.

That makes sense.

No matter which SCSI device I type (s0, s1, s2 etc) I see a flash

of the disk activity light before I get the UNIT ERROR message

Drive is set for Unit 0.


Fun, so far, but definitely  not for the faint of heart.


bill