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.
The glitches are different after preventing the screen mode change, however.
Uhm, quite mysterious this thing
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.