[Coco] Back to my COCO's again

[Gene Heskett]

On Tuesday 11 December 2018 13:17:52 Bill Gunshannon wrote:

> 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.
>
Mmm not 100% sure I've encountered that exact behaviour, so do you have 
a /dd? And is its LSN0 properly prepared? Both for the size of the 
drive, the offset where the os9 partition ends and the basic vdisks 
begin? And where on the drive the os9 file you want to use to finish the 
boot, actually starts, and its length. See the rbf.defs for which bytes 
in LSN0 are what, its all in there.
>
> Fun, so far, but definitely  not for the faint of heart.

Not if bringing up a system from scratch, it can be a very steep hill.
>
>
> bill

Good luck Bill, but I am sure you'll get there, a step at a time.


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