Fatal Labyrinth problem with background

[Former user]

Original issue 333 created by [e-mail] on 2013-04-08T14:33:24.000Z:

What steps will reproduce the problem?
1. Start up Genesis Plus GX.
2. Load Fatal Labyrinth (JU) [!]
3. Use my save state.

What is the expected output? What do you see instead?

In the end of game after killing the dragon, background drawn only by half.

What version of the emulator are you using (official, SVN revision,...)?

Genesis Plus GX r764

Please provide any additional information below (Emulator settings, Console
setting,...)

[Former user]

Comment # 1 originally posted by ekeeke31 on 2013-04-08T20:47:19.000Z:

Well, that's weird, it's not really "drawn by half", it seems more like that the screen is drawn entirely but "moving" instead of scrolling/repeating behind like it should. This is probably a stupid mistake with the VDP rendering, I'm just curious that it was only noticed there, must be some edge case.

Can I have a save state just before the end sequence starts ?

[Former user]

Comment # 2 originally posted by [e-mail] on 2013-04-08T21:13:48.000Z:

Okay, i replay this game and send new save state before the end sequence. ;)

[Former user]

Comment # 3 originally posted by [e-mail] on 2013-04-08T23:40:33.000Z:

Here two save states. First - at death a final boss, and second before final fight.

[Former user]

Comment # 4 originally posted by ekeeke31 on 2013-04-09T11:01:23.000Z:

Thank you for finishing this game twice in a row, since it is not really that easy or enjoyable...

I will look at the savestates when i got the time for it but i can already say that it seems to be an error with the virtual screen size (background planes): it is setup to 512x512 pixels but the game seems to assume it is only 256x256 (or 256x512) so it scrolls incorrectly. I need to figure if this is an error when setting the screen dimension (missed VDP register write) or when filling the screen data (missed VRAM writes).

[Former user]

Comment # 5 originally posted by ekeeke31 on 2013-04-10T10:53:37.000Z:

More on that: before the end sequence starts, the game deliberately sets the virtual screen size to 512x256 then to 512x512, in the same function, but only 512x256 is filled with data, hence the scrolling issue.

The problem is not in my rendering code as far as i can tell but either that the screen size is incorrect or VRAM writes are missing. However, I could not figure what the right size should be from debugging the code and there is nothing odd with the code flow.

Would it be too much to ask for the same savestates but with Regen this time, so i could compare code flows ? Thanks in advance.

[Former user]

Comment # 7 originally posted by [e-mail] on 2013-04-10T17:16:29.000Z:

Ready, regen not have this bug.

I seen same problem in Kega Fusion few years ago, and think, it still there.

[Former user]

Comment # 8 originally posted by ekeeke31 on 2013-04-10T17:22:30.000Z:

Thank you.
But did you just finished the game in one hour ? Do you use cheat codes ?

[Former user]

Comment # 9 originally posted by [e-mail] on 2013-04-10T17:58:20.000Z:

No, i not use cheat codes. :)

I have blood sword, initially weapon has 0 hit points, if use scrolls which increase damage by 1 point, and weapon will be no longer cursed. All monsters dies just in few hits, even final boss have no chances.

[Former user]

Comment # 11 originally posted by ekeeke31 on 2013-04-10T19:40:10.000Z:

Ok, I was able to find what is wrong: the Regen savestate confirmed the virtual screen size was the same in both emus and that 512x512 pixels was correct: for the record, the game actually only fills the top of the screen using normal VRAM writes then uses VRAM Copy DMA to fill the rest (so that lower area is identical to upper area).

The problem is that the game uses an undocumented code to trigger the VRAM Copy operation (110001 instead of 110000), which Genesis Plus GX (and apparently Kega as well) interprets as an invalid code => no data is written to VRAM during DMA

Regen does not seem to check code validity when doing DMA Copy so has no issue with this game.

Now, can you confirm this does not happen on real hardware ? I can't seem to be able to find any video capture from real hardware for this game.

If it is supposed to display fine, it means that both code values 110001 or 110000 are both correct for VRAM Copy DMA operation. It would need to be checked to be sure, maybe there are subtile differences that can not be seen here.

[Former user]

Comment # 12 originally posted by [e-mail] on 2013-04-10T19:50:49.000Z:

On my real Mega Drive 2, end sequence was fine.

[Former user]

Comment # 13 originally posted by ekeeke31 on 2013-04-19T14:36:19.000Z:

OK, fixed in r768