CoCoSDC for TRS-80 Color Computer part 1

9 Replies

See also: part 1, part 2, part 3, part 4, part 5 and part 6.

2014/12/30 Update: Tim Lindner corrected me. CoCo drives started out as double density, not single density. Corrections have been made. That means the 80 track 5 1/4″ drives I had were quad density. Thanks, Tim!

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 double 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 double-density (DSSD DSDD) for my primary drive, and two other 80 track double-sided double quad-density (DSDD DSQD) 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

5 Replies

1/27/2023: Hello, everyone. This page continues to be one of the most-viewed page on my site. Can you leave a comment and tell me what led you here? Thanks! -Allen

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;

   //Serial.begin(9600);

   value = 0x1234;

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

   //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!

1 Reply

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.

Rules:

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:

http://www.cocopedia.com/wiki/index.php/CoCoCoding_1980_Contest

iOS MFI game controller bluetooth protocol

Leave a reply

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…

Leave a reply

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?

Leave a reply

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.

Night Trap (classic FMV) on Kickstarter.

Leave a reply
https://www.kickstarter.com/projects/1018579240/night-trap-revamped

The classic full motion video game, Night Trap, is coming back, if they get Kick Starter funding.

I played Night Trap on the Sega CD, though it was later ported to other systems. It was one of the first, if not the first, live action full motion video games. It starred Dana Plato (from Diff’rent Strokes) as the heroin in a campy B-movie style horror flick.

It is noteworthy because of the controversy that sprung up around it, led by Nintendo, which caused the industry to adopt video game ratings. That alone makes this quite the historic artifact.

The original developers are wanting to re-release it for modern systems, and have gone back to the original 35mm movie film and digitized it in full resolution letting us see, for the very first time, what the movie was meant to look like (and not the low resolution 64-color versions we saw on the Sega).

Very cool. Check it out.