ホーム » 掲示板 » MSX Talk » Hardware » MSX1 benchmark & speed differences

MSX1 benchmark & speed differences

ページ 1/2
| 2

By Takamichi

Hero (651)

Takamichi さんの画像

13-11-2022, 16:17

The PC magazine Technoopolis 1984-04 page 25-27 article benchmarked early MSX1s and their rival computers by executing BASIC instructions then measuring the TIME function. The result, more is better in page 26 while less is better in page 27 Table 3, shows substantial difference between MSX1s. Overall Hitachi MB-H1 is faster than average while Victor HC-6 and Yamaha YIS-508 are slower. The article attributes the reason to MB-H1 having isolated PSU that contributed to cooler running environment and HC-6/YIS-508 having a synthesizer interface. Also General PCT-50 runs FOR-NEXT loop more than 1% faster than the others.
FM-X's extreme "19 seconds" in page 27 must be a typo because nearby text describes FM-X belongs to "59 seconds group". Besides MSX, M5jr shows excellent performance with its integer BASIC.

This reminded me of Hardware differences in Dragon Slayer IV speedruns. 1) Do these speed differences ever impair MSX compatibility/performance? 2) What is the likely cause? 3) Can it happen the TIME function is behaving differently instead of the other part of MSX? 4) Are the differences reflected to the emulation? if no is it sensical to implement them?

ログイン/登録して投稿

By Manuel

Ascended (19685)

Manuel さんの画像

13-11-2022, 21:33

I think the root cause is different implementations of the BIOS and more specifically the interrupt routine.
The TIME function should work on the interrupt and would thus be the same (unless the interrupt frequency is different between the machines).
If I'm right about the root cause (see first line), this is reflected in all emulators that fully execute the ROM code and are otherwise accurate.

By ducasp

Paladin (712)

ducasp さんの画像

14-11-2022, 00:41

Manuel wrote:

I think the root cause is different implementations of the BIOS and more specifically the interrupt routine.
The TIME function should work on the interrupt and would thus be the same (unless the interrupt frequency is different between the machines).
If I'm right about the root cause (see first line), this is reflected in all emulators that fully execute the ROM code and are otherwise accurate.

Surely BIOS if considering all machines were 60 or 50 Hz, the more hardware you have, the more routines you might have hooked to the interrupt, lowering the total cpu time between interrupts available for programs. That is the same reason why MSX2 might be a tad slower on certain configurations than others, because a time consuming routine for keyboard runs more often on certain versions than in others and (if my memory serves me well) and more often than in msx1 machines. Heat should be a non issue, those cpus don't throttle, so either they fail or they are within specs and working as far as I know

By Gradius2

Hero (657)

Gradius2 さんの画像

17-11-2022, 07:36

It would be cool to have a benchmark tool for MSX, just for fun.

By Takamichi

Hero (651)

Takamichi さんの画像

17-11-2022, 11:26

openMSX did not show any speed difference between Hitachi MB-H1 that indicated fast result with the Technopolis's benchmark tests and Yamaha YIS-503 that was slow.

