Category Archives: CoCoSDC

CoCoSDC SDC-DOS version 1.14 release

In case you missed it, in December 2016, a software update to CoCoSDC and SDC-DOS was released. You can find it under “Latest Firmware” on this page:

http://cocosdc.blogspot.com/

SDC-DOS is now up to version 1.14 and includes the following changes:

  1. AUTOEXEC. If “AUTOEXEC.BAS” if found on a mounted disk image, it will automatically run on startup. Holding down SPACE on startup will bypass this. (I think Kenton’s RGB-DOS did this?)
  2. EXP. A new “EXP” command has been added. It will mount an image called “SDCEXP.DSK” and, if present, run “AUTOEXEC.BAS” from that image.
  3. DEF DW. You can now specify DriveWire baud rates.
  4. WRITE/COPY MEM. These commands can now write to flash pages $FExx on a CoCo 3.
  5. RUN @bank. Code to select and execute one of the virtual ROM banks has been rewritten to make it more compatible with various ROMs.
  6. DSKINI. Fixes a bug where drive motor could remain on when using a CoCoSDC and a real floppy controller at the same time.

The update comes with a .DSK image that you mount and then run a utility which will take care of the upgrade.

Nice! I just started setting my CoCo system back up, and will be trying this out soon.

Manually making a bootable NitrOS9 hard drive image – part 2

See also: part 1, part 2 and part 3.

Updates:

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

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

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

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

The Problem With Cobbler

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But wait! It gets worse…

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

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

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

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

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

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

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

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

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

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

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

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

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

ERROR #244

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

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

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

Manually making a bootable NitrOS9 hard drive image – part 1

See also: part 1, part 2 and part 3.

Updates:

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

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

Creating an OS-9 Boot Disk

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

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

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

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

“DOS” Command Booting

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

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

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

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

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

The boot process, therefore, includes:

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

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

CoCoSDC Changes Everything

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

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

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

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

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

But … there is a problem.

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

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.

CoCoSDC for TRS-80 Color Computer part 6

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

When we last left off, I was discussing how the CoCo’s drive controller accessed multiple physical floppy drives by using drive select lines.

In the early days of CoCo disk drives, each drive was configured to respond to the same drive select (drive select 1, for instance). A special ribbon cable was used which flipped some wires at each connection, moving different drive select lines from the controller to the same (drive select 1, for instance) line of the drive. The first plug (for DRIVE 0) would have drive select 1 go to that drive’s drive select 1 pin. The second connector would have some wires twisted and flipped so drive select 2 would go to the drive’s drive select 1 pin. This was done so you did not have to configure each drive (by opening it up and moving a jumper connector) to respond to a different drive selects.

It was this method with a “4-drive cable” that CoCo users could plug up four of the same single-sided drives (all configured as drive 1s) and where they plugged in on the cable would determine which drive they responded to from Disk BASIC.

If you used a normal (and cheaper!) flat cable that passed all four drive select lines to each drive, then the drives had to be configured to know which select they should respond to. A double-sided drive had three drive select options (1, 2 or 3) and also responded to the side select line.

As previously discussed, the CoCoSDC hardware honors some of these drive/side select lines, but SDC-DOS’ disk routines bypass several places where normal Disk BASIC would be using them to pass along to the drive hardware. Because of this, the standard POKEs we used on real hardware to access the back sides of double-sided drives from BASIC do not work. While the hardware is willing the software is not.

But, if you were to boot the CoCo using standard Disk Extended Color BASIC, it will work. The CoCoSDC hardware honors the first two drive select lines and side select. The problem is, without SDC-DOS, you don’t have a way to mount disk images or enable/disable the virtual SD card drives when you want to access a physical drive.

SDC-DOS handles communication with the CoCoSDC firmware. That firmware handles the disk image files and making them look like physical sectors to whatever software is running on the CoCo (Disk BASIC, OS-9, copy protected software using its own disk routines, etc.).

Fortunately, CoCoSDC designer Darren Atkinson has provided a simple BASIC program that can send commands to the CoCoSDC firmware. It’s not as simple as typing in DRIVE0,”GAMES.DSK”,NEW but it does allow the major functions to be done when you are not running SDC.DOS. He shared the following:

