It has only been a week since Roger Taylor announced his project to reverse engineer the custom ASIC Radio Shack used in their Color Computer 3 and we have already learned a few interesting things.

He sent two versions of the “GIME” chip off to be opened up and photographed under a microscope. These images revealed some messages etched in to the chip.

Tequila, anyone?

Written on the original 1986 GIME chip was the word “TEQUILA.” Can we now call the original 1986 release version of this chip the “Tequila GIME”?

CoCo 3’s 1986 GIME – Codename: Tequila (Photo from Roger Taylor)

Tortilla, anyone?

And on the 1987 updated GIME, the word “TORTILLA” can be found:

CoCo 3’s 1987 GIME – Codename: Tortilla (Photo from Roger Taylor)

Since Tandy/Radio Shack is base in Texas, perhaps a love of Mexican food inspired these code names.

Credit where credit is due, too.

The imaging has also revealed the names of the designers, John Prickett (Tandy) and Jim Bruister (VLSI).

CoCo 3’s 1987 GIME – Designer names (Photo from Roger Taylor)

These names were previously known, as documented in CoCo: The Colorful History of Tandy’s Underdog Computer, a book by Boisy Pitre and Bill Loguidice.

Roger has been providing near-daily updates to his project on his Patreon page, but the real fun is expected later once the actual reverse engineering of the circuitry begins.

Until then…

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 operations of the GIME are well documented in the Tandy Service Manual for the Color Computer 3 sold by Radio Shack.

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:

And 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.

CoCo 3 prototype (from the collection of Allen Huffman)

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:

https://nickmarentes.com/ProjectArchive/256mode.html

Which brings us to…

GIME more info…

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:

https://www.patreon.com/posts/project-256-58792912

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.

Well, this is getting a bit silly.

Awhile back I posted an article discussing the alternate color set available in the 32 column text mode on a Radio Shack Color Computer. It was (mostly) available from Extended Color BASIC via the SCREEN command.

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
30 NEXT

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"
20 L=&HFF22

100 ' NORMAL
110 PRINT "Normal"
120 REM
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
1020 RETURN

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?

To be continued…

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.

I discovered that the XRoar emulator already handled this. Consider this example, based on a suggestion by Cathe Cita in the Color Computer Facebook group:

10 CLS
20 PRINT STRING$(128,255);STRING$(128,255);
30 SCREEN 0,1
40 GOTO 40

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:

TRS-80 (6847 VDG) CoCo CHR$(255) versus SCREEN 0,1 color

But on the Tandy model with the 6847T1 VDG chip, it looks like this:

Tandy (6847T1 VDG) CoCo CHR$(255) versus SCREEN 0,1 color

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:

Until next time…