[Coco] cobbler'd disks

Wed May 16 17:56:56 EDT 2007

OK folks, I think I've solved the problem with NitrOS-9.  Apparently my
grfdrv file was corrupt, or at least there was some problem copying it from
the #2 disk.  I have fixed the problem and now have a custom NitrOS-9 boot
disk.  I needed the custom disk because I added a 3.5 inch floppy and I
didn't want to be typing in dmode commands everytime I boot.  I made my own
floppy cable out of spares I have laying around and I can format and copy
files to the 3.5 inch drive OK.  Now I just have to solve a similar problem
I have with OS-9 L2 original (sigh).  Mark Marlette, can you check your
email for a message from me.

On 5/16/07, Mark Marlette <mark at cloud9tech.com> wrote:
>
> Mike,
>
> Ok...but.....
>
> You are missing one important part here.
>
> An image is not created on the coco, which you know. NitrOS-9 is
> based upon scripts.
>
> Go to the modules directory. Don't recall the exact path or names
> here. I run a custom boot and Boisy and I differ on why/where we
> place modules. He places modules based upon function. Example, RBF
> drivers go in the RBF path of NitrOS-9. I don't mix products. So mine
> is party based. CDF has a directory, DriveWire has a directory and
> SuperDriver has a directory. That way the products are not mixed with
> the OS. This is not as big of a deal since NitrOS-9 is not changing
> as much now as it use to be. I just keep a clean directory structure.
> An update to the proper product, short edit using VED to the
> bootlist, run the mb_x script and a new disk is made with the new
> drivers present.
>
> There are two directories. One is bootlists and the other is scripts.
> In the bootlist directory there is a file named standard.bl, read it,
> it makes total sense. This will be the file that contains all of the
> modules that is in your boot.
>
> In the scripts directory, there is a mb file, forget the name, mine
> again are custom, which I will get to in a bit, no pun intended. Run
> this script with NO modifications and NO modifications to the
> bootlist standard.bl. It WILL create a bootable disk. If not then
> there is a hardware issue.
>
> If the above works, then go to the next, custom level. Copy the
> standard.bl to another name. I have several for example.
> Superdriver_floppy.bl, superdriver_hard.bl. These are copies of the
> standard.bl with Cloud-9 specific descriptors for CFs. All .dds from
> C-9 are the same. 256MB or 128MBs. That way when you are done
> flashing the flash. You can swap CFs and transfer programs, etc.
>
> Then in the script directory do the same copy the mb to mb_floppy.d0,
> this will make a floppy boot on /d0, remember you must change the
> name of the .bl you are now running. I have three. mb_floppy.d0,
> mb_hard.dd and mb_hdb.dd.
>
> The only difference between a hard boot and a HDB-DOS boot is the
> boot track. You will see this in the script when it generates the boot
> track.
>
> If you REALLY want to understand NitrOS-9, read and understand these
> scripts.
>
> They work and well. Remember don't change until you can create a bootable
> disk
>
> Hopefully this helps...at 3:26AM........
>
> Regards,
>
> Mark
> Cloud-9
>
>
> At 5/15/2007 09:59 PM, you wrote:
>
> >The original image I downloaded from source forge and transferred to real
> >floppy, works perfectly.  I can format another disk and backup the
> original
> >to it and that works too.  I just can't create a custom boot disk.
> >
> >On 5/15/07, Mark Marlette <mark at cloud9tech.com> wrote:
> >>
> >>Mike,
> >>
> >>Do you run the script and you can't create a DSDD boot disk?
> >>
> >>Out of the shoot NitrOS-9 is DSDD.
> >>
> >>Mark
> >>
> >>That sounds like a hardware problem.
> >>
> >>At 5/15/2007 07:57 PM, you wrote:
> >>
> >> >Here's whats on the screen
> >> >
> >> >KRel Boot Krn tb0..........................etc...............bKrnP2
> IOMan
> >> >Init RBF rb1773 DD D0 D1 D2
> >> >Rammer i2xot*j
> >> >
> >> >Then "FAILED" comes up under NITROS9 BOOT.  Please note that I have
> tried
> >>it
> >> >without the ram disk also and it stops about the same place.  At this
> >>point,
> >> >I can't even make a boot disk using mb and standard.bl.  The only way
> I
> >>can
> >> >make another boot disk in NitrOS-9 is to format a disk and do a backup
> >>(this
> >> >is a DS 40 disk), not very customized eh.  In OS-9 I can only make 35
> or
> >>40
> >> >track SINGLE sided boot disks.
> >> >
> >> >On 5/15/07, Christopher Hawks <chawks at dls.net> wrote:
> >> >>
> >> >>mike delyea wrote:
> >> >> > dmode /dd shows
> >> >> > nam=DD mgr=RBF ddr=rb1773 hpn=07 hpa=FF40 drv=00 stp=03 typ=20
> dns=01
> >> >> > cyl=0028
> >> >> > sid=02 vfy=01 sct=0012 t0s=0012 ilv=03 sas=08 wpc= ofs= rwc=
> >> >> >
> >> >> > dmode /d0 shows the same except for the nam part (which is D0
> instead
> >>of
> >> >> > DD).  dmode /d1 is also the same.  I am only using 360k 5.25floppy
> >> >>drives.
> >> >>
> >> >>Mike:
> >> >>
> >> >>         When you boot the NitrOS-9 disk, what appears on the
> screen??
> >>You
> >> >>should see
> >> >>the "NitrOS-9 Boot" in the center of the screen and if you are using
> a
> >>40
> >> >>or 80
> >> >>column /term, a bunch of debug data.
> >> >>
> >> >>         Attached you'll find a copy of my article from the Coco123
> >> >>(Glenside
> >> >>Newsletter) describing that the boot process is doing as each part of
> >>the
> >> >>debug
> >> >>data appears. It has always (for me) shown what part of the process
> is
> >> >>going
> >> >>into the weeds.
> >> >>
> >> >>
> >> >>--
> >> >>Christopher R. Hawks
> >> >>HAWKSoft
> >> >>---------------------------------------------------------
> >> >>When you say 'I wrote a program that crashed Windows', people just
> stare
> >> >>at you blankly and say 'Hey, I got those with the system, for free'
> >> >>         -- Linus Torvalds
> >> >>
> >> >>
> >> >>NitrOS-9 Level 2 Booting and (trouble)Shooting.
> >> >>
> >> >>by Chris Hawks.  12 May 2006
> >> >>
> >> >>         One of our local Coco-nuts was having a problem with
> NitrOS-9
> >>on
> >> >>his Coco3. It had recently stopped booting NitrOS-9 from HDB-DOS in
> >> >>his SuperIDE. We got together at the monthly Glenside Color Computer
> >>Club
> >> >>meeting to see if we could resolve the problem. He brought his system
> >> >>and I brought a sub-set of my system to the meeting. We were the
> >> >>'presentation' for that meeting. I booted my system from HDB-DOS and
> >> >>my SuperIDE adapter with his compactflash card in a compactflash to
> >> >>IDE adapter as the slave drive. After my systems booted, I looked at
> >> >>the root directory of his compactflash card. It looked OK to me, but,
> >> >>he did have some odd files there. I shut down my system and swapped
> the
> >> >>compactflash cards.  (His as mastr and mine as slave. The boot
> process
> >> >>started and loaded track 34 and the OS9boot and then just stopped.
> From
> >> >>the debugging clues posted to the screen during the boot process, I
> was
> >> >>able to determine the the boot process was unable to find the 'sysgo'
> >> >>module. I re-booted with my compactflash as master and his as slave,
> >> >>and copied 'sysgo' from my root directory to his. We swapped the
> >> >>compactflash cards once again and his compact flash was able to boot!
> >> >>
> >> >>         I was asked to write-up our adventure as a article for the
> GCCC
> >> >>newsletter (Coco 1 2 3). I had not been able to find and information
> on
> >> >>debugging the boot process in NitrOS-9 (except from the source code)
> so
> >> >>here it is.
> >> >>
> >> >>STEP 1
> >> >>         The modules 'rel', 'boot', and 'krn' are loaded into memory
> >>from
> >> >>track 34 by the 'dos' command. 'Rel' ensures that it is located in
> the
> >> >>correct part of memory, sets up some of the hardware, clears the
> screen,
> >> >>and installs the debugging 'print' routine. It prints 'NITROS9 BOOT'
> in
> >> >>the center of the screen and jumps to the execution address of the
> >> >>module 'krn'.
> >> >>
> >> >>STEP 2
> >> >>         The module 'krn' uses the debug 'print' routine to put a 'K'
> on
> >> >>the
> >> >>startup screen. It validates the modules in memory ('rel', boot, and
> >> >>'krn') which prints their names on the startup screen and makes a
> system
> >> >>call (F$Boot) which puts a 't' on the startup screen and links the
> >>module
> >> >>'boot'. It puts a 'b' on the startup screen and calls 'boot'. 'Boot'
> >>reads
> >> >>LSN0 to find OS9boot and puts a '0' on the startup screen. 'Boot'
> then
> >> >>loads OS9boot and puts a '.' on the startup screen for each sector
> read.
> >> >>'$F$Boot' validates all modules in OS9boot which prints their names
> to
> >>the
> >> >>screen, and puts a second 'b' on the startup screen. Next 'krn' links
> to
> >> >>the 'init' module and puts 'i' on the startup screen. Following this
> it
> >> >>links to and executes 'krnp2' the second part of the kernel.
> >> >>
> >> >>STEP 3
> >> >>         'Krnp2' puts a '2' on the startup screen, and puts an 'x' on
> >>the
> >> >>startup screen. Then 'krnp2' tries to 'chd' to the system device
> named
> >>in
> >> >>'init' (usually '/dd'). Next 'krnp2' puts a 'o' on the startup screen
> >>and
> >> >>tries to open the output console named in 'init' (usually '/term').
> >> >>'Krnp2'
> >> >>checks for 'krnp3' and runs it if available. Then 'krnp2' puts a 'C'
> on
> >> >>the startup screen and tries to run the startup module named in init
> >> >>usually 'sysgo'.
> >> >>
> >> >>STEP 4
> >> >>         'Sysgo' opens the output console, prints the NitrOS-9
> startup
> >> >>banner
> >> >>and sets the data and exec directories. 'Sysgo' will execute
> 'startup'
> >>and
> >> >>'autoexec' if available (unless you hold the 'shift' key) and finally
> >> >>starts a 'shell' on the console.
> >> >>
> >> >>         If something goes wrong during the boot, the module will
> call
> >>the
> >> >>'crash' routine which will put a '*' and single character on the
> startup
> >> >>screen.  The '*' indicates that an error occured and the character's
> >>ascii
> >> >>value plus 128 is the error number. For instance '*X' would indicate
> a
> >> >>'Path Name Not Found' error. 'X' is ascii 88, and 88 + 128 = 216, the
> >> >>error code for 'Path Name Not Found'. This is the error we saw when
> >>sysgo
> >> >>was missing from the root directory of the disk.
> >> >>
> >> >>         So, the start up messages look something like this:
> >> >>Krel boot krn tb0...................................................
> >> >>......... bkrnp2 dd d0 rbf rb1773 term w w1 w2 w3 w4 scf cowin clock
> >> >>clock2 init i2xoC
> >> >>
> >> >>         Of course, YMMV (Your Modules May Vary)
> >> >>
> >> >>         This should give you some insight into what goes on during a
> >> >>NitrOS-9
> >> >>boot, and berhaps some debugging assistance when something goes
> wrong.
> >> >>
> >> >>
> >> >>
> >> >>--
> >> >>Coco mailing list
> >> >>Coco at maltedmedia.com
> >> >>http://five.pairlist.net/mailman/listinfo/coco
> >> >>
> >> >
> >> >--
> >> >Coco mailing list
> >> >Coco at maltedmedia.com
> >> >http://five.pairlist.net/mailman/listinfo/coco
> >> >
> >> >
> >> >
> >> >
> >> >--
> >> >No virus found in this incoming message.
> >> >Checked by AVG Free Edition. Version: 7.5.467 / Virus Database:
> >> >269.7.0/804 - Release Date: 5/14/2007 4:46 PM
> >>
> >>
> >>
> >>No virus found in this outgoing message.
> >>Checked by AVG Free Edition.
> >>Version: 7.5.467 / Virus Database: 269.7.0/804 - Release Date: 5/14/2007
> >>4:46 PM
> >>
> >>
> >>--
> >>Coco mailing list
> >>Coco at maltedmedia.com
> >>http://five.pairlist.net/mailman/listinfo/coco
> >>
> >
> >--
> >Coco mailing list
> >Coco at maltedmedia.com
> >http://five.pairlist.net/mailman/listinfo/coco
> >
> >
> >
> >
> >--
> >No virus found in this incoming message.
> >Checked by AVG Free Edition. Version: 7.5.467 / Virus Database:
> >269.7.1/805 - Release Date: 5/15/2007 10:47 AM
>
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.467 / Virus Database: 269.7.1/805 - Release Date: 5/15/2007
> 10:47 AM
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>