[Coco] GIME Chip

jdaggett at gate.net jdaggett at gate.net
Fri Mar 4 22:50:14 EST 2005


Odd

My Coco3 has the 86 Gime chip and I have experienced no problems with it. No 
sparklies and no horizontal scroll issues that I know of. 

I though can see where some chips could have timing issues and where potential 
areas would be. 

First off one has to realize that the GIME sees the memory arrayed as a 256rows x 
1024 columns x 16bit deep or 512K maximum. When the Coco is ran at 1.78 MHz it 
is pushing the GIME timings to the max. The GIME is designed for one speed of 
ram. That is 150nS. Faster Access ram will still work on the same timing as a 150nS 
dram. At 1.78 Mhz one machine cycle for the CPU is 559nS. Half the machine cycle 
is designated for video porrtion and the other half is CPU porrtion. A machine cycle 
starts with the falling edge of the Eclk. While the Eclk is low this is the video portion.

Here comes the real timing issues. The minimum cycle time for 150nS access dram 
is 260nS. That is as fast a you reqad one single read from the dram. That just does 
fit in the 279nS allowed time of the video portion. There are two key timing issues to 
keep the total cycle time under 279nS. The delay from when the Eclk falls to when 
the RAS line must fall. To achieve 260nS cycle time for a read this delay cannot 
exceed 19nS max. THe next critical timing is when the CAS line falls with respect to 
the RAS line. If it fall beyond 75nS then the 260nS cycle time is extended. 

So what does all this mean? Well in a 512K system the address is an 18 bit 
address,  A0 to A17. The dram can handle only 9 bits at a time so the GIME chip 
must break the address up into row and column address. The first 9 address bits are 
the row and the next 9 are the column. The Gime chip must  have the row address 
on the Z-Buss and stable when the RAS line goes low. The row address toteh dram 
is latched inon the falling edge of the RAS line. Likewise the column address is 
latched into the dram on the falling edge of the CAS line. With only 75nS max 
between the falling edge of the RAS and CAS line, the Z-Buss must change the 
output multiplxor within that 75nS window.

When the GIME chip reads data from the ram it reads two bytes at a time. Bank 0 
goes to IC12 and bank1 goes to IC13. When the CAS line is low the data from IC12 
is latched into the GIME chip. When the CAS line is high, data from IC13 is latched 
into the GIME. Data fromteh ram is latched out to the ram databuss 150 nS after the 
falling edge of the RAS line. Thus 150nS acess time. The CAS line must be low for 
75nS minimum. 

One real potential problem I see that can arise is that the time the CAS falls 
referenced to the RAS is at the minimum time of 25nS and the CAS is low for the 
minimum time of 75nS. This would cause the CAS line to go high before the data is 
latched out of the ram and thus a read of IC12 would be garbage. In text mode that 
would be the text data. The read from IC13 would be the attribute data if enabled. 

What maybe the major cause of the "sparklies" is that there is a severe jitter in 
generating the RAS and CAS signals to the ram. I would not be surprised that the 
87 chip corrected some these issues in generating these signals. There has to be a 
close synchronization of the RAS/CAs to the Eclk, that is very critical. At high speed 
there is little room for jitter or slippage in these critical timings. Al;so you h ave to 
consider the multiplexor on the Z-Buss. That has to switch rather fast also. Any 
slewing or delay greater that 15nS or so to get the data stable may cause the GIME 
to read the wrong address for video data. 

Timing like this can vary from chip to chip. Transistors characteristics will vary over 
the area of the wafer. One characteristic that can vary is switching times. 1986 was 
about the time when some major break throughs were made in designing high 
speed CMOS. This chip is CMOS and it is my guess that a few parameters had to 
be tweaked to get a more consistant part and yield. I bet Tandy took a big  hit on the 
yields of the 1986 part.  In IC design you stive for 98% yield. It was not unusual to 
have first run yields on a new IC from that era as low as 40%. That can get 
expensive real quick. I have seen wafer yields for first runs of 68HC05 processors 
yield 6 good die out of 325 on a wafer. At $1500 a wafer those were some awful 
expensive parts.($250 per part). 

james


On 4 Mar 2005 at 12:22, KnudsenMJ at aol.com wrote:

From:           	KnudsenMJ at aol.com
Date sent:      	Fri, 4 Mar 2005 12:22:02 EST
Subject:        	Re: [Coco] GIME Chip
To:             	coco at maltedmedia.com
Send reply to:  	CoCoList for Color Computer Enthusiasts 
<coco at maltedmedia.com>
	<mailto:coco-
request at maltedmedia.com?subject=unsubscribe>
	<mailto:coco-
request at maltedmedia.com?subject=subscribe>

> 
> In a message dated 3/4/05 12:19:13 AM Eastern Standard Time,  
> bowerod at winco.net writes:
> 
> >It  has been a while but if I am not mistaken, the '86 version had 
> >issues with graphics and the '87 was the fixed version. All of my 
> >machines have '87 chips in them so I never really worried about  it.
> 
> 
> 
> 
> The '86 version's infamous sparklies were due to a timing problem in
> some  of that GIME's bus signals.  The general consensus is that the
> '87 chip was  an improvement in every sense.  There were rumors of
> some cartridges, MPIs,  and RAM upgrades that were flaky on the old
> GIME's timing, though I don't recall  such problems myself.  Also,
> some '86 GIMEs were much more "sparkly" than  mine -- I remember
> someone's Coco where you could barely read the screen text  while
> something was running.
> 
> I don't recall any games or graphics that had to be reprogrammed to
> use the  later chip -- but maybe some programs had extra code to get
> around the sloppy  timing of the '86 model, and this code backfired on
> the newer version.
> 
> But as for me, the only disadvantage of the newer chip was that you no
>  longer had the sparklies to tell you how much work was going on in
> another  screen under OS9's multitasking.  While editing source in one
> window, I  could tell when a compile or assembly was done because the
> snowflakes cleared  away :-)
> 
> I think I still have my '86 chip stashed away somewhere, if someone is
>  really nostalgic for those sparklies.  --Mike K.
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco





More information about the Coco mailing list