Category Archives: NitrOS9

Building KenTon/LR-Tech SCSI drivers for NitrOS-9

While the NitrOS-9 project does contain drivers for the KenTon and LR-Tech hard drive interfaces, they are not built or included by default. I wanted to document the steps I took to build and use the KenTon interface under the current NitrOS-9.

Basically, you will be modifying a few makefiles to enable the building of the low level booter, device drivers and device descriptors. If I recall, the changes are the same for each of these makefiles, but you only need to make them for the one you are using. If you are only using the KenTon drivers under NitrOS-9 Level 2 on a CoCo 3, just do that makefile.

  • nitros9/level1/coco1/modules/makefile
  • nitros9/level2/coco3/modules/makefile
  • nitros9/level3/coco3/modules/makefile

Step 1 – Add “KTLRFLAGS”.

These generate the define used inside the generic SCSI source code so it knows which code to build.

TC3FLAGS = $(AFLAGS) -DTC3=1 $(FLAGS)
KTLRFLAGS = $(AFLAGS) -DKTLR=1 $(FLAGS)
IDEFLAGS = $(AFLAGS) -DIDE=1 $(FLAGS)

Step 2 – Add “boot_ktlr” to the BOOTER list.

This makes it a dependency so make will look for it and try to build it. I added it in the middle of the list so when you get updates, it will be easier for the “diff” tool to see what has changed.

BOOTERS = boot_1773_6ms boot_1773_30ms \
 boot_burke boot_rampak boot_wd1002 boot_dw \
 boot_tc3 boot_ide boot_rom boot_dw_becker \
 boot_ktlr \
 boot_dw_arduino boot_dw_38400 boot_sdc

Step 3 – Add the modules to the RBF list.

RBF = rbf.mn \
 rbdw.dr dwio.sb dwio_38400.sb dwio_becker.sb dwio_arduino.sb \
 rb1773.dr rb1773_scii_ff74.dr rb1773_scii_ff58.dr \
 ddd0_35s.dd d0_35s.dd d1_35s.dd d2_35s.dd d3_35s.dd \
 ddd0_40d.dd d0_40d.dd d1_40d.dd d2_40d.dd \
 ddd0_80d.dd d0_80d.dd d1_80d.dd d2_80d.dd \
 ddx0.dd x0.dd x1.dd x2.dd x3.dd \
 rbsuper.dr lltc3.dr llide.dr llcocosdc.dr \
 llktlr.dr \
 dds0_ktlr.dd s0_ktlr.dd s1_ktlr.dd s2_ktlr.dd s3_ktlr.dd s4_ktlr.dd \
     s5_ktlr.dd s6_ktlr.dd sh_ktlr.dd \
 ddi0_ide.dd i0_ide.dd i1_ide.dd ih_ide.dd \
 dds0_tc3.dd s0_tc3.dd s1_tc3.dd s2_tc3.dd s3_tc3.dd s4_tc3.dd \
     s5_tc3.dd s6_tc3.dd sh_tc3.dd \
 ddsd0_cocosdc.dd sd0_cocosdc.dd sd1_cocosdc.dd

Step 4 – Add the dependency to build the driver:

# TC^3 SCSI Booter
boot_tc3: boot_scsi.asm
 $(AS) $(ASOUT)$@ $< $(TC3FLAGS)

# KenTon/LR-Tech SCSI Booter
boot_ktlr: boot_scsi.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS)
 
# SuperIDE/Glenside IDE Booter
boot_ide: boot_ide.asm
 $(AS) $(ASOUT)$@ $< $(IDEFLAGS)

Step 5 – Add the dependencies for building each descriptor. I put mine after the existing TC3 SCSI driver stuff:

sh_tc3.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(TC3FLAGS) $(HDBDOS)

# KenTon/LR-Tech SCSI Descriptors
dds0_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID0) -DDD=1

s0_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID0) $(SCSI_HD)

s1_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID1) $(SCSI_HD)

s2_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID2) $(SCSI_HD)

s3_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID3) $(SCSI_HD)

s4_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID4) $(SCSI_HD)

s5_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID5) $(SCSI_HD)

s6_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(ID6) $(SCSI_HD)

sh_ktlr.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(KTLRFLAGS) $(HDBDOS)

# IDE Descriptors
ddi0_ide.dd: superdesc.asm
 $(AS) $(ASOUT)$@ $< $(IDEFLAGS) $(MASTER) -DDD=1

Now those modules should be built and made available for including in your bootfile. You could do this by editing the bootlist you are using:

  • nitros9/level1/coco1/bootlists/standard.bl
  • nitros9/level2/coco3/bootlists/standard.bl
  • nitros9/level3/coco3/bootlists/standardL3.bl

Or you could use a bootfile editor like ezgen to add them to your current bootfile. Or, if you were just doing something temporary (like I was, to pull data from hard drives), you could just merge the needed modules together and dynamically load them when you need to use the SCSI drive.

Hopefully this will be helpful to someone else.

Creating a RaspberryPi DriveWire server

  • 2016/05/12  This is a work-in-progress article I originally wrote on February 8, 2015, but never completed. The other night I was trying to look up my notes to help Curtis B. with a NitrOS-9 boot disk and I realized I never completed this. I will try to finish it when I have a moment.

Summary

To get DriveWire 4 server running on a Raspberry Pi, you will do the following:

  1. Download the DriveWire server to the Pi and unzip it:
    wget http://sites.google.com/site/drivewire4/download/DriveWire4_4.3.3.zip
    unzip DriveWire4_4.3.3.zip
    cd DriveWire4_4.3.3.zip
  2. Edit the config.xml file to default to your serial port on your Pi in <deviceType> and <serialDevice>. (i.e., “serial” and “/dev/ttyUSB0“)
  3. Run the server with no user interface:
    java -jar DW4UI.jar -noui
  4. On the CoCo, load the needed DriveWire modules from NITROS9/6x08L2/MODULES/RBF:
    dwio.sb, rbdw.dr, x0.dd up to x3.dd
  5. Use the “dw” command to test things by creating a blank disk image:
    dw disk create 0 /home/pi/test.dsk
    format /x0
    dir /x0
  6. Customize your boot disk to include the modules you want and read the documentation to learn how to use all the cool virtual terminals, MIDI and other neat features.

And now, the long version…

Materials Needed

  1. Raspberry Pi B (or B+, or probably the Pi 2 B). I did all these steps on a B.
  2. USB keyboard (a mouse makes things easier, but I do not have one so all of these tips will just use a Pi, keyboard and HDMI TV/monitor).
  3. Compatible* 8GB SD card (or larger).
  4. Ethernet cable to hook the Pi to the Internet. (Required if you plan to do the network install of NOOBS LITE).
  5. WiFi (with a supported USB dongle) or Ethernet is needed later for downloading the DriveWire software and updates, but there are ways to do all of this without any Internet access if you start with the full NOOBs installer.
  6. Compatible* USB serial adapter (or TTL->RS232 converter for use with the built in UART pins of the Pi).

