[Coco] Any info on a mystery 256 color GIME mode?

[jdaggett at gate.net]

Chris 

One thing to remember is that as more functins are added to the basic design the 
bigger the FPGA may have to get. Once beyoind about 200K gates or so the single 
unit cost starts to get up to the $35 to $50 range for the Sparrtan II chips. Those 
have a 2.5 VDC core and I/O voltage of 3.3 with tolerance to 5 VDC. The Spartan 
IIE and the Spartan III are not fully 5 volt tolerant on th I/O pins. 

One horrible drawback of the GIME chip is that to be backward compatible with the 
old Coco 1/2. The design is for the least common denominator, that video ram and 
program ram are the same speed. Thus the design of the GIME chip is for 150nS 
ram!!!! The video ram is accessed during the time the E clock is high. That is the 
video cycle. When the E clock is low, that is the CPU portion of the cycle. So in a 
horizontal scan of 63.5 uS, the best you can get is 113 video cycles at 1.79MHz E 
clock speed. By doing two reads per cycle, you can get max 226 reads of the video 
ram. In 320x200 mode the horizontal refresh is 11.7 uS and the visable or 
horizontal frame time is about 45uS. The rest is border time! This results in 80 E 
clocks cycles per horizontal line and thus 160 bytes read with 2 reads per cycle. 
Thus the pixel clock ican be slaved to the E clcok or vice versa. In the case of the 
GIME chip it looks as if the pixel clock is twice the E clock. With 150 nS ram with 3 
reads per video cycle and the fastest E clock cycle is 2.2MHz before the crash! 
Faster E clock will mean faster access ram. 100nS ram with three reads per cycle 
yields in max E clock of 3.33MHz.

In high speed mode, 1.79Mhz E clock, the video cycle is 279nS. to get 256 colors 
with 320 horizontal pixels, you need to read 320 bytes. With 150nS ram the best 
you can do is 240 bytes. If the design were set up for 100nS ram then there would 
be no problem for 256 color at 320 horizontal resolution. In fact if the design were 
done for 60nS ram then 640 horizontal pixels at 256 color is possible. You can 
make 8 reads of the ram each video cycle. Then you can read 640 bytes of ram 
each horizontal line.

Now if you really want to speed things up then you go to 15 nS ram. You can read 
640 bytes while the horizontal retrace occurs and not have to worry about cycle 
sharing. The only draw back is that you need a 640 byte FIFO. Modern video chips 
today can have large FIFOs and wider data busses to get data into the chip.  
Combined now with 4 nS DDR ram, whole lines are read with ease during retrace 
even at horizontal rates of 31.5Khz. The way the GIME chip processes the video is 
real real real old school. Basically from the old black and white/amber/green days.  
Depending on which phsopher the monitor used. 


james


On 3 Dec 2003 at 10:46, Chris Spry wrote:

> 
> ----- Original Message ----- 
> From: "Nickolas Marentes" <nick at launch.net.au>
> To: <coco at maltedmedia.com>
> Sent: Wednesday, December 03, 2003 3:47 AM
> Subject: Re: [Coco] Any info on a mystery 256 color GIME mode?
> 
> > Gee, if you redo the GIME, would it be possible to mount it on a
> > adaptor board as a drop in replacement for the real one? If so, you
> > may be able to break the CPU clock speed bottleneck so that we can
> > run the CPU faster
> than
> > 2Mhz with the GIME video running normally. Heck, we could even add
> > in our own 256 color mode!!
> >
> > Why stop there?!  Add in a bit blitter, multi plane graphics,
> > several hardware sprites and a sound generator!!!
> >
> > Now I'm really getting exited!!   :)
> >
> > Nickolas Marentes - "Raider of the Lost Mode"
> 
> Nick, I was thinking the same thing a few days ago actually.  It could
> be made to be backwards compatible, but also add more features for
> graphics and sound which would be designed for things like games and
> GUI interfaces. I would LOVE to see these features that the C64 had on
> a CoCo, but with 256 colors too.  It'd make game creation so much
> easier and probably more fun.
> 
> -Chris
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco