FrameManager doesn't properly deal with large scanline counts

[sa666666]

In the old core, there is code that detects the maximum number of scanlines that can occur per frame, and essentially caps it; this is usually accompanied by completely blanking the screen. A few ROMs depend on having this properly emulated:

hectoByte.zip
In this ROM, it doesn't actually hit vsync at all, but it still runs on real hardware as well as the old core. Note the README that accompanies the ZIP file:

A VCS intro needs neither VSYNC nor proper interrupt vectors

The '342' scanlines you see with the old core are the result of capping (ie, this is maximum number of scanlines that can be shown in PAL mode).

Another related example, I think, is Q-Bert. When you press and hold reset, the scanline count goes very high, and as a result calculates a very low fps. This low fps is then fed into the sound subsystem, where is plays the sound very slowly. This isn't how the old core works; in the old core, these large-scanline frames are not used in the framerate calculation.

Finally, I think Quadrun has a related issue. When you press fire just after starting the ROM, the game should say 'quadrun, quadrun, quadrun'. This is happening with the very latest code, but it is running much too fast.

"The Lightbulb Lightens" ROM also exhibits a problem very similar to hectobyte.

[thrust26]

342 is the number of scanlines which Acid Drop displays (in game), probably the limit is resulting from this ROM.

[sa666666]

The 342 is hardcoded as myMaximumNumberOfScanlines for PAL (for NTSC, it's 290). Whether these were determined experimentally or by some formula is unknown.

Also, it appears that hectobyte doesn't work on a real console, or at least not on mine. The ROM worked in the old core, as well as in MESS emulator, but if it doesn't work on a real system, perhaps it should never have worked in emulation at all ???

[thrust26]

@sa666666 On my CRT the 4K version works.

[sa666666]

Sorry, the 4K version is working; I tested the 128b version, which the instructions specifically say only work on an emulator.

Anyway, so the original point stands; we need to somehow cap large scanline counts.

[DirtyHairy]

Hah --- I just removed handling of code that doesn't VSYNC in f0828c5 under the impression that this wouldn't work anyway, and now you come up with a ROM that does precisely that 😃 Funnily, this kinda works (not 100% correct) in Stellerator as I haven't yet found time to port that change there.

I'll look into this eventually.

[thrust26]

Actually this ROM has no frame and no frame rate. I am not sure how it works on my CRT, probably the screen is permanently rolling.

[DirtyHairy]

I guess that's what's going on there. On second though, I also think that there is pretty much no "correct" emulation here, the result is likely to depend on the exact TV set hooked up.

[DirtyHairy]

This is implemented in aba48e8 . Quadrun and HectoByte work fine now. The implementation is slightly different from the old core: FrameManager will now wait a maximum of 30 lines total for the VSYNC start / stop cycle. After that, it will advance to the next state and wait for frame start. I have also taken the liberty of increasing the number of frames used for TV mode autodetection to 80 and the number of initially ignored garbage frames to 20 --- without this, detection started to be unreliable for some ROMs, i.e. Bobby is going home.