#310 MSX Turbo-R secondary bus seems to be hardcoded at 3.57MHz

[SD Snatcher]

While the R800 is being used, the secondary bus of the MSX Turbo-R seems to be hardcoded at 3.57MHz, instead of being at the same speed as the Z80A (defined by set Z80_freq and z80_freq_lock commands).

But when the Z80A is being used, the secondary bus is running correctly at the same clock the Z80A is. The front side bus of the MSX Turbo-R also seems to be running correctly at the same speed as the R800.

The secondary bus of the MSX Turbo-R is the bus that contains the MSX-Engine, the ROMs, the VDP, the YM2413 and the slots.

The front side bus of the MSX Turbo-R contains only the R800 and the system memory.

[Manuel Bilderbeek]

Hi,

Thanks for your report. Can you provide a test case, so that it becomes clearer what you mean, and so that we can also test if any kind of fix has actually solved the problem?

In other words: how can we test this?

[SD Snatcher]

Hi Manuel!

> Thanks for your report.

Its my favorite emulator, so I'm glad contribute to improve it. :)

>Can you provide a test case?

No problem. Proceed as follows:

1) Apply all IPS patches of the SalamanderFixes.zip file (get it at http://frs.badcoffee.info ) to a Salamander ROM. This will be your SalamanderTurboFix_R800.rom
2) Open the resulting file in an HexEditor. Change the byte at 19F6Bh from 82h to 80h.
3) Save it as SalamanderTurboFix_Z80.rom

Now you just have to measure how much time it takes to the game to show a complete autoplay session. The "autoplay session" is that one that follows the presentation intro, where the game autoplays to show how it's done.

I n my tests I got the following results:

1) Real FS-A1ST in Z80 mode: 3m11s02
2) Real FS-A1ST in R800 mode (TRLOAD): 1m51s84
3) Real FS-A1ST in R800 mode (MegaRAM): 2m18s90
4) OpenMSX FS-A1ST in Z80 mode: 3m09s63
5) OpenMSX FS-A1ST in R800 mode (-carta, Z80_freq at 3,57MHz): 2m12s50
6) OpenMSX FS-A1ST in R800 mode (-carta, Z80_freq at 15MHz): 2m12s50
7) OpenMSX FS-A1ST in Z80 mode (-carta, Z80_freq at 15MHz): 1m28s20

On a real MSX Turbo-R, the S1990 keeps the two buses of the machine in sync. The Z80 is on the secondary BUS, which mean they have the same clock. If you overclock the Z80, the entire secondary BUS (including the external slots) must be overclocked too. As a result, the scenario (6) must be faster than the scenario (5).

Just as a curiosity: Do you have a newer version of the OpenMSX debugger? It has passed quite some time since that version I have. And the debugger is so good that it's my primary debugger now. I would like to know if there were any improvements on it, or even a Mac version.

[Wouter Vermaelen]

Hi FRS,

Sorry for taking so long to look into this bug.

In openMSX we don't emulate busses, the CPU's directly talk to the peripherals. Also in openMSX the Z80 and R800 timing is completely independent. So your observations are correct. If you use the R800 and overclock the Z80, it will have no effect at all. If you use R800 and overclock the R800, the communication with peripherals will go faster, even if those periperals are in a real machine located on a 'Z80-speed-clocked-bus'.

So you are correct that openMSX behaves not the same as real hardware in case of overclocking. But that's OK, openMSX is not intended to be a (very) low level hardware emulator. The timing model is only intended to be correct in the normal (= not overclocked) case. Or in other words, the z80/r800 freq settings are only provided as an emulator feature (to reduce wait times for a compilation cycle for example or to make an old game run more fluently). It's not intended to accurately reflect how the real hardware would behave in case of overclocking.

If you find a case where the timing is not correct with the default z80/r800 freq settings, then please file a different bug report.