I ran three benchmarks on Technopolis 1. Calculating prime numbers within 30 minutes (I added XA# and B# to line 70 PRINT):

10 K=0:ON INTERVAL=3600 GOSUB 70:INTERVAL ON
20 XA#=1:B#=3
30 IF (XA#/B#-INT(XA#/B#))*B#=0 THEN XA#=XA#+2:B#=3:GOTO 30
40 IF B#>XA#^.5 THEN GOTO 60
50 B#=B#+2:GOTO 30
60 XB#=XA#:XA#=XA#+2:B#=3:GOTO 30
70 K=K+1:IF K=30 THEN PRINT XB#;XA#;B#:BEEP:END ELSE RETURN

2. FOR-NEXT loop:

10 TIME=0
20 FOR I=0 TO 30000
30 NEXT I
40 PRINT TIME

3. READ DATA:

50 TIME=0
60 FOR J=0 TO 30000
70 READ A
80 RESTORE 200
90 NEXT J
100 PRINT TIME
110 END
200 DATA 3

I ran these codes by writing each in a text file, threw it into openMSX which autotyped it, then RUN. The results were as follows. Figures after prime are XB#/XA#/B#. Figure after fornext and read are the 1/60 sec counts.
openMSX MB-H1 and YIS-503:

prime	2357	2369	17
fornext	3540	=	59 sec 00
read	9431	=	2 min 37 sec 11

Both the prime and fornext results are those of "average" MSXs on Technopolis. However the read result is more than 8 sec faster than any MSX there. For comparison other emulations were;
openMSX FS-A1WSX MSX2+ disk enabled (normal boot):

prime	2251	2267	37
fornext	3770	=	62 sec 50
read	10045	=	2 min 47 sec 25

openMSX FS-A1WSX MSX2+ disk disabled (SHIFT key boot):

prime	2339	2341	45
fornext	3589	=	59 sec 49
read	9562	=	2 min 39 sec 22

webMSX MSX1 Europe disk disabled:

prime	2647	2657	23
fornext	3037	=	50 sec 37
read	8090	=	2 min 14 min 50

webMSX MSX2+ America disk enabled:

prime	2251	2267	37
fornext	3826	=	63 sec 46
read	10046	=	2 min 47 sec 26

webMSX MSX2+ America disk disabled:

prime	2339	2341	45
fornext	3588	=	59 sec 48
read	9566	=	2 min 39 sec 26

It looks having a disk drive significantly refuses the speed.
Could the MSX1 differences on Technopolis had been caused by wiring length/material? Light speed differs between different substances and that is why high end HDMI cables use silver wires. PCT-50 must be directly wired in many places, eg MSX-TV connection, where a detachable cable does with other MSXs which I guess as the reason of fastness.

Is there anyone willing to run these benchmarks on your own MSX and post the result?

By Takamichi

Hero (651)

Takamichi さんの画像

17-11-2022, 15:06

real Sanyo MPC-10:

prime	2357	2369	15
fornext	3540	=	59 sec
read	9997	=	2 min 46 sec 37

The nearest performance machine on Technopolis is Sony HB-55.
I'd like to emphasize my figures after "sec" so far is 1/60 sec whereas those on Technopolis are 1/100 sec. I don't know how accurate are the Technopolis figures.

I discovered the result often fluctuates. For instant the read test changes like 9431, 9364, 9431, 9364... every time I try it on openMSX MPC-10. I tried it on real MPC-10 again and the result was 9410 (2 min 36 sec 50) instead of 9997 above. Are these benchmarks really trustable or are actually random?

By NYYRIKKI

Enlighted (6093)

NYYRIKKI さんの画像

17-11-2022, 15:33

I've made a small tool to measure the most important parts that cause speed difference. All of the reported values are not 100% accurate, but this should give you good basic idea of how the computers differ from each other and what causes the differences. (There is both BIN and ROM version)

https://www.dropbox.com/s/avxx23p7b4okn02/LOCALNFO.zip

Edit: Actually most interesting part is that on real machines the measurements seem to differ quite often compared to emulated machines. ie. Philips machines seem to report a bit slower Z80 clock speed. How ever I've found no energy to test it on many real setups.

By Takamichi

Hero (651)

Takamichi さんの画像

17-11-2022, 16:14

NYYRIKKI wrote:

I've made a small tool to measure the most important parts that cause speed difference. All of the reported values are not 100% accurate, but this should give you good basic idea of how the computers differ from each other and what causes the differences. (There is both BIN and ROM version)

https://www.dropbox.com/s/avxx23p7b4okn02/LOCALNFO.zip

Edit: Actually most interesting part is that on real machines the measurements seem to differ quite often compared to emulated machines. ie. Philips machines seem to report a bit slower Z80 clock speed. How ever I've found no energy to test it on many real setups.

I tried the rom on several MSX models on openMSX and yes Interrupt payload, Keyscan payload and Key scan frequency vary widely between MSX models. Does the .bin work by BLOAD "CAS*",R?
Computers are affected by voltage ripples, inherent noise and incoming disturbances including cosmic rays. Early MSX1s might had been less protected from unwanted disturbances than later models. For instance turboRs are protected from voltage sags unlike the rest. Toggling a turboR's power switch off-on quickly doesn't reset it. One of the MSX FAN issues recounts that turboR stayed on despite all others shut down when the editor's power system was hit by a lightning.

By NYYRIKKI

Enlighted (6093)

NYYRIKKI さんの画像

17-11-2022, 22:18

Takamichi wrote:

I tried the rom on several MSX models on openMSX and yes Interrupt payload, Keyscan payload and Key scan frequency vary widely between MSX models.

Yes, and pay also attention to "VDP handbrake" status... It means that on some computers CPU is paused for some extra time while accessing VDP. Although it is very minor delay, it may multiply in to bigger problem, depending of the use case.

引用:

Does the .bin work by BLOAD "CAS*",R?

Well, I've tried only disk, but yes... It should work from cassette as well using BLOAD "CAS:",R

引用:

Computers are affected by voltage ripples, inherent noise and incoming disturbances including cosmic rays. Early MSX1s might had been less protected from unwanted disturbances than later models. For instance turboRs are protected from voltage sags unlike the rest.

Sure... but maybe I would not try to blame cosmic rays for the noticed speed differences anyway. :) The only important environmental variable, that can actually cause differences in speed measurements is the temperature of the computer as temperature tends to have effect to the crystal oscillators.

引用:

Toggling a turboR's power switch off-on quickly doesn't reset it. One of the MSX FAN issues recounts that turboR stayed on despite all others shut down when the editor's power system was hit by a lightning.

Yes... MSX tR had exceptionally good capacitors on power input. How ever after 30-years the computer tends to shut down a lot faster nowadays. :) This does not affect the execution speed though.

