Monthly Archives: February 2015

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).

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.)

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

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


  • 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:


…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


  • 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.

Penn & Teller’s BBS – MOFO EX MACHINA


  • 2019-09-27: Here is an interesting read about Penn Jilette’s time writing for PC Magazine, which mentions his BBS and links to this post.

Before the public Internet and the World Wide Web, there were computer Bulletin Board Systems (BBSes). A device called a modem (modulator/demodulator) would turn computer data in to audio tones (modulate) so it could be sent across a phone line, and the modem at the other end would turn these tones back in to data (demodulate).

My first exposure to BBSes and modems was thanks to a local Radio Shack in Houston, Texas. They let me use their TRS-80 Model III to dial in to BBSes around the city. The salesmen there turned me in to part of a sales pitch. “This young man is currently connected to a computer across town…”

I never had a modem for my first computer, a Commodore VIC-20 that I received in 1982. I did, however, get to borrow a modem (from that same Radio Shack salesman) to use with my Radio Shack Color Computer I bought in 1983. That modem was a 300 baud (very slow, about the speed of a really fast typist) acoustic coupled version, which was the type with round holes on it that you would set a phone handset in so it could play sound to the mouthpiece, and hear sound from the earpiece. That’s right — you had to dial the phone yourself then set the handset down on the modem when the computer at the other end answered! (There were “smart modems” by then that could dial and answer the phone — that’s what the BBSes used — but they were vastly more expensive. I wouldn’t have one of those until years later when the price came down.)

But I digress.

Over the years, modem technology evolved, and they got faster and cheaper. BBSes were operating everywhere, and I remember calling them as late as 1995-1996 or so after I moved to Iowa. By that time,dialup internet was starting to spread, and soon calling a local BBS would be a thing of the past.

I miss my BBS days. I wrote one in 1983 that a cousin of a friend operated in Houston for awhile, and I ran my own several years later elsewhere in the state. I even started it up again (briefly) in Iowa. It was a fun time, and there was a greater sense of local community on them since most users would be from the local area (avoiding long distance charges).

Magicians Penn & Teller had a BBS of their own, too. It was called MOFO EX MACHINA. The following is a transcript of a dialup session I had with the system on November 24, 1990. Set your wayback machine to 300 baud (but hopefully 1200 by then) and read on:

Remote V.1.3  
Please enter your password 
Incorrect password 
Please enter your password 
Hello, FAN. 
11-24-1990 03:26:34 
Checking your terminal type ... 
Your terminal type is Universal. Please wait... 


(c) 1986,87 eXTended Software Services
(c) 1988 New York Municipal Computer Service Group
    Password series: Beta Trey