Preparation on Windows/Mac/Linux

  1. Download the “NOOBS” installation for Raspberry Pi (currently 1.3.12). You can get the full NOOBS (780MB, just unzip and copy to the SD card and boot), or the NOOBS LITE (22.8MB) version.
    • NOOBS LITE can also be used. It is a much smaller download, but requires the Pi to be hooked up to the internet via Ethernet to download the rest of the OS files which is about 2355MB.
      http://www.raspberrypi.org/downloads/
  2. Unzip the files, then copy them over to a freshly formatted SD card.

Preparation on the Raspberry Pi

  1. Boot the Pi using this card. You will see a menu of operating systems you can install. Choose “Raspbian [RECOMMENDED]” at the top by using the arrow keys and SPACE to select. You may also wish to hit “l” for Language and set it to “English (US)” or your preference, and “9” for Keyboard and select yours. Once Raspbian is selected, press “I” for install. It will ask if you are sure you wish to overwrite the SD card. Select “Y” for yes.
    • NOOBS LITE: The Pi will then download the Raspbian image (2.3GB), then install.
    • NOOBS: The Pi will then install.
  2. The Pi will (eventually) reboot and after a bit, you get a DOS-like screen for the raspi-config utility. Arrow over to Finish and press ENTER. You will not be at the Pi shell prompt.
    pi@raspberrypi ~ $
  3. At this point, I like to do a full reboot to make sure everything is working properly:
    sudo reboot
  4. On a reboot, you won’t go directly to a shell prompt. You will get a login prompt. The default account is:
    username: pi
    password: rasbperry.
    Log in and you will get back to the shell prompt. You will be in the home directory for user “pi”.
  5. Now we need to download the DriveWire 4 software. Note the filename will change when DriveWire is updated, so check the official site if this does not work.
    wget http://sites.google.com/site/drivewire4/download/DriveWire4_4.3.3.zip
  6. After the zip file is download, you can extract it by typing:
    unzip DriveWire4_4.3.3.zip
  7. DriveWire 4 is set up to run with a nice GUI with mouse control. This requires a keyboard and mouse, and the Pi to be set up with X-Windows running. Since I do not have a mouse, and plan to run the Pi headless with nothing hooked up to it but power and the CoCo, this is not an option for me. Instead, I need to manually edit the configuration file to tell it what Linux serial port I will be using.
    cd DriveWire4_4.3.3
    copy config.xml config.xml.org (always keep a backup!)
    pico config.xml

    The editor will open, and you want to look for a few entries:<instance category=”instance” desc=”Autocreated 2013-03-24 23:57:53.831″ name=”TCP connection via TCP“>

    <DeviceType category=”device” list=”serial,tcp-server,tcp-client,dummy” type=”list”>tcp-server</DeviceType>

    <SerialDevice category=”device” type=”serialdev”>COM14</SerialDevice>The first entry is just the name of the connection. You could change that to “Serial Connection” or whatever. The second “tcp-“server” should be changed to “serial”, and the “COM14” entry should be changed to your serial port device. On my Pi, when I plug in a single USB RS232 adapter, it shows up as /dev/ttyUSB0 so that is what I use.
  8. Save your changes back to the file (Ctrl-X, Y) and now you are ready to run the server without a user interface. (Getting the user interface to run requires installed two more additional packages, and I will make a tutorial for that soon, if anyone wants me to.)
    java -jar DW4UI.jar -noui
  9. After a bit, Java will load and the DriveWire 4 server will start. Java is big, and the Pi is small, so it can be quite sluggish. Now, with the USB cable connected between the Pi and the CoCo, you can start testing.

Preparation on NitrOS-9

This tutorial is being written for someone who already has an active NitrOS-9 system and wants to add DriveWire support to it. If you have no customized

If you are using one of the default NitrOS-9 disk images for you system, it should have a NITROS9 directory, and inside of it will be various device drivers and descriptors, including the ones used by DriveWire. Ultimately, you would want to make a custom boot disk that includes these modules, but here is a simple way to merge them together and just load them when you want to use them. From OS-9:

  1. If you are running a stock CoCo 3 with the standard 6809 processor, go here:
    cd /dd/NITROS9/6809L2/MODULES

    …and if you have upgraded your CPU with a Hitachi 6309, go here:
    cd /dd/NITROS9/6309L2/MODULES
  2. The modules you want depend on what you plan to do. Here is the list:
    • drio.sb – this module handles all communication with the DriveWire server.
    • rbdw.dr – RBF device driver that uses DriveWire for disk access instead of disk hardware
      • ddx0.dd, x0.dd, x1.dd, x2.dd, x3.dd – device descriptors for the DriveWire disk drives (/x0 to /x3, with ddx0.dd being a /dd descriptor for DriveWire).
    • scdwp.dr – printer driver
      • p_scdwp.dd – device descriptor /p for scdwp.dr
    • scdwv.dr – virtual serial port driver
      • n_scdwv.dd, n1_scdwv.dd to n13_scdwv.dd – serial port descriptors. /n is the “next available” descriptor, similar to /w for windows. /n devices may also be used for MIDI.
      • midi_scdwv.dd – this is n14 but named /midi for MIDI programs that are hard coded to look for that name.
      • term_z_scdwv.dt, z1_scdwv.dd to z7_scdwv.dd – (??? not in the doc wiki)
  3. For my example, I am only concerned about the disk drives, so I would merge the following modules together:
    chd RBF
    merge dwio.sb rbdw.dr x0.dd x1.dd x2.dd x3.dd >/dd/dw
    This gives me a single file called “dw” I can load to get DW support instantly. First, I need to set the attributes to allow that:
    attr /dd/dw e
    …then I can just load it when I want to use DriveWire:
    load /dd/dw
  4. If this worked, you should now be able to use the DriveWire command, “dw”, to communicate with the server. Type “dw” and it should report back a list of commands:
    config  disk  log  midi  net  port  server
    …and you can then type “dw config” or “dw disk” to see what all it can do.

Using DriveWire

Here is an example of creating an empty disk image and formatting it:

dw create 0 /home/pi/test.dsk
format /x0
dir /x0

If you look on the Pi, you will see a new file “test.dsk” there. You can now use this disk like any other OS-9 disk. In my test, I copied my NITROS9 directory over to it just for fun:

chd /dd/NITROS9
dsave /x0 ! shell

DriveWire’s performance is not as good as you’d get from a No Halt floppy controller like the Disto Super Controller 2 or a hard drive interface like the Cloud-9 SuperIDE or KenTon SCSI. As disk activity is going on, interrupts are masked while data is blasted out of the bitbanger port. Still, it did a remarkable job keeping up with my typing. Quite impressive for a cheap cable and a $35 computer with a serial port.

TO DO

  1. Make the DriveWire 4 server auto-start.
  2. Update the DriveWire 4 software from the command line (is this even possible?).
  3. Update the Raspberry Pi software.

Problems

One issue I immediately ran in to was a bunch of ERROR #207 (Memory Full) errors. mfree still showed 352K free, and it wasn’t the #237 (RAM Full) that happens when there isn’t enough room left in the main 64K memory map.

Building NitrOS-9 on Mac OS X

Since I have to relearn all the steps, I thought I would post them as I go through them. The NitrOS-9 website has a tutorial on building it, but here are my steps with some specifically for Mac OS X:

  1. Install the Command Line Tools for Mac OS X.
    We need the command line versions of the Mac OS X compiler so we can build the tools that are then used to build NitrOS-9. If you have XCODE installed, you may already have them. An easy way to do this is from a Terminal prompt:

    xcode-select --install

    That will launch the Apple Mac App Store installer and get the tools for you. Cool.

    Installing the Mac OS X command line tools.

    Installing the Mac OS X command line tools.

  2. Download Mercurial.
    The NitrOS-9 repository uses Mercurial as version control. You will need to download Mercurial. I had 3.2 the last time I did this, and currently it looks like 3.8 is available. There are several ways to download it using various package managers (Fink, MacPorts, etc.) but I don’t have this installed so I am just using the standalone installer:
    https://www.mercurial-scm.org/wiki/Download
    Depending on your Mac OS X security settings, it may complain that this is from an unknown developer and refuse to run. If you get this message, go in to your System Preferences “Security & Privacy” control panel and tell it to allow the installer to run:
    Screenshot 2016-05-01 17.26.21(Strange. The last time I did this, “Open Anyway” would let me bypass the security settings I am using. This time, it refused, and I had to temporarily allow “Anywhere.” Not sure what’s up with that.) After the install, you will have the “hg” command available.
  3. Download LWTools. These are the cross-compiler tools used to build 6809 source code from Mac/Windows/Linux systems. From a Terminal prompt, find a directory you want to download the lwtools to. I chose a poor location — “CoCo” inside my Downloads folder:
    alsmbpro:lwtools allenh$ pwd
    /Users/allenh/Downloads/CoCo

    From this directory, use the “hg” command to obtain and build the tools. It will build the directory you specify from the command line (“lwtools”):

    hg clone http://lwtools.projects.l-w.ca/hg/ lwtools
    cd lwtools
    make
    sudo make install
    cd ..
  4. Build Toolshed.
    Next we want to build Toolshed. This is a series of command-line utilities that operate on CoCo/OS-9 disk images (like those used with emulators and the CoCoSDC interface). Once again, I do these steps from my “Downloads/CoCo” directory:

    hg clone http://hg.code.sf.net/p/toolshed/code toolshed
    cd toolshed
    sudo make -C build/unix install
    cd ..

    (Note: I had to use “sudo make…” here to get it to build on my system.) The different build/make process shows the different styles of the various developers that made these tools. (Note: Mine seems to fail looking for a command “markdown” at the very end. Not sure what this is, but it seems to be building HTML documentation or something.)

  5. Build NitrOS-9.
    Now we are ready to download and build NitrOS-9. Once again, I start in my “Downloads/CoCo” directory, and issue the following hg commands to download all the NitrOS-9 stuff:

    hg clone http://hg.code.sf.net/p/nitros9/code nitros9
    cd nitros9
    make dsk
    This will build absolutely everything, including tons of ports and disk images you likely do not want. (i.e., if you are only interested in a CoCo 3 6809 setup, why build all the CoCo 1/2 and Dragon versions, or any of the 6309 stuff?). I always build everything, but you can also specify to build just a specific port. For my CoCo 3/6309 build, I could do this instead:
    make dsk PORTS=coco3_6309

    After this, you will have all the sources, and have built all (or some) of the sample disk images for various types of hardware (CoCo 1/2, CoCo 3, 6809 or 6309, CoCoSDC controller versus floppy or IDE hard drive, etc.).

  6. Updating NitrOS-9 and the Tools.
    Later, if you want to update your sources, you can use this comment from the “nitros9” directory:

    hg pull
    hg update
    make dsk

    I do this occasionally to get the “latest and greatest.” You can do this for the other tools, too, by changing in to their directory then issuing the “pull” and “update”, then the appropriate make command.
    If you get a merge conflict because you changed something locally, you might see this:

    alsmbpro:nitros9 allenh$ hg update
    abort: outstanding merge conflicts

    You can use this command to see what files have been changed on your local repository that conflict with the master files. This happens if, for instance, you tweak a makefile or build list or source code:

    alsmbpro:nitros9 allenh$ hg resolve -l
    U 3rdparty/utils/tlindner/sdir.asm

    This reminded me that I already Tim’s “sdir” source code (for CoCoSDC) so enable built in help and such. I have to revert those changes if I want to update, or learn how to use the merge too… I forgot!

These steps should get you everything you need to begin playing with NitrOS-9 on a real CoCo with the CoCoSDC interface, or an emulator. If you plan to use real floppies, you can use toolshed utilities to format and then copy disk image .DSK files over to the physical floppy, but I don’t have any way to hook a 360K Floppy drive to my Mac so I have never done this. CoCoSDC is the way to go there ($40!).

More to come…

 

Invaders09 updated to 1.04

Invaders09 1.04 title screen.

Invaders09 1.04 title screen.

Sub-Etha Software has released another update to our Color Computer 3 OS-9 space invaders-style game, Invaders09. Version 1.04 is now available and is a recommended upgrade for all users. It supplants previous February 1995 release of 1.03. As with all Sub-Etha Software products, bug fixes and maintenance releases are free upgrades.

You may download the 1.04 update as a self-booting .DSK image from our update server:

http://subethasoftware.com/files/coco/

The INVADE09.DSK image includes a fully bootable version of NitrOS-9 v3.3.0 and may be ran directly on a real Color Computer 3 or emulator just by mounting the image and typing “DOS”. You may also copy the invaders1.04.txt documentation file and CMDS/invaders1.04 binary to your existing OS-9 Level 2 or NitrOS-9 6309 or 6809 system.

1.04 RELEASE NOTES

  • Updated title screen (website, new message).
  • Added “secret” options to help screen.
  • Fixed bug that made font not always load.
  • Fixed shield and border graphics, palette cleanup.

KNOWN ISSUES

  • After 20 years, the game still doesn’t have an “attract mode” or “high score” listing. Maybe 1.05 will be out by 2025 to fix this. (Sorry about that, Bob Devries!)
  • The documentation refers to the binary as being called “invaders” but it is really “invaders1.04” on this release. Maybe the author won’t be so lazy next time and will name the binary correctly.

