AllenHuffman at 05:14, 7 February 2007

2007-02-07T05:14:07Z

← Older revision		Revision as of 01:14, 7 February 2007
Line 1:		Line 1:
			{{NavCoCoNextGen}}
	== Video Hardware ==		== Video Hardware ==

JOELAV at 21:15, 2 February 2007

2007-02-02T21:15:25Z

New page

== Video Hardware ==

Some of this stuff is pretty specific and seems like a realistic, natural extension of existing CoCo capabilities. This is copied straight from the maltedmedia mail list and should eventually be reformatted (and this present annotation removed). But it would be good to preserve the original message thread, at least as summarized here, for future reference. Perhaps as a link from this page as it evolves into a more technically complete specification. [JCE 2/2/07]

<pre>
From: Joel Ewy
Date: 1/27/2007
Subject: Re: [Coco] CC-Five (was: Re: Pseudo CoCo4???)(LONG)

John Kowalski wrote:
> > At 02:28 PM 24/01/2007 -0500, James Daggett wrote:
> >
>> >> Actually to improve color resolution would be to have an extra bit set in
>> >> say the INIT1 register that would be say for COCO 4. This would then allow
>> >> bit 6 and bit 7 of the color pallette to be written. Therefore you now have
>> >> a pallette of 16 colors of 256. There could be another trick to swap the
>> >> pallette register bank with writes to a register to map in banks of
>> >> 16 colors. This would keep some backward compatibility.
>> >>
> >
> > I think a neat way of extending the color resolution to 8 bits without
> > causing compatibility issues would be to treat bits 6 and 7 of the palette
> > registers as low order bits for all three R,G and B values:
> >
> > Palette register:
> > bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0
> > I1 I0 R3 G3 B3 R2 G2 B2
> >
> > This way red, green or blue can have 4 bit values to create 16 shades
> > instead of just 4.
> >
> > bits 3 2 1 0
> > Red = R3 R2 I1 I0
> > Green = G3 G2 I1 I0
> > Blue = B3 B2 I1 I0
> >
> > Even if existing software writes values to bits 6 or 7, the resulting
> > displayed colors will still be "correct" except for a slight difference in
> > brightness.
> >
> >
I think those are really good ideas. Using James' suggestion, you could
just use the extra 2 bits for Red and Green. Ostensibly variations in
Blue are not as noticeable to the eye, so some high color displays
simply give more resolution to Red and Green. But how hard would it be
to provide an extra bit switch somewhere to toggle between James' and
John's two interpretations? In fact, if you have two bits to play with
somewhere I suppose you could select between red/blue, red/green,
blue/green, and the Sock scheme, depending on the color composition of
the image you're trying to display.
With this kind of setup you could have 16 / 256 "clean" colors in
3/3/2-bit modes (however you would have 3 sets of 256 colors to choose
from) and 16 / 4096 colors (with some color error) in Sock's (2/2/2)+2
mode. I do think that being able to select more accurate colors would
noticeably improve even an "unflickered" 16-color display.

Palette Interpretation Register:
0 0 = RX, GX
0 1 = RX, BX
1 0 = GX, BX
1 1 = I0, I1
Where RX, GX, and BX represent extra bits of color resolution for Red,
Green, and Blue, and I0, I1 represent 2 LSB for all colors.

I also like James' idea about the auxiliary palette bank(s). I've
thought about that too.

What about a cococopper that could watch for HSYNC and stuff the palette
registers after each scan line from a block of 64 bytes stored at the
end of the raster data for the previous line, without interrupting the
CPU? It could also swap between palette register banks. This would
significantly simplify writing programs that took advantage of various
high color pseudo-modes. You set up the cococopper, load in your
picture/palette data, and go. Doing color quantization, image scaling,
and dithering would still take some time, but all that information, once
calculated, could be preserved with saved images.

JCE
> >
>> >> As for increase resolution there is an unused bit in video resolution register
>> >> at $FF99 Bit 7 in combination with bits 6 and 5 to double the lines per frame.
>> >>
> >
> > This would fit very nicely with the existing video resolution structure.
> >
> > Bits 1,0 set to 11 could enable 256 colors (1 pixel per byte).
> > Bits 7,6,5 set to 010 could enable 480(450?) scan lines.
> > Bits 7,6,5 set to 110 could enable 480 scan lines + double horizontal
> > resolution.
> >
> > It might be tempting to treat bit 7 alone as horizontal resolution * 2, but
> > it's probable that this could break a lot of existing software.
> >
> > Bits 6,5 almost *never* get set to 10 because that makes the display go
> > wonky (Boink bouncing ball demo is one of the only exceptions that does.)
> >
> > John Kowalski (Sock Master)
> > http://www.axess.com/twilight/sock/
> >
> >
> >
</pre>

Video - Revision history

AllenHuffman at 05:14, 7 February 2007

JOELAV at 21:15, 2 February 2007