@mars, that pic is no crash, it is a very fast machine
Ah, I'm reassured but I don't think such machine exists !
If the real MSX2+ shows the same, then we got a speed record.
If it has no VDP brake, then normal games might mess up, but special games can be written.
There are some interesting cases that deserve to be benchmarked:
1) MSX2 machines with/without MSX-Engines
Why? Because the S1985 is known to have a bug in it's /VDPCSR and /VDPCSW logic that causes glitches when running in turbo speeds. This is probably related to some badly designed speed constraints. Probably because it inherited the logic from the S3527 that was meant for the TMS9918
2) Victor HC-9x, in both turbo/non-turbo modes. This machine's setup even allows you to set the I/O wait states when running on turbo mode. It would also be important to test both the versions with the V9938 and V9958 VDP, since the last one is said to have the V9958 /WAIT circuitry.
3) CIEL ExpertTurbo/Expert3: This machine is the only other have have a functional V9958 /WAIT circuitry.
To me this sounds like it would be a good idea to always turn on that WAIT mode on 9958.
Or can that mode cause troubles?
To me this sounds like it would be a good idea to always turn on that WAIT mode on 9958.
Or can that mode cause troubles?
Yes, it can cause trouble to either enable or disable it by yourself. The WAIT bit must always be preserved when writing to the register R#25.
It's detailed in the compatibility testing wiki article.
The same rule applies to the bit0 of the R#9, and the bit 4 of R#25:
For the R#9-bit0:
- If the machine uses it in output mode and it's set to 1, the MSX will freeze
- If the machine uses it in input mode and the user program changes it to output, it can make the VDP loose sync with the external video.
For the R#25-bit4:
- Changing this bit to 1 will cause any non-turbo machine to freeze.
EDIT: corrected the frying issue. The signal is open-collector to avoid the problem.
does openmsx warn that like it does warn PSG?
any more such critical bits in the VDP?
Sorry, I had forgotten that the signal was open collector. The mentioned critical bits can't fry the VDP, but they can make the MSX machine freeze or malfunction.
If the benchmark tool hooks up on HTIMI, it's normal to have different numbers. What the BIOS ISR does first is to check on other interruptions BEFORE testing if it's a VDP one and routing to HTIMI.
I obtained similar numbers when checking exactly how long the ISR took before routing to HTIMI hook. I used BlueMSX and it's built-in clock counter (in the debugger interface). I wrote down the counter number at $38 and then its value when routing at HTIMI. I did that 5 or 6 times in a row, for each MSX generation.
There was great differences in the results within a same row of measurements. BUT there was always a low number, always the same, that came back several time. I took that number to be the exact measurement of the ISR routine, discarding the others, because they were probably generated by the handling of other interruptions before routing to HTIMI.
There are some interesting cases that deserve to be benchmarked:
3) CIEL ExpertTurbo/Expert3: This machine is the only other have have a functional V9958 /WAIT circuitry.
Tests made on openMSX with adding SONY HBD-F1 drive
Normal mode
test 1 : 122251 - test 2 : 79078 - test 3 : 7283 - test 4 : 25914 - test 5 : 18827 - test 6 : 9031 - test 7 : K
(results similar to MSX2 Japanese or MSX2+ Sony)
Turbo mode
test 1 : 244664 - test 2 : 158617 - test 3 : 14582 - test 4 : 51978 - test 5 : 37699 - test 6 : 18084 - test 7 : B
Results on Ciel 2+ Turbo FM:
At 3.58MHz:
At 7.16MHz: