[Coco] NitrOS-9 Level3 problems

[Gene Heskett]

On Monday 07 May 2018 10:37:35 L. Curtis Boyle wrote:

> > On May 7, 2018, at 8:20 AM, Gene Heskett <gheskett at shentel.net>
> > wrote:
> >
> > I came to play with it several years ago now, as the premise of
> > putting the heart of nitros9 in one memory block, all the scf stuff
> > in another, and all the rbf stuff in a third sounded like a heck of
> > a good idea. But the map switching in the boot loader was broken in
> > that it switched to the second map, but had no provision to switch
> > back, or to switch to a third map. And there are some parts of
> > drivewire that refuse to be so cataloged, so some of drivewire would
> > need to be split out into two pieces so as to enable the individual
> > modules to be cataloged as rbf only or scf only. Ideally, the
> > os9boot file should be processed on a module by module basis as
> > opposed to sorting the os9boot file into 3 such sections.
>
> We ran it briefly too; it did slow multi-tasking down, and since we
> were running 8 terminals and 3 printers simultaneously, we went back
> to level 2 (we also only used GrfInt, and no VDGInt, so had a lot more
> system RAM free in the first place). It had a special “start block”
> module, and the _end module to mark the beginning and end of both the
> SCF blocks (SCF, it’s drivers & descriptors), and the the RBF block
> (RBF, it’s drivers and descriptors). It didn’t give full 64K memory
> maps; it basically did a standard 64K system map, with a 16K chunk of
> that reserved for RBF or SCF; it would swap that 16K chunk between the
> two every I/O call as needed.
>
> > There is only one map change trigger in the current lashup, and
> > nothing to effect the reversion to default, and nothing to trigger
> > the switch to the third map. I came to the conclusion that the
> > original author did not give us the whole kit, and despite a couple
> > months I spent trying to get into his head and fix it according to
> > what was written was beyond me. And most assuredly is since the
> > pulmonary embolism that almost put the ~30~ on my story 3 years ago.
> >
> > Alan Dekok claims he had it working on 10+ machines for a year, but
> > so much has been cut up into smaller modules and submodules, all
> > with different names, so doing it to todays code base is likely
> > going to need a better understanding of the code than I currently
> > have.
>
> The splitting of modules is causing some problems
>
> > See nitros9/level3/Level3.doc, then make it work as described. I get
> > the impression that the _end module is supposed to do more than it
> > currently is doing.
>
> From what I remember, it was a special “end of dedicated block
> manager/driver/descriptor marker”, so that the system knew what to
> move to each 16K sub-map.
>
> > Also, the ReadMe.l3 is confusing, as it ends indicating a floppy
> > cannot be formatted.
> >
> > " I've just discovered that CC3Disk11 will crash on trying to format
> > a floppy disk under Level III.  It's probably the memory extensions
> > I made to CC3Disk, and I'm checking it out."
> > -EOF-
>
> This is the same problem that large boot files have with formatting a
> floppy; since the write track system call needs the entire track
> buffered, and in system memory (as it currently stands), INCLUDING all
> the pad bytes, track/sector headers, CRC checks, etc. it takes like
> 5K+ by itself. Combined with your normal OS9Boot, and forcing a full
> 16K of system RAM reserved for the RBF manager/driver/descriptor
> block, probably didn’t leave enough room for it to run. (I think
> someone should rewrite the write track call to use
> external-to-the-system-map memory, especially for regular halting
> controllers; since you are going to lock the system up anyways, shut
> off FIRQ/IRQ, map in a special “track buffer” MMU block overtop some
> other code you don’t need at the time, and then write the track from
> there)
>
> > But whatintuncket is CC3Disk11? It is nowhere in the level3 subdir
> > here, despite what is being built by my attempts indicating that the
> > module splitting done to level1\2 has been carried over, and CC3Disk
> > is now rb1773 etc etc.
>
> CC3Disk11 is just the normal CC3Disk floppy controller driver, but
> edition #11 (which let one access 512 byte sector disks, and non-os9
> format disks). This was put out publicly on Compuserve, Delphi, etc.,
> and may have been part of the Version 3/Kevin Darling driven upgrade,
> that they let trickle out over a few years after Tandy cancelled the
> project.
>
> > I'd run my script to pull and build the latest, but it requires I
> > destroy the sandboxes I have setup to protect it. And with taking
> > care of the missus thrown in, I would rather setup a build tree here
> > in my home dir, and then move it to the /opt dir where apache2 can
> > find it and serve it back out to you. But thats not going to happen
> > today. It really needs a younger mind anyway.

Thanks Curtis.

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