CoCoSDC for TRS-80 Color Computer part 2

In my previous article, I ran through a brief history of disk drives for the Radio Shack TRS-80 Color Computer (“CoCo”). This was intended to give a better understanding to the significance of Darren Atkinson’s CoCoSDC floppy drive replacement.

CoCoSDC was designed to fit in to the FD-502 disk drive cartridge enclosure, so it has mounting holes in the same locations as the original controller. For those who do not have a dead FD-502 controller (or, like me, do not want to gut a perfectly good one), Tim Lindner has produced the CoCoSDC enclosure, which is two pieces of cut plexiglass with some mounting screws and standoffs. I have received my CoCoSDC from Ed “Zippster” Snider, and the enclosure parts from Tim (see photo). Ed was offering the CoCoSDC assembled for $40, or $30 in a kit. The enclosure is $10 (or a few bucks more assembled). For a total of $50 plus shipping, it is a great value (SD card not included).

The CoCoSDC is some flash storage which appears to the CoCo as a ROM, the same as the original ROM chips on a real disk drive (or Program Pak) cartridge. Although CoCoSDC could run with the original Disk Extended Color BASIC ROM, it would be very limited since you would have to configure the SD card on a PC/Mac with to disk images that would appear as Drive 0 and Drive 1 to the CoCo. It would be like having a dual-drive floppy system that you couldn’t switch diskettes! Instead, Darren modified Disk BASIC so you could select which disk image should be used for either DRIVE 0 or DRIVE 1. (The CoCoSDC can only act like those two drives.)

New BASIC commands (or rather, additions to existing commands) allow you to mount existing images from the SD card (just like inserting a floppy disk) or create new ones. For most “normal” stuff, you use a .DSK image, which is basically just an image file containing a bunch of 256-byte sectors that match the normal sectors of a floppy disk.

The original 1981 CoCo floppy drive was a 35-track drive with 18 sectors per track. Each sector was 256-bytes. Thus, a disk image of an original 1981 disk would be about 160K (161,280 bytes = 256 * 18 * 35) and represent 630 sectors. A 40-track disk would be 180K (184,320 bytes = 256 * 18 *40). A double-sided 40-track disk would be 360K (368,640 bytes = 256 * 18 * 40 * 2) and a double-sided 80-track disk would be 720K (737,280 bytes = 256 * 18 * 80 * 2).

The size of the .DSK file on the SD card tells the CoCoSDC what to do with it. Basically, if the file you try to mount is 737,280 bytes or less, it treats it as a bunch of standard sectors. For software that used the standard disk format (256-byte sectors), this works fine.

However, not all software used the standard disk format. Some software chose to use non-standard sector sizes, which was useful for getting more user storage on a diskette or, more commonly, for copy protection. A programmer could have a portion of the disk in normal sector format so Disk BASIC could load some booter code, then that code could bypass Disk BASIC and talk to the drive controller chip directly to seek to other parts of the floppy disk and read tracks with non-standard sector sizes. This provided a simple method of copy protection since Disk BASIC did not handle non-standard sector sizes. Attempting to BACKUP one of these copy protected disks would fail in Disk BASIC.

Special programs, like The Defeater by Carl England, were written that could recreate the special sectors and make a clone of any copy protected disk. The Defeater has also been used to make virtual disk images of copy protected diskettes so they can be used in CoCo emulators and, now, with the CoCoSDC.

CoCoSDC calls these .SDF images and they contain much more than just a series of 256-byte sectors. A full description of the format is on Darren’s CoCoSDC page. SDF is basically an update to an earlier .DMK format created for use with CoCo emulators, but Darren restructured it so it could be implemented with the limited RAM on the CoCoSDC processor. Darren provides a “dmk2sdf” program you can use to convert emulator DMK files to SDF files that can be loaded on a CoCoSDC SD card.

For my project, my first goal is going to be to clone all my legacy floppy disks to a CoCoSDC SD card. Most all of my floppies are normal 35-track disks so they will end up as .DSK files. I also plan to use The Defeater to make images of all my copy protected CoCo software to .SDF files as well. (I’ll have to write a separate article on that. I have had The Defeater ever since Carl showed it to me at a CoCoFEST, but I have never actually used it.)

