[Coco] Does anyone have a Level3 disk that actually boots?

Gene Heskett gheskett at wdtv.com
Sat Nov 29 13:31:33 EST 2014


On Saturday 29 November 2014 07:31:27 Bill Pierce via Coco did opine
And Gene did reply:
> Aaron, I've yet to try any experiments, but I was thinking of trying to
> put the dw sub in the system area, then rbdw in RBF, and scdwn in SCF.
> But until Bill Nobel gets the code up to 3.3.0 standards (if he can),
> I doubt it will work at all since the Level 3 code is based on Nitros9
> 1.2.1 or 1.2.2. A while back, I tried dw4 installed in a very early
> nitros9 release (pre 2.0.0 I think) as well as vanilla OS9 and neither
> would boot. It's probably a small problem with a call to something
> that has been added or moved since then and could probably be fixed to
> work on vanilla. One of the few "system" modules I've seen that will
> work on all versions of OS9/NitrOS9 is EmuDsk, so I know it can be
> done.
> 
> 
> Bill Pierce
> "Today is a good day... I woke up" - Ritchie Havens
> 
> 
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Webmaster of The TRS-80 Color Computer Archive
> http://www.colorcomputerarchive.com/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> E-Mail: ooogalapasooo at aol.com
> 
> 
> 
> 
> -----Original Message-----
> From: Aaron Wolfe <aawolfe at gmail.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Sat, Nov 29, 2014 1:59 am
> Subject: Re: [Coco] Does anyone have a Level3 disk that actually boots?
> 
> 
> On Nov 28, 2014 10:22 AM, "Bill Pierce via Coco" <coco at maltedmedia.com>
> 
> wrote:
> > So far, there is one MAJOR disadvantage to Level 3..... The
> > drivewire4
> 
> drivers will not function. The reason being the drivewire sits on the
> "line" as it is an RBF driver with SCF functions. and cannot be
> seperated.
> 
> > <y question is.. could create another RBF module, renamed to "DW4" or
> 
> something (same for SCF), then move ALL the dw drivers out to another
> space. How much is DW tied to RBF? I know it's tied heavily to SCF.
> 
> The SCF, RBF, and clock functionality of Drivewire is already split
> into separate modules that do not communicate with each other. 
> However, all three of these share a dependency on the common "DW sub"
> module that provides the low level serial communication.  This common
> module will need to be available to both the rbf and SCF address space
> (and the clock if that's made into a separate area).  So long as that
> is done, there should not be a problem.

I will repeat a question I've asked before, has anyone actually gotten a 
disk made from os9L3.os9 to boot?

My /d0 is a 40 track ds drive but is normally set for a 35 track ss 
configuration.

The .os9 image is of a 2880 sector drive, but doesn't have enough stuff in 
the image to even fill a 35trkss disk. I cannot with my present default 
boot, format a disk, so my std mb scripts are hand crafted to delete 
everything on the disk including the boottrack, leaving a disk with an 
empty root dir that reports as 630 sectors capacity, with 620 sectors 
free.

Now, dsave has an option to  handle the boottrack and os9boot files if 
invoked with the -b -v options, so a supposedly bootable disk is created.

So I created, from a copy of a working mb script, one that uses dsave to 
create a 35 trk ss copy of this 2880 sector .os9 file.

But dsave -b is buggier than a 10 day old road kill in late July!!!

It installed a boottrack and an os9boot file but GOT THEM FROM MY DEFAULT 
vdisk boot disk!  So when I rebooted to the floppy, it instantly reverted 
to my default level 2 boot because the boottrack contained boot_tc3!

And returning to the os9gen method , I have been about 5 hours making boot 
disks that jump to the hard drive the instant it loads the boottrack, 
apparently because while the mb script gives os9gen a good boottrack file 
in bttemp, os9gen will not write the new boottrack if it finds a boottrack 
already installed!  It makes a good OS9Boot file, then reports an error 
216 file not found unless I run a basic09 utility that creates a KERNAL 
directory entry that hooks up to the boottrack, making a deletable file 
out of it,  But thats not all, I then have to use dEd to write the first 
line of the file with a string of 5e5e5e5e5e5 etc so os9gen thinks it is 
working with a pristine freshly formatted disk.  That is because I cannot 
format a disk here using the default bootup, only 3 pages of sysram left.

To Bill:
I also used mshell to copy several bits, like a copy of boot_1773_6ms into 
a local directory so I could replace the boot I got when if did a "vfy -sk 
/x1/KERNAL after running the basic09 utility and creating a file for the 
boottrack in the /x1 mounted OS9L3.os9 file.

But everything I copied with mshell was bad.  Looked like it was grabbing 
the /dd LSN0 but wasn't an exact match.  I have to run mshell without a 
mouse as it doesn't even know I have one. So hitting a c for copy, which 
brings up the menu, and another c to confirm, is not working here.  I get 
a file, but not the contents.

Then, without some things like /H0 and its /DD copy and scsisys, and made 
a genes-DD out of a copy of Alan's /D0, I am now crashing someplace after 
the rel screen is opened, but the screen is slid 4" to the right 
preventing me from seeing how far the boot's module listing got but I am 
not getting a FAILED, it either hangs or goes to out to pasture with a big 
shower of confetti on the screen.  So next I saved a copy of my rel_80 and 
rebuilt the bttemp file, but that I believe looks for krn so I'd expect 
I'll have to use ded to change its internal name to krn while leaving it 
as OS9p1 in the local directory.

Or I could say screw it and walk away for the rest of the day, or maybe 
forever.  And it looks like I need to write a delfmt utility that will 
first overwrite the files contents, making it look as if its freshly 
formatted disk, before deleting it.

Unless by chance there is some switch we can set on the os9gen command 
line that will force it to blindly overwrite an existing boottrack.

Is there such a -f beast?  A help os9gen does not show it.

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>
US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS


More information about the Coco mailing list