By NYYRIKKI

Enlighted (6093)

NYYRIKKI さんの画像

18-11-2022, 14:50

Takamichi wrote:

I discovered the result often fluctuates. For instant the read test changes like 9431, 9364, 9431, 9364... every time I try it on openMSX MPC-10. I tried it on real MPC-10 again and the result was 9410 (2 min 36 sec 50) instead of 9997 above. Are these benchmarks really trustable or are actually random?

There is nothing random in how the MSX works, but you can't really trust these tests... For example there is this 10 TIME=0 in beginning of program... Ok, it resets the counter to zero at some point of time, but you don't know if the counter goes to 1 after 1 ms or ie. after 19ms... In theory you could solve it with something like:

10 DEFINT T: T=TIME
20 IF T=TIME THEN 20 ELSE TIME=0

... but BASIC it self is not very fast so there is still difference if the time counter changes at the time of executing IF or at the time of executing THEN. Also if ie. keyboard scan happens when time=0, 1 or 2, it also affects the result in the end. This becomes harder and harder problem depending on how accurate results you need. It also compares the CPU speed to VDP speed and these speeds may vary a bit... Some MSX have different clocks for both chips while others divide the clock from same source. On MSX RTC is likely the most accurate clock, but that is not available in MSX1. For BASIC programmer the problem may be "new", but actually assembler programmers that try to do VDP tricks very accurately at certain moment this time jitter is very real problem as it is next to impossible to get it right in 1 clock pulse accuracy even on machine language simply because even the most simple instruction NOP (do nothing) takes 5 clocks. MSX slot layout, disk drive motor stop counter, keyboard language, BASIC version etc. all cause minor differences in these tests, so it is very much expected that the results are not exactly same.

I've also been surprised on certain times about these BASIC speed differences, check ie this extreme situation:
https://www.msx.org/forum/msx-talk/general-discussion/msx1-4...

By edoz

Prophet (2501)

edoz さんの画像

18-11-2022, 16:47

Gradius2 wrote:

It would be cool to have a benchmark tool for MSX, just for fun.

I wrote one for SymbOS, which allows you to compare your MSX machine even with CPC or Enterprise. But also compare different MSX machines

ページ 1/2
| 2