To do this, I will need both my floppy controller and CoCoSDC plugged in at the same time, which means I need to use a Multi-Pak. The software in CoCoSDC is able to access the real floppy drive interface, and mix real floppy drives with virtual SD floppy drive images.

By default, CoCoSDC boots with all the drives being virtual SD drives. For my situation, I want Drive 0 to be my real CoCo floppy drive, and Drive 1 to be a CoCoSDC virtual drive. I want to turn off the virtual drive 0:


The “DRIVE” command is part of Disk BASIC. Normally, it is used to set the default drive to use for commands like “DIR” and “LOAD”. If I ran to load a program from drive 2, I would have to type LOAD “PROGRAM.BAS:2″, but if I first type DRIVE 2, all future commands will assume drive 2, thus:


…could instead be done as:


Darren has expanded this command so you can put “,ON” or “,OFF” after it to toggle the status of a virtual disk. After typing “DRIVE 0,OFF”, if I type “DIR 0″ I should see my physical floppy drive 0 be listed.

To set a virtual drive, Darren has expanded the command to look for a quote character and a filename on the SD card. If I have a pre-created .DSK image called “BASIC.DSK” on the SD card, I could mount it as drive 1 by typing:


From that moment on, doing any access to Drive 1 would show the content of the BASIC.DSK file. However, in my case, I do not yet have any disk images. I can create one by adding the “NEW” keyword:


This should create a new file called “BASIC.DSK” (a 35-track singled sided disk image) in the root directory of the SD card. I could then insert a real floppy in to drive 0 and back it up to the virtual disk:


When the BACKUP is complete, I can swap out my floppy disks and insert to the next one. To swap out the virtual drive, Darren added an “UNLOAD” option:


I could then create my next disk and do a backup.

If all I had were standard 35-track Disk BASIC disks, this would be fine (if a bit time consuming with all the typing). A small program could be written to help automate this. It might ask you to type a short name for the disk you are inserting (8 characters or less, to match the filename of the .DSK image file) and then have you press ENTER to begin doing the “BACKUP 0 TO 1″. I will be writing (and sharing) such a program, soon.

Up next: 40 track floppies and other issues to solve.


CoCoSDC for TRS-80 Color Computer part 1

After a series of issues with the U.S. Postal Service with multiple shipments to multiple addresses, I finally have received my CoCoSDC and enclosure kit. As previously mentioned, CoCoSDC is a floppy drive controller for the Radio Shack TRS-80 Color Computer that emulates the original disk controller but instead of accessing physical floppy drives, it accesses data on an SD memory card.

First, let’s discuss a bit of CoCo disk drive history…

The Radio Shack TRS-80 Color Computer (later nicknamed “CoCo”) was introduced in July 1980 as a 4K computer that hooked to a TV set. The computer had a TV output (like an Atari 2600), and ports for a cassette cable (for hooking to a cassette recorder to load or save programs), serial port (for hooking up to a printer or modem), and two joystick ports. A cartridge port was provided for running software from “Program Paks” or future hardware expansion.

One such future hardware expansion was the Disk Drive controller (catalog number 26-3022) released in 1981. Although there were already some third party disk drive products, once Radio Shack released an official implementation, it would set the standard and other third parties would release their own compatible clones in coming years (J&M, Hard Drive Specialists, etc.).

The disk drive interface plugged in to the CoCo’s cartridge port and had a 34-pin edge connector coming off of it. A ribbon cable would then connect to standard 5 1/4″ floppy drives. The original Radio Shack unit came with a full height, single sided, 35-track, belt-driven 5 1/4″ floppy drive which provided 156K of storage on a single density diskette. Up to four single-sided disk drives were supported by the interface and the new Disk Extended Color BASIC which was contained on a ROM chip inside the cartridge. (Or, three double sided drives, but no one had those yet.)

Electornically, the interface could support double sided drives with up to 80 tracks (720K). This would later allow the use of 720K double density 5 1/4″ floppy drives, as well as 3 1/2″ drives (introduced in 1983, and made popular by the 1984 release of the Apple Macintosh). Thank goodness for compatible hardware standards (back then).

I found a good rundown of the Radio Shack floppy drives at Techno’s CoCo Floppy Page. Here is a brief summary:

Over the years, it appears Radio Shack released five versions of the disk drive interface. The original required 12V to operate (which the first Color Computer model provided, but later CoCo 2 and 3 models did not provide). Using it on a CoCo 2 or 3 required using a Multi-Pak expansion device, which plugged in to the cartridge port and provided four selectable cartridge slots (as well 12V power for older devices). After that, there was the FD-500 (26-3129) which was a 5V version of the original, followed by the FD-501 (26-3131, released in 1986 with a shorter cartridge) and the FD-502 (1986, 26-3133).

Besides circuit board changes, each release of the disk interface came with different floppy drives. The first two came with vertical full-height single sided drives. The FD-501 and FD-502 came with half height drives in a horizontal case with a slot to add a second drive later. The final FD-502 release was special, as it included a double sided drive, even though (for compatibility reasons), the Disk Extended Color BASIC still treated it like a single-sided, 35 track device. Patches were created to make Disk BASIC use more of the disk space, but disks written in that format could only be readable by other users running the same patches. Alternative operating systems like Flex and Microware’s OS-9 also could make full use of the storage.

On my personal CoCo setup, I eventually had a standard 40 track double sided single-density (DSSD) for my primary drive, and two other 80 track double-sided double-density (DSDD) 5 1/4″ floppies for storage. This gave my OS-9 BBS a massive 1.8 megabytes of storage! (I could have had up to 2.1mb if I had an 80 track drive for my boot disk, but I wanted one drive that was 100% compatible with stock formats). Later, I replaced my 5 1/4″ double density drives with 3 1/2″ drives (though I always had to keep a 5 1/4″ around, since the standard format software was sold on was still that).

Over the years, other store options became available with the introduction of hard drive interface cartridges from Radio Shack and third parties. I used several in my days, starting with a Burke & Burke interface that would use RLL or MFM hard drives, then moving to a KenTon SCSI interface and RGB-DOS (patches to Disk Extended Color BASIC which let you access the hard drive as if it were up to 256 floppy disks).

The introduction of the Iomega Zip drive (with swappable diskettes that stored 100mb each – wow!) was a problem, since the KenTon interface did not generate hardware parity which the Zip drive required. Because of this, I ended up using the competing SyQuest EZ-135 drives (which were faster, and stored more, but ultimately lost the format war to Iomega).

My final hard drive interface was the SuperIDE from Cloud-9. I never actually had an IDE hard drive hooked to my computer, but I did make use of the CompactFlash slot on the interface and used a CF card for my hard drive.

That’s quite the evolution from the original 156K floppy drive of 1981!

But I digress. This article is about the CoCoSDC. As you can see, over the years, floppies became less important as hard drive solutions became available. Many advanced CoCo users might only have two floppy drives (one for compatibility and booting, and possibly a second to make floppy backups easier). The need for 80 track floppies went away once low-cost hard drive options were available.

So why am I so excited about the CoCoSDC? It finally replaces the need for a physical floppy drive for anything but reading old media. Darren Atkinson designed the CoCoSDC to emulate the original CoCo floppy controller, so when it is plugged in to a CoCo, any software designed to access the floppy hardware will still work. This may seem like an obvious statement, but over the years, attempts to bring hard drive support to old systems have always had compatibility limitations. For instance, while Disk BASIC could be patched to allow the user to access virtual floppies on a hard drive, any software that was written to access the floppy controller interface directly would still try to do that, and would never run through the hard drive interface. Only software that used the native Disk BASIC floppy access routines had any hope of running from a virtual floppy drive, and even then, while RGB-DOS patched basic to let you have 256 virtual floppies, even compatible software might only let you type in “0-3″ for the drive to use so it might never let you use those extra drives.

CoCoSDC solves this by pretending to be the original Western Digital 1774 drive controller chipset to the CoCo. This makes it effectively 100% compatible with any software that ever ran from a Radio Shack floppy drive. However, there is still one limitation I can see. CoCoSDC can only map two floppies at a time, so if you actually had software hard-coded to require three or four floppy drives to run, you would be out of luck. (I believe this limitation is caused by the available RAM in the processor on the CoCoSDC.)

In part 2, I will discuss why all of this is incedibly important.

Splitting a 16-bit value to two 8-bit values in C

Recently in my day job, I came across some C code that just felt inefficient. It was code that appeared to take a 16-bit integer and split the high and low bytes in to two 8-bit integers. In all my years of C coding, I had never seen it done this way, so obviously it must be wrong.