DOCUMENTATION

File:  INVADERS.TXT - Revision 1.2 (2/7/2015) - By Allen C. Huffman

|   I    NNNNN  VV  V   AAA   DDDD   EEEEE  RRRR   SSSSS   |
|   I    N   N  VV  V   A A   D   D  E      R  R   S       |
|   II   NN  N  VV VV  AAAAA  DD  D  EEEE   RRRRR  SSSSS   |
|   II   NN  N   V V   AA  A  DD  D  EE     RR  R     SS   |
|   II   NN  N    V    AA  A  DDDD   EEEEE  RR  R  SSSSS   |
| 
The Invasion Begins!

By Allen C. Huffman
Copyright (C) 1994,1995,2015 by Sub-Etha Software
www.subethasoftware.com

INTRODUCTION

     For years, determined scientists have probed the endless boundries of the
universe for extra-terrestrial signals.  Countless satellites have been
launched, radio signals transmitted, and theories formulated...all without
results.  Until now...
     Far out in the eastern spiral arm of the galaxy, something was listening.
And this something didn't like what it heard.  Soon outposts around the planet
were picking up masses moving towards the Earth.  The planet was preparing for
first contact, but no signals came from the void.
     The scientists prepared their welcome speeches.  The government, of
course, prepared defense actions.  The tabloids prepared headlines about the
end of the world.  The invasion began.
     Without warning, waves of disc shaped ships filled the skies.  Blasts of
energy were fired on unsuspecting buildings, knocking out military
installations before any retaliation strikes could be launched.  The Earth was
defenseless except...of course...for one last hope.
     The E.T.H.A. (Extra Terrestrial Hope Association) had planned for the
worst when the big day of contact would arrive.  Along with an endless supply
of peaceful translation equipment they possessed an experimental plasma cannon.
 This would be Earth's only chance for survival.
     You, my friend, are the control operator of this cannon.  Good luck.

INSTALLATION

     Invaders09 is a self contained executable called "Invaders".  Copy it to
your CMDS directory.  Usage is as follows:

     Invaders 1.04 by Allen Huffman (alsplace@pobox.com)
     Copyright (C) 1994,95,2015 by Sub-Etha Software. www.subethasoftware.com

     Syntax: Invaders [-opts]
     Usage : LEFT/RIGHT to Move, SPACE to Fire, P to Pause, Q to Quit.
     Opts  : -? = display this message.
             -m = monochrome colors (for 'montype m' displays).
             -z = secret option if you think it is too slow.
             -* = secret cheat mode (press * to skip level).

PLAYING THE GAME

     At the title screen, joystick users should press "J" or the fire button to
start the game.  [Note:  The joystick must be plugged into the left joystick
port.]  For keyboard control, press "K".  "Q" will quit back to OS-9.
     The game will begin and the playfield will appear.  The object is simply
to move your cannon (at the bottom of the screen) left and right to shoot at
the bad guys.  Direct hits are required as any side shots will be absorbed
harmlessly by the invaders.  Also, equipment limitations prevent your plasma
cannon from moving and firing at the same time.  Readouts at the bottom of the
screen display your current score, round, power rating, and lives remaining.

     Scoring:  Each invader you hit earns you 10 points.  Occassionally, a
mother ship ufo will pass across the top of the playfied.  Destroying it is
worth 100 points.
     Rounds:  After clearing out all fifty invaders, a new round will begin. 
The invaders will start closer to the ground.
     Power:  This determines how many shots your cannon can fire at a time. 
Each round gives you an extra shot up to the maximum of "J" (10 shots).  Each
time you lose a life your power goes down by one to the minimum of "B" (two
shots).
     Lives:  You start with three cannons.  Use them wisely.  Without them the
dreaded "Game Over" message will appear.
     Pause:  During game play, press "P" to pause the game.
     Quit:  Pressing "Q" during a game will quit.

     You have three shields to hide under.  Be warned:  They do not protect you
from bombs dropped by the mothership.  Also, when the invaders get low enough
your shields will disappear.  Be warned again.

WINNING THE GAME

     As with all classic arcade games, the enemies are never ending.  Each
level causes the enemies to start closer and closer to the ground and they get
faster and faster.  Good luck!

THANKS

     Special thanks to YOU for helping support the future of the CoCo and OS-9
by supporting vendors such as ourselves.  Without you, our hobby would have
died years ago.

SPECIAL THANKS

     Thanks to Bob Devries, Robert Gault, Colin McKay, Alan DeKok and the late
Alex Forrest for helping beta test this product and get it to this stage.

RELEASE HISTORY

Programming on Invaders09 began on 8/21/94 and it debuted at the 1994 Atlanta
CoCoFest.

* 1.00 09/24/94 - Release version for 1994 Atlanta CoCoFest!
* 1.01 10/26/94 - Robert Gault patch for >512K systems
*                 Since NitrOS9 call does not work for >512K, call removed
* 1.02 01/29/95 - Converting to 16-color gfx screen (whew!)
* 1.03 02/04/95 - Added test for valid screen BEFORE mapping it into MEM R.G.
*                 Moved hiscore and packet (=enemies) to dp. A.H.
* 1.04 02/07/15 - Updated title screen (website, new message).
*                 Added "secret" options to help screen.
*                 Fixed bug that made font not always load.
*                 Fixed shield and border graphics, palette cleanup.

CONTACTING SUB-ETHA:

    Internet: www.subethasoftware.com
    Facebook: www.facebook.com/subethasoftware

Manually making a bootable NitrOS9 hard drive image – part 3

  • 2016/04/26 – I had a HUGE mistake in STEP 5 about what to put in LSN0 for the os9boot file size. (It’s sectors, not bytes – oops!) Thanks to Travis Poppe for helping me figure out what was wrong in my instructions. I have marked the updates in red. I will do some testing soon to make sure it is correct now.
  • 2016/05/01 – A minor correction to the instructions, and I added links to DSK images of the BASIC and OS-9 programs in this article, as well as a link to the full 128MB NitrOS-9 image, ready for you to start customizing.
  • 2017/02/05 – Well, this is confusing. Ignore my first correction. LSN 0 needs file size in bytes, not sectors. Correcting again.

As promised in Part 1, and teased in Part 2, I finally present some simple steps to making a bootable OS-9 disk without using “cobbler” or “os9gen”. If I had understood this more back in the early 90s when I was using CoCo OS-9 Level 2 full-time, I don’t think I would have seen nearly as many BOOT FAILED messages :)

Step 0 – Creating a 128MB disk image.

