Previous Thread
Next Thread
Print Thread
Page 5 of 8 1 2 3 4 5 6 7 8
Re: Palette generation: request for an explanation #1872 12/29/05 06:52 AM
Joined: Oct 2005
Posts: 52
N
NewRisingSun Offline
Member
Offline
Member
N
Joined: Oct 2005
Posts: 52
Quote:
I wonder, did Nintendo deliberately use a pixel clock that isn't a divisor of the NTSC color signal in order to reduce artifacting?
I would say they used a pixel clock that gives them the horizontal resolution they wanted. The NES' pixel clock actually produces more artifacts than you'd have if you'd sync with the color signal, not less. You just don't notice them because the NES constantly shifts the color burst for every scanline and for every field, causing any artifacts to constantly change over time, canceling each other out over several fields (mostly). You can't do that with the Apple II, because the color itself is produced from the artifacts, and you won't want that artifact color to cancel itself out. smile

By the way, the PAL version of the NES, unlike its NTSC counterpart, does not shift the color burst across fields, resulting in the *ugliest* artifacts I've ever seen.

Re: Palette generation: request for an explanation #1873 12/29/05 10:39 AM
Joined: Jan 2003
Posts: 32
S
sicklittlemonkey Offline
Member
Offline
Member
S
Joined: Jan 2003
Posts: 32
Wow, what a great thread to come back to! It would be great to at least get the Apple II NTSC palette sorted out, let alone all the artifacting. ;-)

RB's Prince Of Persia sceenshot is exactly how it looks on the GS (from memory). It does emulate the colour "artifacting", because that's how the Apple II generates colour. But the GS doesn't emulate complete NTSC artifacting, which on an Apple //e showing the same DHR image would include "thinner" or "thicker" pixels (depending on the number of bits set in a pixel) and colour changes depending on adjacent colours.

Sather's "Understanding the Apple //e" goes into this in great detail, including how to get 16 colours on the standard 8 color hires screen by placing certain colours next to certain others in certain places!

NewRisingSun: if you need any NTSC info from Sather's book, please email me. I really wish I had it scanned. You're right that colour burst is disabled for text portions of the screen for motherboards after a certain revision.

For this reason, any MESS centralizing of the artifacting code would need to include which scanlines have color burst, and which don't.

Cheers,
Nick.

Re: Palette generation: request for an explanation #1874 12/29/05 08:41 PM
Joined: May 1999
Posts: 157
JoJo Offline OP
Senior Member
OP Offline
Senior Member
Joined: May 1999
Posts: 157
Quote:
Originally posted by NewRisingSun:
Yes, but that odd look is less because the NTSC decoder matrix itself looks odd, but because the phosphor primaries are different. I'm only talking about the color decoder here.
The by-the-book primaries nowadays are not the 1953 NTSC's, but the SMPTE-C primaries anyway, which are close enough to common monitor primaries not to require fancy colorimetric transformations.
There is an interesting picture at

http://oldcomputers.net/byteappleII.html

The colors in the picture *should* be representative of a 1977 monitor.


JoJo
Re: Palette generation: request for an explanation #1875 12/29/05 09:59 PM
Joined: Oct 2005
Posts: 52
N
NewRisingSun Offline
Member
Offline
Member
N
Joined: Oct 2005
Posts: 52
Quote:
It would be great to at least get the Apple II NTSC palette sorted out, let alone all the artifacting. ;-)]
As far as I'm concerned, all that is sorted out --- you people just need to decide what decoder matrix is tasty enough for you.
Quote:
NewRisingSun: if you need any NTSC info from Sather's book, please email me.
I got all I need, thanks.

Quote:
The colors in the picture *should* be representative of a 1977 monitor.
Do you really want colors that are that pale? There's also no red at all in that picture.
I think the process of taking a picture off a monitor with a 1977's analog camera, the aging of that photo/negative and the scanning produce so many inaccuracies that this picture is not a good indicator for anything.

Re: Palette generation: request for an explanation #1876 12/30/05 12:56 AM
Joined: May 1999
Posts: 157
JoJo Offline OP
Senior Member
OP Offline
Senior Member
Joined: May 1999
Posts: 157
Well, my vote is for the first one with hue base at 225 - I know that after all it's just a matter of taste, but the first one follows faithfully the accepted standard...


JoJo
Re: Palette generation: request for an explanation #1877 12/30/05 10:37 AM
Joined: Jan 2003
Posts: 32
S
sicklittlemonkey Offline
Member
Offline
Member
S
Joined: Jan 2003
Posts: 32
Quote:
Originally posted by sicklittlemonkey:
You're right that colour burst is disabled for text portions of the screen for motherboards after a certain revision.

For this reason, any MESS centralizing of the artifacting code would need to include which scanlines have color burst, and which don't.
I've done some checking, and I think the GS cleaned-up-RGB output has scrambled my memory. Seems the Apple II color burst was disabled only in pure text modes. Mixed modes _should_ have color artifacting for the text. Can anyone confirm that? Wish I had my II's handy.

In fact, it seems that NTSC monitors are unlikely to be able to immediately stop color output if it is disabled during a frame. Does this sounds right, NewRisingSun? (Also, do your routines work for PAL? The artifacting on the II is very similar in PAL.)

So centralized code wouldn't need to worry about this on a per-scanline basis.

Re: Palette generation: request for an explanation #1878 12/30/05 12:50 PM
Joined: Jul 2000
Posts: 497
Brad Oliver Offline
MacMAME Author
Offline
MacMAME Author
Joined: Jul 2000
Posts: 497
Quote:
Originally posted by sicklittlemonkey:
I've done some checking, and I think the GS cleaned-up-RGB output has scrambled my memory. Seems the Apple II color burst was disabled only in pure text modes. Mixed modes _should_ have color artifacting for the text. Can anyone confirm that?
I can confirm this - an Apple //e hooked up to a TV has no color artifacting in pure text modes. Text at the bottom 4 lines in a graphics mode is artifacted, however.

Re: Palette generation: request for an explanation #1879 12/30/05 08:54 PM
Joined: Oct 2005
Posts: 52
N
NewRisingSun Offline
Member
Offline
Member
N
Joined: Oct 2005
Posts: 52
Quote:
In fact, it seems that NTSC monitors are unlikely to be able to immediately stop color output if it is disabled during a frame. Does this sounds right, NewRisingSun?
I see no theoretical reason why a TV shouldn't be able to immediately stop color decoding, though I have seen technical explanations why it's difficult to do. I would assume that sets with digital signal processing would perform differently than purely analog ones.

Quote:
Text at the bottom 4 lines in a graphics mode is artifacted, however.
The Apple II screenshot on the back of the "gray box" Ultima II release (which is incorrectly captioned as a "Macintosh version presented with high resolution screen graphic without color", even though color is visible --- duh! Also, the colors are wrong...) shows this as well:
http://www.mobygames.com/game/ultima-ii-revenge-of-the-enchantress/cover-art/gameCoverId,11517/

Quote:
(Also, do your routines work for PAL? The artifacting on the II is very similar in PAL.)
Not at the moment, though with modifications I guess they would. It's no priority for me though, as PAL is unimportant in computerland... smile

Re: Palette generation: request for an explanation #1880 12/30/05 11:54 PM
Joined: Jan 2003
Posts: 32
S
sicklittlemonkey Offline
Member
Offline
Member
S
Joined: Jan 2003
Posts: 32
Thanks Brad and NRS. Well, in case anyone's interested, here's an explaination of why Apple - and so presumably other manufacturers - didn't disable colour burst during a frame:

"Even if you can stabilize the color reference, it must be supplied on each line--including during vertical blanking--so that the color monitor can maintain correct phase lock. This is another "high Q" circuit which must be kept supplied with a stable phase reference or color rendition will suffer--usually after just a few lines without a burst.

This is why the Apple does not switch the color burst off during the text part of a mixed display--to do so would cause unspecified behavior of the the "color killer" circuit in the monitor, and poor rendition of the color for many lines after the burst was restored."

From Michael Mahon (ex HP):
http://groups.google.com/group/comp.sys.apple2/browse_frm/thread/1be89fcd88c3d6d8

Re: Palette generation: request for an explanation #1881 12/31/05 12:07 AM
Joined: Oct 2005
Posts: 52
N
NewRisingSun Offline
Member
Offline
Member
N
Joined: Oct 2005
Posts: 52
Quote:
This is another "high Q" circuit which must be kept supplied with a stable phase reference or color rendition will suffer--usually after just a few lines without a burst.
The phase reference is never stable or "locked". While it's true that the Apple II provides a constant reference phase throughout all scanlines, the NES shifts the phase each scanline and each field by 120 degrees, while broadcast Tv shifts it by 180 degrees. But maybe I'm misunderstanding things here.
It doesn't matter anyway --- the composite *emulation* isn't that picky --- if you turn off the color burst for the text lines only, the text lines will be crisp, while the rest will be colorful.

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

Who's Online Now
3 registered members (zino, Bletch, 1 invisible), 148 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,683
Posts114,012
Members4,863
Most Online510
Aug 26th, 2019
Powered by UBB.threads™ PHP Forum Software 7.7.3