Previous Thread
Next Thread
Print Thread
Page 1 of 8 1 2 3 4 5 6 7 8
Joined: May 1999
Posts: 157
JoJo Offline OP
Senior Member
OP Offline
Senior Member
Joined: May 1999
Posts: 157
The latest thread about the NES has generated in me the curiosity to learn more about how a computer generates its palette when connected to a TV set or a composite monitor.

As they say, my ideas about the matter are few, but confused, so I'm asking to those who know better than me to share their knowledge.

What I know (and even these assumptions could be false) is the following:

1) Most of the computers emulated in MESS have been designed by USA/Japan firms, thus:

2) A generic computer (let's say the CoCo) can be plugged to a NTSC TV set.

3) Colors are generated by electric signals whose corrispondence to actual color is dictated by well -known formulas (e.g. NTSC uses a representation known as YIQ)

4) If the computer is meant to be sold in a country using the PAL system, which in turn uses the representation known as YUV, additional circuitry is employed to convert YIQ color space to YUV.

5) Viceversa, if the computer has been developed in Europe then the circuitry does the opposite conversion (e.g. ZX Spectrum/TS-1500)

6) NTSC machines are particularly good in generating false colors called "artifacts" due to flaws in the NTSC systems. For the same reason is much more difficult to create artifacts in PAL systems (more precisely, it's possible to a certain extent, however different techniques must be used to exploit PAL system flaws)

7) Many machines can be connected to composite monitors, which use the RGB color system and sometimes (like the CoCo) exhibit a different palette

Assuming the points above are exact, I'd like to know:

1) What is the minimal set of parameters which must be known in order to define properly a palette? For example src/vidhrdw/tia.c uses 32 values to define 16 NTSC colors, and 32 values to define 16 PAL colors. Is it correct to say that it could use 3 numbers for each color (Y, I and Q components) and perform YIQ->YUV conversion once and for all?

2) Artifacts are built drawing on the screen a proper sequence of b/w or colored pixels. Since it is the tv set rather than the computer that produces the artifacts, there should be a technique (which is machine independent) that given the pattern and the original colors returns the artifact color. Am I right or not?

3) Are the differences (if any) between TV/Composite palettes due to the hardware, or not? In other words, given YIQ colors, is it always possible to generate the composite palette that is exhibited by the real machine, or the two color sets have absolutely no relation because they are generated by e.g. different circuitry?

4) What happens to artifacts when displayed on a composite monitor? I guess they should disappear, but I live in a PAL country and have never seen a color artifact (at least, a properly programmed one!)

5) Related to #4: is it possible at all to generate artifacts on composite monitors using different techniques? If yes, can this technique be modeled in a machine independent way?

6) Do composite monitors sold in USA show different output WRT those sold in Europe?

I hope I haven't asked silly question or bored you to death, but the subject intrigues me and I'd like to know more about it.


JoJo
Joined: Nov 2003
Posts: 804
S
smf Offline
Senior Member
Offline
Senior Member
S
Joined: Nov 2003
Posts: 804
Quote:
Originally posted by JoJo:
4) If the computer is meant to be sold in a country using the PAL system, which in turn uses the representation known as YUV, additional circuitry is employed to convert YIQ color space to YUV.
I'm not convinced that all systems use yiq->yuv conversion in the way you think.

AFAIK Atari 2600 games have different palettes in PAL & NTSC because the games literally just control the phase.

I imagine other systems just have a different circuit that generates the different phases.

There is not necessarily the equivalent of one of those convertors common for the PSX.

smf

Joined: May 1999
Posts: 157
JoJo Offline OP
Senior Member
OP Offline
Senior Member
Joined: May 1999
Posts: 157
Quote:
Originally posted by smf:
Quote:
Originally posted by JoJo:
[b]4) If the computer is meant to be sold in a country using the PAL system, which in turn uses the representation known as YUV, additional circuitry is employed to convert YIQ color space to YUV.
I'm not convinced that all systems use yiq->yuv conversion in the way you think.

AFAIK Atari 2600 games have different palettes in PAL & NTSC because the games literally just control the phase.

[/b]
Interesting... however AFAIK Atari 2600 draws the screen in a way of its own. What about more recent hardware (let's say Apple II/Coleco)?


JoJo
Joined: Nov 2003
Posts: 804
S
smf Offline
Senior Member
Offline
Senior Member
S
Joined: Nov 2003
Posts: 804
Quote:
Originally posted by JoJo:
Interesting... however AFAIK Atari 2600 draws the screen in a way of its own. What about more recent hardware (let's say Apple II/Coleco)?
2600 isn't that different, it just exposes more of the process to the programmer. The sinclair zx80 had the same technique of making the cpu do all the work to draw the screen, although it was in black and white.

From what bob yannes was saying on the subject apple just picked simple points around the colour table and went with those. Making a different revision of the hardware that picks the same PAL colours as the NTSC chip would be trivial, it's just merging different sine waves. The c64 on the other hand had designer selectable colours ( it's a pity they didn't make them user selectable ).

The Amiga was going to have a composite video chip, instead of RGB. It's HAM mode made alot more sense that way, you would have not see any fringing because changing each value would not have such a dramatic effect.

smf

Joined: Mar 2001
Posts: 16,911
Likes: 56
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,911
Likes: 56
Yeah, the 2600's TIA is almost literally half of the 400/800/5200's ANTIC - just the drawing backend minus the nice display list processor.

Joined: Oct 2005
Posts: 52
N
Member
Offline
Member
N
Joined: Oct 2005
Posts: 52
Quote:
NTSC machines are particularly good in generating false colors called "artifacts" due to flaws in the NTSC systems.
The most well-known flaw in the NTSC system is that when using aerial transmission, the color phase may shift. When people speak of "artifacts", they mean color bleeding (cross-color artifacts) and hanging dots or dot crawl (cross-luma artifacts); this occurs with PAL as well.

Quote:
Artifacts are built drawing on the screen a proper sequence of b/w or colored pixels. Since it is the tv set rather than the computer that produces the artifacts, there should be a technique (which is machine independent) that given the pattern and the original colors returns the artifact color. Am I right or not?
Theoretically yes. What you need to know is what kind of color burst signal the original device creates:
Broadcast NTSC shifts the color burst phase every other line by 180 degrees (causing luma artifacts to "crawl") --- not to be confused with PAL, which reverses the phase of the V vector every other scanline ---, most computers do not (because that would make artifact colors unusable, as the color would be different every other line).

I simulate the output of the CGA's composite color generator with all artifacts using C code (look at the DOS screenshots from Ultima 3 Exodus on MobyGames I submitted); this should work similarly with the AppleII and other machines that have similiar color generators.
I'm currently trying this with the Nintendo Entertainment System.

Joined: Nov 1999
Posts: 703
Likes: 8
B
Senior Member
Offline
Senior Member
B
Joined: Nov 1999
Posts: 703
Likes: 8
I've always wondered if artifacting should be moved into the core, or even the OSD layer so that it could be merged with the blitting code.

My rationale is that artifacting largely much works the same, regardless of what system you have, and it would be nice if it didn't have to be done on a driver-by-driver basis.

Not sure how this would work exactly, though...

Joined: May 1999
Posts: 157
JoJo Offline OP
Senior Member
OP Offline
Senior Member
Joined: May 1999
Posts: 157
Why don't verify the correctness of the machine-independence hypotesis first?

Ideally, such a test program would take a screenshot, calculate YIQ components for each pixel, apply the required color/luma transformations and reconvert the image to RGB.

The program would need calibration (to emulate the tint knob, so to say) but it could be used to check if e.g. a 'crisp' Apple II or CoCo screenshot produces the same artifacts currently emulated by MESS.

Next step would be to compare the screenshot with real hardware...


JoJo
Joined: Dec 2005
Posts: 330
A
AWJ Offline
Senior Member
Offline
Senior Member
A
Joined: Dec 2005
Posts: 330
Quote:
Originally posted by Bletch:
I've always wondered if artifacting should be moved into the core, or even the OSD layer so that it could be merged with the blitting code.

My rationale is that artifacting largely much works the same, regardless of what system you have, and it would be nice if it didn't have to be done on a driver-by-driver basis.
I already suggested this in the NES thread. I was going to attempt to program it myself, but it looks like NewRisingSun has already got composite color simulation working at a much more advanced level than anything I'd be able to produce, so I think I'll leave it to the expert.

Are those MobyGames screenshots from dosbox? MESS?

Joined: Oct 2005
Posts: 52
N
Member
Offline
Member
N
Joined: Oct 2005
Posts: 52
Quote:
Are those MobyGames screenshots from dosbox? MESS?
Neither, I am just processing data right now (input is the image of the CGA's video memory plus register values).

Page 1 of 8 1 2 3 4 5 6 7 8

Link Copied to Clipboard
Who's Online Now
5 members (Hydreigon, r09, box, 2 invisible), 16 guests, and 3 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,085
Posts119,081
Members5,014
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com