Recently, I shared this way to crash a CoCo 3 in three easy steps:
Turn it on.
Type in “CLEAR 16500:WIDTH 40”
There is no step three.
I expected to do a follow-up once I had time to look at the Super Extended Color BASIC Unraveled book and try to figure out what was causing this crash. I also planned to figure out what value triggered the first crash. I discovered this in a program that did a “CLEAR 17000” and I just went up and down trying to find a threshold where it crashed, and gave up at 16500.
But I am lazy.
And sometimes dense. It didn’t dawn on me that I might have been able to have the computer try to figure out when it crashed. But it did to Juan Castro. In the comments, Juan wrote:
First thing I thought was to increase the value of CLEAR in a loop to see exactly when it crashes… oops, you can’t, you nuked your loop counter with the CLEAR.
No problem, let’s use fixed memory for the counter. &H400, the start of the (now unused) text screen. We’ll start with 16000 (=&H3E80) and increment by one.
It locks up at 16356 — suspiciously close to 16384. Only 28 bytes off. That’s probably close to how much the stack occupies. (Modulo some buffer headers, variable descriptors, and maybe some non-fatal stack corruption.)
– Juan Castro
Brilliant!
And I bet once we dig in (I believe William Astle has done this work in the past) we will find that location is where an 8K MMU block gets mapped in/out for manipulating the high res text screens. Or some other words to that affect that I do not know how to properly articulate.
I have been going through all my OS-9 hard drive images trying to get everything compiled into one place. During this project I ran across a folder called DECB (Disk Extended Color BASIC). It contained the following files:
I had no recollection of what this was, nor why filenames were in lowercase. That was not normally how files were done from Disk BASIC on a CoCo due to the 32-column screen showing lowercase as inverted video.
The “microwar.txt” was an e-mail response to an inquiry I made to Microware in 1993 about the history of OS-9:
INTERNET# Document Id: UX00f.BUX0039573
Item 6352278 93/08/24 06:03
From: STEVES@MICROWARE.COM@INTERNET# Internet Gateway II
To: COCO-SYSOP Allen C. Huffman
Sub: Re: The History of OS-9
From mcrware!microware.com!steves@uunet.UU.NET Tue Aug 24 17:24:36 1993 Received: from relay1.UU.NET by relay2.geis.com with SMTP (1.37.109.4 /15.6) id AA23578; Tue, 24 Aug 93 17:24:36 +0100 Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5T.61/UUNET-internet-primary) id AA11760; Tue, 24 Aug 93 12:24:35 -0400 Received: from mcrware.UUCP by uucp2.uu.net with UUCP/RMAIL (queuweing-rmail) id 122237.10246; Tue, 24 Aug 1993 12:22:37 EDT Received: from yme by microware.com with SMTP id AA00775 (5.67a8/IDA-1.5 for <coco-sysop@genie.geis.com>); Tue, 24 Aug 1993 10:03:08 -0500 From: Steve Simpson <steves@microware.com> Received: by yme id <AA00684@yme>; Tue, 24 Aug 93 10:03:04 CDT Date: Tue, 24 Aug 93 10:03:04 CDT Message-Id: <9308241503.AA00684@yme> To: coco-sysop@genie.geis.com Subject: Re: The History of OS-9
The “Steve” there was Steve “Homer” Simpson, who I would later know when I went to work for Microware two years later. He provide me with a Microware history article, and a Ken Kaplan interview about Microware’s first 15 years. (Note to self: Get this archived somewhere.)
The “TEST.TXT” file was a 300 line text file, obviously created by a program, that was just this:
This is a file of 300 lines or so, and this is line number * 0*... This is a file of 300 lines or so, and this is line number * 1*... This is a file of 300 lines or so, and this is line number * 2*... ...snip... This is a file of 300 lines or so, and this is line number * 298*... This is a file of 300 lines or so, and this is line number * 299*... This is a file of 300 lines or so, and this is line number * 300*...
I was a bit confused at the purpose of these two files. Fortunately, “contents.txt” cleared things up a bit.
Jan '95 #01 Demonstration Issue 1. All About This Program Allen C. Huffman INFO
2. REALLY *BIG* FILE Bob's Big Boy TEST
3. Microware Information Microware Staff MICROWAR
4. Stuff For Sale Various FORSALE
5. Useless File Bob USELESS
6. Nothing Dan NOTHING
7. Something Bob & Dan SOMETHIN
8. Movie Reviews Sis Kehl MOVIES
9. Spam Recipes Mr. Cook SPAMSPAM
F. Another File Another Writer ANOTHER
G. Nothin' Nobody NOTHING
H. Nothin' Again Nobody Again NOTHING
I. More About Flies Spider-Man FLYFILE
J. Jump Text Jumpman Bob JUMPTEXT
K. KeepThisSecret Spy SPYFILE
*. Use Star for This StarMan STAR
Seeing my name in there let me know that this was indeed something I was involved in. But what was it? I needed to move those BAS files over to an emulator and take a look.
Fortunately, one of them was already in ASCII – “reader.asc” – and it was indeed a BASIC program that apparently I wrote back in 1995.
0 REM * 1 REM * Text Viewing Program Thingy V1.00 by Allen C. Huffman 2 REM * Copyright (C) 1995 by Sub-Etha Software 3 REM * Written for Terry Simons and the MI&CC Upgrade Diskletter 4 REM * 5 PALETTE0,0:PALETTE8,63:WIDTH80:CLS1
I had zero recollection of writing this, but I remember the Mid-Iowa & Country CoCo Club (MI&CC) and its organizer, Terry Simons. Sub-Etha Software attended their Middle America Fest held in Des Moines in 1993. Somewhere, I am pretty sure I have photos from this even, but they are not in my online CoCoFest photo gallery for some reason.
I could tell this was something I wrote, since that line 5 of doing the background black, foreground white, width 80, CLS1 line was how I started all my CoCo 3 BASIC programs.
A quick scan of this program, which I will include in full, reveals it would read the “contents.txt” file and display a directory of text files (articles) on the disk and let the user select one. It would then load the file and let them read it, with options to go page to page through the file. A text file reader with a menu system – neat!
0 REM *
1 REM * Text Viewing Program Thingy V1.00 by Allen C. Huffman
2 REM * Copyright (C) 1995 by Sub-Etha Software
3 REM * Written for Terry Simons and the MI&CC Upgrade Diskletter
4 REM *
5 PALETTE0,0:PALETTE8,63:WIDTH80:CLS1
10 CLEAR17000:DIMFL$(15,3),A$(200)
50 REM * Read Index File
55 OPEN"I",#1,"contents.txt":LINEINPUT#1,IS$:LINEINPUT#1,SB$:FL=0
60 FORA=0TO3:LINEINPUT#1,FL$(FL,A):NEXT:IFEOF(1)=0THENFL=FL+1:IFFL<30THEN60
65 CLOSE
100 REM * Table of Contents
105 CLS:LOCATE28,0:PRINT"Mid Iowa & Country CoCo":LOCATE40-LEN(IS$)/2,1:PRINTIS$;:LOCATE0,3:ATTR0,7:PRINT:ATTR0,0:LOCATE0,22:ATTR0,7:PRINT:ATTR0,0
110 GOSUB1155:LOCATE35,2:PRINT"Main Menu";:GOSUB1130:LOCATE23,23:PRINT"Select File to View or [Q] to Quit";
115 FORA=0TOFL:LOCATE40*ABS(A>7)+5,(A AND7)*2+5:PRINTFL$(A,0):LOCATE40*ABS(A>7)+23,(A AND7)*2+6:PRINTFL$(A,1):NEXT
120 GOSUB1055:A=0:IFA$="Q"THEN450
125 IFA$=LEFT$(FL$(A,0),1)THENFL$=FL$(A,2):A$=FL$(A,0)+" by "+FL$(A,1):GOTO205ELSEA=A+1:IFA<16THEN125
130 SOUND100,1:GOTO120
200 REM * View a File (FL$)
205 LOCATE40-LEN(A$)/2,2:PRINTA$;:GOSUB1130:LOCATE2,23:PRINT"[UP] Next Page [DN] Prev Page [J]ump to Page [P]rint File [Q]uit to Menu";:LN=0:
210 GOSUB1105:ONERR GOTO245:OPEN"I",#1,FL$+".TXT":ONERR GOTO
215 LOCATE32,13:ATTR0,0,B:PRINT"Loading File ...":ATTR0,0:MX=0
220 IFEOF(1)=0THENLINEINPUT#1,A$:A$(MX)=LEFT$(A$,65):MX=MX+1:IFMX<200THEN220
225 CLOSE:LOCATE68,2:PRINT"Lines:";MX;:LN=0:LOCATE0,12:PRINT
230 LOCATE0,2:PRINT"Page"INT(LN/18)+1"of"INT(MX/18)+1" ";:FORA=0TO17:LOCATE8,A+4:IFLN+A<MX THENPRINTA$(LN+A)ELSEPRINT
235 NEXT
240 GOSUB1055:A=INSTR(CHR$(94)+CHR$(10)+"JPQ",A$):IFA<1ORA>5THENSOUND100,1:GOTO240 ELSEONA GOTO255,305,355,405,430
245 FORA=12TO14:LOCATE15,A:PRINT"* File Not Found - Press Any Key for Main Menu *":NEXT:GOSUB1055:GOSUB1105:GOTO110
250 REM * [UP] Next Page
255 IFLN+18<MX THENLN=LN+18
260 GOTO230
300 REM * [DN] Prev Page
305 IFLN-18=>0THENLN=LN-18
310 GOTO230
350 REM * [J]ump to Page
355 LOCATE0,11:PRINT:PRINT:PRINT:LOCATE29,12:PRINT"Jump to Page 1 -"INT(MX/18)+1":";:GOSUB1005:A=VAL(A$)-1:IFA<0ORA>INT(MX/18)THENSOUND100,1:GOTO230ELSELN=A*18:GOTO230
360 IFPG>1THENPG=PG-1
365 GOTO230
400 REM * [P]rint Article
405 LOCATE0,11:PRINT:PRINT:PRINT:LOCATE13,12:PRINT"Ready Printer. Press [ENTER] to Print or [Q] to Quit";
410 GOSUB1055:IFA$="Q"THEN230ELSEIFA$=CHR$(13)THEN415ELSESOUND100,1:GOTO410
415 REM --- if printer is not online, beep and go back to 201... <- check here
420 A=0
425 PRINT#-2,TAB(8)A$(A):A=A+1:IFA<MX THEN425ELSE230
430 GOTO110
450 REM * Quit
455 CLOSE:CLS:STOP
460 END
1000 REM * Line Input
1005 LINEINPUTA$:RETURN
1050 REM * Inkey$
1055 A$=INKEY$:IFA$=""THEN1055
1060 CH=ASC(A$):IFCH>95THENA$=CHR$(CH-32)
1065 RETURN
1100 REM * Clear Text Area
1105 FORA=4TO21:LOCATE0,A:PRINT:NEXT:RETURN
1125 REM * Clear Bottom Line
1130 LOCATE0,23:PRINTSTRING$(79,32);:RETURN
1150 REM * Clear Top Line (well, third one actually...)
1155 LOCATE0,2:PRINTSTRING$(79,32);:RETURN
I used the Toolshed (new GitHub home) decb command line tool to create a blank 32-track DSK image, and then then copy the “reader.BAS” file over to it. I also copied the “contents.txt” file, since that was needed.
I booted up the Xroar emulator, mounted my new disk image, and loaded the program. When I ran it, it went to a black screen momentarily, then I saw this:
I assumed the file might be corrupted, so I then tried to CLOAD the ASCII file in Xroar. That is a neat feature that lets you “Load” a text file, then when you type CLOAD it simulates loading an ASCII file form tape, using the input text file as that ASCII file.
Same problem.
I visually inspected the program. Maybe there was some EXEC to an assembly routine that needed to loaded before RUNing this BASIC.
Nothing.
Was Xroar defective? I went to the Xroar Online Emulator and tried it there, loading my DSK image through the web page.
Crash.
I then posted to the CoCo e-mail list sharing a Dropbox link to a folder containing these files, as well as the DSK image. I asked if anyone could test it and see if it crashed for them, as well. Michael Kline was the first to respond:
Alan,
I tested all BASIC programmes on a CC3. They all lock up.
Michael
This at least let me know it was not an Xroar-specific issue. But what was this issue?
I experimented with the TRON command to see how far the program would get before locking up. It would print some quick values [0][1][2][3][4][5] before the screen cleared and things crashed, but this time to a blank green screen. The output to the 32-column screen was changing behavior.
I commented out line 5 so it would stay on the 32 column screen, and ran it again. I saw it spew out line numbers, before clearing the screen and printing an “?HP ERROR IN 105”. That is the error you get when you do CoCo 3 40/80 column screen commands on the 32 column screen. From the looks of things, removing the WIDTH80 line allowed it to get to around line 60 or so before one of those commands was used and it errored out.
Why would WIDTH 80 crash a program? I did more experiments. After this error, with the system not locked up, I typed “5 WIDTH 40” just to add a screen width, but no PALLETEs or CLS command.
According to TRON, the program was crashing at WIDTH 40… Huh???
Each time a crash like this happened, the virtual CoCo had to be restarted (power cycle). Just a virtual reset would not work. You might get “OK” back but things were not working.
Very, very odd.
I finally got my program to run by changing the value of the CLEAR command in line 10. (Initially, I deleted the whole line after the WIDTH line just to see what happened, and narrowed it down to something to do with the CLEAR.)
I shared my results on the CoCo list, and William “Lost Wizard” Astle, one of the great minds at understanding how the BASIC ROMs operate, replied with this tidbit:
It won’t be a string space bug – handling that didn’t change in the Coco3.
Have you been running it from the 40 or 80 column screen? If so, that’s probably why. The driver for handling output to the 40/80 column screen doesn’t properly manage the memory map and if the stack ends up too low in memory, it gets swapped out while the 40/80 column screen is mapped in, leading to a system crash. String space and the address parameter to CLEAR are both above the stack.
This crash happens if the stack ends up below $4000 if memory serves.
If you aren’t running from the 40/80 column screen, it may be some other weirdness triggering it.
– William Astle, via the CoCo List
Light has been shedded, and I knew all I would have to do is look up the Super Color BASIC Unraveled book to find a clear and concise explanation of this bug. But, before I got there, William added more details:
The only solution as far as I can tell is do no output on the 40/80 column screen or clear less string space. Given that a lot of the numbers used for CLEAR for string space are effectively random with no real understanding of how big they need to be, it’s entirely possible that 17000 is way more than it needs to be. Something most programmers don’t know is that a string constant in the program that is never modified doesn’t use up any string space so often the CLEAR number is massively larger than it needs to be.
Having the WIDTH before the CLEAR should prevent WIDTH from crashing but any subsequent PRINT, LOCATE, INPUT (from keyboard), or HSTAT probably would crash.
– William Astle, via the CoCo List
My confusion continued, and finally a third response form him added this:
It’s not that straight forward and unravelled doesn’t mention it. I only know because I tripped on it hard back in “the day” and it left me scratching my head for quite a while.
Basically, the stack has to stay above $4000 (the screen gets mapped in the $2000 to $3FFF range) so that would probably put the absolute limit somewhere just under 16K (16384). You’d want 200 bytes or so room for the stack so 16000 would be a nice round number. On the other hand, if you reserve any memory with the second parameter for CLEAR, that number goes down.
Perversely, if you could get the stack to be *below* $2000, it would also not crash, but that means a very small program with no PMODE graphics, probably.
The size of scalar variables, arrays, or program text doesn’t actually matter for this calculation because the screen is not mapped in except when doing I/O on the screen.
– William Astle, via the CoCo List
A bug the Unraveled folks didn’t know about? William stumbled upon it back then, and if this code was a version I tried to run, I must have, as well. But, why would I have left it in this non-working version? I expect I may find a “fixed” version of this program in my Disk BASIC disk archives, eventually. For all I know, maybe I kept this one around as a “what is wrong with this program” example, copying it to my OS-9 hard drive so I could post it on a BBS or online service (or even to the original CoCo List back then).
Hmm, I wonder if the old Princeton CoCo list archives still exist. Maybe I posted about this 30 years ago (1995!) when I was writing this program? (Note to self: Look that up…)
But I digress.
If you CLEAR a big enough number, then do a WIDTH 40 or 80, the CoCo 3 crashes hard. I toyed with that value, and you can get to a spot where it works, then a bit higher and you get some different types of crashes with the screen freaking out in different ways, but all end up the same way: crashed CoCo, must hard-reset/power cycle to recover.
Have you ever run into this bug on your CoCo 3? Please leave a comment with your story…
Until next time…
One more thing…
Oh yeah… Here is what the program looks like when it runs.
Juan Castro strikes again, this time providing a short program for me to try on a CoCo 3 (I used the Xroar Online emulator) that shows another quirk in the handling of 16-bit values on the CoCo.
The reason this requires a CoCo 3 is because it makes use of the ONERR GOTO command that was added for Super Extended Color BASIC.
“Goes to the line number if an error occurs during program execution.”
There are two special variables that get set when an error is trapped by “ON ERR”.
ERNO
“Returns an error number that corresponds to the error that occurred.”
ERLIN
“Returns the line number where the error occurred.”
So in this simple program, with a mis-spelled “PRINT” command…
10 ON ERR GOTO 50000 20 PRUNT "I TYPE POORLY" 30 END 50000 PRINT "ERROR";ERNO;"IN LINE";ERLIN
When I run that, I see:
ERROR 1 IN LINE 20
1 must be the value of ?SN ERROR. The manual says to look for “BASIC Error Messages” in the back of this book, but the page is titled ERROR CODES. It is on page 321. It lists errors 1 to 39.
But that is not important for this post.
ERLIN, which you see reported the error was in line 20, has a problem.
If the line number with the error has the high bit set (higher than 32767), it gets reported as a negative number! Changing the program to make the PRUNT typo happen on a later line shows this:
10 ON ERR GOTO 50000 32768 PRUNT "I TYPE POORLY" 32769 END 50000 PRINT "ERROR";ERNO;"IN LINE";ERLIN
If I run this version, I see:
ERROR 1 IN LINE-32768
If the error line is moved to 32767, you will it it report properly.
The book Super Extended BASIC Unraveled II mentions this bug on page 33:
“The ERLIN function will return a negative number if the line number in which the error occurred is greater than 32767. This is caused by the fact that the ERLIN function returns the line number as a two-byte integer instead of a floating point number, as it should.”
– Super Extended BASIC Unraveled II, page 33
I did not know there was a 2-byte integer routine in the ROMs. Always learning something new! (Or, re-learning in case I actually did learn this decades ago.)
Thanks, Juan, for getting my dusty brain thinking.
SPECULATIVE UPDATE: Zaxxon ran on the PMODE 4 2-color screen, and used artifact colors. Those did not display on the CoCo 3’s RGB CM-8 monitor. Perhaps this was just a way to make a CM-8 compatible version of the game? Though, changing the title screen and adding the logo (as well as updating the font) does make it appear it was more than just that.
Unreleased CoCo 3 update to the 1983 CoCo Zaxxon???
After the passing of Steve Bjork, his personal possessions ended up in an estate sale. Among them were some fantastic Disney collectables (Steve worked at Disneyland in the 1970s), and a bunch of CoCo stuff.
After the estate sale, much of this ended up at an auction. Roger Taylor spent over $6700 to acquire and preserve a huge bundle of Steve Bjork diskettes and source code printouts. To support him in this endeavor, I am now backing Roger’s Patreon with a $50/month “hardcore supporter” level. If you would like to help out, consider chipping in, even at a $5/month level, to help offset these investments.
Yesterday, Roger shared some photos of the source code printouts that had been kept in a storage box:
There are listings from pre-CoCo TRS-80 Model I/III software, as well as highly recognizable CoCo programs such as Clowns & Balloons, Mega-Bug, Micro Painter, Rampage, Bash as well as something called Marty Goodman Game which was written in 30 days. This would be released as Marty’s Nightmare for the 1990 Atlanta CoCoFest (the first time I ever met Steve in person).
One of the more curious things in the printout collection is a listing for Super Pitfall 2, which does not exist. It seems Super Pitfall was only released for the original Nintendo Entertainment System (NES), the Color Computer 3, and a Japanese machine called a PC-88. The Wikipedia page has this comment:
YouTube does have a few videos of a game called Super Pitfall 2, described as a prototype and unreleased:
If this Atlantis no Nazo game, which was only released in Japan, was going to be converted to be Super Pitfall 2 for the USA audience, was Activision also going to have a CoCo 3 version done? This seems unlikely, but the source code clearly says “Super Pitfall 2” and also has that text on its title screen! It also shows that Steve worked on this game from 11/11/1987 to 4/6/1988.
Super Pitfall 2 source code listing, from the collection of Roger Taylor.
I do have a theory. Mine Rescue was a game very similar to Super Pitfall that Steve released in 1989. I cannot find the game in the Color Computer Archive (most likely since Steve was still active in the CoCo community and protecting his copyright), but the manual is there:
It was very similar to Super Pitfall. (photos from L. Curtis Boyle’s site)
This was much like Steve’s game Bash was very similar to Arkanoid. (photos from L. Curtis Boyle’s site)
Steve had a library of routines he would use in various games. You could see how the scrolling perspective of his port of Zaxxon might have been re-used for one of the levels in his Ghana Bwana game (photos from L. Curtis Boyle’s site):
I am wondering if this “Super Pitfall 2” might have been the code that was later released as Mine Rescue. But, at the moment in time that printout was noted with “4/6/88”, both the source code and the embedded text for the title screen read “Super Pitfall 2”.
I am looking forward to following Roger Taylor’s exploration of this archive of Steve Bjork material. I wonder what other things will be discovered…
Until then, stop by Roger’s Patreon and please consider supporting him at whatever level you can justify.
This article was originally printed in the May 2007 Volume 3 Issue 2 of the CoCoNuts! newsletter. See it, with photos, here. See more photos of this prototype here.
Updates:
2024-03-12 – Corrected resolution of CoCo 3 (incorrectly said 640×480). Thanks, Curtis!
By Allen Huffman
Prologue – In the Beginning
On a warm August day in 1985, a Federal Express delivery truck pulled in to a parking lot in Clive, lowa like it did almost every day. The driver retrieved a nondescript cardboard box from the back of the truck and carried it to the lobby. The box was signed for and left, then the driver returned to his route, unaware of the significance of what he had just been part of. The box, you see, had been sent by Tandy in Ft. Worth, Texas. The recipient was a small computer company called Microware Systems Corporation. The contents of the box were a secret prototype for a new computer which would be appearing the following year in Radio Shack stores nationwide: the Tandy Color Computer 3 (aka, the CoCo 3).
That was two decades ago – a lifetime in the computer world. Few specifics about what went on behind closed doors at Microware or in Tandy Towers are known. What is known, however, is that Microware had previously established a business relationship with Tandy to produce a version of their OS-9 operating system for the original Color Computer. This time, their involvement would go far beyond just doing another port of OS-9 to new hardware. It would involve them working on the onboard firmware to bring the new machine to life. Microware would be expanding Extended Color BASIC to take advantage of the new hardware.
But why Microware? In 1979, Microsoft (yes, that Microsoft) had done the original Color BASIC for the Color Computer so surely they would be the ones to continue doing so. But, by 1985, Microsoft had moved beyond being just a provider of BASIC and those types of projects just weren’t compelling. Some speculate Microsoft would have done it, but it was just cheaper to have another company work on the project. In either case, Microware was likely chosen because they had previous experience working with Tandy and the CoCo on the OS-9 project. Since there were plans to bring out the next generation of OS-9 (Level 2) for the new machine, perhaps the economy of scale (a discount for doing multiple projects) did play a role in this decision. We may never know the full details, but regardless, in 1986 a new CoCo 3 began appearing at Radio Shack stores nationwide, and its new Extended Color BASIC featured enhancements done by Microware.
Although the story of how Microware had to patch and extend Microsoft’s code is an interesting one, this is not that story. Instead, this is the story of the contents of that secret box. This is the story of the CoCo 3 that almost was.
Part 1 – The Discovery
It was January 2005 and the large, three-story custom-built Microware building was finally being vacated by its original owner. Microware had ceased to exist as an independent entity in 2001 after it was acquired by Oregon based RadiSys Corporation. Over the years, the once thriving embedded operating system company had become a much smaller struggling company trying to compete in a market now filled with hundreds of competitors, including offerings from Microsoft and embedded versions of the free Linux. Although the building, completed in 1996, was once fully occupied by Microware staff, it had slowly been rented out as the company reduced in size. At some point, the building was sold and the former owner became a renting tenant. It was on this day that the last remaining Microware folks would be relocating to a much more appropriately sized rented office space a few miles away.
The move was somewhat emotional for those who had been with the company since the 1980s. Efforts were made to preserve any OS-9 related artifacts that might still prove useful, such as motherboards for any versions of OS-9 that were still supported. VME cards were salvaged and server racks were saved, but endless other pieces of ancient hardware were to be recycled. Large trash units had been brought in to the parking lot. Old PCs, SUN workstations, endless cables and old parts were being thrown in to them. A mountain of monitors was stacked high in the lobby, waiting to be picked up by the recycler. Decades of history had been rendered useless by the advances of technology.
One of the final areas to be cleared out was a small storage room in the basement known as “the morgue.” Inside the morgue were some of the more interesting artifacts of Microware’s past. Shelving units full of Compact Disc Interactive (CD-i) development systems stood across from piles of old software disks and tapes. Endless VME I/O cards, motherboards and reference hardware sat under layers of dust next to boxes of blank EPROMS and serial cables. It was a place that, in the 1980s, would have been a hardware hacker’s wet dream, but today it was just a room of ancient technology with no modern value or use to anyone.
Just like Noah and the Ark, two of each potentially useful item was to be saved. Anything that was no longer supported (or functioning) was to be sent to the great recycling center in the sky. Some historic items were allowed to be taken home, including an infamous Japanese video game system that ran OS-9 and featured mechanized 5 1/4″ floppy drives and a fancy joystick. There were a few other pieces of unusual OS-9 hardware that escaped a crushing fate.
For instance, the CD-i machines also had some historic significance. Many were development systems used to create the tools Phillips and other companies used for making CD-i content. Others had been part of a shopping kiosk business known as Micromall, co owned by Microware in the 1990s. These CD-i machines were saved then sold off at the 2006 Chicago CoCoFest, hopefully helping them end up somewhere better than the recycle bin.
During all of this purging, a nondescript brown cardboard box was discovered. One of the remaining long time employees knew of its contents and made sure to set it aside. This box was the same box that Federal Express had delivered twenty years earlier. This box contained not one, but two Color Computer 3 prototypes and a few other surprises. The contents of this box have since helped us learn a bit more about what Tandy had intended the CoCo 3 be.
Part 2 – From Prototype to Pre-Production
Before the discovery of the actual Color Computer 3 prototypes, the CoCo community had already seen what was being called “prototype CoCo 3s.” A few years earlier, some pre-production CoCos were displayed at a CoCoFest convention. The CoCo Communityis official monk, Brother Jeremy, had acquired them somehow. They were the ones used by Microware for developing OS-9 and, we assumed, the Extended Color BASIC extensions. Externally they looked like the CoCo 3s we are all familiar with, but the motherboards inside were different. The GIME chips were earlier prototype versions, different from the ones found in later production units. Little else is known about these machines, but news of their existence spread through the community.
After hearing that “prototype” CoCo 3s had been shown publicly, one of the original Microware CoCo 3 developers made a comment that those couldn’t possibly be the real prototypes because the real ones were still in storage at Microware. This was the first clue that there was something else still to be discovered. Something few had seen, and something hidden away somewhere in a box stored down in a basement.
When the box was opened, it was clear no one had seen or touched its contents for many years, and quite possibly not since 1986. The insides were dusty. The labels were faded and cracked. A small supply of bubble wrap was all that protected the contents. Inside were two large green circuit boards and three smaller ones.
The large boards were covered in chips and wires. The only thing that gave any clue that this was connected to the Color Computer was a series of familiar connectors on the back edge. The standard CoCo joystick, serial and cassette ports were there along with a cartridge connector. Elsewhere on the board could be found a keyboard connector, and further inspection of the chips revealed a few recognizable ones, like a 6809 processor. The amount of chips (on a board four or more times the size of a production CoCo motherboard) was staggering. The back side of the board was covered in dozens and dozens of long green jumper wires.
Two smaller CoCo cartridge boards were also found as well as an unidentified third board that didn’t seem to plug in to anything. The cartridges matched one that had shown up a few years earlier at a CoCoFest that was thought to be some kind of Ethernet networking pak. The third mystery board carried a Copyright 1984 Tandy notice on it, indicating it was probably too early to be anything CoCo 3 specific. It was this set of five boards that was shown at the 2006 Chicago CoCoFest, and this was when the next round of discoveries were made.
CoCo networking cards, and mystery board.
Part 3 – Blue Sky CoCo
“Everything, even the CoCo, starts with a dream.”
When Disney’s Imagineers start designing a new ride or attraction for one of the theme parks, they initially start with what they call the “blue sky” phase. That is, “the sky is the limit.” Anything is possible, even if impossible. These initial concepts and ideas may be far grander than what is technically possibly, or perhaps possible but economically unfeasible. As the project continues, the budget (and often the realities of technology) whittles down the blue sky plans to something much more humble which hopefully will get approved and built. Disney fans know far too well how grand plans originally become much smaller realities, such as how Walt Disney World’s Epcot “Space Pavilion” went from a full experience with a space shuttle launch to a space station, to just a simulator ride that didn’t pretend to be anything grander.
This same approach is common in many areas of design, and likely played a role in the evolution of the Color Computer series. For instance, it is documented that a Deluxe Color Computer was planned but never released. Evidence of this includes references to a deluxe model in the Color Computer 2 manuals. Little is known about the features of this version other than a documented ability to enter BASIC commands in lowercase. Such capabilities never made it in to any official version of Radio Shack CoCo BASIC, but later models did include support for a lowercase display. There were also references to extra keyboard keys. Coincidentally, Radio Shack stores sold some keyboards as spare parts during this time. Theses keyboards had a few extra keys and could be plugged directly in to an existing CoCo. It is believed that these keyboards were designed for the never-produced Deluxe CoCo. Perhaps some day a prototype of this machine will surface.
It is possible that the CoCo 3 grew out of blue sky plans for the Deluxe CoCo, actually allowing more ambitious plans to be made than just minor improvements. All that known for sure today is that the Deluxe CoCo plans got far enough for keyboards to be manufactured and for manuals to be revised and printed.
To understand what was happening, it is helpful to look at what had already happened. Tandy has already evolved the original grey case CoCo several times. There were a few revisions to the original motherboard with the final versions supporting 64K without hardware hacks. A small run of white cased CoCo 1s was also produced which included an updated keyboard. Next was the CoCo 2 in a smaller white case with a similar keyboard, though they were soon revised to have an improved keyboard which would continue to be used on all later models. There were numerous revisions to the CoCo 2 models, though the only significant feature was the addition of true lowercase for the “Tandy” branded units. (None of the models labeled as TRS-80s had this enhanced video chip.) There was also another minor revision that caused the need for Color BASIC 1.3, but the end result was a machine that was effectively no different than the original 1980 model other than in appearance.
To truly make a successor, Tandy needed something bolder than just a new keyboard and case. Game developers wanted to see enhanced graphics. Similar peer systems, such as the Commodore 64, had more colors and hardware sprite capabilities which allowed more advanced games to be created easier. Some of these capabilities were already available as expansion pak add-ons for the CoCo, but developers couldn’t target those enhancements since the base CoCo did not have them. In order to be useful, the hardware would have to be integrated.
Looking at the lineup of add-on hardware paks sold by Radio Shack, certainly building in enhanced audio (like the Speech/Sound Pak) would be useful. The RS-232 pak would also have made a nice addition, effectively giving all those “power user” features to the base model. A “really deluxe” CoCo with better graphics would also need to support something other than an old-style television set. Other obvious enhancements would | include more memory and speed.
Ultimately, the CoCo 3 that was released in 1996 only contained a handful of these blue sky items. Compromises had to be made to keep costs down. One of the original Tandy CoCo 3 developers, Steve Bjork, has stated that there was a requirement for the CoCo 3 to be produced ata lower cost than the CoCo 2 it was replacing. This ambitious economic goal certainly limited all the developer’s requests for enhanced hardware.
When released, the production model CoCo 3 did contain better graphics (up to 640×225 with four colors, or 320×225 with 16 out of 64 colors). More memory was added, with the base model of 128K expandable to 512K. RGB-analog monitor output was added, as well as audio/video outputs for hooking to VCRs or composite monitors. The CoCo 3 could also run at double speed even in RAM mode, allowing a boost in performance for more than just BASIC ROM calls. (The CoCo 1 and 2 had a “double speed” poke which sped up ROM access, but the so-called “triple speed” poke that sped up RAM access garbled the video display. The CoCo 3 allowed the “triple speed” poke to work for both RAM and ROM code without losing the display.)
Other additions were compromises. In lieu of real sound hardware, developers such a Steve Bjork lobbied for and received an enhanced IRQ timer. This didn’t compete with the music chip in the Commodore 64s, but it did allow enhanced background sound effects using the existing CoCo sound capabilities. There was another IRQ that would have dramatically helped with RS-232 performance over the printer/ serial “bit banger” port. It is believed this was meant to substitute for a hardware RS-232 interface, but it was miswired so that potential was never realized. The list of other enhancements that would have been nice but didn’t make it is something discussed to this day, usually under the guise of what would have been ina CoCo 4.
Overall, the CoCo 3 was a significant leap forward for the series. It contained better graphics, more memory, faster usable speed and even added the extra keys that would have been part of the Deluxe CoCo (but still no BASIC enhancements to allow entering commands in lowercase). The new monitor outputs and new color CM-8 monitor allowed using an 80 column screen, finally breaking away from the 1980-vintage 32-column display. It was a significant upgrade and one that developers took too quickly. The new generation of programs, from enhanced games with full color and background sound to the power of OS-9 Level 2, made the new model a more revolutionary a leap than from CoCo 1 to CoCo 2.
This brings us back to that box and the prototype within. By the time hardware is created, even if it’s just a massive circuit board stuffed with chips and wiring, most blue sky goals have been eliminated. The goal of the initial prototype is to begin working on what will hopefully be produced later. Projects certainly continue to evolve, often based on feedback from working with the prototypes, but examining early designs can shed light on the intent of the designers at that moment in time.
As mentioned earlier, the CoCo 3 prototype contained the common ports found on all CoCos up to that point – cassette, joystick, printer, TV RF out, and cartridge. New RCA jacks were added for composite audio/ video output, and a DB9 appeared for the new RGB-analog monitor. While the RCA jacks would make it to the production CoCo 3s, the DB9 connector did not. Instead, an odd square 10-pin header connector was added to the bottom of the machine. This was likely a cost reduction move since placing the connector there on the motherboard probably saved some layout money, and using a surfacemount header was cheaper than adding a DB9 port. Still, it does indicate that Tandy may have intended to use some kind of monitor that had a DB9 connector like other monitors of the day.
On a side note, the production CoCo 3 still contains one mystery related to the monitor port. Under the machine where the monitor plugs in is a square indention that could have fit some kind of small box. Perhaps there was an idea of converting the main RGB-A output to some other format via a converter box (maybe simplifying monitors between US and other parts of the world). Perhaps there was some other intended us that we may never learn about. Perhaps the CoCo 3 prototype will eventually give us a clue. (A more pressing mystery is why CoCo 3 software always asks Composite/TV or RGB? on startup, even though there was a way to detect if a CM-8 was plugged in.)
Something else learned by inspecting the prototype is that Tandy may have had much higher goals for their base model machine. The prototype has no place for RAM expansion. Instead, it is populated with 512K. This would have driven up cost and would have caused real problems during the RAM price crisis of the late 1980s when memory upgrades shot up by hundreds of dollars due to a fire at an overseas production facility. Looking back, releasing a cheaper 128K unit that could be upgraded later was probably a smart move though it ultimately led to few official Radio Shack products taking advantage of systems with that much memory.
Another interesting discovery was noticing a 1773 chip on the prototype. This chip was part of the CoCo floppy drive controller pak. The prototype had the floppy drive circuitry built in and contained a ribbon cable connector for the disk drive. Tandy must have wanted to integrate disk support in the base model, and perhaps had goals of shipping a floppy drive with the system or allowing the CoCo 3 to just plug in an external drive without needing the drive controller. Tandy actually did this very thing with their Tandy 1000 EX and HX PC compatibles. While those systems contained a built-in floppy drive (5 1/4″ and 3.5″ respectively), there was also a port that allowed plugging up an external drive. More on this later.
Probably the most curious observation was that the prototype did not even have a GIME chip. The GIME was a custom IC created to handle things like graphics and memory. In the early prototype stages, before such an expensive chip could be made, designers created the functionality of the GIME using programmable PAL chips and other support hardware. It is unknown how much GIME support is on the prototype, but since Microware used it to create the Extended Color BASIC enhancements (which included the new graphics modes), and since the prototype had 512K, is believed to have implemented the graphics and memory controller that the GIME later would handle.
There could be other secrets in this prototype. Early developers, under Non Disclosure Agreements with Tandy, received pre-production CoCo 3s with pre-production GIME chips. There were two known revisions to the production GIME (86 and 87 revision), and the early development units are believed to have been just earlier (and buggier) versions of what was released. But, documents given to Microware during this project indicated that one of the specifications for the CoCo 3 was a 256-color mode. Steve Bjork has stated that this mode never existed in any manufactured CoCo 3s,
and notes that the graphics hardware itself did not have enough bits available to represent a 256-color map. However, this early prototype may have had the basis for such a mode before it was deemed either too costly or, perhaps, too likely to compete with the Tandy 1000 graphics. The mystery of the specified 256-color mode may finally be unlocked in these early designs.
In a side note, the whole suspicion of a 256-color mode started when a former Tandy Color Computer product manager made reference to it years later. “Has anyone found the 256 color mode?” he asked. No one had, but noted Color Computer programmers John Kowalski
(“SockMaster”) and Australia’s Nick Marentes were able to find abnormalities in the CoCo 3 schematics published by Radio Shack in the Color Computer 3 Technical Service Manual. As Steve Bjork has mentioned, there were not enough address lines for doing an 8-bit color, but the schematics showed some evidence of alterations in that area. There where two extra lines being routed away from the normal path. Perhaps there were plans to achieve the 256-color mode by some way that would allow accessing those extra lines? Nick was able to track down the original designer of the GIME, but he had no recollection of any such mode. It seems likely that this mode, if it ever existed, may not have even made it to the GIME stages.
So the prototype, while not quite a “blue sky” machine with enhanced sound and true RS-232 serial hardware, did certainly represent a somewhat nicer machine than what was actually released. Imagine a CoCo 3 with 512K standard, normal DB9 monitor port on the back, anda place to plug the disk drive ribbon cable in and still have the cartridge port available. This would have removed need for the MultiPak for the large number of CoCoists who used floppy and RS-232, or perhaps floppy and the Speech/Sound Pak.
When the prototypes are fully inspected and, hopefully, reverse engineered, there may be more mysteries discovered. Though the prototypes were supposedly working when they were packed away 20 years ago, until someone qualified has time to inspect them, no attempts are going to be made to power them up.
2024-03-03 – Added “MexiCoCo” name. Also note about ROM.
Be sure to follow Roger Taylor. He acquired one of the MicroSEP computers from Mexico (aka,. MexiCoCo), which is a rebadged CoCo 3 with some BASIC ROM changes.
Of interest — the ROM is socketed in this machine! Earlier, Roger had shown photos of a GIME chip “Made in Mexico.” Maybe that was connected to this product?
2024-03-09 – Added Dropbox link for direct download, any more background details. I have let Roger know I am now ready to download the 1987 version files and get those available.
Last year, Roger Taylor went through the effort and expense to have the Tandy/Radio Shack Color Computer 3’s custom “GIME” chip decapped and scanned. Super high resolution images are available. This should give someone with the knowledge and skills the ability to reproduce these custom chips.
Read more about this, and other fascinating projects, on Roger’s Patreon page. Consider supporting him. He has made some interesting acquisitions lately, including a “did we know this existed?” Mexico CoCo 3 called a MicroSEP II. He has also spend thousands of dollars to acquire the source code archives of the late Steve Bjork.
Use this “1986 GIME.torrent” file to download with a BitTorrent client and help seed it for others to get a backup of these files. I also have the files in a Dropbox share for those really patient with downloading 140+ GB of image files.
YouTube has been showing me videos from a channel called CoCo Town lately. This one, posted recently, focuses on emulators not getting the CoCo screen’s aspect ratio correct:
CoCo Town YouTube video.
I noticed that the recent XRoar emulator also changed its aspect ratio. It just felt “wrong” to me since I have basically only used XRoar for the past few years. Also, my CoCo 3 has been using a VGA monitor via the Cloud-9 FPGA VGA adapter. I have no idea how accurately it represents the CoCo output, but I know it is recreating it and making it fit on the VGA monitor.
With that in mind, I have a favor to ask. Can someone out there with a CoCo 1 or 2 hooked to a TV set send me a photo of what it looks like on your TV set? A front view of the startup green screen would be ideal.
Likewise, I’d like to see what the CoCo 3 looks like on an analog RGB monitor like the CM-8. I recall the CoCo 3 was very off center using the TV output, but if you can get a picture of that too, I’d appreciate it.
NOTE: This information requires XRoar 1.3.1 or later, as earlier versions had an issue remapping the Control key on Mac.
The XRoar emulator added support for the CoCo 3, but by default, the new CoCo 3 keys (alt, ctrl, f1 and f2) do not work for me — at least on the Mac. The author, Ciaran, pointed me to the “kbd-bind” configuration option. This allows remapping a host computer key and passing it through to the emulated machine. In my case, I want to do the following:
F1 key – F1 key on CoCo 3
F2 key – F2 key on CoCo 3
Left Control – CTRL key on CoCo 3
Left Option – ALT key on CoCo 3
The XRoar manual has the following information about kdb-bind:
When binding keys with -kbd-bind, if the emulated key dkey is prefixed with ‘preempt:’ or ‘pre:’, this binding preempts translation; useful for modifier keys. Interpretation of hkey depends on which user-interface toolkit is in use, and it might be useful to run with -debug-ui 1 to see what the toolkit calls your host keys.
The “hkey” is the name of the key you are trying to remap, and I think it may be different between Mac and PC. By running xroar from the command line with the “-debug-ui 1” option, the terminal will print out keys as you type inside the emulator. I did this, and press the keys I wanted to remap.
Above, I can see that the “hkey” for pressing my Mac’s left control is “Left Ctrl“. My left option key is “Left Option” (spelled out, and not abbreviated like Ctrl was). F1 and F2 were simply “F1” and “F2“.
I went with Control and Option on the left side, since I have duplicates of those keys on the right side of my keyboard. I can remap just the left ones for CoCo 3 use, and still have the right ones for XRoar interface use.
NOTE: You could remap any key — like make F5 turn in to the CoCo 3’s F1, or whatever.
To remap those keys, I can pass the option in from the command line like this:
If I run XRoar using the command line, or with those entries in the xroar.conf file, I can now boot in to the CoCo 3, and hold down my Left Control+Left Option then go to Hardware->Soft Reset and get the hidden CoCo 3 easter egg photo:
Though, the border color does not match that of a real CoCo 3, I don’t think.
I hope this helps someone else trying to use the XRoar in CoCo 3 mode with those four special CoCo 3 keys.