• Please review our updated Terms and Rules here

Simulated Composite Colors (MCE2VGA)

R

Retro Canada

Experienced Member
Joined
Aug 23, 2012
Messages
280
Location
Vancouver, BC
For the glory and honor of the good ol'CGA:


Only the sky is the limit :D

Now I need to find a documentation of all possible color combinations in text-mode and the resulting colour.

Or at least how to generate them on-screen then I can encode them.
 
My DOSBox patch for composite decoding is probably a good place to start. This can be found at https://www.vogons.org/viewtopic.php?f=41&t=12319&start=640#p431721 . If you read later on in that thread there is an explanation of how the algorithm works. If the DOSBox license is not suitable for your purposes there is a UNLICENSE implementation of the same algorithm in the CGAComposite class at https://github.com/reenigne/reenigne/blob/master/include/alfe/cga.h . Let me know if you have any problems understanding the code.
 
Thxs, but I can't perform floating point mutiplications in FPGA :/ not one per cycle...

I just need pattern tables like the ones here explained in the 8088mp blog:

http://8088mph.blogspot.ca/2015/04/cga-in-1024-colors-new-mode-illustrated.html

I will make a python script to process those 256 color tables and generate the patterns for me. Can't enter 1024 color tables by hand....

My algorithm is very simple: there is a shift register of 4 pixels and according to the current column it gets the color by the pixel combination. Simple as that exaclty like the pattern tables.
 
Retro Canada said:
Thxs, but I can't perform floating point mutiplications in FPGA :/ not one per cycle...
Click to expand...

The conversion doesn't need any floating-point multiplications. The RGBI->composite conversion is just one table lookup per 14.318MHz pixel. The composite NTSC to sRGB decoding is a convolution, but that can be reduced to table lookups and adds, since it's all linear.

Retro Canada said:
I just need pattern tables like the ones here explained in the 8088mp blog:

http://8088mph.blogspot.ca/2015/04/cga-in-1024-colors-new-mode-illustrated.html
Click to expand...

The trouble is that for the most general case, that would lead to pretty big tables. Just for solid colours there are 16 possible RGBI colours in each of the 4 phases, so that's 16*16*16*16 colours. Then you've got new vs old CGA and color-burst enabled or disabled, giving 768kB of sRGB data. To get decent-looking transitions between horizontally adjacent colours then you need a wider kernel which makes the tables exponentially larger again.
 
reenigne said:
Just for solid colours there are 16 possible RGBI colours in each of the 4 phases, so that's 16*16*16*16 colours.
Click to expand...

For every 8 pixels you can only have 2 colours, except in the between 2 chars, but this could be mitigated by "doubling" the previous pixel until it finds a know pattern whenever it finds more than 2 colors in a 4 pixel span.

I can only generate 64-colors output, so my color gamut is short, exactly as the EGA.
 
Do you have a page where you explain your solution ? I don't know DOSBox, I don't know how it generates video so for me to figure out your solution is a bit harder, and honestly I don't want to get into DOSBox details...

All I have is RGBI pixels at 14.318Mhz, the current column and row, I can store the last 4 pixels in queue (this is what I am doing now). Nothing more. I don't know if there is a color burst, which graphics or text mode, I can't access other rows, etc. And there is no filtering. And I can only output in 6-pixel EGA pallete.
 
Retro Canada said:
For every 8 pixels you can only have 2 colours, except in the between 2 chars, but this could be mitigated by "doubling" the previous pixel until it finds a know pattern whenever it finds more than 2 colors in a 4 pixel span.
Click to expand...

This is true for standard CGA modes, but there are ways to have more than 2 colours in a 4 pixel span which might get used in a future demo...

Retro Canada said:
I can only generate 64-colors output, so my color gamut is short, exactly as the EGA.
Click to expand...

Ah okay, in that case incorrect colours in the transition may not be the limiting factor in image quality and may not be worth worrying about. And if you're only worried about software that has already been written I guess a table of 4096 6-bit values would work.

Retro Canada said:
Do you have a page where you explain your solution ? I don't know DOSBox, I don't know how it generates video so for me to figure out your solution is a bit harder, and honestly I don't want to get into DOSBox details...
Click to expand...

It uses a 256-element table to model the CGA's chroma multiplexer chip (3 bits for left-colour RGB, 3 bits for right-colour RGB and 2 bits for phase) and expands that to a 1024-element table (4 bits for left-colour RGBI, 4 bits for right-colour RGBI and 2 bits for phase). Then for each 14.318MHz RGBI pixel you just look up in that table the element corresponding to the current phase, the RGBI pixel value and the previous pixel's RGBI value. That gives you an 8-bit waveform at 14.318MHz sample rate which is the NTSC composite signal that you'd get from the CGA's composite output. Then you need to do NTSC decoding to get an analogue sRGB signal from that (depending on desired quality there are a lot of possible ways to do that).
 
Ok I see now. I would need to to another table to convert from the 8-bit waveform back to rrggbb, which is my color depth.

I think for now I will implement only the CGA 16-composite modes as they are pretty simple. I will dig more into this later. Thxs.
 
You must log in or register to reply here.
Back
Top