Hunchback VRAM write issue

[NullPointerReference]

I noticed that the MSX1 Hunchback didn't want to run properly on WebMSX, whilst it worked properly in BlueMSX and OpenMSX.
Tested this with WebMSX emulating MSX1, 2, 2+ in 50Hz and 60Hz configs, all had the same result.
After some troubleshooting I noticed it used the following pattern (3 times in total in the game):

       LD      BC,8098H
L3732: OUTI    
       NOP     
       JR      NZ, L3732

This doesn't result in a 'too_fast_vram_access' warning in OpenMSX btw and works on the real hardware as well it seems (at least the 3 machines + FPGA based one I tested it on); but as mentioned it corrupts the screen in WebMSX; pressing the spacebar still starts the game, but the screen never updates anymore. Replacing the OUTI, NOP with a simple OTIR fixed the WebMSX issue and the game ran just fine afterwards.

The 'original ROM' failing on WebMSX (these are file-hunter.com urls, but I tested on webmsx.org too; same result):
DOWNLOAD: https://download.file-hunter.com/Games/MSX1/ROM/Hunchback%20-%20Ocean%20(1984)%20[4408].zip
DEMO: https://download.file-hunter.com/assets/webmsx.html?url=https%3A%2F%2Fdownload.file-hunter.com%2FGames%2FMSX1%2FROM%2FHunchback%2520-%2520Ocean%2520(1984)%2520%5B4408%5D.zip

The 'OTIR patched ROM' working on WebMSX:
DOWNLOAD: https://download.file-hunter.com/Games/MSX1/ROM/Hunchback%20-%20Ocean%20(1984)%20%5BWebMSX%20%2B%20PSG%20fix%5D.zip
DEMO: https://download.file-hunter.com/assets/webmsx.html?url=https://download.file-hunter.com/Games/MSX1/ROM/Hunchback%20-%20Ocean%20(1984)%20%5BWebMSX%20%2B%20PSG%20fix%5D.zip

Perhaps the timing emulation is very very slightly off ?

[ppeccin]

Hey!

Very strange... Do you know WHY the screen stops being updated?

[NullPointerReference]

No, I can - currently - only describe the behaviour - it seems like WebMSX is not doing any screen-updates anymore (aka not properly listening to VRAM writes anymore); whilst the game is still running 'in the background'; you can hear the sound effects playing and the game is responding to user-input (as can be confirmed by the sound effect when jumping for example). When you die or it's game over there is a very brief 'flash' (single-frame ?) of a black screen, before the ('same') frozen screen returns; you never get any other screen content (menu, demo, game over text) anymore. So it does seem to respond to certain VDP commands (like perhaps a clear screen, or screen mode set command, but not to VRAM write anymore).

It happens with all emulated machines types (MSX1,2,2+,TurboR; EU,JP and USA) and all 'Quick Option' settings (i.e. changing CPU, VDP speeds; unlimited sprites or not, etc.); there is no change in behaviour between any of these settings/machines.

[NullPointerReference]

So I think I figured it mostly out; I initially traced the issue to: function checkVRAMPointerWrap in VDP.js

Whenever the pointer wraps for Hunchback, it turns out "modeData" is "NUL" within the checkVRAMPointerWrap function, not "G2" (yet):

{ name: "NUL", isV9938: true, layTBase: 0, colorTBase: 0, patTBase: 0, sprAttrTBase: 0, width: 256, layLineBytes: 0, evenPageMask: ~0, blinkPageMask: ~0, renderLine: renderLineBlanked, renderLinePatInfo: renderLineBlanked, ppb: 0, spriteMode: 0, tiled: false, vramInter: null, bdPaletted: true, textCols: 0 }

This caused the function to misbehave (G2 is NOT a V9938 screen mode). This let me to believe the real root cause is that after certain VDP registers are written in function "registerWrite(reg, val)" the function "updateMode()" is not called in ALL required cases; aka some 'missing updateMode() calls' in that function. But calling updateMode() unconditionally after each register write still didn't fix the issue; so perhaps the function updateMode needs tweaking ???

Either way I made a code-fix that fixes the Hunchback and seems rather simple, but it works and doesn't seem to break anything else; changing the definition of the "NUL" modeData on line 2449 from:

{ name: "NUL", isV9938: true, layTBase: [...]

to:

{ name: "NUL", isV9938: false, layTBase: [...]

It might not be a very good structural fix to address other potential 'mixed screen modes' - if that is even the case here, but hopefully this helps narrowing it down a lot.

EDIT: This is also related to #41