This doesn’t have anything to do with the rest of the article, but it’s good to know. CoCoSDC creates disk images, by default as 35-track single sided images. As you write data past the end of those 35 tracks, the image expands. This can lead to fragmentation and performance issues as the CoCoSDC firmware has to juggle more bits and bytes. Instead, designer Darren Atkinson sent me a simple BASIC program that will create a .DSK image and expand it automatically to the size (in megabytes) you specify. I called mine SDCMAKE.DSK (download the SDCMAKE.DSK disk image here).

10 INPUT "DSK NAME";DN$
20 DRIVE 1,DN$,NEW
30 INPUT"SIZE MB";MB:IF MB>128 THEN 30
40 A=&HFF48:SC=INT(MB*4096)-1
50 B1=INT(SC/65536):B2=INT((SC-B1*65536)/256):B3=SC-B1*65536-B2*256
60 POKE &HFF40,67:POKE A+1,B1:POKE A+2,B2
70 POKE A+3,B3:POKE A,&HA1:POKE A+2,0
80 IF (PEEK(A) AND 2)=0 THEN 80
90 FOR I=1 TO 128:POKE A+3,0:NEXT
100 IF PEEK(A) AND 1 THEN 100
110 POKE &HFF40,0

You can run that from BASIC and make a fresh “128MB.DSK” file to experiment on under OS-9.

Step 1 – Format the hard drive for the 128MB.

To do this, we must configure the /sd1 device descriptor so it provides 524,280 clusters – the most we can have (65535 bytes in the DAM, multiplied by 8 bits per = 524280). I use 65535 ($FFFF) cylinders, 8 sides, and 1 sector-per-track which works out to 524280 exactly.

dmode /sd1 cyl=ffff sid=8 sct=1 t0s=1
format /sd1

NOTE: There may be more values that need to be set. I tried this tonight (2/5/2017) on an old SyQuest EZ135 SCSI drive (128MB as well) and format showed some real weird stuff. I think there were some other options in my SCSI descriptor (clusters, etc.) that I needed to override.

Format should report “Disk capacity: 524280 sectors (134,215,680 bytes)” and you should see “Sectors/track” and “Track zero sect/trk” both at 1 (sct and t0s in the dmode command), and “Total physical cylinders” at 65,535 (cyl in the dmode command). Do not to a PHYSICAL format, and there is no need to Verify unless you just have some time to kill.

Format Note: During the research for this article, I realized that not only is cobbler and os9gen broken in regards to hard drive images, but it appears format is as well. There is a byte in LSN 0 that indicates the type/format (DD.FMT) of the disk. It has bits that are associated with various floppy disk formats, with one representing single-sided or double-sided. It appears that, by default, format will set that side bit if sides > 1. By formatting a hard drive like I suggested (with sid=8), the double-sided bit will be set, and that throws off cobbler and os9gen. If you format using the “1” option, for singled sided, it will NOT set that bit (thus, single-sided) BUT it will override the sid=8 settings (or whatever is in the descriptor). What we really need are versions of these commands that have a “it’s a HARD DRIVE, darnit!” option that will not set those floppy drive bits. I expect this was done long ago when hard drives started getting affordable, but reinventing the wheel is fun so maybe that will be another article…

Step 2 – Copy the kernel track from a bootable disk on sectors $264-$275 to sectors $264-$275 on /sd1.

I did this using a brute-force BASIC09 program: (Download the KERCOPY.DSK disk image here.)

PROCEDURE kercopy
DIM in,out:BYTE
DIM srcDev,dstDev:STRING
DIM sectorNum:REAL
DIM sectorData(256):BYTE

INPUT "Source drive with kernel:",srcDev
INPUT "Destination drive       :",dstDev

OPEN #in,srcDev+"@":READ
OPEN #out,dstDev+"@":UPDATE
FOR sectorNum=$0264 TO $0275
PRINT "Copying sector "; sectorNum; " from "; srcDev; " to "; dstDev
; "..."
SEEK #in,sectorNum*256
GET #in,sectorData
SEEK #out,sectorNum*256
PUT #out,sectorData
NEXT sectorNum
CLOSE #out
CLOSE #in
END

Please note that this program does no error checking. When you run it, you would type in “/sd0” for the source disk (if that is the one with your kernel boot track) and “/sd1” for the destination. It will then simply read all the boot track sectors from /sd0 and write them to the same place on /sd1.

Given a bit more time, I need to make that program take care of this next step so it does not have to be done manually… At that point, it would be a nice replacement for cobbler, almost.

Step 3 – Mark sectors $264-$275 as used to prevent files from overwriting the “hidden” kernel track.

I use dEd to edit the hard drive in raw mode (/sd1@)  and then just find the 18 appropriate bits in the DAM (disk allocation bitmap) that represent the 18 sectors of the kernel track and set them.

The boot track is located on sectors $264-$275 in the DAM (disk allocation bitmap). The DAM starts at LSN 1. You basically want to set the 18 bits that represent sectors $264-$275. They reside in bytes $14C, $14D and $1FE:

offset $14C = $0F (00001111)
offset $14D = $FF (11111111)
offset $14E = $FC (11111100)

ded /sd1@
CMD: s 1 [ENTER] (skip to LSN=$01 one)
CMD: e (edit mode)
Cursor over to row 04, column C and change that to $0F
Cursor over to row 04, column D and change that to $FF
Cursor over to row 04, column E and change that to $FC
[ENTER] to exit edit mode
CMD: w (to write sector)
Are you sure? y (yes, you are sure)

Step 4 – Copy your OS9Boot file over to /sd1. If this disk is freshly formatted, it should copy as a contiguous (non-fragmented) file.

copy /sd0/OS9Boot /sd1/OS9Boot

Step 5 – Mark the location and size of the bootfile in logical sector 0. This is how the booter knows where to find OS9Boot.

To do this, I do a “dir -e /sd1” and note the “Sector” and “Bytecount” (size) fields. In my example, dir reports OS9Boot is at Sector 109 and has a Bytecount (size) of $5EDD. The sector reported is NOT the one we want to use. That sector is where the File ID sector is for OS9Boot. File ID is what contains the attributes, owner, creation date, etc. as well as the segment list. For a fragmented file, the File ID sector may contain up to 48 entries of different file segments.

Using “ded /sd1@” again, first we want to verify where OS9Boot is. Open dEd, and skip to the sector that was shown in the “dir -e /sd1” output:

ded /sd1@
s 109 [ENTER] (skip to sector shown in the dir -e display)

That sector should have some data on the first row (00), and a few entries on the second row (10). The second row is what we really want. The first three bytes (offsets $10-$12) are the starting sector for the segment (where OS9Boot really begins), and the next two bytes (offsets $13-$14) are the size in sectors.

On a freshly formatted disk, the starting sector should be one higher than what “dir -e” showed. On my system, it is “00 01 0A” ($10A is the sector after the directory entry at $109).

