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

[NullPointerReference]

Possible fix; as deployed on download.file-hunter.com:

File: /src/main/msx/video/VDP.js; function updateMode(forceRenderMetrics) starting on line 770.
The 'fix' is the new line 801: vram.fill(0, 6912, 7424); it should probably use a base-table for the hardcoded values instead; but I could not get find the correct one(s) locally in the file easily (and was too lazy to extract it from the registers). Might not be pretty, but it is effective, tested with the files in the ZIP and a few random other games.

770    function updateMode(forceRenderMetrics) {
...
798        updateVRAMInterleaving();
799        updateLineActiveType();
800        updateRenderMetrics(forceRenderMetrics);
801        if (!forceRenderMetrics) vram.fill(0, 6912, 7424);

[ppeccin]

Hi! Thanks for the report. Does the VDP really clears VRAM itself on mode change just by register access? Is this on the hardware specs? Isn't this a responsibility of the BIOS or software handling the VDP? What happens in those cases where software changes modes during the active raster, like using the line interrupt? I always thought that mode changes did not alter VRAM contents, only by software (games, BIOS, etc). We have to make sure of this. Otherwise it will break a ton of other scenarios. Paulo

…

On Tue, Jun 4, 2024 at 5:48 PM JOM ***@***.***> wrote: Possible fix; as deployed on download.file-hunter.com: File: /src/main/msx/video/VDP.js; function updateMode(forceRenderMetrics) starting on line 770. The 'fix' is the new line 801: vram.fill(0, 6912, 7424); it should probably use a base-table for the hardcoded values instead; but I could not get find the correct one locally in the file easily (and was too lazy to extract it from the registers). Might not be pretty, but it is effective, test with the files in the ZIP and a few random other games. 770 function updateMode(forceRenderMetrics) { ... 798 updateVRAMInterleaving(); 799 updateLineActiveType(); 800 updateRenderMetrics(forceRenderMetrics); 801 if (!forceRenderMetrics) vram.fill(0, 6912, 7424); — Reply to this email directly, view it on GitHub <#105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOLIAZHR5BPLWJO3MLJJ3ZFYR27AVCNFSM6AAAAABILVDWC6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGM4TCNRQGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[NullPointerReference]

I agree, one shouldn't need to wipe the memory like the workaround, perhaps only re-initialising the VDP registers related to the base addresses of sprite data (color, pattern) ? I couldn't / cant really pinpoint the cause (yet), but real hw and other emulators don't have the issue. It doesn't seem to be related to the order of (sub-functions of) the screen-init routines in webmsx.

I.e. needs more research.

[NullPointerReference]

I did a bit more digging and the sprite corruption in WebMSX (which doesn't happen on a real machine; a Philips 8250 in my case) when it switches from SCREEN 7 to SCREEN 2 (after a color-palette fade). As stated in the opening post; when using SCREEN 4 instead of 2 after using SCREEN 7; it also doesn't corrupt in WebMSX.

I digged a bit in https://github.com/ppeccin/WebMSX/blob/master/src/main/msx/video/VDP.js and indeed; if I use function renderLineModeG3 for SCREEN 2 instead of renderLineModeG2 (by hacking this line), there is no corruption.

Given both render functions are the same with the exception of calling "renderSpritesLineMode1(realLine, 0)" (G2) vs " renderSpritesLineMode2(realLine, 0, colorPaletteReal)" (G3) this hopefully pinpoints the issue a bit. Besides the sprAttrTBase and spriteMode being different between SCR2 and SCR4, the are mostly the same config-wise too. It's no fix, but it might help a bit...

PS: The game seems to work just fine using the G3 render-method on both a MSX1 and a MSX2 emulated machine.
Tested with the SCR2 version from the ZIP file I mentioned in a post above.