[Coco] Making OS-9/NitrOS9 more user friendly Facebook group discussion

William Carlin whcarlinjr at gmail.com
Thu Nov 16 20:40:24 EST 2017


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 640x320 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 80x24 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

[rel80_emuboot.bt]
****************************************
* 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:
http://www.gegereka.com/?query=OS9&bank=1


William H. Carlin, Jr.
whcarlinjr at gmail.com


More information about the Coco mailing list