Propeller hi-color VGA mod idea
pedward
Posts: 1,642
In the Propeller Presenter thread I had an idea to do 12 bit color on the Prop. It would take 2 COGs each outputting to a modified R2R DAC.
The gist is that 1 COG controls 2 bits and the other COG controls the other 2 bits.
The image data would be interleaved in 1 of 2 ways, either as an RRG-GBB or RGB-RGB. The RRG-GBB would have the RRG driven by 1 COG and GBB by the other, so the image data would be contiguous, but interleaved.
The byte order would be RRGxRRGxRRGxRRGxGBBxGBBxGBBxGBBx
COG 1 would fetch the even offsets and COG 2 would fetch the odd offsets and display them.
The other method involves encoding the image in 2 plane, an RGB1 and RGB2 plane. This would basically look like the existing VGA driver, but with 2 buffers at different addresses. COG1 would read contiguously from plane 1 and display the low bits, while COG2 would read contiguously from plane 2 and display the high bits.
The COGs would be synced via the H/Vsync bits in either case.
Method 2 seems to be a much simpler encoding scheme, but from a wiring perspective the first method would route the R2R DAC pins contiguously.
In either case, the pixels would be 12 bit, allowing for a much better color gamut and not requiring any dithering to get good looking output. The downside is memory footprint, but the additional capability may offset the reduced resolution.
If you combine this with windowed display, like Phil showed, you could have a really good looking result where a "window" of the screen has a "hi-color" image.
The gist is that 1 COG controls 2 bits and the other COG controls the other 2 bits.
The image data would be interleaved in 1 of 2 ways, either as an RRG-GBB or RGB-RGB. The RRG-GBB would have the RRG driven by 1 COG and GBB by the other, so the image data would be contiguous, but interleaved.
The byte order would be RRGxRRGxRRGxRRGxGBBxGBBxGBBxGBBx
COG 1 would fetch the even offsets and COG 2 would fetch the odd offsets and display them.
The other method involves encoding the image in 2 plane, an RGB1 and RGB2 plane. This would basically look like the existing VGA driver, but with 2 buffers at different addresses. COG1 would read contiguously from plane 1 and display the low bits, while COG2 would read contiguously from plane 2 and display the high bits.
The COGs would be synced via the H/Vsync bits in either case.
Method 2 seems to be a much simpler encoding scheme, but from a wiring perspective the first method would route the R2R DAC pins contiguously.
In either case, the pixels would be 12 bit, allowing for a much better color gamut and not requiring any dithering to get good looking output. The downside is memory footprint, but the additional capability may offset the reduced resolution.
If you combine this with windowed display, like Phil showed, you could have a really good looking result where a "window" of the screen has a "hi-color" image.
Comments
I think it was Phil who once said that this is not necessary and that the driver could be modified so that HSync and VSync are done by code instead of video hardware...
And, if you can, you can use 2 cogs for 16-bit color maybe...
(1) "compatible green"
6-bit green r-2r dac on 16..23 plus sync
4bit red and 4 bit blue on second cog and another 8 pins
Then all software created for standard environment will display monochrome green.
(2) 8 bit plus sync on other pins.
It don't need second cog, but is incompatible with existing software
(3) 8-bit Atari 256-colors palette recreate
Incompatible of course, with all. Needs a more complicated active circuit. Atari used 16 hues with 16 brightness levels. May be useful when trying to emulate 8-bit Atari on the Propeller
I tried to make more vga colors with duty cycle - no way on LCD monitor. It samples signal in discrete moments of time.