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

[jdaggett at gate.net]

Nick

Thanks on some more information. The thought of adding Composite as a add on is 
interesting. To do composite as an addon is not so much a "kludge" as you may 
think. In fact it maybe a careful planned addition based on available die real estate 
and what is the simplest and esasiet way to do it. The main diference why the color 
values in the pallette registers are different for "RGB" and "Composite" modes are 
quite understandable.To generate the composite "I" and "Q" signals from RGB data 
will reguire the the outputs of the DACs to be fed to weighted amplifiers.A total of 9 
such amps are needed to derive the luminance and chromanace signals, Y,I,and Q 
for NTSC from RGB. The PAL version actually does a converstion from RGB to 
PAL composite video external to the GIME Chip. Further leaving me to believe that 
real estate began to become precious.  

    Y = 0.3xR + 0.59xG + 0.11xB 
    I = 0.6xR - 0.28xG - 0.31xB
    Q= 0.21xR - 0.52xG + 0.32xB

OOPs a whole bunch more of circuits and real estate. This complexity can be 
reduced by making the software plugin values of Intensity and phase ito the pallette 
registers instead of RGB data. From intensity and phase it is easier to generate the 
NTSC standard I and Q signals. Y is already stored. 

As for the DACs being 3 bit is just an assumption. RGB signals for laptops and LCD 
monitors when in 16 bit color mode use RGB 664. That is 6 bits of Red and Green 
and four bits of Blue. The four bits of Blue are sent to the four MSbits of the blue 
DAC and the LSbits are set to zero. My guess is in the GIME the lower bit is set to 
zero. By making the DACs 3-bits it is very easy to generate 256 or even 512 colors.

Again I itterate that if there is an internal state machine, we have little or no 
knowledge of how it works. The prodding and pooking at it may take many futile 
hours of works to find the magic sequence. 

I am not so sure about 2 states based on powerup. If that be the case then there 
would need a hardware configuration to switch modes and not a software. 
Somewhat like what Motorola does on the HC11/12 with the MODA and MODB pins 
to set the processor in different modes.

Along this line another thought came to mind. If the 256 color mode were intended 
to be used for games and via a cartridge game at that, then the mode could be 
invoked via external hardware. The GIME chip does know when a cartridge is in the 
slot. Also RESET does go to the GIME chip and the cartridge. It does not 
necessarily mean the the RESET pin of the GIME chip is fixed as an output or the 
"CART" pin be a fixed input. At certain times after a power on reset these pins can 
be dual function or bidirectional I/O pins. If the GME chip powers up in slow mode 
then there is a window of 1.1 micseconds from the release of RESET and the 
completion of the first processor cycle, fetch data at $xFFFE. 

As for a software configuration to this mode we must reflect at what the GIME and 
the software does and what state the computer is at when initialization is complete.. 
This is my understand from reading the Unraveled series,  the technical manual for 
the Coco3 and some general hardware and software knowledge.

1) On power up the GIME configures the memory map as 32K ram and 32K rom.
2) The Software needs to tell the GIME Chip the number of banks of ram, 1 or 2, 
and whether it is 64Kx4  or 128Kx1 density. This sets the bottom of ram! The 
software does some writes and reads to determine what ram is loaded on the board 
and determines where the bottom of ram is. Gee jumperless before jumperless was 
popular!
3) After some initialization the software can configure the memory map in one of 
three states and must inform the GIME of that.
4) Standard configuration is that the memory map is 16K external ROM, 16K 
internal rom, and the rest is ram. This allows for a game at $C000 and the Disk 
Basic at $D000
5) one other provison in the power up initialization is that the 256 bytes from $FE00 
to $FEFF be dedicated to ram! ie Protected Ram!
6) The GIME chip sees the whole extended memory map,  $00000 to $7FFFF. By 
the state of the MC0, MC1 and MC3 bits the GIME will know what is ram and what 
is rom. Why, so that whe then roms are accessed the address lines bypass the 
MMU and go directly to the expansion port. The Z bus maynot be active during the 
CPU cycle when acessing the ROMs, internal and/or external. Oddly enough the 
RAM, according to the service manual block diagram, can be written from either 
GIME chip or from the processor, but is read back to the processor is only thru the 
GIME chip. A unique way to implement DMA if needed. Also needed as the video 
and program memory are shared within the same continuous block of memory.

So knowing these facts gives a starting point. My belief, if Mr X is correct, that a 
program must place a service routine in protected ram. There is a block of 132 
bytes that are not used,  $FE69 to $FEEE. Most likely that is where a service 
routine can be stored! Plenty of room to do some quick simple tasks and jump to  
execution. So if I were to write game program to fit in a cartridge, I would start at 
$C000, init the service routine in ram, cause an interrupt, execute the mode change 
and start my program. 