Just to make sure you have the correct starting sector, in dEd you can skip to that sector (“s 10a [ENTER]”) to look at it and see if it is the kernel. On the top line of the ASCII display on the right you should see the module name embedded in there. In this case, “KrnP2”. That confirms sector $10A is indeed the kernel.

From the NitrOS-9 Technical Reference manual “Identification Sector (LSN 0)” on page 57:

Name    Rel.  Size  Use
        Addr  (Bytes)
DD.TOT  $00   3     Number of sectors on disk
DD.TKS  $03   1     Track size (in sectors)
DD.MAP  $04   2     Number of bytes in the allocation bit map
DD.BIT  $06   2     Number of sectors per cluster
DD.DIR  $08   3     Starting sector of the root directory
DD.OWN  $0B   2     Owner’s user number
DD.ATT  $0D   1     Disk attributes
DD.DSK  $0E   2     Disk identification (for internal use)
DD.FMT  $10   1     Disk format, density, number of sides
DD.SPT  $11   2     Number of sectors per track
DD.RES  $13   2     Reserved for future use
DD.BT   $15   3     Starting sector of the bootstrap file
DD.BSZ  $18   2     Size of the bootstrap file (in bytes)
DD.DAT  $1A   5     Time of creation (Y:M:D:H:M)
DD.NAM  $1F   32    Volume name in which the last character has the most significant bit set
DD.OPT  $3F         Path descriptor options

We will want to put the starting sector (that we got from dEd) as three bytes at offset $15 of LSN 0. We will want to put the byte count (that we got from dir) as two bytes at offset $18 of LSN0.

Now just skip back to LSN 0 and type in the starting sector for the OS9Boot module and it’s size. These go at offset $15-$17 (starting sector) and $18-19 (size in bytes). Basically, you want to edit $15-$19 to be the three bytes that were at $10-$12 in the files’ ID sector, and the two byte size (from dir). In my case, I put in “00 01 0A FE DD” to match the start of my boot file ($00010A) and it’s file size ($FEDD).

s 0 [ENTER]  (skip to Logical Sector 0)
e (to enter edit mode)
Cursor over to row 10, column 5. Change three bytes to the start LSN:
00 01 0A (for me)
Cursor over to row 10, column 8. Change two bytes to the os9boot size:
5E DD (for me)
[ENTER] to exit edit mode
CMD: w (to write sector)
Are you sure? y (yes, you are sure)

Now the kernel track is where the “DOS” command will find it, and its sectors are marked as used to other files will not overwrite it.

OS9Boot has been copied over (and must be contiguous) and LSN0 has been updated to point to where the file starts and how big it is.

Step 6 – The only thing left to do is copy over the other needed files, which at a minimum should be “shell”, “grfdrv” and “sysgo”:

makdir /sd1/CMDS
copy /sd0/CMDS/shell /sd1/CMDS/shell
copy /sd0/CMDS/grfdrv /sd1/CMDS/grfdrv
copy /sd0/sysgo /sd1/sysgo

At this point, you now have a minimally bootable OS-9 hard drive (though it has no commands or anything useful on it yet). You might want to also include utilspak1 (common commands) and the base startup file (which will load them):

copy /sd0/CMDS/utilpak1 /sd1/CMDS/utilpak1
copy /sd0/startup /sd1/startup

I hope this walkthrough demystifies the OS-9 booting process. In a future article, maybe I can present code in BASIC09, C or assembly (or maybe all three versions) that does all of this for you.

2016/5/1: You can download a 128MB disk image here that is the results of me performing this steps tonight.

Until then … tips are always welcome :)

Manually making a bootable NitrOS9 hard drive image – part 2

Updates:

  • 2016/05/02 – Added link to David Ladd’s experiment.

In the first installment, I discussed a bit about how the Radio Shack Color Computer boots OS-9 using the Disk BASIC “DOS” command. I ended the article by mentioning David Ladd’s exciting experiment to place the OS-9 boot track in ROM on a CoCoSDC interface. The advantages of this would be:

  1. No need to write out the kernel boot track to a boot floppy (or virtual floppy).
  2. A whole extra track of disk space on any boot disk.
  3. Faster booting, since copying from ROM would be faster than loading the 18 boot sectors from a floppy drive.

Number 2 is not a huge deal on a hard drive since 4.5K isn’t much space. Neither is number 3 since reading 18 sectors from a virtual floppy on the CoCoSDC is blazing fast. I can already do a complete OS-9 boot to a shell prompt in about 3 seconds. But, faster is faster. It’s number 1 I want to focus on.

The Problem With Cobbler

The OS-9 utilities cobbler and os9gen were written to work on floppy disks. historically, that’s all anyone has ever used them on — even if the floppy was a virtual one contained on an RGB-DOS/HDB-DOS hard drive partition, or .DSK image file across Drivewire.

CoCoSDC allows you to create .DSK image files and mount them as if they are a floppy disk. The CoCoSDC decides what to do with them based on the size of the .DSK file. See the “Disk Geometry Table for DSK Images (without header)” table on the CoCoSDC blog. Basically, any .DSK file with more than 2880 sectors (as many as an 80 track quad density floppy could have) will be treated as a hard drive image.

I’m not quite sure what this implies, since if you mount such an image, Disk BASIC will still see and use the first part of it as a 35-track single sided floppy disk*. To Disk BASIC, all it knows it Tracks 0-34 each contain Sectors 1-8 and each sector is 256-bytes. If you mount such a large .DSK image and then type “DOS”, Disk BASIC will go out to Track 34, Sector 1 and start loading things in to memory at $2600, same as if it was a real floppy disk.

* Is this true? It seems to be. If it’s not, what I am about to describe shouldn’t be working.

Track 34, Sector 1 is sector number 612 (34 tracks * 18 sectors per track = 612). As long as a kernel boot track is found there, you should be able to attach a 128MB .DSK image, type “DOS” and boot in to OS-9 (assuming the boot track has the proper OS-9 booter on it for the CoCoSDC hardware, and there is a OS9Boot file properly set up, too).

This is exactly how the NitrOS9 CoCoSDC sample .dsk image works. Mount it, type “DOS”, and in seconds you are at a NitrOS9 shell prompt. The NitrOS9 makefiles create the .dsk image using the Toolshed tool “os9”. Toolshed supports formatting a .DSK image for OS-9, os9gen-ing a bootfile on to it, and dsave-ing files and directories over to it. You end up with a large bootable .DSK file that is formatted for OS-9, has a “track 34” boot track, and the OS9Boot file linked in at sector 0. Magic.

You would think you could do the same thing via OS-9, but you would be wrong. os9gen and cobbler will not work because they were never written for anything but a physical floppy drive. In a moment, I will explain why this may be an incorrect statement.

If you mounted an OS-9 boot .dsk image in DRIVE 0, and a formatted 128MB OS-9 hard drive .dsk image in DRIVE 1:

DRIVE 0,"OS9BOOT.DSK"
DRIVE 1,"128MBHD.DSK"

…and then you boot in to OS-9 and try to “cobbler /sd1”, bad things happen. cobbler and os9gen will try to place the kernel boot track at track 34, sector 1. If this was a physical floppy interface, seeking to Track 34 and Sector 1 would work, but to OS-9, there is no such thing as physical tracks or sides. Every disk device is just a bunch of logical sectors, and it’s the device drivers job to translate whatever the hardware has to a series of logical sectors. The cobbler and os9gen utilities use something called “math” to figure out what logical sector corresponds to Track 34, Sector 1. It does this with a simple forumla:

logical_sector = 34 * 1 * sectors_per_track * sides (see side note)

Side Note: Sides is used because on a double sided floppy, tracks are interleaved between the two sides of the disk. On a single sided 40-track floppy, there are 720 sectors which make up the top side of the disk. On a double sided 40-track floppy, there are 1440 sectors. The first track’s worth of sectors (sectors 0-17) is written to the first track of the top side, then the next track’s worth (sectors 18-35) is written to the first track of the bottom side of the disk. The job of an OS-9 disk driver is to translate the logical sectors OS-9 uses to whatever format the hardware uses. In the case of floppy disks, it turns 1440 logical sectors of a double sided 40-track disk in to two sides of a physical floppy. On modern hard drives, the drive controller speaks sectors, so the only thing the OS-9 driver has to do is deal with the 512-sector size issue on modern drives, but that’s a topic for another series of articles.

If the hard drive is configured with a different number of sectors per track than the 18 used by a floppy disk, the math will be wrong. cobbler/os9gen will multiply the drive’s sct (sectors per track) setting by 18 (hard coded assumption) and either 1 or 2 sides (see note below) and try to write the kernel track at that location. The end result is a file being written in the wrong place on the .DSK image than where the “DOS” command expects it to be.

Side Note 2: For sides, cobbler and os9gen aren’t using the actual sides field — they are using a bit in the DD.TYP field that indicates if the device is single or double sided. For a proper OS-9 hard drive descriptor, the hard drive bit is set and the sides bit is clear, so cobbler and os9gen should see a hard drive as a huge single sided floppy disk.)

But wait! It gets worse…

While OS-9/6809 can theoretically support a 4GB hard drive, it could only do so by using a large cluster size (having multiple sectors representing one cluster). For me, I am using the largest size possible when each cluster represents one sector. Below, when I mention “cluster” or “sector”, they effectively mean the same thing for me since I am using a cluster size of one sector. Get it? Good.

On my system, in order to get the largest 1 sector cluster hard drive possible (128MB, see note below), I configure my hard drive descriptor to be 65,535 tracks (cyl=$ffff), 8 sides (sid=$8) and 1 sector per track (sct=$1). This (65535 * 8 * 1) gives me 524,280 sectors, which is as large as we can get.

As part of the file system, a series of bits is used to represent which clusters are used or are free. This is called the DAM (disk allocation map) and it serves the same purpose as the FAT table does on a PC. The largest the DAM can be is 65,535 ($FFFF) bytes and since each byte represents 8 clusters. The more clusters, the larger the DAM must be.

DAM Note: Since there are only $FFFF (65535) bytes in the DAM table, with each byte representing eight clusters, the largest amount of  clusters OS-9/6809 can handle is 524280 (65535 * 8). 524280 * 256 bytes per sector is 134,215,680 which is just shy of 128MB (using 1024 bytes of a K). If only we had one more byte in the FAT, then we could fully use the 128MB. By using a larger cluster size, where each DAM bit represented 2, 4, 8, or 16 sectors, the total size of the hard drive can as much as 4GB. The 4GB limit is because OS-9 can only access up to 16,777,215 ($FFFFFF) logical sectors.

Sector Note: If you are clever, you might be thinking “oh, that’s with a 256-byte sector drive, so on an IDE drive where every sector is 512-bytes, we should be able to access 8GB!”. Very clever, but that would only be the case if OS-9 was not using deblocking drivers that split each physical 512-byte sector in to two logical 256-byte sectors. The max sector value that OS-9 can read is $FFFFFF 256-byte logical sectors. If those just happen to be half of each 512-byte sector on an IDE drive, then sure, it’s accessing an 8GB drive, but wasting half of each sector since OS-9 still only sees it as $FFFFFF 256-byte sectors. Now stop being clever so I can finish this article.

Where was I? Oh, right. Trying to use the largest hard drive I can…

If I ran cobbler or os9gen on this 128MB drive, it would multiple the number of tracks (cyl=$ffff) by 34 and then try to write the kernel boot track starting at sector 2,228,190. DOS will be looking for it at sector 612, so this clearly won’t work.

Theoretically, if I had made my hard drive use 29,126 tracks (cyl=$0x71C6), 18 sectors per track (sct=$12), and one side (sid=$1) like a simple floppy disk, I might be able to get this to work. cobbler and os9gen would do the math (track 34 * 18 sectors per track) and end up at sector 612 like it is supposed to and all would be well in the world. Except it isn’t.

First, that only gives a hard drive size of 524,268 sectors, which is 12 sectors shy of our max. I wouldn’t sleep well at night knowing I could be using 12 more sectors just by using more optimum settings. But that’s not the real issue. The real issue is that cobbler and os9gen were never written to work on hard drives. Taking a peek inside the cobbler source code, I find this:

 * Request memory for the FAT buffer + 256 bytes for stack space R.G.
 ldd <DD.MAP
 addd #size+256
 os9 F$Mem

First, the D register is loaded with the DD.MAP field from logical sector 0. That field holds the size of the DAM bitmap which, on a 128MB hard drive image, is $FFFF.

Next, it adds 256 to this value which, on a 16-bit register, rolls over and D ends up being 255.

Finally, it allocates memory which is will use for stuff. Instead of getting $FFFF+256 bytes, it’s really only getting 256 bytes and “bad things can happen.” This is a bug. Cobbler was not written to be used on a disk with that many clusters.

ERROR #244

Maybe that is why cobbler exits with an ERROR #244 when you try it on a hard drive configured that way. At least it does on mine.

As-written, cobbler and os9gen will fail here. They need to be updated to handle things differently, or at the very least, exit with an error if the drive is too large. And honestly, the easiest fix might be to do it like the Toolshed os9 utility does and just seek to sector 612 in the file (or 1224 in the case of a double sided disk). That’s really the only math we need for the boot track.

Up next: Finally, the original promise of this article… How to manually make a NitrOS9 hard drive bootable using only a disk editor, the copy command, and some duct tape.

Manually making a bootable NitrOS9 hard drive image – part 1

Updates:

  • 2016/05/03 – Added link to David Ladd’s article on putting the OS-9 boot track in ROM on the CoCoSDC.

