6502.org

It's not really all that surprising, no. Unlike other Microsoft BASICs, MSX BASIC uses decimal rather than binary significands, which is probably a performance hit right there, and, more importantly, in your case is probably using double precision floating point (14 digit significands and a 7-bit binary exponent).

I have tried to replicate your benchmark (more on this below) and came out with 521.9 seconds (versus your 554.98) based on the TIME variable and confirmed roughly against a wall clock on my Japanese Sanyo MPC-2 (Wavy2), which is an NTSC MSX1 machine running an earlier version of BASIC (1.0 instead of 2.0).

In the benchmark above I added a line 165 DEFDBL A-Z to ensure that I was using double precision (though this is the default, and the result is the same without it). Changing that to DEFSNG uses 6-digit significands which is I think is a more fair comparison to other MS-BASICs and seems to produce the same visual output. This takes 413.37 seconds, a 21% improvement, which puts the MSX machine between the Commodore Plus/4 (MSX1 being 15% faster) and the Commodore 64 (MSX1 being 7% slower).
(I've also run the benchmarks above on a Japanese Sony HB-55, also MSX1, and came out with the same numbers within .02%: 521.98 s and 413.45 s.)

Regarding your post, especially in its original version, you could have made it a lot more clear what changes you were making to the original benchmark code. It took me some time to replicate your output, and it didn't help that for the MSX one you've both lost the top line of the output and terminated the program differently (or not terminated at all, I think; I replicated with 515 GOTO 515 to prevent the program from exiting). You should also check the result from TIME against a wall clock; since TIME doesn't increment when interrupts are disabled it may undercount the time used. (I confirmed that it's very close on my machine, but this may vary across MSX models.) You should also mention that dividing TIME by 60 to get seconds applies only to NTSC MSX models; since it's based on the video refresh interrupt this would need to be 50 on PAL machines.

I'm not clear on why your MSX2 is noticeably slower (6%) than my MSX1, despite being a newer machine running a newer version of BASIC. Perhaps it's actually faster and you're using a PAL model? Without knowing what hardware you tested on, it's hard even to guess. (I'll have another go at this on one of my MSX2 machines if I can get one up and running; I'm currently waiting on a power supply for them.)

I just use Open MSX emulator with the Sanyo MPC-25FD.

I can only suppose that maybe MSX1 Basic is a bit faster than more complex MSX2 Basic.

The CPU frequency are the same in the MSX1 and MSX2. Maybe the observed 5% difference is also caused by small frequency difference for those computer models.

A quick test program suggests the NC200's BBC BASIC uses a 32-bit mantissa in floating-point, which matches the 5-byte format used in standard BBC BASIC:

Again, you're leaving out important information about how you created your benchmark results. If you're using an emulator, please say so; not all emulators are cycle-accurate, even when they claim to be.

I've now taken the program over to openMSX and replicated your result for an MSX2 Sony HB-F1XD as well as my results for for MSX1. (I as yet have not been able to run the code on a real MSX2 platform, though the materials are in that linked repo for anybody who does have one.) And the results list in that repo includes most or all of the results posted here; anybody interested in adding more should feel free to put in a merge request or ask me for commit access.

(There's a nearly 8% difference between PAL and NTSC versions of the NES and nearly 4% difference between the PAL and NTSC models of the C64.)

I have prepared more data for your project. I have added data I got from Chromatix's program.

It seems that it shows rather wrong information for the Atari 800 where mantissa is 10 decimal digits. It is also not easy to guest whether the information correct for the MSX2.

For decimal formats, I would assume that the exponent indicates decimal digit shifts, rather than bit shifts. This would give about a 3x increase in representable dynamic range, which is consistent with what we see for the 800XL; it's only the MSX2 that does something weird. I actually didn't consider the possibility that a home computer's BASIC could use a decimal format.

For decimal formats, I would assume that the exponent indicates decimal digit shifts, rather than bit shifts.

...it's only the MSX2 that does something weird. I actually didn't consider the possibility that a home computer's BASIC could use a decimal format.

Also, again, since you surely translated Chromatix's program rather than running it directly, you should post the actual code you ran. It's easy to make mistakes in code like that that would invalidate the result.

For the Atari, there seem to be several versions of BASIC from at least two different authors/vendors. I've not dug too deeply into that mess, and I'm not likely to get around to it until I get real hardware. (I should have an Atari 800XL or something similar arriving at some point.)

So, do we think MSX2 Basic runs slower than MSX Basic, but we don't know why?

Nothing has been translated but lines 40 and 80. For the Commodore I used....

I hope it will be easy to deduce line 80. ;)

The 8-bit Atari has FP routines in its OS ROM, not in Basic ROM. So they are quite standard.

What became Atari BASIC is a pared-down version of Cromemco BASIC ported to the 6502. That needed 10K of code. To make it fit in Atari's 8K cartridge, some of common routines were moved to the operating system ROMs. This included 1780 bytes for floating point support that were placed in a separate 2K ROM on the motherboard.

Yeah, I'm having serious difficulty with this. I am pretty sure that CBM BASIC has no REPEAT...UNTIL syntax, and VICE's C64 simulation appears to agree with me:
Well, why "hope" when you can simply post the code you used? And ideally, provide a script that runs the emulator with that code. Even better yet, put it in a repo so that others can clone it and quickly reproduce your results. Unless, of course, you want to make a lot more work for people trying to do the reproduction.

I think that to publish a lot of code is not a good idea.