[Coco] Trying to build new images

[Gene Heskett]

On Sunday 08 January 2017 15:06:41 Bill Gunshannon wrote:

> On 1/8/17 1:33 PM, Christopher R. Hawks wrote:
> > On Sun, 8 Jan 2017 11:18:32 -0500
> > Bill Gunshannon <bill.gunshannon at hotmail.com> wrote:
> >
> > [big snip]
> >
> >> Typed:
> >>        chd nitros9/6809l1/scripts
> >>        shellplus mb.dw (mb.dw uses dw.bl)
> >>     runs to completion with only one error on the attempt to delete
> >>        non-existant temporary bootfile.
> >>
> >> Creates an image that gets as far as the "Nitros9 Boot" screen. 
> >> Then it just stops.   One thing I notice is that it puts a copy of
> >> SYSGO in the root directory.  The running image from the zipfile
> >> does not have this.  Thus my statement that the running image does
> >> not appear to have been built from this script.
> >
> > Bill:
> >
> >     IF the only text on the screen is "Nitros9 Boot" then something
> > is wrong with your kernel (krn) or there isn't one on track 34 (from
> > the merge command in the script).
>
> Yes, I am aware that the message I get is from Rel and that seems
> to be where it stops.
>
> >     The boot screen should show something like this at the top:
> > (32 columns and different module names, of course.)
> >
> > Krel boot krntb0................
> > ................................
> > ............ bkrnp2 dd d0 rbf
> > rb1773 term w w1 w2 w3 w4 scf
> > cowin clock clock2 init i2xoC
>
> Funny you should say that.  The working image from the zipfile
> that is my active system doesn't do that.  After the "Nitros9 Boot"
> screen clears I get messages about being a development system and then
> I get the motd.  Haven't seen the above since the last time I ran the
> Radio Shack version of OS9.
>
> >     If the boot process does not complete, the above should end
> > (short) with a '*' and a single letter. It would help with diagnosis
> > if you could supply these details.
>
> Details are nothing after "Nitros9 Boot".
>
> >     Attached is an explanation of the boot process in detail and
> > more info about the error reporting. (With DOS type end-of-lines as
> > I don't know what type 'big' computers you use.)
>
> What are you looking for?  I have Z80's, PDP-11's, Vax, UltraSparc,
> and, naturally, a collection of PC servers and clients. Oh yeah, and
> a MacBook and some Apple ]['s. :-)
>
> I understand the boot process, but that is of little help fixing
> this.  Difference between theory and practice.  I will definitely
> be reading what you sent, though, as it will likely add to  mu
> understanding of the propcess.
>
> Some new info for you and everyone else who is following this.
> I ran ident on the running OS9Boot and on the one being generated
> by the script.  Not even close.  It is obvious that this script and
> bootlist are not what was used to build the system they reside on.
> I edited the bootlist file and added all the stuff that was missing
> (even the stuff that is irrelevant like floppy drivers) and the
> result of this is I now don't get an OS9Boot file at all.  I end out
> with a file called TempBoot in the root directory that appears to be
> the uninstalled OS9Boot.  My guess is it is now too big. Which still
> begs the question, "How did someone make the kernel I am running?"
>
> Don't get me wrong, I am actually having fun again.  And i have no
> doubt with all of your help I will figure this out.  And, I can assure
> you, when I do I will document this so others can do it without
> jumping through all the hoops I am.  :-)
>
> bill

A tool that might be helpfull is my 'vfy', which you can get from my web 
page in the sig. I'd first look at track 34 with ded to see if its even 
there AND the track is fully occupied. I have another utility called 
krnl-to-dir, which builds a directory entry to track 34, making it a 
visible (and danger Will Robinson, deleteable) file, and you can then 
run "vfy -k kernal" (spelling error on purpose) which should show 
everything on that track including the first 6 bytes that identify it as 
OS, and its DOS satisfying data. then 3 modules and their size and 
CRC's, (match those CRC's to the file named in the merge command of your 
mb script) and finally the trailing bytes that pad it on out to 4608 
total bytes, and function as error catchers, which if jumped to, simply 
issue a return from a subroutine. Hex 39's IOW.

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>