NOTE: In this example, I am using modern C99 definitions for 8-bit and 16-bit unsigned values. “int” may be different on different systems (it only has to be “at least” 16-bits per the C standard. On the Arduino it is 16-bits, and on my PC it is 32-bits).

uint8_t  bytes[2];
uint16_t value;

value = 0x1234;

bytes[0] = *((uint8_t*)&(value)+1); //high byte (0x12)
bytes[1] = *((uint8_t*)&(value)+0); //low byte  (0x34)

This code just felt bad to me because I had previously seen how much larger a program becomes when you are accessing structure elements like “foo.a” repeatedly in code. Each access was a bit larger, so it you used it more than a few times in a block of code you were better off to put it in a temporary variable like “temp = foo.a” and use “temp” over and over. Surely all this “address of” and math (+1) would be generating something like that, right?

Traditionally, the way I always see this done is using bit shifting and logical AND:

uint8_t  bytes[2];
uint16_t value;

value = 0x1234;

bytes[0] = value >> 8;     // high byte (0x12)
bytes[1] = value & 0x00FF; // low byte (0x34)

Above, bytes[0] starts out with the 16-bit value and shifts it right 8 bits. That turns 0x1234 in to 0x0012 (the 0x34 falls off the end) so you can set bytes[0] to 0x12.

bytes[1] uses logical AND to get only the right 8-bits, turning 0x1234 in to 0x0034.

I did a quick test on an Arduino, and was surprised to see that the first example compiled in to 512 bytes, and the second (using bit shift) was 516. I had expected a simple AND and bitshift to be smaller, but apparently, on this processor/compiler, getting a byte from an address was smaller. (I did not tests to see which one used more clock cycles, and did no experiments with compiler optimizations.)

On a Windows PC under GNU-C, the first compiled to 784 bytes, and the second to 800. Interesting.

I ran across this code in a project targeting the Texas Instruments MSP430 processor. The MSP430 Launchpad is very Arduino-like, and previous developers had to do many tricks to get the most out of the limited RAM, flash and CPU cycles of these small devices.

I do not know if I can get in the habit of doing my integer splits this way, but perhaps I should retrain myself since this does appear incrementally better.

Update: Timing tests (using millis() on Arduino, and clock() on PC) show that it is also faster.

Here is my full Arduino test program. Note the use of “volatile” variable types. This prevents the compiler from optimizing them out (since they are never used unless you uncomment the prints to display them).

#define OURWAY

void setup() {
  volatile char bytes[2];
  volatile uint16_t  value;

  value = 0x1234;

#ifdef OURWAY  
  // 512 bytes:
  bytes[0] =  *((uint8_t*)&(value)+1); //high byte (0x12)
  bytes[1] =  *((uint8_t*)&(value)+0); //low byte  (0x34)
  // 516 bytes:
  bytes[0] = value >> 8;     // high byte (0x12)
  bytes[1] = value & 0x00FF; // low byte  (0x34)

  //Serial.println(bytes[0], HEX); // 0x12
  //Serial.println(bytes[1], HEX); // 0x34

void loop() {

  // put your main code here, to run repeatedly: 

Program like it’s 1980!

Just for fun, let’s pretend it is the summer of 1980, and you just walked in to a Radio Shack and saw the brand new TRS-80 Color Computer. Unlike the original TRS-80 Model I, this thing could hook up to a color television (instead of a monitor) and display colors and make sound! Amazing.

If you picked one up (and a cable to hook up a cassette recorder for loading and saving programs), what would you do with it? I propose a fun challenge to find out.


Your program can use any modern knowledge, but must run on a stock 1980 4K CoCo running Color BASIC 1.0.

That’s it. However, certain things would not be possible to create ON that machine. For instance, the EDTASM assembler ROM Pak required at least 16K, so any assembly language written on a 4K CoCo had to be hand assembled (somehow). If someone actually does that, it should be noted and given special consideration.

I propose the entries will be created in one of the following ways:

Native versus Expanded versus Cross Hosted – a program could be written on an actual 4K CoCo (native), or on a more expanded CoCo (16K CoCo 1, 512K CoCo 3, etc.), or compiled using PC/Mac/Linux cross compiler tools.

Real versus Emulated – likewise, the coding could be done on a real CoCo, or a virtual one in an emulator.

Ultimately, doing it actually on a native 4K real CoCo would be the only way it could have been done in 1980, but if someone wants to participate using an emulated one that is fine (but it will be noted, just so we can congratulate someone for actually still having a 4K CoCo around that never got upgraded).

More impressive things could probably be done using a later environment (EDTASM on a larger CoCo rather that native hand compiling), or using PC tools. That’s a different type of development, but ultimately, all should run on a stock 4K CoCo.

If you might want to follow this as we figure out how to approach it (or participate), details will be at the CoCoPedia wiki. In coming weeks I will make updates as we figure out more to this challenge:

iOS MFI game controller bluetooth protocol

Starting with iOS 7, Apple added official support for game controllers on an iPhone, iPad or iPod touch. Previously, the iCade standard was used, acting as a keyboard device sending key presses for button up and button down.

I have yet to find any place the discusses how these new controllers work. Has anyone reverse engineered it? Does it have digital rights management so you can’t pair using regular devices? Does anyone know?

1983: From the archives…

My first computer was a Commodore VIC-20 in 1982. In 1983, I switched to a Radio Shack TRS-80 Color Computer. Sometime in 1983, I wrote a bulletin board system (BBS) that could run from cassette tape. I previously discussed this old *ALL RAM* BBS when I converted it to run on an Arduino.

People who know me from the “CoCo Community” (CoCo = Color Computer) have heard this story before, and know that my BBS ran in Houston, Texas after I converted it to use disk drives. It was called Cyclop’s Castle, and the system operator (SysOp) was a guy named Graham who was, I believe, the cousin of another CoCo user I knew there, Trevor.

A few years ago, thanks to social networking, I was put back in touch with both of them, and went through the common process or reliving old memories and discussing things such as this old BBS. Until this week, though, Cyclop’s Castle was only a memory. While I may have a copy somewhere on an ancient floppy diskette, I had no idea where it would be in 1988 when I rediscovered my old *ALL RAM* BBS code and released it as shareware.

Earlier this week, while going through my storage room, I came across tons of old paperwork, including a sheet of paper with pencil notes for Cyclop’s Castle. It had the login messages, user level names and other things that were customized. I also found three printouts of some version of Cyclop’s Castle. The ink is faded, but I do hope it is readable enough for me to type it back in and recover this “lost” program.

It turns out, I did several upgrades to the system. In the original *ALL RAM*, only a user name, password, and access level was stores. For Cyclop’s Castle, it also took the caller’s phone number. There were a number of other small enhancements as well, which I should have rolled back in to the official *ALL RAM* when I posted it in 1988, but I had completely forgotten.

There may be more to tell about the tale of *ALL RAM* BBS. I’ll post more when I get time to go through more storage. Who knows what else I will find?

80’s text-based “where in the solar system” game?

I was calling bulletin board systems (BBS) in Houston, Texas between 1982 to 1984. After that, I moved to a small town with no such systems, and other than the occasional long distance call, I wouldn’t have anything to dial again until 1987 when I moved to a less-small town.

I recall there being an online game called “Where in the solar system”. It would present a description of a planet, and you would have to guess which planet it was. I expect it was some existing program found in “GAMES IN BASIC”-type books or something. Someone had taken that game (or wrote a clone) and changed it to be “Where in Six Flags” (referring to the original Six Flags over Texas near Dallas). It would describe rides instead of planets. I recall it describing things like “you can hear screams” or “you feel vibrations.”

Does this ring any bells to anyone out there? There certainly were localized original programs running in Houston (several BBSes I dialed ran on custom software which never existed anywhere else, and I contributed a number of small programs to Apple NETWORKS BBSes which I don’t expect ever got spread around). I wonder if any of this got preserved.

I bring this up after I uncovered some old paperwork last night. I found my original hand-written instructions for the *ALL RAM* BBS I had written. I did not have a printer at the time. I also found notes for the upgraded/customized version that a friend ran in Houston (Cyclop’s Castle) and discovered it had more things added to it than I recalled. I hope to go through all my old files and scan in all my documents to preserve them, and also clone all the floppy disks I have to disk images.

It does make me wonder how much has just been lost and discarded over the years.