[Coco] Original OS-9 Level 1 source code

[CoCo Demus]

Yeah, I'm taking for comparison the OS-9 Level 1 V2 EuroHard. This version
has the ability to change the video driver on the fly with go32, go40 and
go51 commands. It reloads them I didn't get into the details of how the
magic is done. And yet it has impressive 144 pages left even in HR 51
columns mode:

http://archive.worldofdragon.org/archive/index.php?dir=Disks/Dragon/OS-9/&file=OS-9%20Level%201%20V2.0%20%281985%29%28Eurohard%20SA%29%5BOS-9%5D%5B%21%5D.zip

I made a first comparison and most of modules have grown over the time like
Shell, SCF and the double Clock modules;

So I want to make sure which parts are mandatory for a disk based OS-9. If
you need more parts it would be tailored and generated from sources, never
from the OS-9 itself. At least you could use the NitrOS-9 on a coco-1.
Right now you can barely format a disk.






On Wed, Apr 26, 2017 at 1:33 PM, Neal Crook <foofoobedoo at gmail.com> wrote:

> 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 sizes
> will 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 concatenated
> files are good and bad. Good because memory is assigned to each of these
> two files "atomically" - there is no "alignment space" wasted between
> modules as there would be if each module was loaded individually. Bad
> because, 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 for
> completeness 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 data
> reservations.
>
> The L1 kernelfile:
>
> rel                    81
> krn                  2041
> krnp2                1355
> init                  112
> boot_sdc              240
>
> The L1 bootfile:
>
> ioman                1802
> rbf                  3557
> dds0_80d.dd            47
> mc09sdc.dr            239
> s0_80d.dd              53
> s1_80d.dd              53
> s2_80d.dd              53
> s3_80d.dd              53
> scf.mn               1747
> mc6850.dr            1110
> term_mc6850.dt         63
> term_mc6850_t0.dt      61
> term_mc6850_t1.dt      61
> pipeman.mn            547
> piper.dr               40
> pipe.dd                38
> mc09clock_50hz        347
> clock2_soft           102
> sysgo_dd              483
>
> In 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 and
> bootfile to remove any modules that are not strictly necessary.
>
> There is no reason for the rel, init or boot_sdc modules to remain in
> memory after boot (well, it should allow you to reboot your system without
> doing a disk access but that is not a compelling reason). The current
> design of L1 rel requires krn being straight after rel, but it would be
> simple to remove that requirement. Then, the code that copies the
> kernelfile to high memory could just copy krn, krnp2 and leave the other
> stuff at $2600. That could simply be discarded after bootfile has been
> loaded.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. It
> should be possible to build a minimum-functionality command starter that is
> smaller than that. Is it possible to run without
> pipeman,mn/piper.dr/pipe.dd (another 625 bytes..).
>
> The next thing to look at is whether there are modules that include any
> one-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 an
> unappealing way.
>
> I would be interested to see comparable module sizes for the original OS9
> modules, and to hear about any other lean/mean approaches to reducing the
> memory footprint
>
> regards,
>
> Neal.
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>