Mr X also mentions that the only way out is to do a hardwre reset, push the reset 
button. That is not uncommon among some of the CoCo 1 cartridge games. My 
belief is that once in this mode it is latched into it. In other words ther eis no path for 
eh state machine ot go to reset state other than a hardware reset. SO to exit a 
hardware reset needs to be issued and the whole init routine of RSBasic be done. 
Most likely a warm reset is done.  

Nick I started looking into a redo of the GIME chip in an FPGA as a means of 
learning VHDL and/or verilog. What started that was when I saw the Glenside IDE 
schematics and siad to myself, Self! this could be done in one chip instead of 9. 
Well one thing led to another and then another. The one another was when I came 
across two VHDL sources for a 6809E processor. Boy did that grab my attention. 
The two sources out there are big! They need to fit into a XLINX Spartan II/IIE 200K 
gate minimum. The samllest size package for a 200K gate is 144 oin TQFP. I 
believe the next largest size is 300K and it fits only in a 208 pin TQFP. Beyond 
300K all of XILINX FPGA's are in BGA packages, yuck! I think that a GIME II type 
chip can be done in 300K or less. Depending on what is does. 

Current status is still in the early stages of design. Remember I am still learning 
VHDL as well as designing the logic hardware which is the easy part. Still working 
up the learning curve. 

1) The IDE port logic is done 
2) Address blocks and some of the internal registers address decode logic done.
3) The MMU is done and expanded to 8bits, 2 Meg direct. 
4) I have block diagrams of the logic for video timing generators for all current 
resolution modes up to 640x200. 
5) The CPU E and Q clocks are not slaved to the video. Still need to verify that this 
will not be a problem. Most likely will preclude that 150nS ram no longer usable. For 
the video that is a blessing! Probably the biggest obstical of the whole system.
6) Still undecided as to type of ram. I have been leaning to SRAM. 512Kx8 15nS 
SRAM are now down to the $8 range. Otherwise I have do multiple refresh timing  
generators, multiplexors and the bunch. An 11 bit wide 2:1 multiplexor,  plus a 22 bit 
wide 2:1 multiplexor just to get the data out of the Z-bus!! May just do both!
7) Also would like to put in a RTC and address it at $FF80 to $FF8F
8) Could add a true 16550 RS232 port and a parallel port if real estate is available. 
9) Current block diagram for a monochrome LCD driver on board capable of up to 
640x200 resolution done. Patterned off of the MSM6255 driver. Original goal!

 
Finally one other point needs to be made. If this design gets to extend beyond 300K 
gates, part the cost goes up significantly. It is possible to split up functions among 
two chips. Besides being able to drive an LCD panel, I really do not want to spend 
$200 to $300 for a single chip either. 

james

On 3 Dec 2003 at 21:47, Nickolas Marentes wrote:

