When Radio Shack released their third and final version of the Color Computer, the Tandy Color Computer 3, it included a custom ASIC chip. This chip, called the GIME (Graphics Interrupt Memory Enhancement), replicated most features of the Motorola 6847 video display generator chip used in earlier models. It also added new features such as higher resolution graphics with more colors, and a memory management unit. This allowed the CoCo 3 to be backwards compatible while allowing up to 640×225 resolution graphics and the ability to access up to 512K or RAM.
The GIME could only display 16 colors (from a palette of 64) on a screen at a time, but clever programmers quickly figured out how to make the hardware display all 64 simultaneously. Radio Shack apparently even knew this trick, and offered a diagnostics program that did it as well.
Even cleverer programs started doing things like this:
While the demo scene on the CoCo was quite small, it did exist.
256 colors, too?
During the production days of the CoCo 3, a few commercial programs were sold that claimed to offer 256 colors. These colors were only viewable on a composite NTSC monitor, so those using an RGB CM-8 (or similar) monitor or using PAL versions of the CoCo 3 could not participate.
In 2010, CoCo programmer John Linville even created a full motion video player that made use of this 256 color mode:
But … was there more?
The Quest for the “other” 256 Color Mode
There were a number of features planned for the CoCo 3 that never made it in to production. The earliest PCB prototypes had a floppy disk controller built in. They also used a more standard DB9 port for the monitor rather than the odd header connector on the bottom side of production CoCo 3s.
The new hardware capabilities were implemented through an array of logic chips. These chips would later be consolidated in to the custom GIME chip for production.
Indeed, an early specification document provided to Microware Systems Corp specifically mentioned a 256 color mode. (Microware was the company chosen by Radio Shack to do the extensions to Microsoft Extended BASIC to support the new hardware.)
To read a great overview of the efforts to discover if this 256 color mode ever existed check out Nick Marantes’ website:
Although the GIME was well understood thanks to excellent documentation, no one truly knows how it works. Programmers of various emulators and FPGA projects have had to create their own cleanroom implementation of the GIME by using only the technical references and any behaviors figured out by programmers.
CoCo 3 demos such as those included above would often not initially work on these reverse engineered GIME implementations. Developers would simply find programs that did not work, and figure out how to tweak their virtual GIME until it behaved like real hardware. This means that, to this day, many GIME-bashing demos look different depending on which emulation/recreation you run them on.
Roger Taylor wants to solve this problem. He just launched Project 256 on his Patreon page:
His goal is to sacrifice a few GIME chips (including the original buggy 1986 version and the later “fixed” 1987 version) and have them reverse engineered. This process of decapping has already been used on the CoCo’s original video chip to confirm what the embedded font characters were. It is hoped that the end result to his project will be enough knowledge to do a full clone of the GIME via FPGA. (Note that the GIME-X project has already done a cleanroom FPGA plug-in version of the GIME, adding extra features, but so far no one has done a 100% recreation due to lack of information that would make that even possible.)
Follow Roger’s progress on his Patreon and, if so inclined, consider becoming a sponsor of his efforts.
Maybe one day we will truly know how the GIME works.
This allowed having a screen that was either “nuclear green” or “whatever color the other is”.
Then, I learned that the 6847T1 variant of the Video Display Generator (VDG) chip that was used in later model Tandy CoCo 2s had some different colors of its own and had to write a second installment of the article.
I also learned that the border color did not have to be black on these 32×16 text screens, at least not on the T1 VDG.
The XRoar emulator handles these differences, so if you don’t have a T1-enabled “Tandy” CoCo 2 around (the ones labeled TRS-80 do not have this chip), you can experiment with me via the online XRoar emulator.
There is a control register mapped in to memory at &HFF22 (65314), and by POKEing values at that location, you can set or clear the various T1 VDG bits. The bits I was interested in were bits 3-6:
BIT 3) ALTERNATE COLOR
BIT 4) LOWERCASE
BIT 5) REVERSE
BIT 6) BORDER=BG
In BASIC, you can easily set a bit by getting the current value (using PEEK) and POKEing back that value OR’d with the bit you want to set. For instance, if I want to enable lowercase, bit 4 (value of 16 or &H10 in hex), I do this:
POKE &HFF22,PEEK(&HFF22) OR &H10
Instead of translating bit values to HEX, you can also use the “power of two” operator to create that value. Two to the power of X will be the bit value. For example:
0 REM BIT VALUES
10 FOR BT=0 TO 7
20 PRINT BT,2^BT
Running that will produce two columns of numbers. The first column is the bit (0 to 7). The second column is the value (power of two): 1, 2, 4, 8, 16, 32, 64 and 128. If you run this in Color BASIC, you will see it actual shows 32.0000001 and 64.0000001 for those two values due to how floating point works, but they will still work fine for this example.
Thus, my above example could have been done like this:
POKE &HFF22,PEEK(&HFF22) OR 2^4
That is setting bit 4 (2^4) to turn on lower case.
If I wanted to set bit 3 (2^3) for the alternate color set, it would be:
POKE &HFF22,PEEK(&HFF22) OR 2^3
This is just an easier way to visualize which bit it is (2^BIT) versus knowing what &H80 or &H04 represents.
But I digress…
I created a simple set of routines that work go through all the various combinations of those bits to show normal, reverse and alternate color screens, with and without borders (where supported) and with or without lowercase enabled. The simple program looks like this:
0 REM 6847T1 VDG &HFF22
0 ' BIT 0) 01
1 ' BIT 1) 02
2 ' BIT 2) 04
3 ' BIT 3) 08 BG COLOR
4 ' BIT 4) 10 LOWERCASE
5 ' BIT 5) 20 REVERSE
6 ' BIT 6) 40 BORDER=BG
7 ' BIT 7) 80
10 CLS:PRINT "6847T1 VDG Demo"
100 ' NORMAL
110 PRINT "Normal"
130 GOSUB 1000
140 PRINT "Normal + Border"
150 POKE L,PEEK(L) OR 2^6
160 GOSUB 1000
170 PRINT "Normal + Border + LC"
180 POKE L,PEEK(L) OR 2^6 OR 2^4
190 GOSUB 1000
200 ' REVERSE NORMAL
210 PRINT "Reverse Normal"
220 POKE L,PEEK(L) OR 2^5
230 GOSUB 1000
240 PRINT "Reverse Normal + Border"
250 POKE L,PEEK(L) OR 2^5 OR 2^6
260 GOSUB 1000
270 PRINT "Reverse Normal + Border + LC"
280 POKE L,PEEK(L) OR 2^5 OR 2^6 OR 2^4
290 GOSUB 1000
300 ' ALT COLOR
310 PRINT "Alt Color"
320 POKE L,PEEK(L) OR 2^3
330 GOSUB 1000
340 PRINT "Alt Color + Border"
350 POKE L,PEEK(L) OR 2^3 OR 2^6
360 GOSUB 1000
370 PRINT "Alt Color + Border + LC"
380 POKE L,PEEK(L) OR 2^3 OR 2^6 OR 2^4
390 GOSUB 1000
400 ' REVERSE ALT COLOR
410 PRINT "Reverse Alt Color"
420 POKE L,PEEK(L) OR 2^5 OR 2^3
430 GOSUB 1000
440 PRINT "Reverse Alt Color + Border"
450 POKE L,PEEK(L) OR 2^5 OR 2^3 OR 2^6
460 GOSUB 1000
470 PRINT "Reverse Alt Color + Border + LC"
480 POKE L,PEEK(L) OR 2^5 OR 2^3 OR 2^6 OR 2^4
490 GOSUB 1000
999 GOTO 999
1000 ' INKEY
1010 IF INKEY$="" THEN 1000
If you run that on a standard 6847 VDG CoCo, you will find that borders do not change, and lowercase mode just produces graphics garbage. On a 6847T1 Tandy CoCo 2, you see some different things. Here is what I get in the XRoar emulator:
I had previously learned about the alternate background color being different, but was a bit disappointed I couldn’t make the border go away when in reverse mode — at least, not in the XRoar emulator. (I do not have a real Tandy CoCo 2 to test this on.)
Are there even more colors hidden away in this chip?
In a previous article I discussed the Radio Shack Color Computer’s lesser known text mode screen colors. Below you can see the normal, normal reversed, alternate and alternate reversed color modes:
During a recent discussion with CoCo FPGA programmer Roger Taylor, he mentioned something I was unaware of. He has spent years working on an FPGA recreation of the various Color Computers and casually mentioned a difference in the colors of the video display generator chip found in later model Color Computer 2s.
These machines, while cosmetically similar to previous CoCo 2 models, are identifiable by the case badge reading “Tandy” instead of “TRS-80”. If powered up, you can also tell the difference by the font. The Tandy Color Computer 2 machines had a round O instead of the square O:
The Tandy machines also have a zero with a slash through it, though that is not showing in either of those screen shots.
In addition to having “Tandy” on the outside, and round Os and slashed zeros on the inside, these model Color Computer 2s also had actual lowercase letters instead of inverted uppercase letters that represented lowercase:
You could get a Tandy CoCo 2 in to lowercase using these POKEs:
0 REM LOWERCASE.BAS
10 PRINT "Look, ma! Lowercase!"
20 POKE &H95AC,57:POKE &HFF22,PEEK(&HFF22) OR &H10
30 GOTO 30
The thing I did not realize was that the colors are a bit different between the original 6847 VDG chip used in the TRS-80 CoCo 1s and 2s and the 6847T1 VDG chip used in the later Tandy CoCo 2s. Roger was aware of this since he had been working on faithfully emulating the differences between the chips.
The intent of this code is to clear the 32×16 text screen, then fill the top half with CHR$(255) — orange-ish blocks.
Code Note: For speed, I used “PRINT STRING$(num,char)”, though I could have also done something like “FOR I=0 TO 255:PRINT CHR$(255);:NEXT” but that would have been much slower.
It then switches in to the alternate color set with SCREEN 0,1. One a pre-Tandy CoCo with the original VDG chip, it looks like this:
But on the Tandy model with the 6847T1 VDG chip, it looks like this:
I do not have a real Tandy CoCo 2 here to verify the colors against this XRoar emulator example, but I am told they are accurate.
This means the T1 color set is more like this:
While I was aware of the lowercase and improved font of the 6847T1 VDG, these alternate colors were a surprise to me. Why did Motorola change it? Did they change it on purpose? I know the 6847 was used in several other computer (and at least one game) systems, but was this 6847T1 variant used elsewhere?
Let me know in the comments.
A colorful finale
And here’s all the variations I know of, so far, 6847 and 6847T1, in one gallery: