Why Doesn't the NES Show Artifact Colors?
Moderator: Moderators
Re: Why Doesn't the NES Show Artifact Colors?
That's confusing. When I generate the same pattern and load it into sms_ntsc, I get this:
It really shouldn't be doing the flickering red and blue thing.- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Why Doesn't the NES Show Artifact Colors?
Wow, yes. I haven't seen that since my childhood. SMS Shinobi was my favourite game for a long while.Great Hierophant wrote:Please don't rely on the second video to give an accurate visual of what the effect looks like, my video does in 60p :
https://youtu.be/Fyl1n70tmcM
That is a reasonable representation of what the eye will see on a Genesis in SMS mode with an NTSC CRT. I apologize for the lack of sound, the handheld camera and the one-handed playing. When you scroll the screen, if your eyes are sharp enough you can see the alternating lines a bit. The total effect appears like a wall of rolling cylinders, one level rolling left, the next level rolling right and the third rolling left and so on.
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
Re: Why Doesn't the NES Show Artifact Colors?
Does anyone have a download source for the most recent version of the binary sms_ntsc plug-in? The ones I could find are from 2008-2009 or require compiling.
That looks much closer to the CRT than anything else I have seen. Oddly enough the lines are really hard to distinguish when the image is stationary but are much thinner when you are moving and looking intently at the screen.lidnariq wrote:That's confusing. When I generate the same pattern and load it into sms_ntsc, I get this:It really shouldn't be doing the flickering red and blue thing.
-
- Posts: 592
- Joined: Thu Aug 28, 2008 1:17 am
- Contact:
Re: Why Doesn't the NES Show Artifact Colors?
I think you got that wrong. The artifacting colors (blue/orange) remain solid/fixed on the CoCo systems. But you never know what state you'll be in on power up, so games as the user to "reset" the system until the "right" colors appear (or some other matching system).tepples wrote:CoCo's video chip is an MC6847 Video Display Generator, whose datasheet indeed specifies half a color burst period per pixel. At that, rate, the scanline can reasonably be 454, 455 (standard), or 456 dots long. It turns out, according to note 6 on page 7, that the MC6847's scanline is of the standard length, 455 dots or 227.5 color burst periods, which causes the color burst phase to be opposite from one scanline to the next. Thus artifact colors would appear slightly harder to exploit than they would be on a 228-period video circuit like that of an Apple II or a 7800: you have to make checkerboards rather than vertical lines.
It doesn't change per scanline:
__________________________
http://pcedev.wordpress.com
http://pcedev.wordpress.com
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
Re: Why Doesn't the NES Show Artifact Colors?
Tepples is not wrong about the datasheet, it clearly says 227.5. I agree that if you hooked up a CoCo 1 & 2 game to a B&W monitor, you would see straight vertical lines, not checkerboard. I would suggest that Tandy's implementation works by lengthening the number of pixels somehow to an even 228.
Re: Why Doesn't the NES Show Artifact Colors?
Even though it's from a CoCo, that screenshot looks so Apple II-like it isn't funny.
Re: Why Doesn't the NES Show Artifact Colors?
Wikipedia's article about the CoCo says that
The datasheet for the bus arbiter ("SAM") has the following note:
[edit] Wait, the output of the MC6847 is still component (Y ΦA=V ΦB=U); it doesn't become QAM until it is processed by the next IC (the MC1372). Somehow that's got to be what's doing this.
Internally, the MC1372 looks like it just rapidly multiplexes between (A-ref), (B-ref), (ref-A), and (ref-B). I really don't see how this would cause the observed behavior.
Unfortunately, I'm not altogether clear what they mean by that. Having found the schematic, the color/pixel clock ("VCK") is generated by the MC6883 ("SAM") and goes through a slight lowpass (first order, 6MHz) before feeding the MC6847.Unfortunately the VDG internally can power up on either the rising or falling edge of the clock, so the bit patterns that represent orange and blue are not predictable. Most CoCo games would start up with a title screen and invited the user to press the reset button until the colors were correct. The CoCo 3 fixed the clock-edge problem so it was always the same; a user would hold the F1 key during reset to choose the other color set.
The datasheet for the bus arbiter ("SAM") has the following note:
(boldface original) ... so I don't think there's any such scanline stretching going on.In order for the VDG and MPU to share the same dynamic RAM [...] the VDG clock must be stopped until the VDG data fetch and MPU data fetch are synchronized [...] Once synchronized, the VDG clock resumes its [master clock÷4] rate and is not stopped again unless an extreme temperature change [occurs]. When stopped, the VDG remains stopped for no more than 32 OscOut cycles
[edit] Wait, the output of the MC6847 is still component (Y ΦA=V ΦB=U); it doesn't become QAM until it is processed by the next IC (the MC1372). Somehow that's got to be what's doing this.
Internally, the MC1372 looks like it just rapidly multiplexes between (A-ref), (B-ref), (ref-A), and (ref-B). I really don't see how this would cause the observed behavior.
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
Re: Why Doesn't the NES Show Artifact Colors?
For this particular example, the CoCo graphics are almost too exact in terms of likeness compared to the Apple II :tepples wrote:Even though it's from a CoCo, that screenshot looks so Apple II-like it isn't funny.
As you can see, neither machine has offset graphics :
Re: Why Doesn't the NES Show Artifact Colors?
Do SMS games look different on an actual SMS?Great Hierophant wrote:That is a reasonable representation of what the eye will see on a Genesis in SMS mode with an NTSC CRT.
I've never owned one, so I've only played them through Genesis (Model 1) and emulation.
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
Re: Why Doesn't the NES Show Artifact Colors?
Ditto, but I seriously doubt it. I cannot seem to find any Youtube videos of the game as played on a real SMS, but this TV commercial for the game seems to support the idea that it does : https://www.youtube.com/watch?v=n-N2fjSrouIAsaki wrote:Do SMS games look different on an actual SMS?Great Hierophant wrote:That is a reasonable representation of what the eye will see on a Genesis in SMS mode with an NTSC CRT.
I've never owned one, so I've only played them through Genesis (Model 1) and emulation.
Does anyone have a recent blargg ntsc filter for Kega Fusion? The only ones I have been able to find are five to six years old and fail miserably to reproduce this effect.
Re: Why Doesn't the NES Show Artifact Colors?
Two-player Double Dragon!? I can't wait!
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Why Doesn't the NES Show Artifact Colors?
The NES version should really have been called Single Dragon.Asaki wrote:Two-player Double Dragon!? I can't wait!
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
Re: Why Doesn't the NES Show Artifact Colors?
It did technically have two player, but its two player modes arerainwarrior wrote:The NES version should really have been called Single Dragon.Asaki wrote:Two-player Double Dragon!? I can't wait!
I know this is getting a bit off topic now, but here is a stumper. The C64 has a low resolution 160x200 and high resolution 320x200 mode. But all the available evidence suggests that it does not show composite artifact colors. By comparison, the IBM CGA uses the same resolution and the Apple II is pretty close. Consider this dungeon walls on screenshot of what the C64 would display (according to WinVICE) on an NTSC color monitor :
On an IBM PC with CGA, the walls will look something like this :
And on an Apple II, they will look like this :
An Atari 8-bit machine will show walls with brown and blue colors, although this varies on the model of the machine.
The only reason why I can tell that the C64 does not show artifact color is because it is using a 8.18MHz dot clock whereas the other systems are using a 7.16MHz dot clock : http://dustlayer.com/c64-architecture/2 ... your-clock
8.18MHz is not an even multiple of the 3.58MHz color burst, so you don't have the half-clock which makes for the ideal artifact color.
Re: Why Doesn't the NES Show Artifact Colors?
The C64 and VIC-20 were designed to generate a completely compliant NTSC signal (other than 240p vs 480i - although on the NTSC VIC-20 there's even a control to use proper interlaced timing), 227.5 color periods per scanline, proper phase reversal from scanline to scanline, &c.Great Hierophant wrote:I know this is getting a bit off topic now, but here is a stumper. The C64 has a low resolution 160x200 and high resolution 320x200 mode. But all the available evidence suggests that it does not show composite artifact colors.
[...]
The only reason why I can tell that the C64 does not show artifact color is because it is using a 8.18MHz dot clock whereas the other systems are using a 7.16MHz dot clock
The VIC-20 (because I looked it up more recently) uses a 4 ¹/₁₁ MHz master pixel clock, with exactly 260 pixel periods per scanline. (The C64 would thus have exactly 520 pixel periods per scanline). The visible portion or the scanline (75%) corresponds to ≈96 low-resolution VIC-20 pixels; ≈192 high-resolution VIC-20 pixels/low-resolution C64 pixels, or ≈392 high-resolution C64 pixels.
The real question to me is what is the CoCo doing wrong such that artifact colors work. But short of ever getting an oscilloscope into one, I'm not certain I'll find a technical explanation I'm satisfied with.
-
- Posts: 780
- Joined: Tue Nov 23, 2004 9:35 pm
Re: Why Doesn't the NES Show Artifact Colors?
Isn't "proper phase reversal from scanline to scanline" a PAL (Phase Alternating Line) feature? If not part of NTSC, this suggests that the feature is useful in cancelling out color errors like artifact color even with NTSC.lidnariq wrote: The C64 and VIC-20 were designed to generate a completely compliant NTSC signal (other than 240p vs 480i - although on the NTSC VIC-20 there's even a control to use proper interlaced timing), 227.5 color periods per scanline, proper phase reversal from scanline to scanline, &c.
Apparently they did not do enough right with composite color because you cannot guarantee which pattern of colors will be generated when you boot the system. Atari did not do so hot here either, almost every system in the line shows different colors. I guess that Origin forgot that the C64 does not support artifact color, so their stripey walls would still look rather stripey and colorless on a TV. They could easily have used solid colors.lidnariq wrote:The VIC-20 (because I looked it up more recently) uses a 4 ¹/₁₁ MHz master pixel clock, with exactly 260 pixel periods per scanline. (The C64 would thus have exactly 520 pixel periods per scanline). The visible portion or the scanline (75%) corresponds to ≈96 low-resolution VIC-20 pixels; ≈192 high-resolution VIC-20 pixels/low-resolution C64 pixels, or ≈392 high-resolution C64 pixels.
The real question to me is what is the CoCo doing wrong such that artifact colors work. But short of ever getting an oscilloscope into one, I'm not certain I'll find a technical explanation I'm satisfied with.