Bug in Zanac-EX on MSXturboR | MSX Resource Center (صفحة 2/4)

بواسطة Manuel

Ascended (19303)

06-01-2022, 08:12

max_iwamoto wrote:

Probably rare timing issue as screen rolls almost to the half of the screen before that happens.

What do you mean with 'rare'? It happens every other time the title screen scrolls in.

بواسطة gdx

Enlighted (6108)

06-01-2022, 09:29

Jipe wrote:

With a Turbo-R just push the PAUSE Key for same BUG

It's a shame this PAUSE isn't emulated.

بواسطة Takamichi

Hero (599)

06-01-2022, 10:22

I remember seeing these graphic patterns on FS-A1 when paused. My memory might be wrong but it's worth trying the other machines.

بواسطة ducasp

Paladin (677)

06-01-2022, 13:56

Does that happen when running in z80 mode or in R800 mode or both?

بواسطة max_iwamoto

Hero (628)

06-01-2022, 17:54

Manuel wrote:

max_iwamoto wrote:

Probably rare timing issue as screen rolls almost to the half of the screen before that happens.

What do you mean with 'rare'? It happens every other time the title screen scrolls in.

If it wasn't rare, it would happens as soon as screen rolls up. I think some condition randomly happens around middle of the roll. As we know, the game uses screen split during the game and maybe using same INT routine in the title screen but instead of switching between VRAM page 0 and 1 for the top menu, "switching" between VRAM page 0 and 0, so screen always displayed. So, at some point something happens and variable switching from 0 to 1..2 and game displaying other VRAM page.

بواسطة Manuel

Ascended (19303)

06-01-2022, 21:32

ducasp wrote:

Does that happen when running in z80 mode or in R800 mode or both?

I ran the cartridge just like that, there's no way to change to another mode. So it was Z80.

بواسطة Manuel

Ascended (19303)

06-01-2022, 21:36

gdx wrote:

Jipe wrote:

With a Turbo-R just push the PAUSE Key for same BUG

It's a shame this PAUSE isn't emulated.

No, it isn't, because it is emulated. And indeed, it shows some corruption during the game play as well, but it disappears when unpausing.

بواسطة ducasp

Paladin (677)

06-01-2022, 22:04

Manuel wrote:

ducasp wrote:

Does that happen when running in z80 mode or in R800 mode or both?

I ran the cartridge just like that, there's no way to change to another mode. So it was Z80.

My guess is that this is indeed a bug that perhaps is triggered by the interrupt routine of the game that handles this being called again before it has even returned or it is taking longer than expected and losing an precious interrupt to update the screen... For each new generation of MSX computers the BIOS interrupt routines started to take more and more time to return, thus, leaving less time for software routines that run after it to finish before a new interrupt comes in... That is a quite interesting stuff to check, now I'm curious to figure it out but have no time to debug into it... Is it possible to reproduce it on Open MSX Turbo R Machines?

بواسطة Arjan

Paladin (782)

06-01-2022, 23:11

I tested on openMSX, the glitch only appears on the GT but not on the ST.

On the GT, when KEYINT is called after pushing all the registers except iy/ix the BIOS jumps to another routine to check some midi stuff. If I replace that jump(+nop) with push iy/push ix (making it the same as the KEYINT routine on the ST), the glitch also doesn't appear on the GT.

بواسطة max_iwamoto

Hero (628)

06-01-2022, 23:27

I found where the issue is located. Address 4C2Ah. There we have LD A,3Fh / OUT (C),A / LD A,82h / OUT (C),A

The 1st 3F will set VRAM page 1. If you put a breakpoint there and change 3Fh to 1Fh intro scroll will finish good.

So, the interrupt subroutine should not get there in the intro. This is where it does screen split in the game. It happens only one time during the intro scroll.

So, my original idea was correct

---

The fix should be simple. Modify code in the area and check if game currently not in a gameplay mode and change 3Fh to 1Fh. If gameplay is going, leave 3Fh for the screen split.

---

Now we need to find out why it happens.