This article discusses how to manually make a hard drive bootable under the NitrOS9 operating system running on a Radio Shack Color Computer.

Creating an OS-9 Boot Disk

Creating a bootable OS-9 Level 2 disk in the past was always pretty simple. If you booted from a disk in drive /d0 and wanted to make a freshly formatted disk in drive /d1 bootable, all you had to do was run “cobbler /d1” (which wrote out the boot track and OS9Boot file based on what you currently were using) and then “dsave /d1 ! shell” (which copied all the files from your /d0 boot disk over to the newly bootable disk in drive /d1). Done! Beyond the infamous “BLOB” (bootlist order bug) that plagued users for years until someone figured out what caused it, you were pretty much guaranteed to have a new bootable OS-9 disk without any hassle.

Another method was to use the os9gen utility, which would read a text file list of individual modules and merge them together in to the OS9Boot file and write out the boot track. This was the method used when you wanted to customize what was in the boot disk, and the only option if you didn’t have any of the great 3rd party utilities that were written to make the job so much quicker and easier.

I almost never made a boot disk those ways. Once I had one that worked, I tended to just use utilities like Burke & Burke’s ezgen to edit the bootfile and insert, rename, remove or replace modules. Once I understood that OS9Boot was just a (contiguous) file on the disk and the only thing that made it special was two entries in logical sector 0 (LSN0) telling the booter where to find it, it became a simple thing to manipulate them without using any special tools. Between ezgen and the ded disk editor, and maybe a few other ones, I pretty much forgot how to use cobbler or os9gen.

NitrOS9 works the same way, however, today most folks are just using floppy disks for booting. The free Drivewire project lets OS-9 pretend it has a hard drive by communicating over the CoCo’s serial port to a Mac (or PC or Linux) machine running the Drivewire server. Still, you had to have something to load OS-9 from Disk Extended Color BASIC. Traditionally, that was the “DOS” command.

“DOS” Command Booting

The “DOS” command would go out to Track 34 of the floppy disk and, if the first two characters there were “OS”, it would load the entire track in to memory starting at address $2600. It would then execute the code starting at $2602 (just after the “OS” characters). That code could be anything, including a small standalone program that loaded up something else from the disk. Almost all of my RS-DOS disks had some form of “DOS” booter on it that would do things like set the drive seek speed to 6ms or turn on double speed mode. Sub-Etha Software sold Super Boot by Carl England which did things like this and allowed you to specify any command for “DOS” to execute.

For OS-9, the code on track 34 contained a booter, which knew how to find the “OS9Boot” file, and the OS-9 kernel module. DOS would load that in to memory and the boot process would begin, hopefully ending with an OS9: prompt.

Since booting begins with the “DOS” command, we can only boot from whatever device it supports. If the CoCo only had Disk Extended Color BASIC, that device has to be a floppy disk. The boot track on that floppy disk could then contain a hard drive boot module that goes on and finds OS9Boot on a hard drive (MFM/RLL, SCSI, IDE, Drivewire, CoCoSDC, whatever the booter knows how to work with).  Thus, we had a two stage boot: Boot is loaded from floppy, then boot loads OS-9 from the hard drive.

The only way to boot fully from the hard drive was to use a Disk BASIC replacement like RGB-DOS (today known as HDB-DOS and freely available). RGB-DOS altered Disk BASIC so commands that normally read from a WD1773 floppy drive controller would read from a SCSI hard drive. (HDB-DOS was later updated with versions for IDE hard drive controllers, Drivewire, etc.). Using RGB-DOS, it was possible to put that initial OS-9 boot floppy on a virtual hard drive floppy and boot entirely from the hard drive. The “DOS” command was still acting like it was reading sectors from a floppy disk, they were coming from a hard drive.

When using RGB-DOS, typing “DOS” would go to a virtual floppy disk, load in the boot track, and then proceed. Once the booter track was loaded from the virtual floppy drive, it took over and then … would look for OS9Boot on the physical floppy drive. Why? Because the boot code on track 34 was still floppy drive code. As mentioned earlier, replacement boot modules were needed to finish loading OS9Boot off of whatever hardware was being used.

The boot process, therefore, includes:

  1. Typing “DOS” to load the boot track. If using Disk BASIC, this was a physical floppy disk. If using RGB-DOS/HDB-DOS, this was a virtual track from a hard drive parition.
  2. Low level “booter” takes over and loads “OS9Boot” and starts OS-9. If using stock OS-9, the booter looked for OS9Boot on a physical floppy disk. If using an alternate booter, it could look for it using SCSI, IDE, Drivewire, or whatever.
  3. OS9Boot takes over, and OS-9 is running using whatever OS-9 hardware drivers it has to access floppy drives, hard drives, serial ports, etc.

That may seem like a lot of pieces, but it’s really only three steps.

CoCoSDC Changes Everything

Historically, the only way to boot CoCo OS-9 was through the “DOS” command, whether that be the standard version that loaded from a physical floppy drive, or a modified version that loaded from a hard drive. There was nothing that required this to be so — it was just how it was done.

When Jeff Vavasour wrote the first CoCo 3 emulator, he created a replacement for the BASIC ROM that did nothing but simulate the DOS command by loading a virtual track from a virtual hard drive image. This let OS-9 users who had no use for BASIC boot directly in to OS-9 without even needing the CoCo ROM files. This could have easily been done on a real CoCo, perhaps by replacing the ROM on a KenTon SCSI hard drive interface with code that did nothing but boot OS-9. It seems likely this was done, but I never heard about it.

Recently, David Ladd began working to do this using the CoCoSDC. The CoCoSDC is an incredible floppy drive replacement that. Unlike RGB-DOS, it let you copy a standard floppy boot disk to a virtual .dsk image file and “DOS” boot from it. Both Disk BASIC’s floppy code and OS-9’s floppy booter code still think they are talking to a real floppy so “it just works.” But, another feature of CoCoSDC is virtual ROMs. There is 128K of flash onboard that can be configured to look like up to eight different 16K ROMs to the CoCo. It ships with SDC-DOS in bank 0, and pure Disk Extended Color BASIC 1.1 in bank 1

David wondered if he could just take the track 34 boot code and put it in ROM somehow, and thus never need a boot track again. By theory, this should be very simple, but If you simply clone all of track 34 and write that out to a flash bank (starting at $C000),  that won’t do anything but crash the system when the CoCo starts up and tries to execute $C000. Instead, $C000 needs to contain a small bit of code that will copy the boot track code (from just after it in the ROM) down to $2600, and then JMP $2602 to start it — just like DOS does. Easy!

With six available ROM banks in the CoCoSDC, one bank could have the KenTon SCSI boot track, another the Cloud-9 SuperIDE boot track, and another the Driverwire boot track. What a great idea!

But … there is a problem.

In the next installment, I will discuss that problem and how to solve it.