Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
I remember that a LOT of games for my MSX (I live in Brazil) don't work without some modification. For example, several need some kind of tweak on the loader, like poke -1,0.
I would like to know what are the causes that make those adjustments necessary: Some kind of hardware spec that don't follow the guidelines, or lack of knowledge on those guidelines by developers, or something else?
Seemingly there is an entire page dedicated to this (by the MSX wiki).
Most of the time, programmers programmed code like how they usually did with the Commodore 64 and ZX-Spectrum and completely ignored the standards made by MSX computers at the time due to the brand new concept of "home computer standard":
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 ZX-spectrum, C64, and other platforms of that time. The whole concept of "Home computer standard" was a new thing to game coders, so they usually completely ignored the MSX standard definitions because on 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 tough it was fine. It might have been that they were not even aware of MSX2, disk drive etc... or those kind of things just sounded like "not interesting abnormal peculiarity in business means"
There are lots of reasons why incompatibility finds its way(s) into MSX computers: assuming RAM would be present at a given slot, directly accessing I/O ports, bugs with subslot handling, ignoring MSX-DOS or MSX-Disk BIOS coding guidelines and assuming that only MSX-DOS1 would ever be possible, etc:
- The programmers assumed that the RAM would be present on 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 believing that some resources couldn't ever be present on a specific slot (ram on slot 0-x, for example).
- Directly accessing I/O ports, as this isn't allowed by the standard, or by doing 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 alternate implementations of a given extension, like the RS-232 or the MSX-Music. It's a known troublemaker for games that do direct I/O on the MemoryMapper ports, making them incompatible with MSX-DOS2. On some machines, it's known to cause problems with certain joysticks.
- 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 ever have 3.57MHz. This causes problems on turbo machines, which run such games too fast.
- Assumption that the amount of free memory on 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 holding [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
The famous poke -1,x depends on each computer's slot configuration. The general formula is poke -1,((peek(-1)xor&hff)and&hf0)*1.0625. This is copying the high nibble of the secondary slot selection register into the low nibble. And why is this necessary? Sit down and relax.
The original 1983 specification of the MSX system allowed for four memory slots, each divided in 4x16K pages. You can switch any page of any slot into the page with the same number (same addresses range) of the Z80, thus making the slot contents visible.
A MSX boots (let's ignore cartridge games and the disk system for now) in MSX-BASIC with the following slots configuration: BIOS ROM in page 0, BASIC interpreter in page 1, RAM in pages 2 and 3. Assuming a 64K RAM computer, a game that wants to use more RAM than the upper 32K must switch the RAM slot in page 0 and/or PAGE 1. The usual procedure for this (which works in almost all the machines) is: check the slot switched in page 3, then switch the same slot in page 0/1. And, hey, it worked.
Life was good for those cassette games but then the MSX2 standard appeared in 1985. Amongst other improvements, it introduced the concept of expanded slots. This means that one or more of the four primary slots can be expanded, meaning that the slot actually consists of four subslots. So in that case you no longer have e.g. slot 3, but slots 3-0, 3-1, 3-2, and 3-3.
How does that work? To switch a expanded slot, let's say 3-2 in page 1, you first switch primary slot 3 in page 3. Then you write a value in the secondary slot selection register for this slot, which is located at its address FFFFh. This register contains four two-bit fields, each indicating the secondary slot number that is visible at each page when the slot is switched to that page. Whoa. So in our case the value would be xxxx10xx (xx = the previous value).
So now let's say we are loading a game from a cassette tape in our shiny MSX2 computer. The game does the "let's check the page 3 slot and switch it in page 1" trick to get more RAM visible. But that does not work. Why?
MSX2 computers have usually slot 3 expanded, and RAM is in one of these subslots. Let's say it's in 3-2 in our case. So the game sees that slot 3 is on page 3, so it switches it on page 1... but what secondary slot is visible? Answer: we don't know, it could be anything! Chances are that it is not subslot 2 as we expect, so no RAM is actually visible and... booom.
The "magical poke" solves this by making sure that the values of the secondary slot selection register of the RAM slot for pages 0 and 1 are the same as for pages 2 and 3 (which are usually the same). You can poke directly from BASIC because the RAM slot is already visible in page 3 (-1 = &HFFFF in BASIC), then the non-expended-slots-aware game can happily switch just the primary slot, and tada! RAM is here happily waiting for us.
xor&hff is needed because the secondary slot selection register is actually read inverted.
– Konamiman
Apr 26 '16 at 11:54