Below is a BASIC program I sometimes use when SDC-DOS is not present. It’s a little slow and definitely more cumbersome than entering commands in SDC-DOS, but it gets the job done.  Save this program somewhere on your CF card or SCSI disk so you can run it when using RGB/HDB DOS.
 

The program is:

10 OS=PEEK(&HFF7F):INPUT "MPI SLOT#";SL
20 IF SL<1 OR SL>4 THEN 10
25 SL=SL-1
30 INPUT "SDC DRIVE#";DR
40 IF DR<>0 AND DR<>1 THEN 30
50 LINE INPUT "COMMAND? ";C$
60 IF LEN(C$)<2 OR MID$(C$,2,1)<>":" THEN 50
70 C$=C$+CHR$(0):P=VARPTR(C$)
80 P=PEEK(P+2)*256+PEEK(P+3)
90 POKE &HFF7F,OS AND 240 OR SL
100 POKE &HFF40,67:POKE &HFF49,0
110 POKE &HFF4A,0:POKE &HFF48,DR+224
120 A=&HFF4A:B=&HFF4B
130 FOR I=P TO P+254 STEP2:POKE A,PEEK(I):POKE B,PEEK(I+1):NEXT
140 ST=PEEK(&HFF48):IF ST AND 1 THEN 140
150 POKE &HFF40,0:POKE &HFF7F,OS
160 IF ST AND 128 THEN PRINT "ERROR";ST
 (I sure hope WordPress doesn’t eat the program listing again.)
 
He provides the following instructions:
 
When you run the program you will be asked for the MPI slot number containing the CoCo SDC (1-4).  You could edit line 10 to remove the INPUT statement and just set variable SL equal to the slot number.Next you will be asked for the SDC Drive Number (0 or 1) to which the command will be applied. Enter 0 for commands that don’t apply to a specific drive number, or just press ENTER.Finally you will be asked to enter a command string. Command strings begin with a letter and a colon (:). Immediately following the colon is a path name to a file or directory on the SD card.

 

Commands Available:

D:  set current directory on SD card
K:  create new directory
M:  mount or eject a disk image
N:  create (if necessary) and mount a DSK file
X:  delete a file or an empty directory

Examples:

——————————————–
Set current directory to /GAMES/ARCADE

SDC DRIVE#? 0
COMMAND? D:/GAMES/ARCADE

——————————————–
Mount Donkey Kong image in drive 0

SDC DRIVE#? 0
COMMAND? M:DONKEY.DSK

——————————————–
Eject the disk image in drive 1

SDC DRIVE#? 1
COMMAND? M:

There is also a Rename command (R:).  That one requires a second null-terminated string (new leaf name) to be included in the 256 byte data block immediately following the first string.

 

C$ = “R:PATH/TO/OBJECT.EXT”+CHR$(0)+”NEWNAME.EXT”+CHR$(0)

This will be a key piece to handling RS-DOS doubled sided disks and backing up the individual sides to CoCoSDC disk images.

He also provided a way to call the additional DSKCON routines that SDC-DOS adds:

Here is a Basic subroutine which calls DSKCON to mount the file named DN$ into drive 1. Explanation of the code follows:

1000 DK=PEEK(&HC004)*256+PEEK(&HC005)
1010 SD$=”M:”+DN$+CHR$(0)
1020 P=VARPTR(SD$)
1030 POKE 238,PEEK(P+2):POKE 239,PEEK(P+3)
1040 POKE 234,&H85
1050 POKE 235,1
1060 EXEC DK
1070 ST=PEEK(240):RETURN

1000 assign DSKCON code address to variable DK
1010 build command string (SD$) to mount the file
1020 get pointer to the string descriptor (P)
1030 set DSKCON buffer to the command string data
1040 set DSCKON opcode to transmit a command string
1050 set DSKCON drive number to 1
1060 call DSKCON
1070 read DSKCON status result into ST and return

Meaning of bits in the status code:

Bit 7: set on any error.
Bit 5: set if file is already open in other drive.
Bit 4: set if file or directory was not found.
Bit 3: set on various hardware errors.
Bit 2: set if file or path name is invalid.

– Darren

You may be wondering why we might want to call SDC-DOS’s DSKCON directly. After all, if you are running SDC-DOS, you already have these commands. In my situation, I needed a way to detect if an image exist. There is no such call, so the only thing you can do is attempt to mount the image (DRIVE 0,”IMAGE.DSK”) and if it fails with a not found error, it doesn’t exist. On a CoCo 3, there is an ONERR command one could use to error trap that call so you might do something like this:

100 REM See if image DN$ exists.
110 ONERR GOTO 150
120 DRIVE 0,DN$
130 REM If here, we were able to mount, so it must exist.
140 PRINT "Image exists."
150 END
...
200 REM If here, we were not able to mount.
210 ONERR 'Turn off ONERR
220 PRINT "Error mounting image.":END

This works, but ONERR was only added in the CoCo 3’s Super Extended Color Basic. For the CoCo 1 and 2, this technique wouldn’t work. Thus, Darren provided me his DSKON routine so I could try to mount an image that way and read the returned status code.

Now I should have all the pieces I need to do what I want to do, which means this is a good place to say…

To be continued…

CoCoSDC for TRS-80 Color Computer part 5

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

The story so far…

In 1980, Radio Shack introduced a computer with color. Later, they introduced a disk drive for it. Even later, everyone stopped using disk drives so an enterprising engineer created a disk drive replacement for a 34-year old computer. This is the story of that disk drive replacement.

Sort of.

Color BASIC PEEKs to get the stat and end of a BASIC program in memory.
Color BASIC PEEKs to get the stat and end of a BASIC program in memory.

As I write this, it has only been a week since I got out my old Tandy Color Computer 3 (CoCo). I have forgotten many things, and can’t remember why I remember other things. For instance, PEEK(25)*256+PEEK(26) will give you the memory location where your BASIC program starts, and PEEK(27)*256+PEEK(28) is the end of it. Subtract those two and you know the byte size of your program. But I digress.

I have now spent a bit of time playing with the CoCoSDC disk drive interface. Initially I just took all the CoCo .DSK image files I had downloaded in the past and copied them to an SD card and spent an evening loading up software. I even ran across a game written by former Sub-Etha Software guy, Joel Hegberg, that had been published in a 1989 issue of Rainbow magazine. Ah, great times. Such nostalgia.

On another evening, I dug through my storage room and finally located a few containers of old 5 1/4″ floppy disks. There had even been one left in my FD-501 floppy drive while it was stored for a decade. The disks I tested still seemed to read (though I already crashed one). I did some test backups, and marveled at how fast the CoCoSDC was compared to the mechanical floppy of decades past. I wrote a bit of BASIC code (similar to what I shared in part 4) to see if I could automate this process.

On my third evening of CoCo time, I started writing the actual backup program. When I was a beginner programmer, I used to blast through code and hack everything together until I had it working. Then I would make a printout, and begin completely rewriting it, all cleaned up and nicer. Think of it as manual two-pass optimization. :) This time, with two decades of programming experience more, I am trying to do more planning and designing.

In order to understand what makes this a challenge, one needs to understand the various types of disks that the CoCo could use over the years: from original single-sided 35-track RS-DOS disks, to double-sided 80-track disks for RS-DOS or alternate operating systems like OS-9. As long as the format used standard 256-byte sectors (i.e., no funky track layout formats which were common with copy protection methods), I wanted to be able to back it up to the CoCoSDC.

First, let’s discuss what it took to create and read these disks.

The Color Computer’s disk controller hardware has four drive select lines it can control. Actually, they are technically three drive selects and one side select. The original CoCo disk drives were single sided, and Radio Shack’s Disk BASIC used these four lines to select one of four possible single sided disk drives. The various disk related commands (BACKUP, DIR, COPY, etc.) allow drive numbers 0-3.

As drives went from 35-track to 40-track, and went from slow belt-driven drives to faster direct drives, CoCoists figured out how to patch Disk BASIC to access 40-tracks, and speed up the drives. (Disk BASIC accessed the drives with a 30ms step rate. Later drives could run at 6ms.)

Patching for 40-track drives was simple, but has some limitations. Disk BASIC reserved enough memory to maintain four 35-track Granual Allocation Tables (GATs, kind of like how FAT is the PC file system). When you patched it for 40-track drives, you could only use three (single sided) drives max. If you wanted to use an 80-track drive, you could only have one. There were alternate patch methods that allowed more drives, but they re-used memory which prevented you from having files open from different drives at the same time. Tradeoffs.

As double-sided drives became common, CoCoists realized that instead of using these four lines to select four single sided drives, they could be used to access three double-sided drives. Alternate operating systems like Flex and OS-9 were able to make easy use of double-sided drives, but Disk BASIC users had to come up with more patches.

As it turns out, patching for double-sided drives in Disk BASIC was easy if you just wanted to treat each side of the disk as it’s own single sided disk. If all you had was a single double-sided floppy drive (DRIVE 0), you could do a simple one-byte change that would make DRIVE 1 access the back side of DRIVE 0. Now you could double your storage without having to cut notches in the floppy disk and make them flippies you had to manually turn over.

If you had two physical double-sided drives, you could make them appear as four separate single-sided drives (DRIVE 0-3). This became a very common practice for many CoCoists, especially after Radio Shack released the FD-502 disk drive which was double-sided.

Now let me pass the buck… Here is an archived webpage that I found useful when explaining the drive selects and how to make Disk BASIC access the back side of double-sided drives:

http://www.oocities.org/theother_bob/coco_page/ccdisk00.htm

In it, he refers to the July 1985 issue of Rainbow magazine which had a very detailed article about Disk BASIC and drive selects and tracks and GATs and stuff. Here is a scan of that issue:

https://archive.org/details/rainbowmagazine-1985-07

(Wow. That was weird. I used Google to find that scan, and when I clicked the link, it opened right to the article I am talking about. Spooky. If yours does not, look on page 26, “Getting on the Right Track” by Colin J. Stearman. Wow again. I remember reading this when it first was published… 29 years ago!)

(Wow #2. I just realized this was the Anniversary issue where Rainbow included a reprint of their first 2-page newsletter. Look at the first letter to the editor on page 6 and see who wrote in to suggest that. “Great idea, Allen.” Ah, my lame claim to fame! Oh, and they printed my request for pen pals in the October 1985 issue on page 9 too. Such memories!)

But I digress…

In the Stearman article, he shows how to take a dual-drive system (with two double-sided drives) and make it look like four drives to Disk BASIC. DRIVE 0 would be the top side of the first drive, DRIVE 1 be the top side of the second drive, DRIVE 2 be the bottom side of the first drive, and DRIVE 3 be the bottom side of the second drive. (This kept DRIVE 0 and 1 as two different drives for compatibility.)

For Disk BASIC 1.1, here are POKEs. They work on a CoCo 3 because it’s Disk BASIC is copied in to RAM on startup and can be changed, but for earlier machines, it has to be a 64K machine with a “ROMRAM” program that copies the ROMs in to RAM then runs from RAM (so you can POKE the RAM copy and make changes). For systems where the ROM can’t be copied and ran out of RAM (16K or 32K), you would have to modify and burn a new ROM for the drive controller.

POKE 55453,1 'Drive 0 accesses top side of physical drive 0
POKE 55454,2 'Drive 1 accesses top side of virtual drive 1
POKE 55455,1+64 'Drive 2 accesses back side of physical drive 0
POKE 55456,2+64 'Drive 3 accesses back side of virtual drive 1

The drive select bits are bit 1 (first drive), bit 2 (second drive), bit 3 (third drive), and bit 7 (side select). If my understanding is correct, CoCoSDC hardware emulates bit 1, bit 2 and bit 7. In SDC-DOS, you can disable a drive so those bits control a real floppy controller if one is also plugged in via a Multi-Pak or similar device.

This means you might be able to do something like this:

DRIVE 0,"FLIPPY1.DSK" 'Make Drive 0 a .DSK image
DRIVE 1,"FLIPPY2.DSK" 'Make DRIVE 1 a .DSK image

POKE 55453,1 'Drive 0 top side of physical drive 0
POKE 55454,2 'Drive 1 top side of virtual drive 1
POKE 55455,1+64 'Drive 2 back side of physical drive 0
POKE 55456,2+64 'Drive 3 back side of virtual drive 1

DIR 0 'Uses first half of FLIPPY1.DSK
DIR 1 'Uses first half of FLIPPY2.DSK
DIR 2 'Uses second half of FLIPPY1.DSK
DIR 3 'Uses second half of FLIPPY2.DSK

But, you cannot. While the CoCoSDC hardware is able to emulate up to an 80 track double-sided drive, and while OS-9 can make use of this easily, the SDC-DOS software works differently and those original Disk BASIC patches will not work. The designer, Darren Atkinson, explained:

When the DSKCON routine in SDC-DOS is called to do I/O for a sector with standard numbering (track 0-34, sector 1-18) it bypasses the traditional floppy access method of spinning up the motor and stepping the head to the correct track. Instead it just calculates the absolute sector number and sends an LBA request to the controller.

This optimization does not look at the drive selects table, so it won’t honor any changes you have made with POKEs.  – Darren

Entirely new patches would be required for the current release of SDC-DOS 1.2. Or, perhaps, a much easier method is available…

I like easier. Let’s do it that way.

To be continued…

CoCoSDC for TRS-80 Color Computer part 4

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

After about a decade in storage, I have finally gotten my Tandy Color Computer 3 set back up. Based on the 2004 copyright of the last item I purchased for it – a Cloud-9 SuperIDE hard drive interface – I guess about ten years ago was the last time I did anything with it. I bought that interface because it has a CompactFlash slot on the side of it, and I liked the idea of using a 128MB memory card as a hard drive rather than big, clunky physical drives. I recall being at a Chicago CoCoFEST! (like the one coming up in April 2015) and leaving the convention site to go buy a CF card, and then spending the evening copying data from my old SCSI SyQuest EZ135 drive disks to it.

I had stopped using the CoCo 3 as my primary computer in 1996, though I still had it set up (and may have even still been running an OS-9 BBS on it) for a year or so more. It’s hard to believe twenty years have passed since the days of 8-bit computers.

Over Christmas break, I set up my CoCo 3, Multi-Pak, floppy drives and SCSI hard drive on a small computer desk in my livingroom next to my TV. There was no room left for a monitor on this modern desk. 80s-style desks usually had an upper shelf for the monitor since old systems took up most of the desk with the computer and external accessories. I guess I forgot how unreadable 80 column text was on a TV via composite video, so I spent another night getting out my 80s computer desk so I could have a spot for my CM-8 monitor. Unfortunately, I had hacked the monitor cable so I could also use it with my MM/1 and it I may have a wire loose – the colors do not work properly (no red, it seems). At least I can read the (off colored) 80 column text now.

I have now spent a bit of time playing with the CoCoSDC. It is significantly faster than a real floppy drive. As a test, I created a new blank disk image as DRIVE 1, and then make DRIVE 0 access my real floppy drive so I could do a backup:

DRIVE 1,"MYDISK",NEW
DRIVE 0,OFF
BACKUP 0 TO 1

I would listen to the physical drive click and clack as it read data for about five seconds, then see the red LED on the CoCoSDC clip for a mere moment as it wrote to the disk image file on the SD card. Wow – fast.

I also did some tests of booting OS-9 from a real floppy versus a virtual floppy. CoCoSDC blazed through the NitrOS-9 boot screen as if it were booting off a hard drive. I believe I read that it’s still not as fast as the fastest hard drive interfaces, but it’s still quite impressive.

I began writing a quick test program in BASIC that would prompt me to type in an disk image name, and then it would create that on DRIVE 1 and prompt me to do the backup. I wanted to automate my floppy archiving so all I had to do was insert floppy, type a disk image name, and press ENTER. I wanted it do do something like this:

10 LINE INPUT "DISK NAME: ";DN$
20 DRIVE 1,DN$,NEW
30 PRINT "PRESS ENTER TO BACKUP 0 TO ";DN$;
40 LINE INPUT A$
50 DRIVE 0,OFF
60 BACKUP 0 TO 1
70 GOTO 10

Note: I wouldn’t actually write it that way — I just simplified it for this example.

I ran the program and it worked for the first backup then the program ended. Where was my GOTO?

I had forgotten that in Disk Extended Color BASIC, the BACKUP command clears out the BASIC program so it can use that memory for the disk copy buffer. Oops! No using the BACKUP command in a BASIC program. (On the CoCo mailing list. Robert Gault mentioned that RGB-DOS and HDB-DOS both patched BASIC so this does not happen. Most of my final years using the CoCo were with these alternate DOSes so perhaps that is why I was surprised.)

To solve this, I will either have to write my own backup routine in assembly that I call from my BASIC program, or see if I can find another way to do this from BASIC. I will show you that in the next installment.

To be continued…

CoCoSDC for TRS-80 Color Computer part 3

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

Today, my project to archive all my old Radio Shack TRS-80 Color Computer floppies continues. I will be using Darren Atkinson’s amazing CoCoSDC interface to copy from physical 5 1/4″ floppy disks to disk image files on an SD memory card, all from a computer that first came out in 1980. If you are just joining me, please read the two earlier parts for an introduction.

My previous article concluded with me describing an easy way to backup standard Color Computer floppy disks. Due to limits of affordable floppy drive hardware at the time, the Color Computer’s Disk BASIC ROM was only written to support a 35-track floppy drive. As technology improved (and prices got lower), Radio Shack would switch from using old full-height, belt-driven 35 track floppy drives to half-height 40-track drives. However, to maintain backwards compatibility, Disk BASIC was never updated to use those extra five tracks, meaning that whether you used the first CoCo disk drive introduced in 1981, or the last one sold in 1991, Disk BASIC still treated it as a 35-track, single-sided device.

Almost as soon as 40-track drives were hooked up to a CoCo, users went to work figuring out how to make use of the extra storage potential. Simple patch programs were released that modified Disk BASIC so it could use all 40 tracks. With this patch, you could still read and write to an original 35-track disk, but if you formatted and wrote to a 40-track disk, only users running the same patch could read it. Because of this, through the entire history of the CoCo, virtually all Disk BASIC software released on floppy disk was in the 35-track format.

I was one of those users, so many of my old CoCo disks are 40 tracks. Since the floppy drive hardware emulated by CoCoSDC emulates the original floppy drive interface, the same patches should work to set CoCoSDC Disk BASIC to 40-track mode and then these floppies can be backed up the same way. (Basically, the patch would change the upper limit from 35 to 40, so formatting with the DSKINI command or using the BACKUP command would now access all 40 tracks instead of just 35.)

Problem: If by default, creating a new .DSK image with the DRIVE command makes a 35-track .DSK file, how can you make a 40-track .DSK file?

According to responses from the CoCo mailing list, the designer Darren says you can download  a blank 40-track .DSK image file and mount and use it. But, he also said that images will automatically expand if you write past the 35-tracks. Thus, if I have loaded my patches that set Disk BASIC to 40-tracks, then I create a new blank 35-track .DSK image and BACKUP to it, once it writes past the 35th track, it should start expanding the file to become a 40-track image file.

I will be testing this, soon.

Bigger problem: Early on, users figured out that some floppy drives actually could actually write past 40 tracks and get a bit more storage. I tested this on the drive I had at the time, and found I could reliably write up to 42-tracks of data. Somewhere in my archive are old, old floppy disks formatted to 42-tracks. Will CoCoSDC work with these?

I will be testing this soon, too. I hope to find a way to do this entirely from the CoCo without having to put the SD card in a PC/Mac and work with it.

More to come…

CoCoSDC for TRS-80 Color Computer part 2

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

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

DRIVE 0, OFF

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:

LOAD "PROGRAM.BAS:2"

…could instead be done as:

DRIVE 2
LOAD "PROGRAM.BAS"

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:

DRIVE 1,"BASIC.DSK

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:

DRIVE 1, "BASIC.DSK",NEW

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:

BACKUP 0 TO 1

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:

DRIVE 1,UNLOAD

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

See also: part 1part 2part 3part 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.