[Coco] Grumpy santa

[Gene Heskett]

On Tuesday 25 December 2018 20:03:27 rietveld rietveld wrote:

> Level 3 is making me a grumpy Santa tonight
>
> Sent from my BlackBerry

Its busted. It does NOT manage the memory correctly, methinks because of 
missing code, but I could not quite get my head around what it is 
supposed to do, so never managed to make it do what the general outline 
that Alan Dekock wrote up, said it was doing. That, and drivewire having 
modules that needed both rbf mapped in and scf at the same time, so 
there is no clear boundary between the two file systems if drivewire is 
used. I think what needs to be done is to pick the rbf code out of dw 
and put it in a separate module, and the scf stuff left over could then 
be loaded into the scf mapped blocks.

Thats the first fix, get the boundaries between the two functions clearly 
delineated again, then 2: fix the loader at boot time so it looks at the 
module header and automaticly puts rbf stuff in the rbf reserved blocks, 
and scf stuff in the reserved scf blocks. That would remove the need for 
us to presort the os9boot file. This sorting belongs in parsing the 
individual modules of the os9 boot file once the memory has been mapped 
by the first new module. Not by having a marker module to separate the 
filesystems in the bootfile. That was a kludge from the gitgo.

And it should be possible to do away with the _end module if done right. 
Each of those is a suck on system memory we don't need. Even the load 
parser should run in low memory, deleting itself and freeing the memory 
its using once the boot file has been loaded and sorted to its assigned 
memory blocks, note the s.

I also suspect that it may not work on any 128k machine. The second 
memory allocation almost has to fail if using any hirez gfx screens.

To summerize, drivewire is incompletely separated. It may be handy to 
first write a utility that based on the header marker as to whether its 
rbf, scf, or something else, that scans the rest of that module, 
throwing an error when an os9,call is found thats out of spec, like an 
scf call in a module marked rbf (or vice versa).  Thats just so we'll 
have a comprehensive list of modules that actually need fixed.

I'm sure that a younger brain will see other things that need done.  The 
concept Alan originally planned was laid out long before drivewire was 
even dreamed of, that level3 code we have was originally done when 
Nitros9 was at "about" 1.16, and drivewire violated the rbf/scf 
separation rules quite a few times since. And drivewire, to me, is 
something that MUST be maintained in functional condition, its too 
valuable an addition to nitros9 to ever consider giving it up just to 
make level3 work.

Frankly my own system was the most advanced and versatile at about 
nitros9 V1.22, and has gone steadily downhill since. Every change since 
has managed to eat system memory like theres an unlimited amount of it.
I took the os9boot file apart for a boot of 1.22 that could drive two 
monitors, format a floppy and run multivue flawlessly. It had these 
modules in the os9boot file:
====
OS9p2           OS9p3           OS9p4           IOMan           Init
Clock           RBF             CC3Disk         D0              D1
D2              RAM             R0              SCSISYS         h2
dd              SCF             SACIA           T2              T3
Midi            CC3IO           VDGInt          WindInt         Term
W               W1              W2              W3              W4
W5              W6              W7              W8              W9
W10             V0              V1              V2              V3
V4              Parallel        LP              PipeMan         Piper
Pipe            VRN             Nil             FTDD            Wpdrv
Wp              Wecho
====
And I had 20 kilobytes of smap free.  Now?
{t2|08}/DD/OLD-FAITHFUL:smap

    0 1 2 3 4 5 6 7 8 9 A B C D E F
 #  = = = = = = = = = = = = = = = =
 0  U U U U U U U U U U U U U U U U
 1  U U U U U U U U U U U U U U U U
 2  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 3  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 4  _ _ _ _ _ _ _ _ _ _ _ _ _ U U U
 5  U U U U U U U U U U U U U U U U
 6  U U U U U U U U U U U U U U U U
 7  U U U U U U U U U U U U U U U U
 8  U U U U U U U U U U U U U U U U
 9  U U U U U U U U U U U U U U U U
 A  U U U U U U U U U U U U U U U U
 B  U U U U U U U U U U U U U U U U
 C  U U U U U U U U U U U U U U U U
 D  U U U U U U U U U U U U U U U U
 E  U U U U U U U U U U U U U U U U
 F  U U U U U U U U U U U U U U U .

 Number of Free Pages:  45
   RAM Free in KBytes:  11

Looks like enough to format a floppy, right? I haven't been able to 
format a floppy in 2 decades or more, format crashes sometime in writing 
the first 4 or 5 tracks... Multivue crashes, out of system memory. And 
my complaints about the profligate use of system ram have been ignored. 
I used to run /t2 with at least 4 pages of buffer, its running on 1 now 
and that cripples rzsz's speed.  And I have no functioning 7 wire 
protocol on /t2, and software flow control useing xoff/xon hasn't worked 
in 15 years or more. So if drivewires not working, I am reduced to 
running /t2 at 4800 baud, and limiting the window to 256 bytes if this 
machine is the sender.

Its very discouraging to put it mildly.

But hey, I hope everyone has had a very enjoyable Christmas. ;-) We must 
never forget the real reason we celebrate today.

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>