Mega Drive VDP triggers the vblank interrupt very prematurely, scanline counter doesn't match real screen position

[devinacker]

This is a follow-up to an issue that came up following some discussion on #7390 (starting from here.)

Basically, @DavidHaywood noticed that inserting coins during certain parts of the attract sequence on mp_shnb3 would cause the game to lock up. I determined this to be because of the Mega Play BIOS resetting the main CPU and then sending it commands which the game would handle via the vblank interrupt handler sometimes earlier than it's actually supposed to, causing it to behave like it never actually received the commands at all and getting stuck until the machine is reset.

This seems to be caused by the fact that when the main CPU's vblank interrupt occurs, the screen device is at y=186, but the VDP's scanline counter is at 224, which suggests to me that the VDP is running at the correct speed but is just too far forward in time for some reason. @angelosa also noted that the same timing difference appears to happen when emulating a regular Mega Drive, but I haven't tested that myself.

(Curiously the "shift" between the two seems to be about equal to the actual length of the vblank period (38 lines), but that may or may not be a coincidence.)

I know that sega315_5313_device has an alternate timing option which causes it to track the screen's actual y-position instead of using its own separate scanline counter, but enabling that in megaplay.cpp doesn't seem to play nice with its custom screen updating (possibly because of the alternate resolution for handling the BIOS video overlay or something).

[angelosa]

SMS VDP output really should superimpose over MD, the bitmap is currently stretched (wrong) in the screen_update_megplay (sic) in drivers/megaplay.cpp. Former also currently sends vblank irqs to the mtbios (sic) CPU at y=236, which is again wrong and way offset than 186. Regardless it should really derive its vblank irq callback from the master VDP by the magic of genlock instead.

[ghost]

the bitmap has to be stretched, lowest common denominator etc.

1280/320 = 4 1280/256 = 5

this is the only way it can be done cleanly as an overlay without having uneven stretching.

the relative positioning of the layers is confirmed with the stretching, that was a recent improvement (and a good one)

[angelosa]

Nope, it needs a special device that can handle superimposing instead. Something similar to how laserdisc_device works except applied to two different bitmap sources.

[ghost]

given that the way the laserdisc support handles things seems to have caused no end of problems (does it even work with bgfx yet?) I'm entirely unconvinced.

Furthermore, this is what the PCB outputs, this isn't something where there's a passthrough cable to mix 2 signals (eg how the Megadrive and 32X mix) it's all onboard.

I think one issue we are encountering here is the backwards way in which MAME handles timings again, where the screen device dictates them, rather than the screen device being given pulses for blanking and deriving the timing in realtime. The Megadrive code was initially written to do its own timings, only syncing to MAME's screen timings for drawing the bitmap, as at the time it was impossible to get MAME to match what people had researched using the screen device callbacks alone. Of course it was probably never correct anyway. The SMS stuff derives its timings in a different way.

Really the VDP should be a proper extension of the SMS VDP, and likely inherit a lot of the base timing stuff from there, however at the moment it really only uses the SMS stuff for when it's switched into SMS mode.

[angelosa]

PRESS START BUTTON in mp_sonic is offset with current handling compared to the original source, notice how the final N is misaligned wrt Sega wording just below.

[ghost]

well original source there is outputting bad data on the right hand side... so yeah there could be a few pixels offset, but you get that between layers of tilemap chips etc. anyway.

[MooglyGuy]

You're right about one thing, @DavidHaywood, which is that laserdisc_device shouldn't be used as a template for just about anything in MAME, screen mixing included. It's a pretty brutal hack, and is not applicable in this case in any event.

Also, laserdisc_device is dodgy mostly due to the fact that it's one of maybe about two things in MAME that actually makes use of YUV textures. Also-also, take a long hard look at the phrasing you used in slagging off MAME's laserdisc support, and ask yourself just how well you'd handle being on the receiving end of that. Given the fact that you lose your rag when @cuavas so much as asks you to adhere to reasonable standards, it makes you come off as a massive hypocrite.