[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