Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ms. Pacman unstable image #274

Closed
sa666666 opened this issue Dec 22, 2017 · 10 comments
Closed

Ms. Pacman unstable image #274

sa666666 opened this issue Dec 22, 2017 · 10 comments

Comments

@sa666666
Copy link
Member

sa666666 commented Dec 22, 2017

The attached ROM runs differently in Stella compared to real hardware. In particular, every so often, the screen displays only half an image, and the scanline count jumps to 148 or so. It seems to be an interaction with either VSYNC or WSYNC, but I haven't researched any further.

Testing on real hardware (light sixer) doesn't give the same output, but the image still jumps very slightly every now and then, under the same conditions as above. So it looks like whatever is causing the issue on real hardware is being amplified in Stella.

Testing shows similar behaviour (but not as severe) in Stellerator, and both Javatari and z26 have an unstable image too. So it seems the ROM is doing something strange.

Initial report from AtariAge: http://atariage.com/forums/topic/252919-ms-pac-man-inprovements
ROM: MsPac-Man_NTSC.zip

@DirtyHairy
Copy link
Member

Have you checked whether the issue is influenced by setting jitter on / off?

@sa666666
Copy link
Member Author

Jitter has no effect. Attached is a state file that exhibits the problem.
MsPacMan-NTSC(multicolor).st0.zip

@ale-79
Copy link

ale-79 commented Dec 22, 2017

The game cut short the frame from time to time, sending VSYNC and starting a new one after just about 150 scanlines-

On my 14" CRT, instead of a stable "short" frame like in Stella, I get a rolling screen.
In fact, all CRTs that I tested in the past have a minimum number of scanline per frame that can be displayed (and a maximum too, obviously). VSYNC is ignored if that minimum count isn't reached.

The TV I'm currently using displays with NTSC aspect ratio between between 244 and 287 scanlines and with PAL one between 288 and 360. Below 244 VSYNC has no effect and the TV starts displaying the subsequent frame without vertical retrace, while over 360 there's a vertical retrace even if VSYNC in not enabled.

@sa666666
Copy link
Member Author

Well, I guess we can say "the ROM shouldn't do that", but in any event it would be nice to have emulation duplicate what happens on a real TV/console, even if the ROM is buggy. Certainly nothing for 5.1 or anything, but perhaps something to keep in mind.

@thrust26
Copy link
Member

My PAL TV behaves exactly the same as Alex'. But I suppose NTSC TVs have different parameters here, else e.g. the Artillery Duel version with 241 scanlines wouldn't exist. So before we change emulation, we should find out. And then we probably would have emulate differently for PAL and NTSC.

@thrust26
Copy link
Member

We could improve jitter emulation here. I don't know the current algorithm and I am not sure about the right one too. But IIRC, minor scanline changes do not cause any jitter. So I suppose a big scanline count change should cause massive jitter, even if it is only for one frame.

Or we start emulating sync ranges. Out of sync ranged (these are definitely different between PAL and NTSC TVs) as well as switching between NTSC and PAL (around 288 scanlines). Also we should check what happens if a game jitters around that switching range.

@sa666666
Copy link
Member Author

The more we dive into proper emulation for the TIA, the more it seems we need to emulate a TV too. I suppose this is because of the very close relationship between TIA and TV.

We can even bump this to prio 3 and worry about it later (if ever).

@DirtyHairy
Copy link
Member

I have lately been thinking about something on the middle ground between the current code and a full fledged CRT emulation that could plug into the current frame manager code. I have been thinking about two algorithms working in interlock: one that tracks vsync and tries to lock onto the frame size with some inertia, and a second one that works similar to the current algorithm, but with a very tight tolerance margin regarding variations in frame height / vsync timing.

I could imagine that such an approach could be able to capture many of the features of a CRT. I can give this a closer look after finishing the new audio.

@sa666666
Copy link
Member Author

I can no longer duplicate this issue in either Stella or Stellerator. Perhaps other changes have fixed the problem? I will await some testing, otherwise I think we can close this one.

@thrust26
Copy link
Member

thrust26 commented Dec 8, 2020

The issue is still there. But it's the game, not Stella. The game regularly exceeds the overscan timer.

@thrust26 thrust26 closed this as completed Dec 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants