Fatal Labyrinth problem with background

[GoogleCodeExporter]

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,...)

Original issue reported on code.google.com by Metal.So...@yandex.ru on 8 Apr 2013 at 2:33

Attachments:

• 20-11-54(08,04,13).jpg
• save.zip

[GoogleCodeExporter]

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 ?

Original comment by ekeeke31@gmail.com on 8 Apr 2013 at 8:47

• Changed state: Accepted
• Added labels: Type-Defect, Priority-Medium, VDPEmulation

[GoogleCodeExporter]

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

Original comment by Metal.So...@yandex.ru on 8 Apr 2013 at 9:13

[GoogleCodeExporter]

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

Original comment by Metal.So...@yandex.ru on 8 Apr 2013 at 11:40

Attachments:

• save.zip

[GoogleCodeExporter]

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).

Original comment by ekeeke31@gmail.com on 9 Apr 2013 at 11:01

• Changed state: Started

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 10 Apr 2013 at 10:53

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ready, regen not have this bug. 

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

Original comment by Metal.So...@yandex.ru on 10 Apr 2013 at 5:16

Attachments:

• saves.zip

[GoogleCodeExporter]

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

Original comment by ekeeke31@gmail.com on 10 Apr 2013 at 5:22

[GoogleCodeExporter]

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.

Original comment by Metal.So...@yandex.ru on 10 Apr 2013 at 5:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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.

Original comment by ekeeke31@gmail.com on 10 Apr 2013 at 7:40

[GoogleCodeExporter]

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

Original comment by Metal.So...@yandex.ru on 10 Apr 2013 at 7:50

[GoogleCodeExporter]

OK, fixed in r768

Original comment by ekeeke31@gmail.com on 19 Apr 2013 at 2:36

• Changed state: Verified