Home » Wiki » MSX compatibility problems
MSX compatibility problems
This page was last modified 14:48, 26 May 2023 by Mars2000you. Based on work by NYYRIKKI and Friguron and others.

Contents

Introduction

MSX computers are compatible with more recent generations or between different makers of the same generation if programs are coded in strictly accordance to standard. Unfortunately this is not always the case.

Origin

The main reason why we see compatibility problems is that companies that produced software and games tried to program the MSX the way they were used to on the ZX-spectrum, C64, and other platforms of that time. The whole concept of a "Home computer standard" was a new thing to game coders, so they usually completely ignored the MSX standard definitions because in specific parts of the world there were only a few different MSX1 machines for sale. If the game worked on those few machines then they thought it was fine. It might have been that they were not even aware of the MSX2 or expansions like a disk drive etc... or those kind of things just sounded too niche to worry about from a business perspective.

Aackosoft's Paul van Aacken said about compatibility problems in 1986 "As all MSX software houses have discovered, staying within the rules is OK as long as you know what the rules are." He also told that "The intimate support which is usually provided to independent software developers by companies like Atari and Commodore when they release new machines was not forthcoming from the Japanese manufacturers. The twin barriers of distance and language were partially responsible, and another problem was the inexperience of the Japanese consumer electronics giants in dealing with independent companies in a way that was not necessary for televisions or HI-FI units." (Source: MSX Computing magazine April/May 1986)

Common problems

The most common reasons why games don't start are:

  • The programmers assumed that the RAM would be present in a given slot, and hardcoded it into the program
  • Bugs on subslot handling: the game doesn't support subslots or has a bug for subslots on a specific slot. This also applies to assuming that some resources could never be present in a specific slot (RAM in slot 0-x, for example).
  • Directly accessing I/O ports, as this isn't usually allowed by the standard, or by using hardcoded VDP I/O access. This causes problem on upgrades or allowed hardware variations, like the MSX2 upgrade cartridges. It also causes the program to fail to use alternative implementations of a given extension, like the RS-232 or the MSX-Music. It's a known cause of trouble for games that do direct I/O on the MemoryMapper ports, making them incompatible with MSX-DOS2. It may also cause problems when Atari compatible joysticks are used instead of MSX joysticks or cause hang / misbehaving when mouse is connected instead of joystick.
  • Directly jumping into the BIOS routines, instead of using the default jump-table interface.
  • Incorrect CALLs for the SubROM on MSX>=2 machines. It's difficult to call the SubROM from DOS, and programmers tried unofficial tricks that cause problems on many machines.
  • Assumption that the CPU would always be running at 3.57MHz. This causes problems on turbo machines, which run such games too fast.
  • Assumption that the amount of free memory from BASIC would always be a given amount (like 28815 or 24972 bytes). But floppy-equipped models had less free RAM. This is often solved by keeping the [CTRL] key pressed while booting the MSX. That way only 1 drive is initialized, which frees up some memory. If that is not enough (like the case with many cassette games) the whole disk drive needs to be disabled. This can be done by holding [SHIFT] key pressed while booting the MSX.
  • Ignoring MSX-DOS or MSX-Disk BIOS coding guidelines and assuming that only MSX-DOS1 would ever be possible. This causes many programs to freeze when run on MSX-DOS2


Fortunately, some of these problems are easy to fix, but it may require some knowledge of programming and MSX internals.

For a more in-depth analysis, check the Compatibility testing article.

First things to try

When trying to get a program to work, you should first try POKE-1,(15-PEEK(-1)\16)*17 before loading the program. If that does not work, see if there is already a POKE-1,XXX (where XXX is a hardcoded value) in the program loader and replace it with the POKE-1,(15-PEEK(-1)\16)*17 if found.

Note that this POKE will hang on those machines where RAM (8000-FFFFh) is located in slot 0-X (except for slot 0-0). For example machines using the DW64MX1 engine that have their RAM in slot 0-2. With RAM in a non-expanded slot, this POKE has no effect. If you encounter this POKE in a loader, also try removing it; some people used to add it to any loader regardless whether it was necessary or not.

If these tips don't help, then some more advanced debugging is necessary.

Below there is a collection of some known incompatibility problems with their fixes or workarounds. Please feel free to expand the list, if you have any good tips:

Examples

Auf Wiedersehen Monty

  • Version:
    Cassette
  • Problem description:
    This game does not work on machines that have slot 0 expanded.
  • Visual effect:
    Game hangs while loading.
  • Cause:
    RAM search routine does not switch BIOS back. (RAM support on slot 0 does not work anyway)
  • Workaround:
    (routine identical to Gauntlet)
    Patch game to skip RAM search on slot 0: search for string "3D 21 00 00 3C D3" and replace the first 3D by 00.
    You also need to fix XOR checksum byte, that is last byte of the block (=right before header) Original byte = 0C, so 0Ch XOR 3Dh XOR 0 = 31h)
    Note: The same problem for machines with RAM on expanded slot-0 applies for this fix, just like Gauntlet.


Bumpy

  • Version:
    Cassette tape by Loriciels
  • Problem description:
    This game does not work on many MSX.
  • Visual effect:
    Game hangs at presentation picture.
  • Cause:
    The Slot search routines are buggy.
  • Workaround:
    Modify the 3 next files.

    File "BUMPY2"

    Replace the block below at 0008H.

    DB A8 47 08 78 E6 30 47 DB A8 E6 F0 3D 21 00 00
    3C D3 A8 4F 7E 2F 77 BE 79 28 27 1E 00 79 0F 0F
    E6 C0 B0 D3 A8 3A FF FF 2F E6 F0 B3 32 FF FF 79
    D3 A8 7E 2F 77 BE 79 28 09 1C 7B FE 04 20 DE 79
    18 CE D6 04 21 00 40 C6 04 D3 A8 4F 7E 2F 77 BE
    79 28 2B 1E 00 79 0F 0F

    by

    3A 41 F3 E6 0C 0F 0F 47 3A 42 F3 E6 0C B0 47 3A
    FF FF 2F E6 F0 B0 32 76 FA 3A 41 F3 E6 03 47 3A
    42 F3 E6 03 07 07 B0 47 DB A8 E6 F0 B0 32 77 FA
    3A C1 FC E6 03 47 07 07 B0 47 DB A8 E6 F0 B0 32
    75 FA 3A C1 FC E6 0C 47 0F 0F B0 47 3A FF FF 2F
    E6 F0 B0 32 78 FA FB C9

    File "BUMPY3"

    0003H: 6E -> 74
    4773H: FB C9 00 -> 3A 78 FA 32 FF FF FB C9 00


    File "BUMBY4"

    4F13H: D3 A8 -> 00 00

    Also replace the BASIC loader by the following:

    10 CLEAR 50,&H83FE:COLOR8,1,1:SCREEN2
    20 BLOAD"BUMPY1",R:LINE(0,0)-(8,0):LINE(0,191)-(8,191)
    30 BLOAD"BUMPY2",R:BLOAD"BUMPY3",R:BLOAD"BUMPY4",R


Galaxian

  • Version:
    Cartridge or Cassette.
  • Problem description:
    This game does not work on machines that have the main RAM in an expanded slot. (E.g. MSX2+ and MSX turbo R)
  • Visual effect:
    The MSX freezes on empty screen or reboot in loop.
  • Cause:
    The SP register is define to 0000h at start. This causes a write to the address FFFFh (and change the secondary slot) when the instruction CALL or PUSH is executed.
  • Workaround A:
    Insert a expansion memory of 64kB or more in a free cartridge slot. (Do not use a slot expander.) This method does not work for MSX turbo R because this machine always selects its internal RAM.
  • Workaround B:
    Get galaxian.rom file (usually 8192 bytes long) and look into the .rom header initial bytes.The typical galaxian.rom dump file will show two dreaded LD SP, 0x0000 lines of code at the beginning of the file.This code interfers with the Secondary Slot Selector Register of mapped memory MSX models.To solve this writing to 0xFFFF memory address, the LD SP, 0x0000 line should be changed into LD SP, 0xFFFE.Apparently there are 2 instances of LD SP, 0x0000 at the beginning of this .rom dump, they appear at offset 0x0010 (16 dec) and offset 0x0044 (68 dec). Just changing these "31 00 00" byte sequences into "31 FE FF" (on both places), will turn galaxian.rom into a universally working dump .rom file for every MSX machine.
  • Note:
    The latest cartridges do not have this bug.

Gauntlet

  • Version:
    Cassette
  • Problem description:
    This game does not work on machines that have slot 0 expanded.
  • Visual effect:
    Game hangs when selecting player.
  • Cause:
    RAM search routine does not switch BIOS back. (RAM support on slot 0 does not work anyway)
  • Workaround:
    Patch game to skip RAM search on slot 0: Search for string "3D 21 00 00 3C D3" and replace the first 3D by 00 This code is two times on the tape.

    Note: The game will still not run on machines with RAM on slot 0, like the Victor HC-9x machines.


Highway Encounterer

  • Version:
    Cassette tape
  • Problem description:
    This game does not work on machines that have slot 0 expanded.
  • Visual effect:
    Program hangs to loading screen.
  • Cause:
    Vortex Software guys forgot to insert LD A,(0F933h) to address 95A2h on 3rd file on the tape.
  • Solution/Workaround:
    (Expect that BASIC is in slot 0)
    LOAD"CAS:
    45 POKE&H95A2,&HAF: POKE&HF95A3,&h26
    RUN


Miner Machine

  • Version:
    Cassette
  • Problem description:
    This program does not work on MSX2 and up.
  • Visual effect:
    Program does not start
  • Cause:
    Non standard BIOS entry point #0849 has been used to clear the screen to avoid Z-flag clearing


Rock'n Bolt

(by Activision, Pony Canyon)

  • Version:
    Cassette and ROM
  • Problem description:
    This game has some graphic problems on the other MSX other than MSX1.
  • Visual effect:
    The platforms are not displayed in the right place.
  • Cause:
    Unknown.
  • Solution/Workaround:


The Brain

  • Version:
    Cartridge
  • Problem description:
    This game exits to MSX-BASIC with the error "Type Mismatch in 21060" in brazilian and european MSX machines.
  • Visual effect:
    Error "Type Mismatch in 21060"
  • Cause:
    Due to differences in character tables between Japanese and International System ROMs, some control characters on PRINT USING instruction have been changed: In this case, control character "&" (used on control strings like "& &") has been changed by "\" on international machines, but has been assigned for string substitution, causing the instruction to expect more variables than has been provided.
  • Solution/Workaround:
    To play The Brain on a non-Japanese MSX we need change the following bytes.

    19AFh: 26 -> 5C
    19B4h: 26 -> 5C
    2296h: 26 -> 5C
    229Ah: 26 -> 5C

    For more information please refer to this thread: [1]

Zaxxon

(by Electric Software, port from the ColecoVision version)

  • Version:
    Cassette
  • Problem description:
    Doesn't work on MSX2 or newer
  • Visual effect:
    Doesn't scroll and sound loops
  • Cause:
    A VDP register mirror are used. This causes a writing on register 15 instead of 7 on MSX2 or newer, it changes the default status register value to read at each interrupt.
  • Solution/Workaround:

    Patch for CAS file:
    - replace "42 59 20 50 2E 48 2E" at 00AFh by "C6 80 E6 87 D3 99 C9"
    - replace "C4" at 09D6h by "C2"
    - replace "C6 80 D3 99" at 6C0Bh by "CD 24 80 00"
    - replace "C3 21 80" at 6CF4h by "C3 4F 89"

    You also can apply following patch to fix PSG I/O.
    - replace "D8" at 6E07h by "98"
    - replace "D8" at 6EE5h by "98"
    - replace "D2" at 6EEEh by "92"
    - replace "C7" at 6F01h by "87"

    (Press Shift at MSX's start-up until beep)
Retrieved from "https://www.msx.org/wiki/MSX_compatibility_problems"