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

[Gene Heskett]

On Wednesday 03 December 2003 18:30, jdaggett at gate.net wrote:
>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
>
Here's another, in the form of a question:  Has anyone investigated 
the HD63C09E?  The one I have in my coco3 has rise and fall times on 
every output pin that measure in very small numbers of nanoseconds.  
If the chip could run that fast internally, I see no reason that this 
so-called 4mhz part couldn't be pushed to 20 or more mhz.

So the question then is, how fast can it go right out of the box?  I 
don't know...

>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

-- 
Cheers, Gene
AMD K6-III at 500mhz 320M
Athlon1600XP at 1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.