|Looking for CoCo help? If you are trying to do something with your old Color Computer, read this quick reference. Want to contribute to this wiki? Be sure to read this first. This CoCo wiki project was started on October 29, 2004. --OS-9 Al|
This page was last updated on 02/7/2007. Total Pages: 544. Total Files: 907.
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]
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/ > > > > > >