> > 2) In standard operation the color mode in the GIME chip is a lookup
> > table
> of 16 of
> > 64 total colors. This is the 16 pallette registers of 6-bits each.
> > Each
> register holds a
> > color information in the form of r0r1g0g1b0b1 or i0i1p0p1p2p3. Two
> > bit
> level of R,
> > G, B or two bit level of intensity and 4 bit level of phase. Thus
> > what is
> stored in ram
> > is the address offset into the table rather than the actual color
> information. Each
> > pallette register holds six bits of color information. When a
> > pallette
> register is
> > selcted and the the format is RGB then the  data from the pallette
> register goes to
> > three 2-bit DACs. In the case of Composite the my guess is two of
> > the
> 2-bit DACs
> > are concated in some form to form a 4-bit DAC and we get 16 levels
> > of hue
> and 4
> > level of saturation or intensity to feed to the compsite video port.
> 
> > 3) I also have some conflicts between Mr X and teh R&D Memo. First
> > Mr X
> claims
> > that 256 mode can be entered in at 320x200 resolution. Yet the R&D
> > Memo
> states
> > 160x200 resolution.
> 
> John Kowalski did some clock cycle calculations after "Mr.X" told us
> that the resolution was 320x200 and he concluded that it couldn't be
> right. 160x200 on the other hand was possible. Later, we got our hands
> on the Tandy R&D document and lo and behold, John's calculations
> proved right...the resolution of 160x200 was the documented
> resolution.
>
> > Yet another conflict that I have is the R&D Memo states a
> > pallette ram of 512 total colors with 256 displayed. This would
> > require a
> 256 byte
> > block of ram somewhere else and not within the GIME chip. I
> > seriously
> doubt that
> > the chip has an extra 240 8-bit addressable registers.
> 
> The register I show on the GIME block diagram shows 8 bit data
> BYPASSING the pallette RAM. This voids the need for additional ram if
> it is used in a different manner to map the colors.
> 
> I personally believe the 256 color mode is available only under
> composite video out only. Bear this in mind....
> 
> According to "Mr.X", the GIME was originally designed to be RGB only.
> Tandy asked for composite to be added in so that the CoCo3's price
> point was lower by negating the need to purchase the RGB monitor and
> therefore putting it at a lower "game computer" starting price point
> that the Tandy 1000. This is why the composite color mapping is
> different to RGB. The composite was "kludged" in later. I therefore
> suspect that the composite circuitry has something to do with the 256
> color mode due to this "kludge".
> 
> > 4) Now we get to Mr X. The format he states that is stored
> > "yyyyyrgb" is
> basically
> > Hue, saturation and brightness. WIth this format 256 colors is
> > possible.
> 
> He could be wrong with the exact layout of these values. He had
> trouble remembering the exact sequence.
> 
> > 6) Another note of the R&D Memo, to display 256 colors using 1 byte
> > per
> pixel you
> > do not need a lookup table. In RGB format the data can be stored
> > simply as
> R0, R1,
> > R2, G0, G1, G2, B0, B1. Then the GIME chip needs to have three bits
> > for
> the DACs
> > and not 2. That now brings me back to the R&D Memo. It states 512
> > colors.
> Well
> > that is 2^9 colors. Taking the previous example and expanding the R
> > DAC to
> 3 bits
> > and behold you have 512 color in which any 256 can be displayed from
> > a 8
> bit data.
> > This fits the design criteria. The DACs are fed from a 9 bit
> > register.
> Load that
> > register with 8 bits and do some form of shifting to get the 9th bit
> > in.
> 
> Well, there is the possibility that the GIME DAC's are indeed actually
> 3 bits but since the palette ram only holds 2, 1 bit is discarded?
> 
> > 1) the internal state machine that gets to the mode is unknown. One
> > we do
> not know
> > exactly what sequence that activates it. Secondly we do not know if
> > there
> are
> > certain time constrainst. That is to go from state 0 to state 1 to
> > state 2
> must be done
> > in so much time or else the state machine resets.
> 
> Here's my current theory on this "machine state" thing....
> 
> I suspect that the GIME has 2 states of power-up. It is currently
> wired (probably forced due to Tandys request) to power  up in the
> current 64 color mode. The other mode, as "Mr.X" states, once entered
> can only be exited via a reset. Maybe the special state is actually a
> RESET but it has to be done at a certain time with certain conditions
> set in order to activate this other mode hense why the code has to be
> in the upper protected RAM area (the only area protected during this
> reset). He does also state that the RAM is treated as one big block or
> maybe he meant that the MMU is inactive in this mode?
> 
> > 3) From what I gather the IRQ service routine needs to execute from
> > $FE00
> to
> > $FEFF. Also if this were intended for games, were the games to tun
> > in
> RSDOS or
> > OS9 or both?
> 
> Mr.X states that it was meant for games.
> 
> > Either way the sequence needed to be reliable and repeatable.
> 
> Probably could have been but Tandy didn't want the CoCo to have more
> features than the Tandy 1000 and demanded it be "suppressed".
> 
> > Nick I guess it is a difficult task though not impossible. If you
> > could
> send me some
> > info on what you have tried, maybe I can try something or come up
> > with
> more ideas. I
> 
> John Kowalski (who I've invited to join this list and add to this
> conversation) has a better memory than I at what we have tried. All I
> can say is that we have tried playing with all the conventional
> registers with no success.
> 
> ...but if you wanted to hide something, you wouldn't hide it in a
> conventional location would you? *IF* this mode really exists, it
> would be hidden in an unconventional way. I've even tried rapid power
> off and on with the hope of "crashing" the GIME into the mode by
> accident to at least prove its existence. No luck. I've tried both '86
> and '87 GIME's with no luck. There are differences in the '86 and '87
> GIME's. John has discovered that he can create interlaced video with
> the '86 GIME but not the '87. On the other hand, the '86 GIME has bugs
> with it's horizontal virtual scrolling but the '87 GIME fixed it.
> 
> I believe that playing with the '86 GIME will be our best bet. Mr. X
> claims to have activated the mode and it was with a first production
> release model...most probably an '86 GIME.
> 
> Brother jeremy has a few prototype CoCo3's with earlier GIME chips. He
> brought them to a Pennfest and John and I had a bit of a fiddle with
> them. We found that the ealier GIME crashed more easily but it also
> had distinctly better RGB video output (sharper). Probably because
> being a prototype, the component used for the video stages were
> optimised compared to the mass produced production CoCo's.
> 
> I do have one extra piece of interesting info which I haven't place on
> the web site yet.
> 
> There is a handwritten extra register in the Tandy R&D document.
> 
> It says...
> 
> "FF27 - Will also be used for power-up system configuration. Bit
> definitions are TBD"
> 
> Kinda hints towards my theory of the the power-up/reset state to
> switch the mode.
> 
> > will have some time towards the Christmas season and am interested
> > in the workings of the chip. Partially because I have started
> > redoing the GIME
> chip in an
> > FPGA to drive an LCD I managed to obtain for a very very cheap
> > price.
> FREE. It is
> > 640x200 but not color. Can't ask for everything when free. Also the
> > ram
> will be
> > static ram instead of dram. That way I can convert a CoCo 3 into a
> > nice
> field
> > astronomy computer to control my telelscope.
> 
> 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"
> 
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco