Monthly Archives: December 2014

Word wrapping in Extended Color BASIC

2015/1/2 Update: Please see my follow-up article for two improved versions of this.

Last night, I began writing a program on my 1980s Radio Shack Color Computer. I am planning on going through hundreds of old floppy diskettes and copying them to disk image files.  The program I began writing will help automate this task.

I am using a new bit of retro hardware called the CoCoSDC. It acts like a floppy drive controller, but instead of writing to round pieces of magnetic plastic, it writes that data out to disk image files on an SD card. You can learn more about CoCoSDC in another series of articles I have been writing.

CoCoSDC is a brilliant piece of design work in that it detects and adjusts for the various models of Color Computers (1, 2 or 3) it is plugged in to. I decided my program should do the same, so my goal is to have one BASIC program that could be loaded on an original 1980 Color Computer 1 or 2, using its 32 column display, or run on a 1986 Color Computer 3, using the 40 or 80 column text screen. There are a few challenges I needed to solve:

  • The program should work on an original Radio Shack TRS-80 Color Computers or early model TRS-80 CoCo 2s, which had a 32 column display with uppercase character set. (On the Motorola 6847 VDG chip used by this machine, lowercase letters were represented by inverse uppercase characters.)
  • The program should take advantage of the later model Tandy Color Computer 2s that had an enhanced VDG chip that could display true lowercase. This option should still be available for earlier model CoCos which may have an aftermarket lowercase kit (like my old grey CoCo 1 has).
  • The program should work on a Tandy Color Computer 3, and let the user select between 32, 40 or 80 column display. This would allow it to worked hooked up to a crappy old TV display, or have nice 80 column text for users that had a good monochrome composite monitor or RGB-A color monitor.

I quickly designed and wrote a functional prototype, missing only a few features I had in mind. I started out by hard coding it to use a variable for the screen width so I could center text and and such. For example:

WD = 32
A$ = "CENTER THIS!"
PRINT TAB(WD/2-LEN(A$)/2);A$

By making that PRINT line a subroutine, I could call it anywhere I wanted to print centered text:

10 WD = 32 'SET SCREEN WIDTH
20 CLS 'CLEAR SCREEN
30 A$="IT WORKS!":GOSUB 1000
40 END
1000 REM PRINT CENTERED A$
1010 PRINT TAB(WD/2-LEN(A$)/2);A$
1020 RETURN
CoCo centered text.
XRoar emulator acting as a Radio Shack Color Computer 1.

I also made a routine to display a horizontal row of dashes so I could use that with nicely formatted menus.

Eventually, I needed to display some verbose text to the user, and knew I would need to make a routine to handle wrapping long lines. It’s easy to hard code PRINT statements when you know your screen width, but when it can vary, we can have the program do it for us.

Earlier in 2014 I implemented such a word wrap routine in C for a Raspberry Pi program I was designing. Unfortunately, porting that code to BASIC wouldn’t be possible since it took advantage of too many C features that have no BASIC equivalents. Instead, I had to design a new one.

Also, I wanted the option to pass in strings with upper and lower case and have them converted to uppercase. The only design restriction I enforced was to try not to do any string rebuilding. Interpreted BASICs have their own type of garbage collection (like you might find in Java and other modern languages) that do all kinds of memory shifting when you add two strings together. My program could be faster if it avoided that. (Not that it really matters, but good habits learned later in my programming career are difficult to break even when I am pretending it’s 1983.)

Here is the first version I came up with:

2015/1/5 Update: Please see my next article for two improved versions of this.

10 CLS 15 INPUT"SCREEN WIDTH [32]";WD:IF WD=0 THEN WD=32
20 INPUT"UPPERCASE ([0]=NO, 1=YES)";UC
25 TM=TIMER
30 A$="This is a string we want to word wrap. I wonder if I can make something that will wrap like I think it should?":GOSUB 1000
35 PRINT"TIME TAKEN:"TIMER-TM
999 END
1000 REM WORD WRAP
1001 '
1002 'IN : A$=MESSAGE
1003 '     UC=1 UPPERCASE
1004 '     WD=SCREEN WIDTH
1005 'OUT: LN=LINES PRINTED
1006 'MOD: ST, EN
1007 '
1010 IF A$="" THEN PRINT:LN=1:RETURN
1015 IF UC>0 THEN FOR ST=1 TO LEN(A$):EN=ASC(MID$(A$,ST,1)):IF EN<96 THEN NEXT ST ELSE MID$(A$,ST,1)=CHR$(EN-32):NEXT ST
1020 LN=0:ST=1
1025 EN=LEN(A$)
1030 IF MID$(A$,ST,1)=" " AND ST<EN THEN ST=ST+1:GOTO 1030
1035 IF EN-ST>WD THEN FOR EN=ST+WD TO ST STEP-1:IF MID$(A$,EN,1)<>" " THEN NEXT EN ELSE EN=EN-1
1040 IF EN=ST THEN EN=ST+WD-1
1045 PRINT MID$(A$,ST,EN-ST+1);
1050 LN=LN+1
1055 IF EN-ST+1<WD THEN PRINT
1060 ST=EN+1:IF ST<LEN(A$) THEN 1025
1065 RETURN

Note: This is not my normal production programming style. I created this example for better readability, but in the future I will share some of the tricks we used at Sub-Etha to optimize BASIC programs to take up less memory and run faster. (They won’t be very readable…)

Word wrap, lowercase.
Word wrap, lowercase.
Word wrap, uppercase.
Word wrap, uppercase.

The subroutine at line 1000 expects the string to be in A$, the width of the display in WD, and the variable UC can be set to 1 to force the output to be in uppercase (which is slower). When it returns, LN will contain how many lines were printed. I also print out the TIMER so I can compare the speed of the routine, and see how much slower it is with uppercase conversion.

On the right are screen shots of the wrapped output with and without uppercase conversion. You can see that converting a few lines of text the way I did it took about five times longer.

There is one extra feature I should mention. One of the things that bothers me about many word-wrap routines I have seen is that they tend to ignore the final character of a line meaning that if you print a line that is exactly 40 characters long to a 40 column display, they usually wrap the last word even though it would have fit on the line. This is because, at least on all the systems I have experience with, when you print to the final character, the cursor moves to the start of the next line, then the PRINT command finishes and adds a carriage return. Here is an example of printing three 32 column lines on the CoCo:

10 CLS
20 PRINT"12345678901234567890123456789012"
30 PRINT"12345678901234567890123456789012"
40 PRINT"12345678901234567890123456789012"

You get something like this:

Printing without semicolon.
Printing without semicolon.

BASIC does not know that a line was skipped before it adds its own carriage return. You can prevent BASIC from adding a carriage return by adding a semicolon to the end of the PRINT line:

10 CLS
20 PRINT"12345678901234567890123456789012";
30 PRINT"12345678901234567890123456789012";
40 PRINT"12345678901234567890123456789012";
Printing with semicolon.
Printing with semicolon.

Most word wrap routines I have seen just don’t bother dealing with this, and never use the final character of the line. For my routine, I wanted a line that was exactly the length of the screen width to fit, so I always add the semicolon, then in line 1055 I print a carriage return if the line was shorter than the screen width (and thus BASIC didn’t already move the cursor to the next line).

Little things like this make the code bulkier than it needs to be.

Now I turn things over to you… This can be done much better. How would you implement a word wrap? And note there are several goals that would require different code:

  • Code size may be most important.
  • Execution speed may be most important.
  • You might want to use as few variables as possible.
  • You might want to avoid string manipulation.
  • You might not be able to alter any variables passed in (thus, if the user passes you A$, you are not allowed to change A$).

For me, I wanted to avoid string manipulation (for speed) and use fewer variables. Without that goal, I could have done the word wrap routine easier by making a copy of the string the user passed in and manipulating the copy. This is why my uppercase conversion makes changes to the string the user passed in. If I had the goal of not modifying what the user passed in, I would have had no choice other than making a copy in another string variable.

The choice is yours. Send in your best attempt and explain your goal. Here are the requirements:

  • A$ will be set to the string the user wishes to display.
  • WD will be set to the screen width.
  • UC will be 0 if the string is to be displayed as-is, or not 0 to convert to uppercase.
  • On return, LN will be the count of how many lines were displayed.

If you need a quick and easy emulator to run it in, check out XRoar. I have tips on how to get it running over at CoCopedia:

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

Have fun!

P.S. This example requires Extended Color BASIC. As it turns out, while the 1980 Color BASIC supports MID$(), you cannot use it to modify a string. Thus, A$=MID$(B$,1,1) would work, but MID$(B$,1,1)=”N” would not. My first CoCo had Extended Color BASIC so I never had to live without the extra features.

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.

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

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!

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

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.