NYCDT                      Node 3                             XTPCSS v. 2.3

                 New York City Department of Traffic

         Employees are to take not that we are still testing
         this system and we are not yet ready to network this
         machine with the IBO-DEC 80 files.  Do not rely on this
         system as a sole source of information and do *not*
         count something filed here as "Recorded Diem" until you
         are notified to do so by your supervisor.

         We would like to thank those brave enough to help us
         work out the in-operatives in this system.  Remember,
         "We are rebuilding New York."

         Thank you for staying within the fifteen minute time
         limit, we are back-logged on reimbursments for phone
         expendentures.  These calls should be short enough to
         fall under the 'petty cash' heading on Form 36J3/201/6
         (available from Supervisor Bradley's Brooklyn office).

15 minutes Press any key -->

NYCDT                      Node 3                             XTPCSS v. 2.3

                 New York City Department of Traffic

         WARNING:  Any attempt to enter names for exception of
         parking tickets is ILLEGAL!  More importantly, before
         we bring this machine on-line it will be audited, save
         the favors until after we are up to speed.

         Notice: Meter maids applying for gun permits that were
         approved before January 21, 1988 please contact the
         assistant-supervisor's secretary: because of the
         Maynes-Fieldstein difficulty some permits were approved
         without official approval.

Press any key... except that one.

NYCDT                      Node 3                             XTPCSS v. 2.3

                 New York City Department of Traffic

  Verifying use-approval code.  Please stand-by.

  Usr apprvd.
  Accs denied.  Accnt clsd.

  Usr apprvd.
  Accs denied.  Accnt clsd.

  Usr apprvd.
  Accs denied.  Accnt clsd.

    Manual override/%THY!  MO:HCK@NYC

NYCDT                      Node X                             XTPCSS v.666

                New York City Department of Tra
                                          --trapdoor activated--

          Thanks to bribes, kickbacks and the department in
          charge of tracking municipally-owned equipment
          (or lack there of any such department), we are proud
          to present a bulletin board with a real purpose...

14 minutes Press any key -->

W E L C O M E   T O

                    M O F O   E X   M A C H I N A

A public service bulletin board from the good folks
at the Buggs & Rudy Discount Corporation.

Mofo controls this bulletin board, telling you about Penn &
Teller and the ever-changing world in which they live in.  Why
not give it a try?

Press any key... except that one.

14 minutes Press any key -->

                        T E L L E R   T A L K
      Hello, and thanks for logging on.  This is Teller.  I'm writing
this installment in a hotel room in Baltimore on November 10th, 1990.
We're touring this fall, and this is my fifth hotel room, if you don't
count the one in Chicago by the ice machine that I moved out of so that
I could sleep.
      I am reading SUNDAY NIGHTS AT SEVEN the Jack Benny
biography/autobiography.  In dark type is interesting stuff from a
manuscript by Benny.  It's nice, good-natured stuff about the life of a
vaudevillian, radio star, and tv personality.  In light type (the bulk
of the book) is petty crap, poorly written (dictated into a tape
recorder?) by his smug, talent-free adopted daughter.  Oh, boy, at last
she has the chance to brag about being a spoiled brat and get back at
her demanding mother.  Unfortunately, every once in a great while, she
quotes George Burns or somebody else good; so you can't get away with
just skipping the light type.
      The tour is going gangbusters.  It's a bit eerie.  We land in a
new city.  We drive into town.  We walk into the theatre, which is
always distinctly different from the last one.  And there on stage is a
little microcosm that is absolutely the same:  our set.  It's almost as
if somebody picked up everything in my bedroom, even the waste basket

13 min [?,C,G,M,Q] --> ?
[C]ontinous, [G]oodbye, ,[M]ore, [Q]uit this file

13 min [?,C,G,M,Q] --> C

full of trash, and placed it, exactly as it was, in the middle of the
      My happiest extracurricular activity:  I heard a great band in
Milwaukee, The Rhythm Club.  Four women and a bass player who are all
amazing musicians and who, like NRBQ seem to be able to do ANYTHING they
want at the drop of a hat.
      Upcoming events -- Letterman on November 20th.  Our big special:
"Don't Try This At Home" on the 23rd.  Minneapolis, San Francisco, Los
Angeles, then a short vacation.  Ta for now.

13 minutes Press any key -->

What's up with Penn - 11/20/90

Well Mofo computer friends,  

I'm on an airplane flying to Minneapolis where we'll do our show
for a few nights.  I'm writing this on my Grid 1450SX, a major cool
computer that I get to borrow because I'm writing the back page for
"PC Computing" magazine.  The issue on the stands right now has an
article of mine on the back page with a little drawing of me.  The
picture is okay - my fat smiling face sitting at a computer but the
computer has a sticker that says, "Kiss Me, I'm User Friendly". 
I'm sorry, it was not my idea.  They didn't show it to me before it
was printed.  As a matter of fact this whole article was edited
heavily but they promised that won't happen in the future.  I've
asked Pie to get my original one on this machine so you can check
it out.  I've written my next four back pages already and you can
tell because the vast majority mention Uma Thurman.  That means I
had to have written them before I saw "Henry and June" where Uma
doesn't feature her Thurmans.  Since then, I don't talk about her

12 min [?,C,G,M,Q] --> C

much.  I hold a grudge.  I'll try to get all the "PC Computing"
articles on-line here so you can read them without having to buy
"PC Computing" but you have to promise that if you read them here
you'll write a letter to "PC Computing" and tell them how much you
liked my articles and how because of them you'll buy the magazine
from now on every month.  They've had someone cancel their
subscription and write a nasty letter because I'm too violent.  I
need your help.

We've been on TV a lot pimping the "Penn & Teller: Don't Try This
at Home" - If you have a Nielsen box, please watch it and nothing
else that whole week and if you don't have a Nielsen box, use your
own judgement.  I think it's a good special and if it does well,
they'll let us do it again.

This is the first thing I've written in a long time for the Mofo
machine.  Since the Wall Street Journal talked about it we're
trying to get it up and keep it good so, if you got any ideas - let
us know.  I'll be writing stuff for this area pretty often from now
on and maybe I'll even write something good but right now I'm on an
airplane and you know how that is.

I'll have a diet cola, no glass, no ice,


12 minutes Press any key -->

           P E N N   &   T E L L E R ' S   S C H E D U L E

Television appearances:

November 16 - Late Night with David Letterman
November 20 - "Live at Five" in New York
November 23 - Penn & Teller "DON'T TRY THIS AT HOME" on NBC at 8:00 PM

Live appearances:

November 21 - November 25    Minneapolis
November 28 - December 16    San Francisco
November 18 - December 31    Los Angeles

11 minutes Press any key -->

                      N E W   P A S S W O R D S

   There are a couple new passwords.  To keep things clear I'll
   just list them all.

   MOFO -- basic password, basic TTY terminal
   MOFOV -- for fans who can emulate a Dec VT-100 terminal
   MOFOC -- fans that want to skip the Cold Open screens
   MOFOCV -- combo of C & V, natch

   Let me know if there are more options you want.


-- Some people have said that the vt-100 emulation isn't working.
I'll look into it and let you know why.

11 minutes Press any key -->

                     Join Penn & Teller's F.B.I.

They're three thousand nine hundred and fifty three point twenty
five miles below Manhattan, to be exact.  Coming at you louder
and louder from the Center of the Earth.

Want to know more? (Y or N): Yup

                     Join Penn & Teller's F.B.I.
              F A N S   B E L O W   T H E   I S L A N D

Penn & Teller, with the help of MOFO the Psychic Gorilla have
gone under, way under, to develop a fan club for all of you out
there who know these boys are onto something big.  Yeah, you'll
get bimonthly newletters, discounts on wild t-shirts, records,
tapes and videos, and someday (after they're out of style), there
may even be a button.  Gives you chills, huh?  You'll learn how
to swindle and humiliate like a pro, talk a blue streak about
funky new strains of music, pull crack-up jokes out of thin air.
Hey, you'll learn how to be cool.  This club's not for wimps or
Doug Henning/David Copperfield fans (redundant), your stomach is
probably not strong enough to join.  Think it over carefully.
Then GET DOWN, and send six dollars to:

Penn & Teller's F.B.I.
Earth's Center
c/o Box 1196, NY, NY  10185-0010

10 minutes Press any key -->

                            S E R V I C E
                      without the smile, for now

No, there is no electronic mail for now.  Talk to the Evil
Overload SweetiePie about this if you wish.  Don't bother
me, I just do as I'm told, when I feel like doing it.

There should be some fresh stuff on the board soon.  The
email probably won't return until I figure out a stable way
for it to operate, and perhaps not even then.

We're thinking about it.

November 1990:

Someone called in and trashed all the files on the hard drive.
We're not sure why, but we've taken some measures to make it a
little more difficult.  There are two announcements here, each
written by Penn and Teller.  Soon there will be a way for you to
write to them.

10 min [?,C,G,M,Q] --> C


10 minutes Press any key -->

                    A N O T H E R   W E L C O M E

    Glad you could squeeze in among the twenty calls a day that
    we've been getting.  Any comments you would like to leave for
    Penn & Teller should be sent with the electronic mail system.
    You have to log in with a name and password to use it.

Is this your first time on? Nope

 -- you said  to stop --
    by pressing a key

                   M O F O ' S   M A I N   M E N U

                This is Mofo's root menu, all submenus
               are accessed from here.  You can return
               to the previous menu from each submenu,
                       eventually ending here.

          Mofo ex Machina, version 3.0
          G: say goodbye (disconnect)

That was almost 25 years ago. Hopefully one day we can hear Penn tell us more about this BBS, and how it started and ended. Drop by Penn’s Sunday School (audio podcast) and drop him a note and maybe, if there is enough interest, he will make it a topic for an episode.

Preserving the past 8-bits at a time

There have traditionally been two types of computer owners: Users and Creators (programmers). In the early days of home computers, long before the existence of software stores, if you had a computer, you had to be a programmer to do anything with it — even if doing something with it just meant blinking some lights.

Soon, these Creators had become so prolific that they created their biggest creation: Users. By the time the home computer market exploded during the 1980s, there were people buying computers who would never create anything. Their technical skills may have only required them to know how to plug everything up and type some commands to load a program.

The days of the Creator as the primary computer owner have passed. Slowly over the 90s and 2000s, Creators became just a small percentage of the computer owning population. Many early Creators themselves went on to become Users as they no longer has the desire (or perhaps skills) to create the things they needed to make a computer useful. Why reinvent the wheel by writing your own word processor if you could just buy Word Star?

Certainly, if you were a Creator, you may have the only copies in existence of anything you created, whether that be a BASIC program, a love letter to an old girlfriend, or version of the Ghostbusters theme song you hand entered from sheet music.

If you were just a User, there is a much greater chance that someone else also has a copy of that Color Baseball you used to play so much on the family TV when you were twelve. However, relying on “someone else” to preserve it doesn’t always work. Today there is much software that has been lost, seemingly, forever. Even if you were just a User, it might be worth looking through all your old stuff you have in storage. You might have the only copy of something left in existence. (At least, until someone else does the same. But if you find it first, that saves them the work, right?)

As to myself, I was a Creator. I had cassette tapes and floppy disks and hard drives full of programs, documents, letters, music files, home movie scripts, song lyrics, ideas, and more. These are mostly items I have not seen since the 1980s as I moved from one piece of technology to another (cassette to floppy drive to hard drive), never looking back. I expect only the current “needed” stuff ever got transferred to the next new format. Sadly, some of the things I Created are now gone forever as the only floppy disk the contained them are unreadable.

If you still have some old tapes, diskettes or hard drives from an early computer, consider doing an archiving project. You never know what you might find.

In future articles, I plan to start sharing some of the really cool things I have found from my past, and sharing some tips on migrating your old data — at least if you are migrating it from an old Radio Shack Color Computer.