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

[jdaggett at gate.net]

Going beyond the current video and color resolutions that the GIME chip has, 
imposes a new set of problems. For one, the way the GIME chip uses cycle 
sharing/stealing to read from video ram is cumbersome and old fashion. Just 
speeding up the ram and reads by the video section alone eventually meets limits 
for data bandwidth. Ultimately the processor speed needs to be increased to keep 
up with the video chip. The only way I see that is to either do the processor in FPGA 
or ASIC. By doing an ASIC, which is the more costlier route, the current processor 
can be moved over to HCMOS and 0.25 micron. The CPU core could run at 
between 2.4 and 3.5 VDC and I/O either 3.3 and/or 5.0 VDC. By going to HCMOS E 
and Q clock speed can be bumped up to around 8 to 12 MHz. With the 2 phase 
clock internal that would be equivalent to 32 to 48 MHz single phase clock 8-bit 
processor. The current two designs I have seen for an FPGA all use single phase 
clocks. The fastest so far from synthesis is about 16 MHz. The other is around 10 
MHz. Far from say the Z80/8080 core that I have seen that runs at 25 to 35 Mhz. 
There is even a 6502 core that runs at I think 40 MHz. . 

It would have been nice if Motorola had put the U register into the HC11/12 and 
allowed double increment and decrement of the pointer registers .Then a port of 
OS9 to the HC12 would be a breeze. An HC11/12 with the power of the 6809 at 8 
MHZ buss speed.! Oh what could have been. I told that to a product manager at 
Motorola back in 1999. It would have made one heck of an 8-bit embeded 
processor.


just some thoughts 

james

On 3 Dec 2003 at 15:53, john donaldson wrote:

>    While your at it, how hard would it be to add 640X480
> VGA graphic mode. I heard the COCO4 GIMI was supposed to
> have this.  In fact don't even use RGB output. Make it ALL
> VGA. Older monitors are getting harder to find.
> 
> John Donaldson
> 
> 
> On Wed, 03 Dec 2003 14:10:12 -0500
>   jdaggett at gate.net wrote:
> >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
> >
> >
> >
> >-- 
> >Coco mailing list
> >Coco at maltedmedia.com
> >http://five.pairlist.net/mailman/listinfo/coco
> 
> <TEXTAREA NAME="Signature" ROWS="4" COLS="60">
> 
> -- 
> 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/20031203/9c9b20a7/attachment-0001.html>