Making OS-9/NitrOS9 more user friendly

William H. Carlin, Jr.

Recently there was a Facebook discussion in the Tandy Color Computer OS-9 / NitrOS9 group on the topic of increasing the user friendliness of OS-9/NitrOS9.  The initial post by William Schaub was in regards to his first succesful creation of a custom NirtOS9 boot disk.  Here is the link to the discussion: (https://www.facebook.com/groups/1929079184021683/permalink/1955505531379048/)

Admittedly there are steps that could be taken to make OS-9/NitrOS9 more user friendly.  We need to look at other Unix and Unix like operating systems of the era.  How user friendly are these systems?  About as friendly as OS-9.  Anyone what has worked with CP/M, FLEX, Unix, SCO, Solaris, AIX, etc. can attest to this.  Understanding comes with experimentation, reading thick manuals, and lots of help from experienced administrators.  OS-9 has esoteric command line tools with single letter switches.  Building a new boot disk that is customized to your specific hardware configuration, while easy to understand once you get the concepts, is not very intuitive if you have never worked with the aforementioned legacy systems.  The current method straight from the NitrOS9 distribution requires the editing a text file containing a list of the modules that make up the kernel, device drivers, and their corresponding device descriptors by putting an asterisk in front of modules you do not want to use and removing the asterisk from modules you do want to use.  You may also need to modify the script that contains a series of commands the will format and create the boot disk.  The current method can only create boot floppy disks and takes some creative modifications to bend it to your will if you want to boot from a hard drive or the CoCo SDC being sold by Ed Snider.

While the main topic of the Facebook discussion centered on the creation of boot disks, there are other glaring issues that compound the matter.  The command programs and system utilities are not consistent in terms of uniformity with the switches and parameters.  A glaring example is the dsave command:
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Syntax: Dsave [<opts>] [<to path>]
Usage : Generates procedure file to copy all files from the current directory to <to path>
Opts  :
  -b = make a system disk by using OS9boot if present
  -b=<path> = make system disk using path as source
  -i = indent for directory levels
  -l = do not process below the current level
  -m = do not include makdir commands in procedure file
  -n = don’t load copy/cmp
  -r = force rewrite of file on copy
  -s<num> = set copy size to num K
  -t = don’t issue tmode (pause/nopause)
  -v = verify copies
Examples:
   Create a script to copy /h0 to /h5 with forced rewrite:
       chd /h0; dsave -r /h5 > dsave.out
   Immediately copy /d0 to /d1 with a 24K copy buffer:
       chd /d0; dsave -s24 /d1 ! shell -p
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Notice the ‘-b’ switch can be used to make a system disk with the current data directory as the source or can be followed immediately by a ‘=’ to specify the path for a source disk that contains a boot track and OS9Boot file.  The ‘-s’ switch requires that you specify the memory size in kilobytes without a space after the switch.  This is inconsistent with the format of the other switches used in this utility and this is not the only command that does this.  Finally, you must specify the destination path as the last parameter.  Let us look at the format command:
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Syntax: Format <devname>
Usage : Initializes a NitrOS-9 diskette
Opts  :
  R   – Ready
  L   – Logical format only
  “disk name”
  1/2 – number of sides
  ‘No. of cylinders’   (in decimal)
  :Interleave value:   (in decimal)
  /Cluster size/       (in decimal)
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
The parameters do not use the dash ‘-‘ to delimit the switches.  Each parameter has it’s own delimiter.  The device to format must be specified as the first parameter.  Here is what I mean:
This command formats a standard 180K single sided floppy disk in drive 0 without extra prompting.
format /d0 “Scratch” 1 ’35’ R
The following hypothetical example would be more consistent with other similar operating systems:
format /d0 -v “Scratch” -s 1 -t 35 -r
where -v specifies the volume name, separated by a space, enclosed in quotes (because spaces can be used in the disk volume name)
where -s specifies the number of sides to format (single sided or double sided floppy disk) with the parameter separated by a space
where -t specifies the number of tracks (cylinders) on the disk with the parameter separated by a space
where -r specifies that you want to begin the format immediately without prompts (for procedure files)
these switches should be able to be given in any order along with the target device.
These inconsistencies greatly increase the complexity of using OS-9.  There is no “cannon” for how a program should accept parameters.  It is up to the whim of the individual programmer, especially when the utility is developed in assembly language and does not use the built in OS-9 kernel system calls to parse the command line and return the parameters back to the program.
Another great hurdle to ease of use with OS-9 is the scant live documentation.  OS-9 has a built in help facility the displays the most basic information for each system command.  The descriptions of the dsave and format commands above are straight from the built in OS-9 help command.  Sometimes there is a brief description provided below the syntax and sometimes not.  An example is the help for the smap command:
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
{N2|03}/DD:help smap
Syntax: SMap
Usage : Display NitrOS-9 system memory map (Level 2)
{N2|03}/DD: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 U U U U _ _ _
 5  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
 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:  44
   RAM Free in KBytes:  11
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
smap is a command relatively new to NitrOS9 and is not covered in the OS-9 users manual.  To a new user who has never used OS-9, what does the help text and the resulting output from running this command tell you?  What is the system map?  Can this information help you solve a problem you are having?  Is it related to a particular error message?  What do the dashes and ‘U’ characters mean?
Let’s look at a similar command that you can somewhat intuitively figure out what the output means:
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
{N2|03}/DD:help mmap
Syntax: MMap
Usage : Display NitrOS-9 memory map (Level 2)
{N2|03}/DD:mmap
     0 1 2 3 4 5 6 7 8 9 A B C D E F
  #  = = = = = = = = = = = = = = = =
 00  U U U U U M M U U M U U _ _ U U
 01  U U U U U U U U U U U U U U U U
 02  U U U U U U U _ _ _ M U _ _ _ _
 03  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ U
 04  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 05  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 06  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 07  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 08  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 09  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 0A  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 0B  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 0C  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 0D  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 0E  _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
 0F  _ _ _ _ _ _ _ _ _ _ _ _ _ _ U U
  Block Size: 8192
 Free Blocks: 214
 KBytes Free: 1712
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
The output from mmap displays the current memory map usage for the system at run time.  In this case, a CoCo 3 with 2 megabytes of memory.  You can assume that ‘U’ stands for a used memory block and the dash ‘-‘ is free block of memory.  What does the ‘M’ stand for?  I have been using NitrOS9 for over ten years and I still can’t tell you what the ‘M’ stands for.  If I was really determined to find out I could go to the NitrOS9 distribution web site and look at the source code and hope that it is commented enough to figure it out.  If not, I could spend some time trying to figure out what the source code is doing.  Compare that to the OS-9 Technical Reference Manuals and maybe I could determine what the ‘M’ stands for.  However, Joe “new CoCo user” who initially wants to just play Kings Quest 3 and then is later curious about what this OS-9 thing is all about will have absolutely no clue what in the world the ‘M’ stands for.  If he is unfamiliar with hexadecimal then he may be totally screwed trying to figure out what mmap is telling him about the OS-9 memory usage.  Joe’s only recourse is to ask the mail list, possibly riling the annoyance some that are tired of seeing the same question posed 75 times over the last decade, and possibly chastising Joe for not Googling the archives of the mail list first to find the answer for himself.  The only saving grace is that the free space and number of free blocks are displayed in kilobytes using base 10 numbers.  Not so if you use the mfree command:
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
{N2|03}/DD:help mfree
Syntax: Mfree
Usage : Displays the amount of free RAM memory
{N2|03}/DD:mfree
 Blk Begin   End   Blks  Size
 — —— —— —- ——
   C  18000  1BFFF    2    16k
  27  4E000  53FFF    3    24k
  2C  58000  7DFFF   13   152k
  40  80000 1FBFFF   BE  1520k
                   ==== ======
            Total:   D6  1712k
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Joe “new CoCo NitrOS9 user” can readily determine that he has 1712 kilobytes of free memory because that is in base 10.  If he want to know he has 214 free blocks of memory free then he needs to convert the hexadecimal value “D6” to base 10.  With a little simple division he may be able to determine that a block of memory consists of 8 kilobytes.
During the late 90s it appears that there was a great deal of OS-9 freeware and shareware development going on that was available on BBS systems and commercial online services like Delphi and Compuserve.  Unfortunately for me, I had already moved on to the IBM PC platform.  During that time a scaled down version of the “mroff” text paging system was developed.  Along with a primitive version of the Unix “man” help system.  Without access to the message forums of that era I can somewhat determine this was created to have a live “on CoCo” version of the documentation for the Carl Krieder clib library allowing for easy reference that did not rely on thumbing though printed documentation, usually from a dot matrix printer.  Also included in the man/mroff archive are more extensive versions help for the standard OS-9 commands of the era.  The locations of expected files are hard coded into the program but if you dig around you can find the C source code and change those default locations to wherever you would like and even add some additional functionality if you were so inclined.
Since there are existing Unix/Linux tools for the easy creation of these mroff compatible files I believe that an effort should be made to document as completely as possible all classic OS-9 commands and their modern NitrOS9 equivalents.  A tool should be created to pull the short description, syntax, and a portion of the more complete description from those mroff files and compile that into the classic /dd/sys/helpmsg format that is the standard OS-9 help system.  The man program should to be revamped and expanded to be more like their Unix/Linux equivalents.  Institute the existing equivalent section numbers.  Have a configuration file located in the standard OS-9 directory (/dd/sys) to customize the location of the man pager files and any other applicable additions like the Carl Kreider c library (clib) so users have the flexibility to keep them where they are or put them where they want to.  With SDC hard drive emulation, MESS and VCC hard drive emulation, and DriveWire I think we can afford to make more use of  configuration files, both system and user, to customize the behavior of system components.  These configuration files will help to eliminate the hard coded directories in legacy programs and make the man pager system more flexible.
Back to my perceived inconsistencies of the standard OS-9/NitrOS9 commands.  It is of my opinion that most, if not all, commands should be rewritten to have a more consistent usage of command line switches while maintaining the backwards compatibility of key commands that would break legacy programs and process files (tmode anyone).  Additionally, to make the system as easy as possible for new users, adding the double dash ‘–‘ full text commands like in Linux.  Any built in help with a -h or –help would execute the help command to display the existing help for that command that resides in /dd/help/helpmsg.  This will eliminate the need to store the help text inside of the module binary.  If more information is needed about the command then the user can look up the man page.  Implementing these proposed changes needs to be considered carefully to try and keep the length of the module as close to the existing legacy module as possible so as not to take up an extra 8k block of memory.
If the community decides that expanding the scope of live on the system help is a direction we want to go in, we should also consider more extensive descriptions of error messages.  A simple one line description of the error that corresponds to the error number generated by the OS-9/NitrOS9 kernel is all that we currently have.  A more detailed description of the error in “plain English” with common causes and any generic solutions would go a long way.  The difference between error “207 – Memory Full” and error “237 – RAM Full” is not readily apparent to Joe “new CoCo NitrOS9 user”.  Error 207 indicates that the system memory RAM is full.  The typical result is that a new process cannot be forked by the kernel.  Error 237 indicates that there are no more pages, if using OS-9/NitrOS9 Level 1, or 8k blocks, if using OS-9/NitrOS9 Level 2, available to load another module into memory or assign memory for program data.  More descriptive text would help the new user determine what the problem might be without having to resort to asking the mail list the same questions that have been posed for years.
Default system behavior and custom user behavior should also be considered.  If a new user wants to see numbers in base 10 then that should be an option.  If an old school OS-9 user wants to keep everything in hexadecimal, that should also be an option.  If you want to be super hard core and see everything in octal, that too could also be an option.  Much like the dot ‘.’ configuration files of Linux, like ‘.bashrc’, they can be used for specific user customization that override system defaults to create a tailored experience based on user preference.
Don’t take my rather lengthy email wrong.  I’m not here to dump on OS-9/NitrOS9.  I love OS-9.  I consider it to be a harmony of mathematical precision that demonstrates the power of the 6809/6309.  It is an amazing feat for the era considering there is no memory protection that can keep a rouge process from overwriting the kernel and it’s data areas or changing the system memory block map if using OS-9/NitrOS9 Level 2.   I’m also not coming as some kind of “expert” who wants to dictate my vision for the future of OS-9/NitrOS9.  This is our operating system.  This is a community effort.  Comments and discussion are certainly welcome.  I also don’t want to dictate the direction of the core NitrOS9 system developers.  None of the core operating system functionality should ever be modified to fit these proposed changes.  Backwards compatibility with existing legacy software should be and always should be paramount.  That is the beauty of NitrOS9.  You want something new?  Build a module to fit that need.  You want new core functionality?  Make a kernel extension like the OS9Pt2 that adds text descriptions to error messages or OS9Pt3 that adds a core dump for debugging purposes.  You don’t like how the standard dir command displays the directory.  Make a new one.  There are plenty examples of those.  I think I have at least 6 programs that display the directory in a different manner.  Some are Y2k compliant and some are not.  Some of these are so good that patching them to display Y2k compatible disk, file, and folder dates would be another great idea.
New comers to OS-9/NitrOS9 are attracted by the games and should be wowed by the power of our multitasking, multi-user operating system. They should not be turned off by the perception that OS-9/NitrOS9 is difficult to use and understand.
There is a shining light at the end of the tunnel for those new OS-9/NitrOS9 users.  That shining light is Bill Pierce’s MShell.  For those who do not know, MShell is graphical file manger for OS-9/NitrOS9 that is similar in functionality to Norton Commander for MS-DOS or Directory Opus for Amiga.  The program runs on a 640×320 2 color graphics screen and can be used with both mouse and/or keyboard.  MShell is several times faster than the file management capabilities of MultiVue.  How this ties into making OS-9/NitrOS9 more user friendly is MShell’s modular design.  There are already a number of proposed features like a memory test, a drive check, a configuration editor, a system manager, running BootMajik, running Sound Chaser, running CoCoIDE, a DriveWire 4 Manager, and a text editor.  These proposed features can reduce a lot of the complexity of configuring OS-9/NitrOS9 and making boot disks or modifications to the current boot, if booting from a hard drive or from DriveWire 4, a lot easier than using scripts and module lists or some of the other command line and text mode tools currently available.  Hopefully Bill will include some kind of plug-in modules function that will allow others to add their own program, available from a pull down menu.
I want to touch on one more subject.  That is open sourcing the majority of existing and in progress applications and utilities.  Let’s face it, us OS-9/NitrOS9 guys are not getting any younger.  Anyone could get run over by the proverbial bus at any time.  Surviving spouses may not know what you are working on.  Without specific instructions left behind in our wills, who knows what will happen to unfinished code or any rare hardware that we are holding on to.  Often after the grieving process these things could simply be thrown in the trash and lost forever.  That is why I think it is important to make arrangements for passing on hardware to someone in the community and to have software projects on one of the open source Git Hubs, the Color Computer Archive, or on archive.org.
Ok, that is it for my opinions on the state of OS-9/NitrOS9 in 2017.
As promised, here are my custom boot lists and make boot scripts.
Basic description of the type of system being built:
HDB-DOS default disk, ide 0-1, DriveWire Becker interface with network drives 0-3, DriveWire network printer, DriveWire network serial devices 1-8
Standard comments and expanded comments denoted by single and double asterisks respectively
[emuh0_ide_dw_becker.bl]
***************************************
* NitrOS-9 Level 2 CoCo 3 Bootlist
*
* NitrOS-9 Level 2 V3.3.0 HD6309 Enhanced
*
* This bootlist is presented as an example for creating custom bootfiles.
* A module may be excluded from the bootfile if an asterisk (*) is the
* first character of the line.
*
* Modified 6/14/2014 By William Carlin, Jr.
* Included Robert Gault’s HDB-DOS hard disk modules for MESS/VCC
* emulated systems.
*
***************************************
* Kernel/System Section
*
* These modules are mandatory.
* The main portion of the NitrOS-9 Kernel
../MODULES/KERNEL/krnp2
* Kernel subsystem for full text error messges (Optional)
../MODULES/KERNEL/krnp3_perr
* Kernel debugging subsystem. Performs MC6809/HD6309 registry dumps (Optional)
*../MODULES/KERNEL/krnp4_regdump
* Input/Output Manager
../MODULES/SYSMODS/ioman
* System Initialization Code
../MODULES/SYSMODS/init
*
***************************************
* CDF Section (HawkSoft)
*
* Not sure but SCSI and IDE drivers for a CD file system?
* Compact Disc File Manager?
*
*../MODULES/CDF/cdf.mn
*
* CDF descriptors – select as needed
* SCSI descriptors (IDs 0-6)
*../MODULES/CDF/sc0.dd
*../MODULES/CDF/sc1.dd
*../MODULES/CDF/sc2.dd
*../MODULES/CDF/sc3.dd
*../MODULES/CDF/sc4.dd
*../MODULES/CDF/sc5.dd
*../MODULES/CDF/sc6.dd
* IDE descriptors (master/slave)
*../MODULES/CDF/ic0.dd
*../MODULES/CDF/ic1.dd
*
***************************************
* Random Block File Manager
*
* RBF Section
*
../MODULES/RBF/rbf.mn
*
* DriveWire Section (Network Drives)
*
* DriveWire driver
../MODULES/RBF/rbdw.dr
* Serial bit banger module
*../MODULES/RBF/dwio.sb
* Becker IP interface for MESS/VCC emualated systems
../MODULES/RBF/dwio_becker.sb
* DriveWire descriptors – select as needed
** Use DriveWire network disk /x0 as your default drive /dd
*../MODULES/RBF/ddx0.dd
** Drivewire network disks 0-3
../MODULES/RBF/x0.dd
../MODULES/RBF/x1.dd
../MODULES/RBF/x2.dd
../MODULES/RBF/x3.dd
*
* HDB-DOS hard disk modules for MESS/VCC emulated systems (Robert Gault)
*
* HDB-DOS hard disk device driver for MESS/VCC
../MODULES/RBF/EmuDsk.dr
* HDB-DOS hard disk device descriptors
** Use HDB-DOS /h0 as you default drive /dd
../MODULES/RBF/ddh0_emudsk.dd
../MODULES/RBF/h0_emudsk.dd
*
* SuperDriver Package (Cloud-9 product)
../MODULES/RBF/rbsuper.dr
* Select Low level SCSI and/or IDE driver
*../MODULES/RBF/lltc3.dr
../MODULES/RBF/llide.dr
* SuperDriver descriptors – select as needed
* TC^3 SCSI DD descriptor (ID 0)
*../MODULES/RBF/dds0_tc3.dd
* TC^3 SCSI descriptors (IDs 0-6)
*../MODULES/RBF/s0_tc3.dd
*../MODULES/RBF/s1_tc3.dd
*../MODULES/RBF/s2_tc3.dd
*../MODULES/RBF/s3_tc3.dd
*../MODULES/RBF/s4_tc3.dd
*../MODULES/RBF/s5_tc3.dd
*../MODULES/RBF/s6_tc3.dd
* TC^3 SCSI HDB-DOS descriptor
** This module can be used to access RSDOS and OS9 disks contained in SCSI HDB-DOS drives 0-255
*../MODULES/RBF/sh_tc3.dd
* IDE DD descriptor (Master)
*../MODULES/RBF/ddi0_ide.dd
* IDE descriptors (master/slave)
../MODULES/RBF/i0_ide.dd
../MODULES/RBF/i1_ide.dd
* IDE HDB-DOS descriptor
** This module can be used to access RSDOS and OS9 disks contained in IDE HDB-DOS drives 0-255
*../MODULES/RBF/ih_ide.dd
*
* WD1773 floppy support for Tandy and compatible disk controllers
../MODULES/RBF/rb1773.dr
* WD1773 floppy support for Disto Super Controller II
*../MODULES/RBF/rb1773_scii_ff74.dr
*../MODULES/RBF/rb1773_scii_ff58.dr
* Floppy device descriptors
** 35, 40, and 80 track floppy disk device descriptors
* DD – default device – choose one if needed
*../MODULES/RBF/ddd0_35s.dd
*../MODULES/RBF/ddd0_40d.dd
*../MODULES/RBF/ddd0_80d.dd
* D0 – drive 0 – choose one if needed
*../MODULES/RBF/d0_35s.dd
*../MODULES/RBF/d0_40d.dd
../MODULES/RBF/d0_80d.dd
* D1 – drive 1 – choose one if needed
*../MODULES/RBF/d1_35s.dd
*../MODULES/RBF/d1_40d.dd
../MODULES/RBF/d1_80d.dd
* D2 – drive 2 – choose one if needed
*../MODULES/RBF/d2_35s.dd
*../MODULES/RBF/d2_40d.dd
*../MODULES/RBF/d2_80d.dd
* D3 – drive 3 – choose if needed
*../MODULES/RBF/d3_35s.dd
*
* RAMDisk driver
../MODULES/RBF/rammer.dr
* RAMDisk descriptors – select as needed
** Make the ram disk the default drive /dd if needed
*../MODULES/RBF/ddr0_8k.dd
*../MODULES/RBF/ddr0_96k.dd
*../MODULES/RBF/ddr0_128k.dd
*../MODULES/RBF/ddr0_192k.dd
** 8k, 96k, 128k, and 192k fixed sized ram disks
*../MODULES/RBF/r0_8k.dd
*../MODULES/RBF/r0_96k.dd
*../MODULES/RBF/r0_128k.dd
../MODULES/RBF/r0_192k.dd
*
* MyRAM RAMDisk driver (Gene Haskett)
*../MODULES/RBF/myram.dr
* MyRAM RAMDisk device descriptor
*../MODULES/RBF/mr0.dd
*
* Memory device descriptor
** This is required by some programs for direct access to memory
*../MODULES/RBF/md.dd
*
***************************************
* Sequential Character File Manager
*
* SCF Section
*
../MODULES/SCF/scf.mn
*
* CoCo 3 I/O sub-drivers
** required drivers for the input/output subsystem; displaying characters on the text screen and the built in CoCo keyboard
../MODULES/SCF/vtio.dr
../MODULES/SCF/keydrv_cc3.sb
* Sound module: CoCo 3 built-in sound generator
../MODULES/SCF/snddrv_cc3.sb
* Joystick modules: choose joy for hi-res joystick adapter or
* (M)icrosoft or (L)ogitech mouse using 6551 or 6552 ACIA
../MODULES/SCF/joydrv_joy.sb
*../MODULES/SCF/joydrv_6551M.sb
*../MODULES/SCF/joydrv_6552M.sb
*../MODULES/SCF/joydrv_6551L.sb
*../MODULES/SCF/joydrv_6552L.sb
*
* CoGrf/CoWin subroutine module
* Use CoWin with Multi-Vue; use CoGrf
* for basic text and graphic window support..
* Select only one.
../MODULES/SCF/cogrf.io
*../MODULES/SCF/cowin.io
*
* CoVDG I/O subroutine module
* Select one or both
*../MODULES/SCF/covdg.io
../MODULES/SCF/covdg_small.io
*
* Select only one term descriptor
** 32, 40, 80 column CoCo screens; bit banger and ACIA (RS232 Pak) terminal support
*../MODULES/SCF/term_vdg.dt
*../MODULES/SCF/term_win40.dt
../MODULES/SCF/term_win80.dt
*../MODULES/SCF/term_scbbt.dt
*../MODULES/SCF/term_sc6551.dt
*
* Select as many window descriptors as needed
** CoCo 3 window device descriptors
../MODULES/SCF/w.dw
../MODULES/SCF/w1.dw
../MODULES/SCF/w2.dw
../MODULES/SCF/w3.dw
../MODULES/SCF/w4.dw
../MODULES/SCF/w5.dw
../MODULES/SCF/w6.dw
../MODULES/SCF/w7.dw
../MODULES/SCF/w8.dw
../MODULES/SCF/w9.dw
../MODULES/SCF/w10.dw
../MODULES/SCF/w11.dw
../MODULES/SCF/w12.dw
../MODULES/SCF/w13.dw
../MODULES/SCF/w14.dw
../MODULES/SCF/w15.dw
*
* Select as many VDG window descriptors as needed
** 32 column screens for backwards compatiblity for some programs and for games
../MODULES/SCF/v1.dw
../MODULES/SCF/v2.dw
*../MODULES/SCF/v3.dw
*../MODULES/SCF/v4.dw
*../MODULES/SCF/v5.dw
*../MODULES/SCF/v6.dw
*../MODULES/SCF/v7.dw
*
* Serial port drivers
* CoCo Bit-Banger terminal port
*../MODULES/SCF/scbbt.dr
*../MODULES/SCF/t1_scbbt.dd
* 6551 ACIA
*../MODULES/SCF/sc6551.dr
*../MODULES/SCF/t2_sc6551.dd
*../MODULES/SCF/t3_sc6551.dd
* Tandy Modem Pak
*../MODULES/SCF/modpak.dr
*../MODULES/SCF/m1.dd
*../MODULES/SCF/m2.dd
*
* Printer drivers (bit banger)
* ../MODULES/SCF/scbbp.dr
* ../MODULES/SCF/p_scbbp.dd
*
* DriveWire 3 Printer drivers
../MODULES/SCF/scdwp.dr
../MODULES/SCF/p_scdwp.dd
*
* DriveWire Virtual Channel Driver (serial networking)
../MODULES/SCF/scdwv.dr
*../MODULES/SCF/term_scdwv.dt
../MODULES/SCF/n_scdwv.dd
../MODULES/SCF/n1_scdwv.dd
../MODULES/SCF/n2_scdwv.dd
../MODULES/SCF/n3_scdwv.dd
../MODULES/SCF/n4_scdwv.dd
../MODULES/SCF/n5_scdwv.dd
../MODULES/SCF/n6_scdwv.dd
../MODULES/SCF/n7_scdwv.dd
../MODULES/SCF/n8_scdwv.dd
*../MODULES/SCF/n9_scdwv.dd
*../MODULES/SCF/n10_scdwv.dd
*../MODULES/SCF/n11_scdwv.dd
*../MODULES/SCF/n12_scdwv.dd
*../MODULES/SCF/n13_scdwv.dd
*
* /Z DriveWire remote NitrOS9 terminal
*../MODULES/SCF/term_z_scdwv.dt
*../MODULES/SCF/z1_scdwv.dd
*../MODULES/SCF/z2_scdwv.dd
*../MODULES/SCF/z3_scdwv.dd
*../MODULES/SCF/z4_scdwv.dd
*../MODULES/SCF/z5_scdwv.dd
*../MODULES/SCF/z6_scdwv.dd
*../MODULES/SCF/z7_scdwv.dd
*
* DriveWire 4 MIDI device descriptor
../MODULES/SCF/midi_scdwv.dd
*
* VRN is a driver module used by certain games, including King’s Quest III,
* Leisure Suit Larry and Flight Simulator II.  A /nil descriptor is also
* supported.
../MODULES/SCF/vrn.dr
*../MODULES/SCF/vi.dd
*../MODULES/SCF/ftdd.dd
*
* /NIL device descriptor
** this device requires the above vrn device driver and allows you to dump SCF output to a nothing device
../MODULES/SCF/nil.dd
*
***************************************
* Pipe Manager
*
* Pipe Section
*
* Pipes are a useful but optional part of a system.
../MODULES/PIPE/pipeman.mn
../MODULES/PIPE/piper.dr
../MODULES/PIPE/pipe.dd
*
***************************************
* Clock Section
*
* Select one clock module depending upon your power line frequency
* (60Hz = USA/Canada; 50Hz = Europe, Australia)
../MODULES/CLOCKS/clock_60hz
*../MODULES/CLOCKS/clock_50hz
* Select one clock2 module that supports your real-time clock, if any.
* Besides support for the internal software clock, the following
* hardware clocks are supported: Burke & Burke, Disto 2-N-1, Disto 4-N-1,
* Eliminator, Harris, SmartWatch, Cloud-9 (SuperIDE), the MESS emulator, Jeff
* Vavasour’s CoCo emulator and DriveWire
*../MODULES/CLOCKS/clock2_soft
*../MODULES/CLOCKS/clock2_bnb
*../MODULES/CLOCKS/clock2_disto2
*../MODULES/CLOCKS/clock2_disto4
*../MODULES/CLOCKS/clock2_elim
*../MODULES/CLOCKS/clock2_harris
*../MODULES/CLOCKS/clock2_smart
*../MODULES/CLOCKS/clock2_jvemu
*../MODULES/CLOCKS/clock2_messemu
*../MODULES/CLOCKS/clock2_cloud9
../MODULES/CLOCKS/clock2_dw
*
***************************************
* System Kick-Start Module
*
* Choose which startup module you wish to use. (sysgo_dd is recommended
* for most configurations.)
*
* Alternatively, this module can reside in the root directory of the
* boot device, saving precious system RAM.
*../MODULES/SYSMODS/sysgo_dd
*../MODULES/SYSMODS/sysgo_h0
* Use for /dd and /DD/SYS/sysgo.cfg configutation file
*../MODULES/SYSMODS/sysgo_bd
[END]
This is my modified make boot file with extra comments for new users denoted by double asterisks **
[mb.emuh0_ide_dw_becker]
** turn off printing the executing line in the procedure file
-t
** do not stop executing the procedure file when an error occurs
-x
* turn off pausing output when the screen has filled with text “.1” indicates the current terminal
tmode .1 pau=0
echo
echo * NitrOS-9 Level 2 V3.3.0 HD6309 Boot Creation Script
echo *
echo * This script creates a bootable floppy disk image
echo *
echo * The resulting disk will boot NitrOS-9 from /d0 and then
echo * complete the boot process from /dd.  /dd is set to the
echo * hard drive /h0 of the emulated system.
echo *
prompt Insert a blank disk in /d0 and press a key:
echo *
echo * Step 1: Format disk in /d0
format /d0 “NitrOS-9 L2 V3.3.0 HD6309 Boot” 1 ’35’ L R
echo *
echo * Step 2: Create a custom boot track with hard drive boot
echo *         support for emulated systems and 80×24 boot screen
** use grep to output to the screen the modules that will be merged into the boot track
grep -vf ‘\*’ ../modules/boottrack/rel80_emuboot.bt
** build the boot track by parsing the boot track module list and merging that into the bttemp file
grep -vf ‘\*’ ../modules/boottrack/rel80_emuboot.bt ! merge -z >-/dd/tmp/bttemp
echo *
echo * Step 3: Add the system modules to the bootfile and
echo *         write the custom boot track to the disk
** use grep to output to the screen the modules that will be included in the OS9Boot file
grep -vf ‘\*’ ../bootlists/emuh0_ide_dw_becker.bl
echo os9gen…
** generate the boot track and the OS9Boot modules
os9gen /d0 -t=/dd/tmp/bttemp<../BOOTLISTS/emuh0_ide_dw_becker.bl
del /dd/tmp/bttemp
echo *
echo * Step 4: Populate the disk with essential files
copy ../MODULES/SYSMODS/sysgo_bd /d0/sysgo
makdir /d0/CMDS
copy -w=/d0/CMDS ../CMDS/Shell ../CMDS/grfdrv
echo *
echo * We’re done
echo *
echo * Do not forget to copy the new boot disk to your HDB-DOS
echo * hard drive from RS-DOS and then run the LINK.BAS program
echo * to link the NitrOS-9 partition location.
[END]
This is my new boot track list that is parsed by grep to build the boot track
****************************************
* NitrOS-9 Level 2 CoCo 3 Boot Track
*
* NitrOS-9 Level 2 V3.3.0 HD6309 Enhanced
*
* This boot track list is an example for creating
* custom boot tracks.  A module may be excluded if
* preceded by an asterisk (*)
*
****************************************
* The REL module initializes the video display
* accordingly and passes control to the boot
* module.  Select only one.
*
* 32 column VDG display
*../MODULES/BOOTTRACK/rel_32
* 40 column GIME display
*../MODULES/BOOTTRACK/rel_40
* 80 column GIME display
../MODULES/BOOTTRACK/rel_80
* 32 column VDG PAL display
*../MODULES/BOOTTRACK/rel_32_50hz
* 40 column GIME PAL display
*../MODULES/BOOTTRACK/rel_40_50hz
* 80 column GIME PAL display
*../MODULES/BOOTTRACK/rel_80_50hz
*
****************************************
* The boot module locates the boot file
* (usually OS9Boot) located in the root of
* the appropriate boot device.  Select only one.
*
* floppy disk boot 6ms step rate (fast)
*../MODULES/BOOTTRACK/boot_1773_6ms
* floppy disk boot 30ms step rate (standard)
*../MODULES/BOOTTRACK/boot_1773_30ms
* Burke & Burke hard disk boot
*../MODULES/BOOTTRACK/boot_burke
* Cloud9 RAM PAK boot
*../MODULES/BOOTTRACK/boot_rampak
* Western Digital 1002 hard disk boot
*../MODULES/BOOTTRACK/boot_wd1002
* DriveWire boot
*../MODULES/BOOTTRACK/boot_dw
* DriveWire Becker interface boot (MESS/VCC emulation)
*../MODULES/BOOTTRACK/boot_dw_becker
* DriveWire Arduino boot
*../MODULES/BOOTTRACK/boot_dw_arduino
* Cloud9 tc3 SCSI boot
*../MODULES/BOOTTRACK/boot_tc3
* Cloud9/Glenside IDE boot
*../MODULES/BOOTTRACK/boot_ide
* Cloud9 ROM boot
*../MODULES/BOOTTRACK/boot_rom
* Virtual Hard Disk boot (MESS/VCC emulation)
../MODULES/BOOTTRACK/boot_emudsk
******************************************
* NitrOS-9 kernel (mandatory)
../MODULES/BOOTTRACK/krn
[END[
The grep utility can be found in many available archives online.  I found grep by itself on this site:
William H. Carlin, Jr.

One thought on “Making OS-9/NitrOS9 more user friendly

  • December 11, 2017 at 9:49 pm
    Permalink

    This is a great write up, thanks for doing it. I wasn’t able to read it all, because it got very technical, but the essence of it is good, and I could follow.

    Are you aware of the “Ease of Use” edition of NitrOS9 that Curtis Boyle, Bill Nobel, David Ladd, and company are working on? It’s a streamlined image that’s designed to boot either from the CoCoSDC or MAME/Emulator VHD, it’s got simplified drivers at the moment, and an improved G-Shell with auto-launch icons, it’ meant for anybody to get up and running with the OS without “having” to be technical, it’s a great idea, and it’s making progress, and I think it’s addressing some of the things you’re bringing up here.

    Thanks for taking the time to share your knowledge.

Leave a Reply


Copyright © 2017 The Rainbow Online. All rights reserved.
Magazine Credits