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

[Nickolas Marentes]

> 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"