Possible to "force" a game to run in MSX mode instead of MSX2?

Pagina 2/2
1 |

Van tfh

Paragon (1836)

afbeelding van tfh

05-11-2019, 16:01

Meits wrote:
Parn wrote:
Meits wrote:

Two might be the speed. At least in Basic the MSX1 is faster than any MSX after it (be it in z80/3.5MHz mode). How this translates to machine language, I don't know. Just a little while ago I ran Maze of Gallious on both a turbo R (in z80 mode) and a Philips MSX2. Booted both at the exact same time. After an hour they ran significantly out of sync with each other. And I mean really... I'd have to recheck it, but it was way more than half a minute.

Well, I would expect them to run out of sync since the Philips machine is 50Hz while the turboR is 60Hz by default. Unless your Philips has some kind of mod.

Both ran at 60Hz. If I kept the Philips at 50Hz the deviation would be way bigger after an hour.
It intrigues me enough to want to do a marathon videocapture of the computers I have here showing the same software on the same frequency/clock speed/processor mode.

I don't know how stable the frequency from a crystal is after 30+ years, and I can imagine that even temperature can have some influence.

Van Grauw

Ascended (8507)

afbeelding van Grauw

05-11-2019, 19:37

Indeed, no two crystals run at exactly the same speed. This is why demo effects which rely on the precise synchronisation between the CPU and VDP don't work in machines where they are clocked by different crystals. A 1% clock crystal speed deviation is not beyond what I would expect.

That is not to say that there could not be other reasons for the speed variation, after all the MSX2, MSX2+ and MSX turboR BIOS and ISR are all slightly slower than their predecessors, and MSX2+ and turboR computers also have a 1 or 2 extra wait cycles when accessing the VDP.

But for a vsynced game that should only result in an extra dropped frame when the game code is taking near exactly as long as a frame so it would be pushed just over the edge, not a common occurrence. It could play a role, but clock variation alone already can explain it. If you want to prove that slower BIOS plays a role it would be better to count frames (e.g. in an emulator).

Van NYYRIKKI

Enlighted (5396)

afbeelding van NYYRIKKI

07-11-2019, 03:04

Meits wrote:

I used the palette info overlay using an MSX1 and an MSX2. There were no RGB deviations.

I should ofcourse checked the way you did, but I did not think of that. Neither did I expect that the palette info overlay would therefore deviate from what's shown on the actual MSX screen. Cuz if they're the same in the overlay but different on the MSX screen one of them is wrong and you just showed which... And that's the one I used to check.
Maybe something the openMSX guys could take a look at :)

This overlay just dumps the values from MSX palette registers. Since there are no such on MSX1 all of the returned values are just irrelevant. I don't think this can be really fixed as if there would be some approximation on 3bits those values would not represent real situation anyway. I would say this is just wrong use case for the overlay.

Van Parn

Champion (424)

afbeelding van Parn

07-11-2019, 03:25

Grauw wrote:

But for a vsynced game that should only result in an extra dropped frame when the game code is taking near exactly as long as a frame so it would be pushed just over the edge, not a common occurrence. It could play a role, but clock variation alone already can explain it. If you want to prove that slower BIOS plays a role it would be better to count frames (e.g. in an emulator).

It is known that turboR is actually slower when using the VDP (for example, among other things), but I find it really surprising to hear MSX2 and turboR were significantly out of sync when running a vsynced MSX1 game such as Maze of Galious. I wouldn't expect that at all unless there were some other factors at play, like cartridge emulation. For example, bank switching is noticeably slower in games originally made with 8kB banks converted to run in 16kB mappers.

I'm really not discounting @Meits' experience with the subject. I'm just truly curious about where the discrepance is coming from.

Van Meits

Scribe (5635)

afbeelding van Meits

07-11-2019, 19:55

It was a bit less than I claimed before. It turned out MoG displays the autoplay sequences in the same order, but did not start at the same place. However, there's still a significant difference.

I have no clue why the Konami logo screen looks off on the MSX2.

Edit:
Now that I review the video I see the sequences are still not in the same order (tsk tsk), but somehow it seems those random scenes are being displayed for the same duration. If not, this is not a valid comparison :RNFF:

Van Parn

Champion (424)

afbeelding van Parn

09-11-2019, 17:28

This was absolutely fascinating to watch; thank you for taking the time to make the video, @Meits. You can tell right at the beginning that the turboR is slower, and weirder still, at the second time each demo runs, some random stuff happens and the demo ends differently in the turboR (in the first demo, Popolon is hit by a bullet coming from the monster below; in the second demo a bat hits Popolon). Are you using a real cartridge in both computers?

Van Meits

Scribe (5635)

afbeelding van Meits

10-11-2019, 14:59

I flashed it to an MFR Wink

Van Manuel

Ascended (15804)

afbeelding van Manuel

10-11-2019, 17:13

As said before, no single crystal is the same as another, so there are always slight timing differences anyway. And in this case, the BIOS routine differences may definitely also play a role. And all these timing differences may also lead to different random number generation, so different behaviour for the enemies, even in the demo.

Pagina 2/2
1 |