Crazy "mapper bug" on Laser Squad (cassette version)

By Louthrax

Prophet (2274)

Louthrax's picture

10-06-2016, 02:06

So I was trying this evening to fix a strange bug in Laser Squad : the game does not work correctly if you insert a RAM expansion in your MSX (game crashes after you select the map).

I first suspected the usual problems (RAM detection error, subslot issue, etc...). Checked the code, debugged on openMSX, everything seemed OK.

After several hours of head scratching and tests, I noticed that the game was working if the RAM expansion has no mapper ("WTF, that's an MSX 1 game !"). I then searched the game code and found those lines:

	inc	d
	ex	af,af'
	dec	d
	ld	a,00FH
	out	(0FEH),a
	ld	hl,0B114H
	push	hl
	jp	L4330

So the game is writing 15 to memory mapper port 0FEH! I checked the Spectrum version, the code is identical here.

Wondering what that was intended for? Maybe a debug port on Spectrum (or this port has a specific function), and the developpers forgot to remove this code for the MSX version ?

Anyway, just wanted to let you know of that (might be interesting to check for people doing Spectrum ports).

Login or register to post comments

By Louthrax

Prophet (2274)

Louthrax's picture

10-06-2016, 02:26

Looks like I've found something:

Port 0xfe

Every even I/O address will address the ULA, but to avoid problems with other I/O devices only Port 0xfe should be used. 
If this port is written to, bits have the following meaning:


            Bit   7   6   5   4   3   2   1   0
                +-------------------------------+
                |   |   |   | E | M |   Border  |
                +-------------------------------+

The lowest three bits specify the border colour; a zero in bit 3 activates the MIC
output, whilst a one in bit 4 activates the EAR output and the internal speaker.
However, the EAR and MIC sockets are connected only by resistors, so
activating one activates the other; the EAR is generally used for output
as it produces a louder sound. The upper two bits are unused.

I guess the code above was setting the background color to white when the game start loading.

By ARTRAG

Enlighted (6361)

ARTRAG's picture

10-06-2016, 08:46

Interesting. Maybe there's some other residual code from the spectrum version and it could be worth to look for all in/out opcodes and see what ports are used.
I would examine also the "AI code" in the additional levels, as,if I understand, maps from the expansion pack are taken directly from the speccy.
Spectrum has also ram based i/o for the video. It could be interesting to see if coders did an accurate port or they missed something. It wouldn't be a surprise to find that they worked in rush quick and dirty.

By ARTRAG

Enlighted (6361)

ARTRAG's picture

10-06-2016, 08:42

From here

Quote:

When the ULA is drawing the screen, it needs to access video memory; the RAM cannot be read by two devices (the ULA and the processor) at once, and the ULA is given higher priority (as the electron beam cannot be interrupted), so programs which run in the contended memory (from 0x4000 to 0x7fff) or try to read from Port 0xfe (when the ULA must supply the result) will be slowed if the ULA is reading the screen. Note this effect occurs only when the actual screen is being drawn; when the border is being drawn, the ULA supplies the result and no delays occur.

the ULA ram seems mapped in 0x4000 to 0x7fff

By msxski

Resident (54)

msxski's picture

10-06-2016, 14:24

Very interesting!

By Louthrax

Prophet (2274)

Louthrax's picture

10-06-2016, 19:41

ARTRAG wrote:

Interesting. Maybe there's some other residual code from the spectrum version and it could be worth to look for all in/out opcodes and see what ports are used.
I would examine also the "AI code" in the additional levels, as,if I understand, maps from the expansion pack are taken directly from the speccy.
Spectrum has also ram based i/o for the video. It could be interesting to see if coders did an accurate port or they missed something. It wouldn't be a surprise to find that they worked in rush quick and dirty.

Hi Artrag,

Thanks for the info, I checked the level files and they have no mapper-related code sequences.

Will reply to your "MSX 2 tile emulation" idea later, had no time at all today (but I really like the blackbox idea !).

By RetroTechie

Paragon (1563)

RetroTechie's picture

10-06-2016, 20:03

ARTRAG wrote:

It wouldn't be a surprise to find that they worked in rush quick and dirty.

For ZX Spectrum -> MSX, there exist many sloppy coded ports. Especially for el cheapo tape games that weren't popular enough (read: profitable) to throw much programmer time at. Or in a rush to get ZX game to market on MSX too? The other way around too (MSX -> ZX), but not as much.

So a programmer forgetting to remove a few ZX-specific instructions: no surprise. But kudos for pinpointing the problem here! Smile2

By Louthrax

Prophet (2274)

Louthrax's picture

10-06-2016, 22:06

Glad I had a quick look at the Spectrum world thanks to this bug: just discovered a lot of RAM is unused between 00000H-05AFFH (even on the MSX version). That might be usefull Smile