25 years ago, I was an active OS9 user, and almost knew what I was doing! Then life happened. Last year I dug the old CoCo3 out of storage, and this series documents my journey back to almost.
Starting with a dead hard drive, but there was a backup - 60 odd 720k floppy disks, also 25 years old. Besides that, a floppy drive CoCo3 with MPI, some floppies that still worked, and many boxes of CoCostuff. And the community. I was amazed at the number of people still campaigning the CoCo, and new products like the CoCoSDC certainly made restoring my old system more likely. Finding OS9 still under active development made it certain.
Getting started was easy. Since the 90s, NitrOS9 has gained the ability to suss out various sized floppy drives all by itself, understands the SDC, and provides an empty hard drive image to stream my backup to. And the stream program preinstalled, come to think of it.
Most of the old floppies were actually good! and I soon (heh) had the old hard drive mounted as /h1, with a bootable NitrOS9 EOU image as /dd. This is recommended as an easy way to keep the OS current without accidentally smashing your data, we'll keep this setup for a while.
The first task is to tweak system settings to my likings. Plural, because a CoCo simply doesnt have the room or speed to do everything/allthetime. We must divide and conquer.
Divide what? OS9 already divides the boot into three datasets, a file for each.
/dd/OS9Boot - merged glob of OS9 parts to load
/dd/startup - list of things to do at startup
/dd/SYS/env.file - system wide environment settings
Because small systems generally used a boot floppy, there wasn’t a menu system. Copy that floppy! We could still do that, with a bunch of SDC images for drive 0 and the separate data image in drive 1. But you might not want to, for example OS upgrades would become chore to the nth.
To manage these files today, NitrOS9 provides the swapboot utility. You might have already used it to set up drivewire or an emulator. It easy to create your own options. Copy the big 3 files, adding a custom file extension to each to ID a set.
Start with your original boot, as soon as it is semi-tolerable. Then experiment away, knowing the original is still close at hand.
cp /dd/OS9Boot /dd/OS9Boot.nos9
cp /dd/startup /dd/startup.nos9
cp /dd/sys/env.file /dd/sys/env.file.nos9
cp will yell at you if the extension i(set name) is already used. To deliberately modify an existing set, add the overwrite option
cp -ov /dd/OS9Boot /dd/OS9Boot.nos9...
And remember, if the system ends up unbootable, you can mount it as a data drive, boot with any NitrOS9 image and manually cp -ov a set of known good files over the failed ones and try again.
You might think all this manual copying sounds a little old fashioned, and it is. OS9 has been described as Unix like, and here is an example of the Unix motto “Do one thing and do it well”. Swapboot allows a casual user to change boot files from a menu. It could be expanded to look like an application, adding code to validate the user as administrator, perform crash recovery, and add things like overwrite confirmation dialogs. But cp already does all that, it’s always available and well tested.
There used to be a second motto, “Keep it Simple Stupid”. But we have to reach back to a time before XML, before the windows registry hive, back to the 8 bit ASCII text file. Understood by man and machine, changeable with standard utility editors, and access controlled with file permissions. Sometimes there will be a fancy UI tool to edit these files, like MultiVue’s ‘control’ applet. But one can always cut to the chase and wade in there with a text editor.
Lets do that. /dd/SYS/env.file describes how you want your hardware used. Control manages some of this, in fact it’s the best thing for setting colors. But first, let’s swoop in there and set a few things...
MONTYPE = 0 for composite, 1 for RGB, 2 for monochrome
CONVTYP = text console resolution - 1 for 40x25, 2 for 80x25
CONXSIZ = text console width - usually 40 or 80 matching resolution
DEFTYPE = gshell startup screen resolution
6 for 320x200x4
7 for 640x200x4
8 for 320x200x16
PTRRES = 0 for low res joystick/mouse, 1 for hires mouse adapter
RBFDEV = disk drives or equiv - /dd /d0 /d1 /h1 /r1 etc
SCRDEV = printers and serial ports - /p /t1 /t2 etc
DATA = default data directory (usually /dd)
EXEC = default execution directory (usually /dd/CMDS)
To go further, check the file ÉNV_FILE_DOCUMENTATION.pdf for a complete list of tweaks you can make.
In addition to configuration data, you might want to change the things that load or run at startup. These are listed (surprise!) in the file startup. NitrOS9 makes this pretty easy to edit, starting with all the things. Just take out the bits you don’t need.
All you really need to do is link the command interpreter shell, to make sure this handy gadget doesn’t get dropped on the floor. But the time prompt is easy to skip, and some extra windows are cheap to own. A basic text startup is simply:
link shell
setime<>>>/1
shell i=/w1&
shell i=/w2&
Adding graphics doesn’t have to be painful. It’s true all those fonts and patterns take time to load, but you don't have to load then all! At the rock bottom, you can run 4 color Multivue by adding this one line:
cd sys; merge stdfonts stdpats_4 stdptrs
This sort of quick loading boot is good for file wrangling, organizing MultiVue, and getting right to tasks like text entry.
cp /dd/startup /dd/startup.fmgr
cp /dd/OS9Boot /dd/OS9Boot.fmgr
cp /dd/SYS/env.file /dd/SYS/env.file.fmgr
Between these two extremes is the best boot speed for the apps you normally use. I’m sure there is a doc but things are getting a little long now, so...
That leaves the actual glob of modules in OS9Boot. In the past, this was part of initial setup. NitrOS9 has automated or relocated many of the things we used to change in this file, so it’s not time to worry about it yet
But that time will come. My guess is next issue. Till then, see you on the online.
______ Home______ Links______ Support______ Writing Web Pages______