[Coco] NitrOS-9 Level3 problems

[L. Curtis Boyle]

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