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

[jdaggett at gate.net]

Nick:

I did read your webpage and found it interesting. 

One question I have? Did you try to find it on both version of the GIME chip?

Some comments on your search:

1) Bit 7 and bit 6 of Init 1(FF91) register seems to allow  any combination of 
64K,128K, 256K or 512K of DRAM. This appears to be a carry over from the old 
SAM chip that allowed one or two banks of 4K or 16K DRAM, one bank of 64K 
Dram and oddly enough one bank of 64K Static Ram! The bank size and dram size 
helps define the memory map that the GIME has to work with. 

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. 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. My guess is the later may 
have been abondoned and someother form to get 256 colors 

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. In this 
format there really does not have to be a set of pallette registers to use as a lookup 
table. Mr X states 5 bits of intesity. Is that really intensity or saturation? one means 
is to leave saturation at a fixed level and the alter hue and intensity to get 
essentially 256 colors. In reality you get 240 colors. I really don't consider 8 hues of 
black as different colors. That is essentially what you get with intensity at $00. 
Conversely with intensity at $1F, 8 hues of white is not to apealing also. 

5) Another problem I havewith Mr X's inputs. If the data is stored as a HSB signal 
then thisis better suited for shoving out the composite video port of teh GIME Chip 
and not the RGB. While individual levels of R,G and B can be derived from the 
intensity bits, you are still left to process the "rgb" bits. Again the real estate on the 
chip is brought into question. 

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.

Some items that is still troubling:

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. 

2) Obvisously in 256 color mode the pallette registers are not needed. Could they 
be used for something else? Are they a key to get into the mode? That leaves 
address $FFB0 to $FFDF unused in CoCo3 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? Either way the sequence needed to be reliable and repeatable. Also 
you really do not want to make the programmers jump through a hundred hoops to 
get into the mode. But then this is Tandy! The same company that went from the #1 
retailer of computer to ought of the business in less than 10 years. All I have to say 
is Tandy 1000 series! enough said. 


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 somethig or come up with more ideas. I 
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.

james


 

On 3 Dec 2003 at 7:13, Nickolas Marentes wrote:

> Hi Dennis,
> 
> Your list is doing remarkably well. I'm very impressed by the number
> of CoCo newbies and ex-CoCo users returning. It;s great to see the
> CoCo spirit thriving.
> 
> Thank you for providing the CoCo community with this much needed
> resource.
> 
> Onto other matters...
> 
> I was just wondering what your opinions are on my personal quest to
> resolve the secret 256 color mode...is it real or is it fake?
> 
> Read my web page I have created documenting all the information I have
> collected to date.
> 
> http://www.nickm.launch.net.au/ProjectArchive/256mode.html
> 
> Nickolas Marentes
> 
> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://five.pairlist.net/pipermail/coco/attachments/20031202/9da056f1/attachment-0001.html>