Boulder Dash tape (.cas) on MSX2: 60 Hz switch?

Paragon (1934)

06-09-2020, 08:28

So I was trying to run Boulder Dash (♫) from tape (.cas) in the emulator.
The odd thing is, on when run on a PAL MSX2 system (8250) the game switches to 60 Hz. I tried various .cas images.

This seems some side-effect? I don't think it was purposely programmed to do that, probably MSX2 wasn't even around at the time of release/porting the game, + Orpheus hailing from the UK, game targeted for the European market.

E.g. the intro screen, the music, def. feels too fast. When running a dump from disk it stays at 50 Hz.

Someone who has any clue here? Is there more (tape/.cas) software that exhibits this behaviour? Could it be an emulation or .cas format flaw? (Tested openMSX, WMSX & blueMSX.) Thanks :)

- edit: tried the .tsx as well: same result.

!login ou Inscrivez-vous pour poster

Par gdx

Enlighted (6213)

06-09-2020, 11:09

To set the display to 50Hz, you must set bit 1 of register 9 to 0.
To write in a register on MSX1, only the bits 0-3 are used. Whatever the state of the other bits, we can only write in a register from 0 to 7. On MSX2, there are more registers so if we want to write in register 1 while bit 4 is at 1 then it will write in register 9.

The problem is there in my opinion.

Par AxelF

Champion (395)

06-09-2020, 14:45

I see whats happening,
The stack is writing all over the 'System Variables' aerea, and overwriting the backup values of VDP Registers. (0xffe7 and up)
By moving the stack to a saver place, the 'System Variables' will not be overwritten.

Use a HEX editor and change at Adress #19B4/19B5 the values FD FF in to 00 1C
or
Search for HEX combination FDFF2185C6229BFD and change the FDFF in to 001c

Par ren

Paragon (1934)

06-09-2020, 18:19

Thanks guys! So did they do a bit of a sloppy job here, or is this more of some unfortunate (schmelting) accident?

So the reason the dump on disk is not having the issue would either mean that it's based on some tape release that was bugfixed, or that it was fixed by the dumper... (right?)

Par Grauw

Ascended (10768)

06-09-2020, 18:19

This sounds not just like a sloppy job but something completely nonstandard. The stack has no business being above F380H (HIMEM). It’s surprising that it even continued to work with so little issues on MSX2 and up.

Par ren

Paragon (1934)

06-09-2020, 18:23

It wont run on 2+ in my tests (Neither does that disk dump btw..)

Par [WYZ]

Champion (451)

06-09-2020, 20:47

Quote:

So I was trying to run Boulder Dash (♫) from tape (.cas) in the emulator.

This is the original OST ;)

Par ren

Paragon (1934)

06-09-2020, 23:10

Yeah, that was some promo for the (excellent) WYZ arrange

Quote:

This is the original OST

So that's at NTSC speed, way too fast, and game is not supposed to run that way
For 'original' I would refer to the Atari 8-bit (NTSC) tune, the platform BD was originally released for. (NTSC since the developer/composer was/is a Canadian, publisher from NYC.)

Real Atari 800 XL (PAL apparently): https://youtu.be/oMIqMU7oI_g
(longer running PAL intro music @ https://youtu.be/flws-YkoVcg)

Atari 8-bit 60 Hz emulated: https://youtu.be/rp6DH9BSVGg

So it seems, tempo wise, the MSX PAL theme sits somewhere between the original PAL & NTSC versions.

Par gdx

Enlighted (6213)

07-09-2020, 09:53

I found 3 versions converted to ROM.

0EDEh: FDFF2185C6229BFD -> Works on MSX2 but at 60Hz, Not work on MSX2+/Turbo R
061Bh: 00882185C6229BFD -> Works (FDFF is replaced by 0088)
0EDEh: 89FD2185C6229BFD -> Works (FDFF is replaced by 89FD)

Par Metalion

Paragon (1625)

07-09-2020, 17:06

Grauw wrote:

While that's completely true, there's an vast area (1700+ bytes from $F3FC to $FAF6) used only by the BASIC interpreter that is free to use by any program that does not need BASIC. Whatever the program, the stack will never reach such a enormous size, so in my opinion, it can be located there if needed.

Par gdx

Enlighted (6213)

08-09-2020, 02:17

Metalion wrote:

While that's completely true, there's an vast area (1700+ bytes from $F3FC to $FAF6) used only by the BASIC interpreter that is free to use by any program that does not need BASIC.

Not everything in this area is necessarily used by Basic only. Some Math and Bios routines use this aera. The F419h-F662h or F6BEh-F7C4h areas are more safe to use and should suffice in a lot of cases.