[Coco] Original OS-9 Level 1 source code

[Bill Pierce]

Neal and Felipe, using Brett's CocoBoot, you could eliminate boot, rel, and init. CocoBoot loads the OS9Boot file directly.
We use this with the bootrom for booting NitrOS9 on startup on the Coco3FPGA. This would reduce system memory use.
I don't know if Brett has a version usable on L1, but I doubt it would be hard to implement.

 

 

Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page

E-Mail: ooogalapasooo at aol.com

 

 

-----Original Message-----
From: Neal Crook <foofoobedoo at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Wed, Apr 26, 2017 4:33 pm
Subject: Re: [Coco] Original OS-9 Level 1 source code

Hi Felipe,Your email prompted me to look at the size of the files on my L1 system.The platform is my multicomp09 FPGA system so the module set and file sizeswill obviously be different for a Coco or other platform.The boot process involves a "kernelfile" loaded from track34 and a"bootfile". Each of these files consists of a set of concatenated modules.Memory is assigned in increments of 256 byte "pages". The concatenatedfiles are good and bad. Good because memory is assigned to each of thesetwo files "atomically" - there is no "alignment space" wasted betweenmodules as there would be if each module was loaded individually. Badbecause, once loaded, no module in either of these files can be removed(the memory is permanently allocated).[you know all this stuff already I expect, I'm just including it forcompleteness and so that anyone can point out errors that I have made]Here are the module sizes in bytes (decimal). No allowance is made for datareservations.The L1 kernelfile:rel                    81krn                  2041krnp2           1355init                  112boot_sdc              240The L1 bootfile:ioman                1802rbf                  3557dds0_80d.dd       47mc09sdc.dr            239s0_80d.dd              53s1_80d.dd              53s2_80d.dd              53s3_80d.dd              53scf.mn               1747mc6850.dr            1110term_mc6850.dt         63term_mc6850_t0.dt      61term_mc6850_t1.dt      61pipeman.mn            547piper.dr               40pipe.dd                38mc09clock_50hz        347clock2_soft           102sysgo_dd              483In order to save memory, you need to save increments of 256 byte "pages".Obviously, the first thing to do is to shave down the kernelfile andbootfile to remove any modules that are not strictly necessary.There is no reason for the rel, init or boot_sdc modules to remain inmemory after boot (well, it should allow you to reboot your system withoutdoing a disk access but that is not a compelling reason). The currentdesign of L1 rel requires krn being straight after rel, but it would besimple to remove that requirement. Then, the code that copies thekernelfile to high memory could just copy krn, krnp2 and leave the otherstuff at $2600. That could simply be discarded after bootfile has beenloaded.All of that is quite simple but would only save 1-and-a-bit pages.There's no shell in this list, and I think that contributes about 1.5K. Itshould be possible to build a minimum-functionality command starter that issmaller than that. Is it possible to run withoutpipeman,mn/piper.dr/pipe.dd (another 625 bytes..).The next thing to look at is whether there are modules that include anyone-time code setup. This could be moved to REL and discarded after boot.Of course, that starts to compromise the modularity of the system in anunappealing way.I would be interested to see comparable module sizes for the original OS9modules, and to hear about any other lean/mean approaches to reducing thememory footprintregards,Neal.-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco