[Coco] NitrOS-9 Level 3

[Gene Heskett]

On Tuesday 27 August 2013 08:59:41 Bill did opine:

> I've seen references to NitrOS-9 Level 3dor the Coco 3, but have not
> found anywhere to download it. Does anyone have links I could use. Is
> it better/worse/faster/slower than Level 2?
> 
> Thanks

Level 3 is part of the regular Nitros9 hg pull, it even builds here on 
linux, Bill.  But its not bootable on my machine, I believe because of the 
mix-n-matching between rbf and scf function calls in drivewire (on the coco 
side).

So there is no way to build a bootable os9boot file until such time as both 
the rbf.mn stuff, and the scf.mm stuff have grown the code needed to make 
sure they are mapping their own memory dynamically, as needed.  When you do 
the level3, it assumes that each has free access to its memory, but level3 
allocates individual blocks for each.  The dw modules in the coco's 
bootfile still assume a level2 system map, and because its not, they 
scribble all over memory neither one owns outright. =="boot failed" 
messages.

The dw stuff I have looked at are very stripped, nowhere near complete 
modules.  Entry and function are there, but the rest of the 5 or so 
addresses that are expected to be specified for the getstt and settstt and 
exit routines aren't there.  So if I have it running here, the coco can be 
rebooted, finds the heartbeat and dw works fine.  But if I do something 
here to interrupt dw on this end, the coco crashes because the code to 
handle a clean exit isn't there.

How much more code it would take to make it so the coco could clean up and 
exit, I've no clue.  I have thought of listing the src to the printer so I 
might be able to figure out what needs to be done, but haven't primarily 
because that still wouldn't make level3 bootable.

TBT, I think thats a job for a younger mind as this one is at 78 having a 
hard time getting itself into the mindset that used to make it easy for me 
to "get into the original coders mind" & understand what he was doing, or 
trying to and failed, the usual reason I dig into something in the first 
place.

So AISI basically, 2 things need to happen, first being a good 
understanding of what those two level3 modules actually do to the system 
memory mapping/allocation, then the incorporation of those concepts into 
the dw stuff in the bootfile, and the missing driver functions need to be 
added so that the dw server can be rebooted independently from the coco 
without crashing the coco.  How difficult, and how much bigger that might 
make the bootfile, I won't hazard a guess.  The memory problem as I see it, 
would need to have 2 new routines, which would have to be duplicated in 
both file  managers, one to be used as an intercept at the beginning of any 
call that will write to memory which will make sure the gime is properly 
reloaded so that it owns the memory, and one to be put immediately in front 
of the rts to restore the map to wherever it was found.  But that will also 
need another $10 to $14 bytes of DP(0) memory to store the maps, and the 
last time I took inventory of the DP assignments, that spare memory does 
not exist, at least not in usable 8 byte wide pieces.

My thoughts on that would be to find a single byte free in the DP, to be 
used as a tally byte to tell the gime updating code (in the clock module I 
believe, or is that a separate call in krn2 now?) that would tell this code 
which map is loaded, so it could skip that for speed if the right map is 
already loaded, or if it needed to reload to a certain other mapping, do 
it.  That overall might be the fewest bytes solution to the memory 
scribbling problem.  The lack of DP memory might be best solved with a data 
module thats treated like a $30 byte ramdisk.  It might offer a usable way 
out.  And it would both enhance what the coco can do because the system ram 
problem is shoved way back on the burner, and would also slow it some, but 
probably less than 5% by my SWAG.  We've gained way more speed than that 
over the original Tandy level2 release.  Lots more.

I could be full of it, but thats how I see it. :)  And I'm not trying to 
point fingers here either, all that wasn't done originally because of 
sysram considerations.  Level 3 would fix lots of that, but its a huge 
step, and may break some very old code, and those modules that make Level 3 
work would have to be conditionally assembled and loaded into the bootfile 
separate from the level 2 counterparts in order not to further degrade 
level 2 with code thats skipped come exec time.

Classic example of Chicken v Egg.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views 
<http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml>
It isn't necessary to have relatives in Kansas City in order to be
unhappy.
		-- Groucho Marx
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.