[Coco] CoCo 3 FPGA?

[jdaggett at gate.net]

On 31 Jul 2007 at 13:13, L. Curtis Boyle wrote:

> On Tue, 31 Jul 2007 13:07:36 -0600, <jdaggett at gate.net> wrote:
> 
> Would it not be better then to just do 8 bit color, with a 24 bit
> palette  (perhaps latched registers to set them all)? If you can pick
> you own  colors from a 24 bit palette (original VGA only had 18 bit),
> then you  could do 320x200x256 with only 64K of RAM (and 640x200x16
> for the same).  It would be easier to implement the code too, not
> having to worry about  1.5 bytes for a palette definition, etc.). You
> could do a 160x200x256 in  32K, which would match the original Coco 3
> "mystery mode", except you  would have way more colors to play with.
> 
> 
**********************

Curtis

To do 16/24 bit color would be better with a pallette register. Now instead of 
one byte per color you need two or three bytes per pallette color. 

Doing that you then program into the GIME's pallette registers an 8bit offset 
in to the main pallette registers. This would give you 256 16/24 bit colors. 

Again as I stated before there would have to be a modification to software 
so that the colors get initialized correctly or to have the user change the 
colors. 

james 

> > On 31 Jul 2007 at 12:54, Joel Ewy wrote:
> >
> >> Why not a real 12-bit 4096-color mode as a less memory and
> >> (possibly) CPU intensive alternative to 15- or 16-bit modes?
> > *****************
> >
> > Memory wise 12 bit color will require as much memory as 16 bit
> > unless you compress and eliminate the unused nibble. The issue
> > really is not how  much memory needed for a scren but how fast that
> > memory can be written.
> >
> > IF  you have 640x480 with 16 bit color, 2 bytes per pixel. You need 
> > 614,400 bytes of info. The 6809 takes a minimum of ten machine
> > cycles to do a double byte load and store for a transfer. At 80nS
> > machine cycle, 12.5MHz buss speed, to transfer a full screen will
> > require ~24.6 milliseconds. Compared to the current Coco's 640x200
> > at 2 bit color of ~9.26  milliseconds for double byte load and
> > store. Thee concern is time. With a verticle  refresh of 59.94 Hz,
> > that means each screen needs ~16.68 milliseconds to refresh.
> >
> > For 16 bit color the refresh time needs to be reduced or the data 
> > transfer into video memory needs to be speed up. To meet 640x480 16
> > bit color to write a full screen would need a buss speed of at least
> > 20MHz. With the current setup of the CPU/GIME chip IDMA transfer
> > would require 25nS dram max. To get that you need to either have
> > SRAM or SDRAM.
> >
> > Finally you need to  have the software in SECB and/or Nitros9 su
> > pport  that. Having the hardware doing it is one thing. If there is
> > no software to  take advantage of it is then not worth the hardware
> > effort.
> >
> > It is possible to get 20 MHz buss speeds with an FPGA. It is very
> > much possible to expand many functions of the GIME chip. WHo is on
> > board to upgrade software to take advantage of the  new features?
> >
> >
> > james
> 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition. 
> Version: 7.5.476 / Virus Database: 269.11.0/927 - Release Date:
> 7/30/2007 5:02 PM
>