openMSX bugs

Page 15/15
8 | 9 | 10 | 11 | 12 | 13 | 14 |

By gdx

Enlighted (5711)

gdx's picture

21-09-2022, 14:38

mcolom wrote:

Yes, at 8057 it call makes the call with BC=0000 (register 0, value 0). BUT then at 8727 it sets BC=0002 (register 0, value 2), changing the screen mode. And it does it all the time, during gameplay.

You are right. I must have misplaced the break point but I replaced BC=0000 by BC=0002. Graphic glitches were still there on my turbo R.

By mcolom

Champion (259)

mcolom's picture

21-09-2022, 21:11

The glitches are different after preventing the screen mode change, however.
Uhm, quite mysterious this thing Big smile

By mcolom

Champion (259)

mcolom's picture

22-09-2022, 10:03

I made a quick test: in the function at 84e8h I did a jp MIGUEL_CODE to execute in a different place the same code:
sub_84e8h:
jp MIGUEL_CODE
;ld a,c ;84e8
;out (099h),a ;84e9
;ld a,b ;84eb
;or 080h ;84ec
;out (099h),a ;84ee

This is the new code somewhere else:
MIGUEL_CODE: ; (6 bytes)
ld a,c
out (099h),a
ld a,b
or 080h
out (099h),a
jp 0x84f0

In short, it's a jump to execute the same code somewhere else (at 8006h, overwriting 6 zeros).
So, it does exactly the same, and the only difference is the jump, but slightly slower.

Result: now the emulator and the real machine show exactly the same graphical glitches.
Unfortunately I can't show both side by side because msx.pics is not working well at this moment :/

It's related to timing, but I don't know know how exactly.

Page 15/15
8 | 9 | 10 | 11 | 12 | 13 | 14 |