I did some work with SSI on Eye of the Beholder but only as a consultant.
I also co-owned a Power House Comic so I had access to all the gaming materials and before the public.
I know very little about the internal workings of the Tiger Chip or the Harmony cart. Never seen a TC and as I've only one HC I don't feel like ripping it appart to examine it. I'm sure others on this forum could help with answering those questions. The TC does use additional accumlators and banking that differs from the standard chips. Makes programming easier but costs a lot more to make.
The 256 colour mode was no fable. Most thought it is was just a typo in the flyer, but it in fact exists, depending on your chip version, and how much code you want to apply.
Here is a bit of conversation and info about the subject from a few years back.
I'll put it here, but then if you want to keep the topic going I think we should go private as it really isn't on topic, not even the right forum
CoCo Team: OMG! I finally found you after nearly 3 years of searching!!!I am so delighted to have been able to track you down
Spent ages going through old forum and email posting, dead email
Addresses, hundreds of gaming sites, et c.
I am Tiger and I run the CoCo archives out of Australia. Some developers and I have been trying to modify a CoCo3 by adding back the hardware you researched and recoded back in 1984. I would really, really, love it if you could help us. We are trying to find schematics, code tables and any software related to producing 256 colors along with anything else you can share on the matter.
Hopefully u still have something about stuff u found in the Gime chip with luck. Or u got a technical document from tandy that only u software designers got listing what the gime could do and listing things that can be done but not approved by Tandy. See a group of us have been doing research on the Inner workings of the Gime and noting them down.
So far we have found some really nifty things which are useable.
Also you have inner knowledge about any hidden modes tandy did not disclose. The Major one is the so called 256 color mode in CMP and RGB modes myth that Mark Seigel said existed and that he was the only person to ever activate it on a production run coco 3. You might be able to finally end this debate with a YES or NO comment. That way people can get back to hacking the gime and use modes that exist and make them better.
GZ: Do you mean for OS9 or RS? I can send both files.
No, not the OS9 one. The other machine code one for games.
GZ: Correct and agreed.The CoCo was far ahead of its time.
Then again, it was made for military use, satellite tracking, in the
Series of Dragons.
And it supports a *NIX OS, with a 4 way serial bus and hardware
Expandable address port.
All this in a $25 gaming computer?
Damn, those were the days!
You'd have loved to see my modified 6-Gun running 256 Full height
Drives all lined up on one wall, an 85Mb SCSI drive, my 300 baud
Coupler modem (don't sneeze!), my Oblique Triad and Quolla Pad drawing
Board, CM-10 monitor, Digital scanner, Gorilla Banana 7-pin Dot Matrix
CHAINSAW, 1-Mb expansion the size of a modern laptop (2Mb coming along
After I was moving onto an 80386-DX2 overclocked to 75 MHz), shelves
Of books, walls covered in paper and my D&D/SHadowrun gaming table.
Yes, it sounds like you are on the right path. Hope some of my old
Helpped? They have advanced our project years and rediscovered code and gaming methods lost to the CoCo community for decades!
GZ: Give this a try.
Ok. What you described is the Page flipping technique if I am understanding right its what sockmaster and Roger Taylor used for their respective hi color displays. My technique uses 2 screens one is the 320x225x16 mode then the next screen is shifted down one row and it uses the reserved lines per field bits which is a 320x210x16 mode.
And when both screens are running you get a 320x480x? Color display we found that the color depth was more then 16colors and it was running at 30fps which is normal as it uses two modes.
So the technique you used for your cold hack, did you have to set it in the last 256bytes area called Fexx and you could only get out of it using the reset button because it was locked in and needed a cold reset to get back to basic.
As Seigel says that this 256 color rgb mode was a real 1byte/pixel mode hidden by Tandy.
GZ: Oh, I know what you mean now. The one I sent you is the one that works best in games as it is small and fast. Try this one instead. I think it is what you seek. The thing is though, it is large and not game friendly.
While I was browsing through my unravelled series. Had a strange thought about the IRQ routines FeF7-FeF8 I am thinking of setting my hack to use the third Irq just too see what happens as I have only ever used Fef8 in my handler never thought about the last one. Been getting the urge to hack the Gime again and implement the little info you remember in my hack.
If only the Gime Diagram actually said what the unnamed register that by-passes the palette ram was called would help find any other secrets hidden in the Gime.
OMG! YES. YES! YYEESS!!!! That is it. THAT is the missing code!They look really good and they work in Mess as well. I was expecting a viewer program to view them. Are you using 3 screens to create the images? And the viewer program is built into the 30granule files?
GZ: yes, the viewer is stored with the image data, no external program required
Ok. Its way more clearer and less flickering. Your viewer technique is more efficient then any others I have seen.
GZ: Images are taken from 320x200x8bit reduced photos. As to your code causing a lot of flickering, you are using too many scanlines. I've long lost touch with Jeff but hope you are right.
Steve Bjork and I did some technical works together years back, but
Separately from one another.
I very much doubt I'll be able to help you much more on the CoCo as
I've forgotten more than most people will ever know on the system.
However, I suggest you contact Prickett, as he was an R&D engineer for
The chip. You could also try Lear, Hawkins, Scott,
Even Pike if any of them can be found. They developed all the
Software for MicroWare which Tandy used to run the system. They'd
Know more about the code addressing than anyone alive and likely more
Than what was ever documented.
I'm including a couple R&D notes and schamatics. Nothing new. All
Released around 1986. Very rare then but I'm certain common now. One
Of Hawkin's own notes clearly indicates 256 colour mode
I'm trying to dig up a copy of my old computer room. If I find it,
I'll pass it along.
PS I think the CoCo3 maxed somewhere around 250 just to be
Also, I seem to recall having to send a small array of data to map out
the RGB 3 bit 8x8x8 mode in order to set up the display, though I do
not recall what data nor where it was sent. Once the data was sent,
then a new state was ready and a new PMode using 3 screens cycles
could be used. This was how 256 colour GIFs were achieved.
Reading what you sent me is fascinating for sure! Because if my limited hardware skills are correct.
You could do a 256 mode in a stock coco 3 without needing the 1 or 2 meg boards all you need to know is the time for signals on E Clock falling and rising edge to display the 3 screens on separate scanlines.
So Mr X's or Mark Siegel said he did it on a stock coco 3 which needed a hardware reset to get out of it and only could happen in Fexx and needed the Timer reg and Mmu which is exactly what your info says.
This method would also increase resolution depth and color even if the memory bandwidth could not do a 320x200x256 colors normally as it is doing 3 screens using one color each of R, G,B at the one time on seperate screens.
Also my hack increased the vertical line count which your method should also create interlaced and possibly overscan too.
What would make it hard is doing double buffering for say a game for smooth animation.
I can see why Tandy did not want this knowledge ever to get out back in the day it would be too much competition too their T-1000 line up.
Oh yes your little tidbits does help greatly and it seens to correspond with what my hack does except your method was more graceful while mine is like being hit over the head with a sledge hammer. :-) Because for my hack to work i used a Lsbr wait which seems to send the irq into la la land and traps it in the Fexx area which only effects the reserved mode bits in FF98 and FF99 all other modes and bits work as normal so i suspect that somehow my Lsbr is similiar to doing a double duty cpu cycle pause type trick.
Yeah would be a treat seeing your old setup from the past :-)
GZ: I made most of my games and artwork demos prior to modifying for 1Mb and my code was designed for a stock 128K system. I'm glad some of my ancient knowledge is still of use.
Well the more I set the coco 1,2 bits in the video mode register to coco 1,2 lines per row the more it shows the scrolling is faster when you use less lines per scanline using the unused vres 210 mode. Why Tandy even had these lines per row settings for is a waste of space especially when using coco 3 modes.
Well I know what your doing in these pics is not the method everyone knows for 256 color display using multiple screens which causes flickering, your method is essentially flicker free. You are using the technique that Mr X's(Mark Seigel) told Nick Marentas years ago. Your using a Timer based IRQ and other stuff only vastly improved. And it only allows 1 page so as u mentioned in a previous email it cannot be used for animation as there is no way to do double buffering. But it may be possible to do a graphics adventure.
Greg just this other tidbits has helped me figure out why I got video flicker in the bottom border region as I and another person pushed the overscan way past 250 lines we were displaying graphics upto about line 260 roughly.So if i reduce the graphics to around 240 it should reduce video flicker. And be more static. Thanks for the tips. All my images are now very clear!
GZ: Here's a detailed schematic of the CoCo3.This was gold back in the 80's.
Sure they are common now.
I once had one that had a bunch of circuit modes in my own handwriting;
MMU expansions, keyboard buffer bosts, stabler SALT, and a lot
More...I'm sure someone has all this around... my copy was stolen a
Few years back and sold on eBay.
Long story, don't ask.
I have several CoCo schematics but I have never seen one that detailed! Too bad about the one with all your notes on it being stolen.
Thanks very muchly for all the info. I know others who might be able to use the extra info and piece it together and unlock this method you guys designed as the more we read your stuff the more likely Mark Seigel used one of your demos to activate it and Roach saw it and told him to never disclose what he saw. Hence why his conversation with Nick and Socks sounded like someone who never designed the code but only knew bits and pieces about how it worked.
With the new flash drive type devices now in use on the coco 3. Storage is no problem. But yes 58g per image is a lot of disk space. But imagine the graphic adventures done using your tweaked code method and how many screens you could have on a 2gig flash card. You could essentially create a game that encompasses all the coco's beginning and end :-)
Btw that Elf pic looks super on the CoCo!
GZ: Here are some of my old emails from Marty and Dale on the subject of the GIME.Date-Received: Tue, 18-Nov-86 23:43:12 EST
Sender: [email protected]
Organization: AT&T Bell Laboratories, Columbus
COCO3 GIME chip specs.
[Generally, I try to avoid repetition of information which is distributed
in other newsgroups. However, this information seemed particularly
timely. I've also been hearing from individuals that they are not always
receiving the newgroups but those on the mailing list do receive their
digest. Since I am keeping old issues you may request any you have
missed. -- JDD]
Date: Fri, 14 Nov 86 14:24:28 est
John: here is a 5-page map of the new Coco-III MMU/graphics chip
That many hackers will find useful. Its authors are identified
In its original header, and I've added some things here & there.
It may be too big for mod.os.os9, or maybe it should be one
Posting by itself. There has been nothing here from mod.os.os9
For two weeks or so, but then ihnp4 tends to "blink" a lot and miss
what's going by.
PS: Latest rumor is that OS9 Level II for the Coco-III won't be out
Until Feb '87.
Several sources to fix up older OS9 for the Coco-III (ramdisk,
boot fix) have come thru on comp.sys.m6809 (the new net.micro.6809.
------- Reposted article starts here --------
>From ihnp4!chinet!draco (Kent D. Meyers) Sat Nov 8 21:49:06 1986
Subject: COCO3 GIME chip specs.
This information was gathered by Kevin K. Darling.
Edited and commented some more by Mike Knudsen.
This is a text for you to use to study the capabilities of the CoCo-3.
Some minor parts may be in error (??). Insiders should clue us in on these.
Purpose of release is to show some of the extra thought in the machine.
In NO way should it be construed as an "official map".
Now have fun! -- Kevin
* Many Thanks from All of Us to the Contributors who shall remain UnKnown!
I COCO-3 MEMORY, and GIME REGISTER MAP (1 Sept 86) KD ver1 I
SYSTEM MEMORY MAP:
RAM 00000 - 7FFFF (512K bytes)
ROM 78000 - 7FEFF when enabled
I/O XFF00 - XFFFF I/O space and GIME regs
64K PROCESS MAP:
RAM 0000 - FEFF (possible vector page FEXX)
I/O FF00 - FFFF (appears in all pages)
Note: the same page of Vector Page RAM at 7FE00 - 7FEFF (when enabled),
will appear instead of the RAM or ROM at XFE00 - XFEFF. (see FF90 Bit 3)
XFF00-0X PIA0 (not fully decoded)
XFF20-2X PIA1 (not fully decoded)
XFF40-5F SCS see note below (usually Disk Controller)
XFF60-7F undecoded (for current "legal" peripherals)
XFF80-8F reserved (This time we'll believe it, right?)
XFF90-BF New GIME Features (Modes, MMU, and Palette)
NOTE: If MC2=0, then XFF50-5F is SCS, and XFF40-4F is internal to CoCo.
This helps to reject non-RS disk controllers.
FF90 INITIALIZATION REGISTER 0 (And ... CocoMax's Mouse!)
Bit 7 - CoCo Bit 1= Color Computer 1|2 Compatible
Bit 6 - M/P 1= MMU enabled
Bit 5 - IEN 1= GIME IRQ output enabled to CPU
Bit 4 - FEN 1= GIME FIRQ " "
Bit 3 - MC3 1= Vector page RAM at FEXX enabled
Bit 2 - MC2 1= Standard SCS
Bit 1 - MC1 ROM mapping 0 X - 16K int, 16K ext (Old 1|2)
Bit 0 - MC0 " " 1 0 - 32K int (New 3 pwr-up)
1 1 - 32K external (New)
CoCo bit set = MMU disabled, Video address from SAM,
RGB/Comp Palettes => CC2.
Clearing MC3 SHOULD let us run programs that clobber FEXX, no??
FF91 INITIALIZATION REGISTER 1
Bit 6 - 0=64K chips, 1 = 256K chips
Bit 5 - TINS Timer INput Clock Select: 0= 70 ns, 1= 63 us
Bit 0 - TR MMU Task Register Select (0/1 - see FFA0-AF)
FF92 IRQENR Interrupt Request Enable Register (IRQ)
FF93 FIRQENR Fast Interrupt Request Enable Reg (FIRQ)
(Note that the equivalent interrupt output enable bit must be set in FF90.)
Both registers use the following bits to enable/disable device interrupts:
Bit 5 - TMR Timer
Bit 4 - HBORD Horizontal border
Bit 3 - VBORD Vertical border
Bit 2 - EI2 Serial data input
Bit 1 - EI1 Keyboard. Does this really work??
Bit 0 - EI0 Cartridge (CART)
I have no idea whether both IRQ & FIRQ
can be enabled for a device at same time.
FF94 TIMER MSB Write here to start timer.
FF95 TIMER LSB
Load starts timer countdown. Interrupts at zero, reloads count & continues.
Must turn timer interrupt enable off/on again to reset timer IRQ/FIRQ.
FF98 Alpha/graphics VIDEO MODES, and lines per row.
Bit 7 = vidmode 0 is alphanumeric, 1= bit plane (graphics)
Bit 6 = na ...
Bit 5 = DESCEN 1= extra DESCender ENable
Bit 4 = MOCH MOnoCHrome bit (composite video output) (1=mono)
Bit 3 = H50 50hz vs 60hz bit
Bit 2 = LPR2 Number of lines/char row:
Bit 1 = LPR1 (Bits 2-1-0 below:)
Bit 0 = LPR0
000 - 1 line/row 100 - 9
001 - 2 101 - 10
010 - 3 110 - 11 (??)
011 - 8 111 - 12 (??)
FF99 VIDEO RESOLUTION REGISTER
Bit 7 - na ... (bits 6-5):
Bit 6 - LPF1 Lines Per Field: 00= 192 lines 10= 210 lines
Bit 5 - LPF0 " " " 01= 200 lines 11= 225 lines
Bit 4 - HR2 Horizontal Resolution
Bit 3 - HR1 " "
Bit 2 - HR0 " " (see below for HR, CRES bits)
Bit 1 - CRES1 Color RESolution bits
Bit 0 - CRES0 " "
Text: CoCo Bit= 0 and FF98 bit7=0. CRES0 = 1 for: use attribute bytes.
HR2 HR1 HR0 (HR1 = don't-care for text)
80 char/line 1 X 1
64 " 1 X 0 (not in BASIC)
40 " 0 X 1
32 " 0 X 0
X Colors HR2 HR1 HR0 CRES1 CRES0 Kmem
H4 640 4 - 1 1 1 0 1 32
H3 640 2 - 1 0 1 0 0 16
(not 512 4 - 1 1 0 0 1 24
BASIC) 512 2 - 1 0 0 0 0 12
H2 320 16 - 1 1 1 1 0 32 Other combo's are
H1 320 4 - 1 0 1 0 1 16 possible, but not
(no 320 2 - 0 1 1 0 0 8 supported.
support 256 16 - 1 1 0 1 0 24
... 256 4 - 1 0 0 0 1 12
in 256 2 - 0 1 0 0 0 6 Like PMODE4
BASIC) 160 16 - 1 0 1 1 0 16
Old SAM modes work if CC Bit set. Then HR and CRES bits are Don't-Cares.
Note the correspondence of HR2 HR0 to the text mode's bytes/line.
Also that number of colors = 2 * (2 ^ CRESbits). No 8-color modes??
FF9A BORDER PALETTE Register RGBRGB (XX00 0000 = CoCo 1|2 compatible)
FF9C VERTICAL FINE SCROLL
FF9D SCREEN START ADDRESS Register 1 (bits 18-11)
FF9E SCREEN START ADDRESS Register 0 (bits 10-3)
FF9F HORIZONTAL OFFSET Register (And ... MultiPak's Ghost!)
Bit 7 = horizontal offset enable bit = 128 char width always
Bit 6 = X6 ... offset count (0-127)
Bit 0 = X0
Note that video start address can be given to nearest 8 bytes, not 512!
If Bit 7 set & in Text mode, then there are 128 chars (only 80 seen)/line.
This allows an offset to be given into a virtual 128 char/line screen,
useful for HORIZONTAL HARDWARE SCROLLING on wide text or spreadsheets.
And for moving 40-char windows around on 80-char screens??
FFA0-AF MEMORY MANAGEMENT UNIT (MMU)
FFA0-A7 Task #0 DAT map (8K block numbers in the 64K map;
FFA8-AF Task #1 DAT map task map in use chosen by FF91 Bit 0)
Each register has 6 bits into which is stored
the block number 0-63 ($00-$3F)
of the Physical 8K RAM block (out of 512K) that you wish to appear at the
CPU Logical address corresponding to that register.
Also can be shown this way: the 6 register bits,
when the Logical Address is in the range of that register,
will become the new Physical RAM address bits:
18 17 16 15 14 13
MMU Register: CPU:
Task0 Task1 Logical Address / Block#
FFA0 FFA8 0000 - 1FFF 0
FFA1 FFA9 2000 - 3FFF 1
FFA2 FFAA 4000 - 5FFF 2
FFA3 FFAB 6000 - 7FFF 3
FFA4 FFAC 8000 - 9FFF 4
FFA5 FFAD A000 - BFFF 5
FFA6 FFAE C000 - DFFF 6
FFA7 FFAF E000 - FDFF 7
Ex: You wish to access Physical RAM address $35001. That Address is:
A- 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
.....3.... .......5...... .......0...... .......0...... .......1......
0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 1
Taking address bits 18-13, we have: 0 1 1 0 1 0, or $1A, or 26. This is the
physical RAM block number, out of the 64 (0-63) available in a 512K machine.
Now, let's say you'd like to have that block appear to the CPU at Logical
Block 0 (0000-1FFF in the CPU's 64K memory map).
You would store the Physical Block Number ($1A) in either of the two Task Map
registers that are used for Logical Block 0 (FFA0 or FFA8). Unless your pgrm
that is doing this is in the Vector RAM at FEXX (set MC3 so ALWAYS there),
you would want to use your current Task Map register set. If the TR bit at
FF91 was 0, then you'd use MMU register FFA0 for the $1A data byte.
To find the address within the block, use Address Bits 12-0 plus the Logical
base address (which in this case is $0000):
Now you could read/write address $1001, which would actually be $35001.
FFB0-BF COLOR PALETTE Registers
Reg bits- 5 4 3 2 1 0
CMP ... I1 I0.P3 P2 P1 P0 Intensity and Phase (16 colors x 4 shades)
RGB ... R1 G1 B1.R0 G0 B0 Red Green Blue (64 RGB combo's)
When CoCo Bit is set, and palette registers preloaded with certain default
values (ask, if you need these), both the RGB and CMP outputs appear the same
40/80 Column Text Screen Bytes are Even=char, Odd=attribute, in memory.
Characters selected from 128 ASCII. NO text graphics-chars.
Char Attributes- 8 bits... F U.T T T.B B B
Flashing, Underline, Text foregrnd, Backgrnd colors 0-7.
FFC0-DF SAM : same as before (mostly compatible Write-Only Switches)
FFD8 = CPU .895 MHz (no address-dependent speed)
FFD9 = 1.79 MHz
FFDE = Map RAM/ROM (RAM accesses use MMU translations)
FFDF = all RAM
Comments by MJK:
Seems that BASIC's power-up initialization doesn't do as much as it could
to insure Coco 1|2 compatibility. In FF90, should set Bits 7 and 2,
and clear Bits 6 and 3. Would allow continued use of FEXX page.
BASIC is giving us only a fraction of the powers inside the GIME;
hope OS9 Level II does better (not till Feb. '87??).
RS disk controllers "ghost" all of FF4X at FF5X, and some software is said
to use FF5X addresses instead of official FF4X.
FF90's MC2 bit probably was intended to accomodate such code,
but nothing (??) can save DISTO controller, which uses FF5X for
add-on hardware features.
How many of these registers and bits are Read/Write, not just Write-Only??
MMU (FFA0-AF) and Palette (FFB0-BF) read correctly.
Attempts to read FF90-9F show all 7E with a couple 40s.
POKEs to FF90 have momentary effect (screen flashes), but BASIC seems
to refresh most of the GIME registers after each timer interrupt
or some such interval. Hopefully the refresh values are kept in
low system RAM, maybe C0 and up -- so POKE values in there and let
BASIC put them into the GIME for you. Meanwhile, block 6809 interrupts
to play with the GIME.
-30- Fine. --MJK
18461 24NOV86-0419 Hardware Hacking
RE: MONITOR CONNECTION (Re: Msg 18417)
From: MARTYGOODMAN To: DAVIDJOHNSON
Just to clarify...
I DID design the OLD dual driver Moreton Bay used
to sell for the Coco ONE, but I had NOTHING what so ever
to do with the design of the dual driver
they sell for the Coco 2. Tho, as I said, I hear it is
a good unit.
18464 24NOV86-0424 CoCo 3 Graphics
RE: tsedit fix (Re: Msg 18457)
From: ARTFLEXSER To: RICKADAMS
I would imagine that a POKE&HFFDF,0 for RAM mode would
probably restore the CoCo 3 commands to functioning. Pressing RESET or typing
DLOAD should do the same.
18465 24NOV86-0432 CoCo 3 Graphics
RE: memory mapping (Re: Msg 18428)
From: MARTYGOODMAN To: DENNYSKALA
(1) I have had the TAB bug reported to me from several folks.
Another example of the shoddy job Tandy and Microware did
with the Basic on the CoCo 3. To call their work
third rate would be too much of a compliment!
(2) KDARLING has posted a set of GIME chip specs on the
CoCo 3 data base. These, I believe, will tell you all
you need to know about ROM addressing on the CoCo 3.
It is an old file... but a valuable one! Get it now!
In brief, tho, in answer to yer question:
The GIME chip controls decoding of ROM addressing.
It can be programmed to see any of the three following
16K of "internal" ROM and 16K of "external" ROM
(this is the only mode available on the old CoCo 1 and 2)
32K internal ROM
32K external ROM
All this is controlled by a port at $FF90.
The low order two bits of that port. (bits 1 and 0)
If bit 1 is zero, then you are in 16K int and 16K ext mode.
That is, the thing behaves like a CoCo 1 or 2.
If bit 1 is set to 1 and bit 0 is zero, then the thing
decodes all of $8000 thru $FEFF from its internal 32K ROM.
If bit 1 is set to 1 and bit 0 is also set to 1, then
the thing decodes all 31.75K ($8000 - $FEFF)
from a 32K ROM in the cartridge port.
Note taht this allows you to make a 32K ROM pak.
18473 24NOV86-0607 Hardware Hacking
RE: J&M controller (Re: Msg 18449)
From: MARTYGOODMAN To: ARTFLEXSER
Off the top of my head I'd ordinarily be skeptical about
55 milliamps making a differnce, but in that application
we are at the very limits of the capabilities of the
power supply of the CoCo, which is marginal for such applications.
J&M should be told about this suspicion. It should be very
easy for them to drop power consumption by 55 ma by
using CMOS chips for some of their logic.
There is a community of CoCo progammers consisting of nearly 300,000 world wide who have talked about this conversation for years yet have never been able to prove it or give any details of use.And OMG!!! Here you have been sitting with this collecting dust all this time !!!
GZ: Huh. I had no clue. First I've heard of it.
GZ: Attatched is an archived PDF document containing a lot of info on CoCoHardware, started by me and greatly expanded upon by others, finally
Sorted by Dale.
It may contain some useful info.
GZ: Also, everyone is too fixated on just the GIMEEveryone is looking for a GIME spec when they should be looking for
the SALT and VDG specs as well since they also affect video.
I think I have some of those around... been digging into boxes I've
Not look at in some 30 years.
30JUL86 General Information
New CoCo is HERE!
From: RAINBOWMAG To: ALL
New York -- Tandy Corporation today announced the release of
The long-awaited Color Computer 3! The much-rumored successor
To the Color Computer 2 offers several improvements in
Performance as well as price. It is expected this new
Machine will overwhelm the home computer market.
The Color Computer 3 comes standard with 128K RAM and can be
upgraded to 512K RAM. The Microsoft BASIC in ROM has been
Enhanced by Microware to allow several new features. The new
CoCo also supports OS-9 Level II, which has been rumored
By many OS-9 experts.
Color Computer 3 uses the 68B09E which is designed to operate
At 2MHz. The CoCo will still normally operate at 1MHz, but a
Double-speed poke is fully supported to take advantage of 2MHz
Operation. However, the heart of the new machine is an
Advanced technological design by Tandy. The functions of the
SAM and VDG chips have been combined into one chip called the
GIME (an acronym for Graphics Interrupt Memory Enhancer). Use
Of this chip allows the Color Computer 3 to operate at an
Effective speed nearly four times that of the old system and
Display a full 256 colors.
Of course, once officially sold, the flyers changed...
-- Composite and RGB video, as well as standard RF output.
-- 64 colors to choose from.
-- 320 x 192 graphics in 16 colors.
-- 640 x 192 graphics in 4 colors.
-- Text-screen widths of 32, 40 and 80 characters.
-- Upper- and lowercase characters with true descenders.
Where did that 256 color mode dissapear to?
GZ: back in the day I contracted to Pioneer Eletronics for a while... back
Then the US still had a parts standard set by N.A.P.C.O. and crossed
Parts with MCM and SK.
TCC1014 vc2645qc is the full UIC Part number for what is commonly
Called the GIME.
I pulled out the old service manual, made in Taiwan...
And several of us discussed the findings.
FF40 - FFBF: Not used
Note: FF22, FF23 are duplicated in tcclOH (VC2645QC), and V.D.G Control Bit
(Bit 3 through Bit 7) affects this IC (TCC1014) only.
1) System Timing, Address Multiplex,
Device Select, MMU
By now, it should be apparent that
controlling DRAMs is a fairly complex
task. In the Color Computer 3, it is
done by the TCC1014 (VC2645QC: ACVC).
In addition to address multiplexing,
RAS* and CAS* generation, WEO*, WEI*
timing control, and refresh
generation, the ACVC performs other
Tasks. It contains the Master
Oscillator, the frequency of which is
controlled by a 28.63636 MHz (PAL:
28.4750 MHz) crystal (XI). The Master
Oscillator is divided by eight to
give a 3.579545 MHz color reference
Signal to the Video Display Generator
LOGIC and Composite Video Signal
(NTSC version only). This reference
Signal is then divided by 4 Cor 2)
Again to provide the 0.89 MHz
(1.78 MHz) E and Q clock signals for
In the PAL version, the Master
Oscillator frequency is slightly
Shifted down than in the NTSC version
For fitting with the PAL encoder
The ACVC (IC6) also controls
access to the memory, granting
access to the processor during the
high time of E (CPU portion) and
access to the VDG LOGIC during the
low time of E (Video portion). During
each access, whether by the CPU or
the Video, the ACVC must provide
appropriately synchronized RAS* and
CAS* signals, as well as the
corresponding address signals, to the
DRAMs. Note that the DRAM access time
must be twice as fast as that
required by the CPU alone in order to
be able to respond to VDG accesses.
In order for the ACVC chip to provide
the appropriate addresses to the
DRAMs, all 16 CPU address lines are
input to the ACVC. It then
multiplexes these into low order and
high order addresses (ZO through Z8,
refer to MMU) which are sent to the
DRAMs along with RAS* and CAS*.
Another function of this section
is to provide address decoding and
device selection for the computer.
Figure 5-6 shows how the SO, SI, and
S2 lines are connected to IC9, a
74LS138, in order to provide
appropriate signals to enable ROM
selection, PIA selection, and various
cartridge selection signals. Due to
the nature of the ROMs and in order
to prevent data bus contention, the
ROMs are enabled only during the E
portion of a read cycle.
As it is clear from the Memory Map,
the memory area of the CoCo3 is from
&00000 through &7FFFF (512K bytes).
The Memory Management Unit (MMU)
inside of the TCC1014, pins FFAO
through FFAF, selects A13 - A18
(actually A16 - A18). Figure 5-7
shows the Block Diagram of the MMU.
TCC1014(VC2645QC) PLCC ACVC C-MOS
[Coco] GIME chip information data
Analysis of the following data would indicate that there were possibly 3
series of production GIME's, 6xx, 7xx and 8xx.
There were 2 manufacturers, VTI and VLSI. The VLSI manufactured chips
had an A at the end of the chip number (TCC1014A).
623 V B769 2645A0001 TCC1014 Tandy 1986 KOREA A VTI
623 V B823 2645A0001 TCC1014 Tandy 1986 KOREA A VTI
623 V B825 2645A0001 TCC1014 Tandy 1986 KOREA A VTI
625 V C027 2645A0001 TCC1014 Tandy 1986 KOREA A VTI
625 V C135 2645A0001 TCC1014 Tandy 1986 KOREA A VTI
627 V C192 2645A0001 TCC1014 Tandy 1986 MEXICO R VTI
627 V 8917 2645A0001 TCC1014 Tandy 1986 MEXICO R VTI
629 V C030 2645A0001 TCC1014 Tandy 1986 KOREA A
733 Z X323 2838-0001 TCC1014A Tandy 1987 MEXICO R VLSI
737 Z X482R 2838-0001 TCC1014A Tandy 1987 MEXICO R VLSI
746 Z X546 2838-0001 TCC1014A Tandy 1987 KOREA A VLSI
807 Z X555Q 2838-0001 TCC1014A Tandy 1987 KOREA A VLSI
824AV M9823 2838-0001 TCC1014A Tandy 1987 VLSI
As a comparison, the numbers below are from Brother Jeremy's prototype
CoCo3. It seems to have a code name of "Tequila".
615 V VB140
05ES VC 2645A
The first number, possibly a batch number has come in three variants.
A 6xx number which appears to be batches of Korean '86 chips.
A 7xx number which appears to be batches of Mexican '86 chips.
A 8xx number which appears to be batches of Korean '87 chips.
Does this first digit signify a batch? Maybe a version number?
Someone once told me that there were at least 7 revisions of the GIME
and that the '86 and '87 were the last and final 2 releases. We all know
that the '86 GIME has more bugs than the '87 so could there be various
versions of the '86 with different fixes?
Also the chip "model number" is TCC1014 on the Korean '86 chips whereas
it is TCC1014A on the Mexican '86 and Korean '87 chips. Maybe the Korean
'86 chips are the buggy ones while the other '86 and the '87 are fixed?
Could those "fixes" have removed certain funtions thought "unused"?
From: HARBIE To: MARTYGOODMAN
I JUST GOT A CHANCE TO TEST ONE OF THE NEW COCO 3 ON SPECIAL .
THE GIME CHIP IS MARKED TCC1014A BUT OTHERWISE THE PCB IS THE SAME .
THIS NEW GIME DOES FIX THE HORIZONTAL SCROLL BUG AND ALSO FIXES THE PROBLEM OF
SOME SCREEN MODE LIKE 80 COLUMN 2 COLORS WHICH USED TO HANG THE MACHINE . I
WILL HAVE TO RUN TEST ON ALL THE OTHER UNOFFICIAL MODES TO SEE HOW THEY BEHAVE
THEY WERE CHANGED .
THAT COULD BE AWHILE SINCE I CANT FIND THE FILE I MADE OF THE SCREEN MODES AND
THEIR PROBLEMS .
THEY DID NOT , REPEAT >>>NOT< << FIX THE TIMING PROBLEM WITH THE MEMORIES , THE
512K UPGRADE RUNS AS HOT AS EVER !
From: MARTYGOODMAN To: HARBIE
One other difference you may note on the new GIME chip is
that in addition to the A added to the part number,
the COPYRIGHT DATE on the chip is now 1987, not
1986 as before. At least, that is what MY
new “A” model TCC1014A has as ITS copyright date.
I am MOST annoyned that the DRAMS still run sizzling!!!
From: HARBIE To: MARTYGOODMAN
YAR RIGHT ABOUT THE © YEAR .
AND I BBURNED MY FINGER WHEN I TOUCHED MY DRAMS AFTER I MODIFIED THEN THE RS
RECOMMENDED WAY . THE EMPHILL WAY STILL RUNS QUITE HOT BUT A LOT BETTER .
From: Greg ZumwaltUse 2 of the RS-HS101 sinks, placing one on bank A and the other on C.
This greatly reduces the thermal output and allows the 1.9MHz overclock
to work without delay. SImple and cheap solution. You can also load the
circuit and remove C4 and C5 to adjust timing and reduce heat.
From: MARTYGOODMAN To: HARBIE
I take it you recommend the Hemphill mod of adding a resistor
in parallel with the 120 ohm one (a 47 ohm one, I believe, yes?)
as opposed to the more widely suggested fix of clipping out
That is what some others seem to be concluding.
From: HARBIE To: MARTYGOODMAN
YEP , IT’S A TAD COOLER AT LEAAST .
BTW , I JUST COMPLETED A CHECK OF ALL THE GRAPHIC MODES AND THE CONCLUSION IS
THAAT THE ONLY THING THEY FIXED WAS THE HORIZONTAL SCROLL BUG . ANY OTHER
IDIOSYNCRAZIE OF THE UNSUPPORTED MODESS IS STILL THERE .
ALSO THE 210 LINES MODES STILL SCRAMBLES THE SCREEN AND THE 200 LINES MODE
STILL HAS ONLY 199 LINNES . MAY BE THE TCC1014B ?
E-Mails with Kevin
To: Kevin Darling
Where might I find the 25 line patch by Kevin Darling. Convential means of
searching have not turned up any reference to a patch by anyone to generate a
25 line display, that I can find. Joerg Sattler,
I took the GIME chip out and cleaned the connections on it and in its socket
and still got the same results. I was wondering if the chip I have was one of
the old ones or the supposably update GIME chip. The info I got off of it is
Is that one of the old ones or one of the new ones? Does CRC have any GIMeE
Drat. The new part is TCC1014A, I believe. The Tandy stock number is MX-0992
for the CoCo-3. Hey, I bet Frank Hogg has some GIMEs! He's been posting here
lately, so either he'll spot your question or you can ask him here or in email.
I have GIMEs in stock. Probably the last known supply of them. Call the office
for details. I don't think I can quote prices etc here. (rules you know)
Frank Hogg -- FHL 315-469-7364
well one thing for sure is OS9 is stable! The longest record for running the
machine without re-booting is 4 months. Im sitting about 2-3 months now and
unlike that time I use the machine more. (that 4 months i was away at college
the bbs was the only thing running)
From: NEALSTEWARD To: ALL
I’m back after suffering from all sorts of strange bugs and crashes. It
turns out that my old GIME gave out on me. New ones are available from
Radio Shack Consumer Mail. The part number is MX-0992 and the cost is
a steep $34.17 + $2.00 shipping + tax. Almost 40 bucks later, my coco3
is alive and well. I can even run Gshell with my 2 megs, which wouldn’t
work before. It’s like getting a new machine.
What is odd, is that I can find no schematic for the inner IC map,
only the block diagrams and logic maps.
I'll keep looking, but most of what I have left is of little value.
Can you send me your OS9 graphic viewer?
GZ: This is the IrfanView of its era. It is a multi format image viewer.Originally it was just for RAT and BMP. Later, upon request, DM3 and
many other formats were added, including GIF... think about it, that's
256 colour display.
Do you have a bit spec for the supported 64 colors?
GZ: It would seem I still do. Here you are.
Do you have anything on the HSCREEN modes?And, it is true you helped the great Pike, master of his domain, never needed anyone's help, to fix his drive controller? It's just one of the rumors we've all heard and wonder about.
Also, why is it no one can find any of the POKE codes or the upper address set? Were they in Rainbow or another magazine or book?
GZ: No, these were never in print. Back so long ago, these were part ofAn ongoing correspondence with G.W. Pike. He was working on his 6Gun
Drive controller that allowed for up to 6 floppy drives and 2
Asynchronous read/write. He was experiencing issues with video due to
Where he was storing his code. Eventually I helped him resolve the
Code and he sold the work to Owl Ware. Eventually Owl Ware and I got it up to 256 drives, as shown in my photo of my old work center. Pike didn't finish the project because of person issues, getting divorced.
So, these are just from some of my old notes I recently pulled of some
I've only got over 2,600 disks... only about 400 of which are sorted.
> Mmmm hopefully this Bob is still alive. Do you know how I could reach him?
> The more we think we have discovered all the tricks in the coco 3. New
> things pop up.
> This reprogramming to get old address paths working sounds like a pain
> Its awesome you still have all this knowledge hidden on old floppies. I
> know I archived close too a thousand floppies full of coco 1,2 and 3
> software and still doing it today, just from what you sent me.
> I feel like a child in a playfair as I was looking thru your
> If you have decayed disks there is a way too extract the data from
> it. I did it on a very bit rotted copy of Cbasic3. Using a program called
> defender. It allows you too copy sectors and tracks seperately it might be
> something worth looking at if you have some. But it is very annoying as it
> is a PC tool and it requires you attach a physical 5.25 drive to your PC.
GZ: Bob RusellR.R. Enterprises
PO Box 975
But that was back in 1983
Yeah, we were the CoCo gods back then... no internet, no national free
Calling, no info like they have now. But like I say, it's been a very
You should look at my DEdit program. It does sector by sector
editing. Made for the CoCo DEdit 3.0 last version.
Fortunately I have ported all my 5.25 disks to PC as virtual DSKs.
Many years back I donated my 8 and 14 inch floppy drives to a computer museum.
If I do find more, I will let you know.
Any chance you can send me your unsorted collection as well?
GZ: Lowell Turner has provided me with copies of all my old floppies,including about 100 missing ones. I have a LOT of disks to sort out.
Also found some of my A.I. projects and Turtle codes or the robotic controls.
Once I have everything sorted "enough" I will send you an updated archive.
GZ: Okay, recovered about 1,200 disks.And.... guess what I found? Some of my 256 demo programs!
I don't know what became of Lowell. He had big plans, lots of goodideas, and just vanished.
I now have 1042 duplicate disks to sort out, from, 5,354, leaving me
with 4,330 to organize.
Do you think Bjork might have any information as he was also an uber coder of that era?
I keep trying to contact him as he is active on NitrOS but everyone says he's a stuck up SOB who won't speak to anyone and never helps others. He refused to release his software even for a system over 20 years old.
GZ: Steve and I goBack a long way, but we were never close so I don't think it would
Help. Beside, I understand his position, although I think he's a bit
Of a tight ass. I released all my CoCo software years ago to the