search

stella-emu / stella

A multi-platform Atari 2600 Emulator
https://stella-emu.github.io
GNU General Public License v2.0
610 stars 112 forks source link

Scanline count incorrect #265

Open thrust26 opened 6 years ago

thrust26 commented 6 years ago

I noticed this, because some PAL ROM which display color on TV show an odd scanline count in Stella (-> PAL color loss).

I checked Espial and maybe this has to do with VSYNC not starting at the beginning of a scanline. Or with INTIM, which seems to be one higher in 5.x. Or a combination...

Bi! Bi! (AKA Skindiver) (2600 Screen Search Console) (Jone Yuan Telephonic Enterprise Co) (PAL).zip Artillery Duel (1983) (Xonox - K-Tel Software, John Perkins) (6230, 7210, 06004, 99004) (PAL).zip Espial (1984) (Tigervision - Teldec) (7-012 - 3.60016 VC) (PAL).zip Canyon Bomber (208 in 1) (Unknown) (PAL).zip Blackjack (Paddle) (Unknown) (PAL).zip

DirtyHairy commented 6 years ago

I just did a superficial test. Espial seems to strobe RSYNC every frame. If I disable rsync, I get 310 scanlines as in Stella 4.7.2, so I guess this is a scanline cut short by RSYNC, just like Fatal Run.

As for the others, I have no clue without a deeper analysis. @thrust26 , do I read you correctly that all of these show an odd number of scanlines in both Stella 4 and 5? Maybe there is more to PAL color loss thank just the "naked" scaline count.

thrust26 commented 6 years ago

Maybe there is more than one problem. Probably we should try to solve the problem why odd scanlines in Stella (both versions) show correctly on TV first.

thrust26 commented 6 years ago

I wrote a simple color loss test program and tested it on my own Sony Trinitron PAL CRT TV. And it turns out, that it does not care all for odd or even scanlines! So at least my TV is no reference here.

@DirtyHairy @ale-79 and anyone with a PAL CRT TV: Can you verify my results, please?

ColorLoss.zip (move joystick up and down)

Maybe there is no issue at all? Or maybe there even is no PAL color loss at all for a progressive signal?

DirtyHairy commented 6 years ago

@thrust26 I'll check it out on our LCD this weekend. My guess is that whether or not color information gets lost depends on the details and tolerance of the decoder circuit.

thrust26 commented 6 years ago

I don't think any LCD will produce color loss under any conditions. We have to test this on CRTs.

ale-79 commented 6 years ago

Currently I have a small 14" crt that I use for gaming. This TV shows color loss with odd scanline counts (confirmed with the test rom) just like Stella. All the games in the first post with the exception of Espial display in B/W using this TV. Espial is in color with no visible artifacts.

Some CRTs don't show color loss, but instead wrong colors in the top area of the screen. The height of the affected area seems to vary depending on the specific game, and it is also usually different every other frame, so that you can spot three different areas from top to bottom: 1- wrong colors (e.g in "artillery duel" the sky is magenta) 2- wrong and correct colors alternating each frame (the sky flickers between magenta and cyan - difficult to see in a still picture) 3- correct color (cyan sky)

Some colors seems to be unaffected (or very similar to the correct one), so the effect is not always so visible.

The following pictures are from an early 2000s 16/9 CRT showing this kind of artifact: 01 02 03 04 05 06

sa666666 commented 6 years ago

I'm beginning to wonder if we can ever get this right without (as @DirtyHairy suggested at one point) emulating the TV colour decode circuitry. Because what seems to be happening here is that colour loss is just one possible effect, and the naive approach that Stella uses (colour loss on odd scanline count) is simply inadequate and not always correct.

Sort of like the old TIA emulation, where we tried to emulate certain behaviour without understanding exactly where they came from. When @DirtyHairy implemented the TIA as a combination of various counters, many other effect came 'for free'. That is, once we emulated stuff at a lower level, all those strange artifacts just happened on their own, without emulating them specifically.

I've never really seen any documentation on how PAL TVs work. Even the Blargg effects are technically NTSC only, and if we were being precise, they shouldn't even be used in PAL mode. Maybe in the end, the TV effects (Blargg, etc) have to further developed to emulate the decode circuitry, and the colour-loss will come 'for free' too.

sa666666 commented 6 years ago

Or to be more precise, we are currently trying to emulate the end result, when what is probably needed is emulation of the actual hardware at a lower level that is causing this result.

thrust26 commented 6 years ago

The color loss is coming from the eponymous Phase Alterning Line hardware. This means, the colors of two consecutive scanlines are transmitted with a phase shift of 180° for the second line and then averaged. Errors in the phase shift cause no hue error like in NTSC but only reduce the saturation, which is much less noticeable to the human eye.

That's the part that I get so far. But how this causes a complete saturation loss when the scanline count is odd goes over my head. In my mind every 2nd frame would have the first scanline shifted by 180° and the 2nd not shifted. And then everything should work fine by averaging those. But obviously that's not how it works. Looks like I have to dig deeper.

Anyway, I think we have two unrelated issues here:

  1. Espial (why is the scanline count wrong in 5.x?)
  2. PAL color loss (this works as designed in Stella, except for the additional effects described OK)

IMO we should concentrate on fixing the first, because that's a bug and a regression. The second would be an enhancement.

thrust26 commented 6 years ago

I just did a superficial test. Espial seems to strobe RSYNC every frame. If I disable rsync, I get 310 scanlines as in Stella 4.7.2, so I guess this is a scanline cut short by RSYNC, just like Fatal Run.

So something with RSYNC emulation is not 100% correct, right? IIRC I once had the vague idea that RSYNC works differently for NTSC and PAL.

DirtyHairy commented 6 years ago

So something with RSYNC emulation is not 100% correct, right? IIRC I once had the vague idea that RSYNC works differently for NTSC and PAL.

Check out #5 --- to me, @ale-79 results with the logic analyzer confirm RSYNC emulation. RSYNC effectively cuts shorts the scanline. It seems the old core didn't count the truncated line, while the old core does. The question to me is under which circumstances this additional line leads to color loss. I suppose it depends on the length of the resulting 'short line' and was going to write a test program to test this, which I never found time to to :smirk:

So, to sum it up, the emulation is fine, but we should refine line counting for those shortened lines. Or we leave it as is --- as @sa666666 says, our implementation of color loss is just an effective model anyway and will not describe the phenomenon 100% correct in any case.

DirtyHairy commented 6 years ago

But how this causes a complete saturation loss when the scanline count is odd goes over my head.

From my naive understanding, the decoding circuit has to phase shift the color signal before averaging, and the phase alternates between 0 and pi. Phase errors cancel out, while the signal (which was modulated with a corresponding phase shift) is preserved. Btw, humbuckers on an electric guitar work the same way 🎸 😏

If the frame has odd scanline count, the phase of the first line will alternate between frames. I think that this somehow throws off the synchronization in the decoder circuit and messes up the relative phase, causing the color information to be erased by destructive interference.

EDIT: Wikipedia suggests that simple CRTs lead the averaging to the human eye, while other use more sophisticated circuitry to do the cancellation electrically before driving the CRT. I think this is the reason for the difference between sets.

thrust26 commented 6 years ago

< So, to sum it up, the emulation is fine, but we should refine line counting for those shortened lines. Or we leave it as is --- as @sa666666 says, our implementation of color loss is just an effective model anyway and will not describe the phenomenon 100% correct anyway.

If the fix is not too complicated, I would opt for it. Probably that needs more research.