Ahh, misspent youth. When I was a young man, I caught the bug. Computers. The Radio Shack in the mall put a TRS-80 Model III out in front of their store, and I was intrigued. Intrigue turned to passion, and passion turned into nerdly obsession, and I spent every hour I could standing there, playing with it, learning about it, writing programs in BASIC which I couldn’t save, and which would be gone the next time I could convince my parents to take me to the mall.
From there, I was hooked, and my obsession eventually became a career. My first computer was almost a Timex/Sinclair ZX-81, which I saved for all summer, mowing lawns in order to have the $99 that this wonderful little machine cost. At the end of the summer, my parents intervened, and, since it had the Good Housekeeping seal of approval (and the ZX-81 did not), I ended up with a Radio Shack TRS-80 Color Computer, instead - grey case, with 16K of memory on what was almost a reference implementation of the 6809E chipset.
I was thirteen.
Between the TRS-80s and the Burroughs mainframe running the CANDE OS (pronounced like "candy") with the VDTs and DecWriter printer terminals at the college where my dad was taking night classes, this was my introduction to computer science. I read every book I could in the college library – even the ones I didn’t understand. I learned about Pascal and LISP, BASIC and FORTRAN, Algol 68 and SNOBOL. I learned about the TRS-80 Color Computer. I memorized the memory map. I knew the PEEKs and POKEs. I became an expert on the hardware – and then I started hacking it. Primitive relay driven robotics projects, toy tanks with wires dangling out of them, wired to the PIA chip in the CoCo. Sensors and bad, poorly connected soldering. Memory upgrades. A floppy drive! No more finicky, unreliable tape backups. And in the end, many years later, a hard drive. 40 Megabytes worth of RLL driven storage, way more reliable than the floppies, thanks to a WD1002A-27X ISA hard drive controller, and an interface kit from Burke and Burke. More space than I would ever use.
|I spend a lot of my time|
doing things like this.
Radio Shack, in the heyday of the TRS-80 line, controlled a large part of the home computer and business computer markets, but, eventually, the the IBM PC won. And, like many other computers and video games, my Color Computer ended up in boxes in the attic, full of hardware, cables, slowly mouldering floppy drives -- and one 40 megabyte RLL hard drive, containing a file system not compatible with any modern system, accessible through hardware increasingly incompatible with modern PCs - or any other hardware. A hard drive containing the only copies some of the first programs I ever wrote, slowly deteriorating on largely inaccessible hardware.
Over the years and decades, I had made some attempts to recover this, to move these files to modern hardware, before the inevitable happened, and the contents of that drive were lost forever. Many challenges lay in that path, including no clear interface between the CoCo and a PC, no way to directly access the hard drive from modern equipment, and the fragility of the old equipment. In the end, the fragility became a major issue, and rescuing the data from the hard drive became a race for time, as simply accessing data on the disk would tend to corrupt it. There was one program in particular, an adventure game written in Pascal that I wrote, which I very much wanted a copy of. If I could get that file, I would consider the recovery effort to be a success.
Recently, I attempted one more time to salvage these old floppies and the hard drive, and, this time, I succeeded. Here's how I did it, with notes on what worked for me, and what didn't.
Access to the hardware
Solving the monitor problemSome of the first problems to solve were simply access to the hardware. The Color Computer uses RF output in an analog format (NTSC, PAL in other parts of the world), which is not compatible with modern televisions, for the most part. Fortunately, I do have an old analog television, just for problems like this, but, it's small, and, the CoCo has never had truly great output for televisions -- wavy lines and other interference are common. There are a couple of possibilities here, and I tried them both. First, I can convert the analog output to VGA using a converter. These converters proved to be a little difficult to find, but I managed to find a decent one on Amazon, which I used for a while. In the end the resolution wasn't there, and the output was a bit fuzzy -- good enough to play old video games, but not good enough for clear text.
The second possibility, at least on the CoCo III, is to use composite output. I have an old Apple ][ monitor, so, I tried this for a while, but, the output was never very crisp, especially at higher resolutions (such as when running OS-9 in 80 column mode), so in the end, eye fatigue did this solution in.
The third possibility, at least on more late model CoCos, is that there is a mostly-CGA-compatible port on the underneath of the machine, which can plug to the (mostly) proprietary CM8 monitor which was sold as an accessory to the CoCo. These monitors are hard to find, having not been made in several decades, but there are other, truly CGA compatible monitors that can be used (if you can find one), usually with a bit of level converting or other soldering involved. In the end, I did -- very luckily! -- score a CM8 monitor on eBay, and, in the end, this was the solution I went with for video output.
The Keyboard ProblemThe second problem to conquer, hardware-wise, is the fact that there is not a detachable keyboard for the CoCo. In the past, what I have done to solve this is to find an older keyboard, and re-wire it so that the keys on the keyboard map to the IO matrix that the CoCo expects. This usually involves a lot of soldering, a rather thick cable between the keyboard and the computer, and an irrevocably altered case. None of these were desirable, so, after a week or so of crouching on the ground typing on the old machine, I broke down and got a PS/2 keyboard interface from Cloud9. This allows me to plug a readily available, modern keyboard into the Color Computer. I had a mini keyboard in the style of the original IBM PC which I used. It's got real springs in the keys and makes some very satisfying, if somewhat loud, clacky sounds while typing. Between that and the coiled cable, it is very retro-awesome.
Rescuing the FilesIn order to copy the files off of the floppies and on to something a little more reliable, I used another product from Cloud9, their SuperIDE interface. There are essentially two interfaces like this, one created by Cloud9, and the other put together by the Glenside Color Computer club -- who, incidentally, have been annually hosting the "last" CocoFest for over twenty years at this point. Because the Cloud9 interface supports NitrOS-9, and because NitrOS-9 and DriveWire integration is pretty tight (I used DriveWire later on in the process), I went with the SuperIDE interface. This interface allows me to hook up IDE devices to the CoCo, and access them like regular hard drives. In my case, I used a ZIP drive to do initial backups, and a compact flash card to do the initial booting into NitROS-9. I also used the compact flash to back up RSDOS (ie, native color computer) disks. HDB-DOS, an extension to Disk Extended Color BASIC (or, "DECB" for short), allows a CF card to look like 255 individually addressable floppies. For the first four floppy drives, a command allows you to switch back and forth between real floppy drives and the virtual ones, which allows you to copy between the physical drives and the CF card. After some long nights of babysitting the machine while changing floppies, accompanied by a database to track which slot had which virtual floppy, the easy part of copying the RS-DOS files was done.
This setup also allows for partitioning of a CF card (or other IDE device) to have two partitions -- one, RSDOS "floppies" as described above, and the other, an OS-9 partition. One of the emulated floppies serves as the boot floppy for the OS-9 system, and can be set to execute when the system powers on. This setup requires you to load a custom version of HDB-DOS into one of the ROM banks in the SuperIDE interface (The custom ROM image points to the correct offsets for the partitions), and creating an OS-9 boot floppy image suitable to your system, loaded into the correct "floppy" slot. Make backups, and make backups often! Use a scratch CF card, instead of one you might mind losing data on. Setting this up can be a little tricky, but is well worth the effort. Cloud9 can also set you up with a preformatted CF card, to save you the effort. Many thanks to Mark Marlette and Boisy Pitre over at Cloud9, who answered all my dumb questions and got me un-stuck on more than one occasion!
Access to OS-9OS-9 proved to be slightly more difficult, especially as I was not to be satisfied by simply backing up the files into a safer medium than that which a dying hard drive provided. I wanted to get these files off of that hard drive, and accessible to a PC. Cloud9 offers a service for this, but I wanted to give it a go first, before admitting defeat. After many false starts, This is what I did:
1. Create a NitrOS-9 boot disk, and alter it to allow access to the old hard drive. RLL and MFM hard drives are not plug and play. Even on the PC, the user of these devices had to know things like the number of cylinders, sectors, the sector size, and the desired interleave factor to get them to work right. In the CoCo, same thing. For the Burke & Burke interface, and using OS-9, you create a driver description file (which uses a core driver module, provided here by B&B ages ago), which contains this information. These are hard to set up. In older versions of OS-9, the order of modules in the OS9Boot file matters, and they must be in contiguous sectors on the disk. Size matters, as well, and the entire process of creating a viable boot disk with a working boot file is very, very finicky. Fortunately, when I was young, I saw the danger of losing this information, once I got it right, and made many backups of the boot floppy. Like, a lot of backups. Ten, maybe twenty. The paranoia, as it turns out, was justified -- these 30 year old floppies started failing pretty regularly once I started accessing them again.
|Fragile. So very fragile.|
I fortunately had some floppies which were "new" -- never opened, never used (but still decades old). These also proved to be a little unreliable, but less so, and, mostly good enough. From here, with the same (arduous) process described above, I created a NitrOS-9 boot disk, and added in the old drivers. NitrOS-9 is a more modern implementation of OS-9, and is actively maintained (go here for the code base, and here for more information), so, the process is a bit easier these days, but it can still be touch and go. After a few tries, I had access to the old hard drive under NitrOS-9.
From here, make many, many backups of the boot floppy, and continue to the next step.
2. Alter the boot disk so that it can talk to the Color Computer and some sort of modern hardware at the same time. Ideally, this would mean that the boot disk would be able to talk to a modern hard drive (a PATA/IDE drive, in my case, since I am using the SuperIDE interface. Interfaces for SCSI exist, as well), and the old RLL/COCO XT drive at the same time. Another very desirable feature would be to talk to a modern PC using something like DriveWire. Having this all at the same time would be ideal.
Unfortunately, it did not work out. I could get the combinations of (DriveWire + COCO XT) and (DriveWire + SuperIDE) to work, but not (DriveWire + COCO XT + SuperIDE). The problem appears to be the undelying SuperIDE drivers and the COCO XT drivers interfering with each other. Most attempts with all three wouldn't even boot, and things like loading the other drivers (say, COCO XT) after successful boot would at best not be able to access their respective drives, and, at worst, immediately crash the system on loading the driver and device descriptors. Since my goal was not truly to have a system with all these at the same time, but rather to rescue old files, I resolved to use the two combinations, (DriveWire + COCO XT) and (DriveWire + SuperIDE), to do separate pieces of the work. Since I could have (DriveWire + SuperIDE), I used that to copy any OS-9 specific floppies I had over to my IDE drive (an IOMega ZIP drive, which worked out very well for this purpose), and, to rescue the files off the hard drive, I used the combination of (DriveWire + COCO XT). To copy the files using either configuration, I used the built-in OS-9 command, DSAVE, which basically issues a bunch of directory change and COPY commands, to copy each individual file. Depending on memory configuration, you may need to direct the DSAVE output to a file first, and then execute it. In OS-9, you can preload modules to make execution faster (for instance, you may preload and hold resident in memory the DIR, CHD and LIST commands). I found that I had to remove a lot of the modules I had preloaded in order to get DSAVE to not error out because of too little memory, even on a machine with a 512K expansion board (this is a LOT of memory for a Color Computer, considering the first iterations of the machine came with memory sizes such as 4K and 16K). There is another program available for the CoCo, named "ARC", which, for a lot of things, does a better job of copying directories and subdirectories, but, because of the state of the drive it was copying from, it didn't always work out. I found that the slow, plodding method that DSAVE takes to be more reliable in this situation. ARC, however, is a great tool. It, and a bunch of other really useful tools can be downloaded here.
Note- using the "ex" builtin, if you have Shell+ installed (standard on NitrOS-9), can reduce the memory problem I describe here.
From here, the procedure was:
- Start DriveWire on the PC
- Ensure connectivity from the CoCo, usually by just doing a DIR on the remotely emulated drive
- Start DSAVE on the CoCo, and monitor it. I would recommend getting a book and sitting there babysitting it, because, while reliable, there will from time to time be hiccups, and you'll need to restart it occasionally.
After quite a few hours, the copy process was done. There were read errors on the old hard drive, as is to be expected, but I'd guess that about 90% of what was on there was successfully copied. At some future date, I may try to repair the hard drive sector by sector, but I don't actually have high hopes for that, since every read tends to corrupt it just a little bit more.
I did, however, find many cool things on that drive!
What I found on the hard driveIt's amazing, looking back in time to where I was about two decades ago. The last that this machine was heavily used was somewhere around 1992 to 1995.
Languages, Languages, LanguagesI have always loved playing around with different computer languages. Aside from the standbys of C and Pascal (of which I have two versions each, from Microware and Frank Hogg Laboratories/DynaSoft), I also have compilers for languages such as LISP (xlisp in this case), LOGO (fun! this language can do a lot more than just turtle graphics!), and PILOT (a programming language for teachers, allowing them to create online lessons), and Basic09 (a cleaned up, Pascal-like version of BASIC made specifically for the OS-9 operating system).
Snapshot of lifeThere were also grocery lists, to do lists, old, low resolution GIFs, lists of phone numbers, and letters to an old girlfriend (Did she really used to call me that? How embarrassing.) There were also emails and posts from the Delphi and CompuServe systems (but not the missing archives, sorry), as well as emails sent across the RiBBs BBS system, and various online manuals. There were also copies of Tandy's productivity software, such as DeskMate and MultiVue, which is a windowing system for OS-9. MultiVue is still under active development. Latest versions, source code repository, and news can be found here.
|An older version of MultiVue running on my CoCo, output to my TV. The drives are listed along the left side, with details in the middle. This is showing the top level directory for floppy drive 0, which is a bootable drive (note the os9boot file). MultiVue is capable of launching programs, managing windows, and so forth.|
In the end, I did find a copy of the program that, for me, had become symbolic of this rescue effort, and the measure of success as to whether my rescue attempts, in the end, came through.
I was successful. I rescued it from the old, dying system, and now have many backups of it, and many other programs like it. Named ADVGAME.PAS, it is a youthful attempt at creating a text-based adventure game.
Here's the code:
Note: DynaSoft Pascal does not have a string data type.
And there it is -- rescued from my dimming earlier years, an attempt at a world, an exposition of self taught, budding skills. Time has passed, the hardware no longer relevant, the software relevant to nobody but me. But I had to reach back, through the unrelenting waters of time, and grasp for one distant yet limpid memory, and rekindle that link to my own personal past.
I won. I got it. I made that link. And thirteen? Distancing and ever fading thirteen.. Thirteen, I'm all right with you.
(disclosure: although I mentioned Cloud-9 a bit in this post, I am not an employee, shareholder, etc. I just use their stuff :-) )