SCREEN initialisation issue for MSX1 screenmodes on MSX2, MSX2+ emulated devices

[NullPointerReference]

It seems changing from a MSX2 screenmode to a MSX1 screenmode - using the proper BIOS call #005F (CHGMOD) - results in the VRAM memory not getting 'wiped / reinitialised' correctly, leading to sprite/screen corruption in certain cases.

Below an example ROM 'The Untouchables' by Ocean Software. A well-known File-Hunter community member added a very nice SCREEN7 'introduction' screen (before the original main menu) when ran on a >= MSX2 machine that is shown instead of the original MSX1 introscreen (which is still shown on MSX1 machines).

After displaying the SCREEN 7 image it switches to SCREEN 2 using the BIOS and runs the game as usual. The ROM works fine (original code-path) on an emulated MSX1 machine, but on an emulated MSX2 machine, the 'main screen' has corrupted sprites in WebMSX.

This corruption doesn't occur with OpenMSX, BlueMSX or on original hardware.

Some digging:

• When swapping the MSX2 code path to run as SCREEN 4 instead of SCREEN 2 after the new SCREEN 7 introscreen --> no sprite/screen corruption; implying it only corrupts / affects MSX1 screen modes when running on a >= MSX2 emulated machine.
• When wiping the VRAM after changing to SCREEN 2 using a follow up BIOS call, the game looks fine as well; further implying the VRAM initialisation emulation might not be a 100%.

The 'fixed' SCREEN 2 + VRAM wipe code-path looks as follows: LD A,2 CALL 005FH ; CHGMOD --> SCREEN 2 XOR A LD HL,0000H LD BC,0FFFFH CALL 016BH ; BIGFIL --> MSX2 only, fill 64kB VRAM with 0s.

I've uploaded the 3 test-files (SCR2 with corruption, SCR4 without corruption, SCR2 + VRAM wipe without corruption) in a single .ZIP file here: https://bugreport.nl/downloads/webmsx_untouchables.zip