4MB?!? My first box had 16k, second had 64k, 3rd 512k, fourth 8MB, fifth 64MB..256MB (upgrades) 6th 512MB, 7th 2GB.I only counted desktops that were primary. (Not that a TI-99/4A was a desktop, per se - primary storage was a casette)

Sinclair BASIC on Spectrum +2: 387 seconds. So I think 388 seconds on a +3 is more than right. Maybe the method you used is not that accurate... Face it: built-in BASIC on Spectrum machines is definetely not fast.

For machines that support DEFINT and DEFSNG you can add this:0 DEFINT X,P,A,F,W:DEFSNG S

For some reason I couldn't define W as an integer in the original code on the VZ/Laser, it didn't exit properly.

A VZ200 emulator said just under 205 for this version. FOR NEXT is sure to have different results though and the emulator I used probably doesn't have exact timing yet.I'm using a patched ROM that re-enables some of the Level II BASIC commands so don't assume it works on a standard VZ/Laser either.

Commodore +4 has 1.8 MHz CPU. 50 bad lines and other 153 lines for screen area where CPU has to be slower make average CPU frequency equal to 1.15 MHz. Commodore Basic is old and slow. AMSTRAD LOCOMOTIVE BASIC is much newer and faster. So it is not only the hardware benchmarks but BASICs benchmarks...

This Apple I is actually an emulation under MAME 0.184, running at original speed. Apple's cassette BASIC was also written by Steve Wozniak and was the predecessor to Integer BASIC; it is very similar in most respects, except for the latter's added graphics features. However, the program did need an added loop at the start to initialize the sieve array F():

11 FOR I=1 TO W:F(I)=0:NEXT I

since this version of Apple BASIC did not initialize arrays automatically.

The time is almost identical to Tim Locke's for Integer BASIC. Given that the two versions of BASIC are closely related, this isn't surprising. As long as the program doesn't do much I/O and fits within memory, an Apple I is almost identical to an Apple II in computing speed.

Yeah yours is a faster way to do this particular problem but that's irrelevant to a benchmark. The purpose isn't to find the fastest way to solve a problem, it's to find a program that will run unmodified (or as close as possible to being unmodified) on every system in the list. Some people don't get it when they say, "Hey, I can use such-and-such a feature of my particular compiler to run even faster!" This isn't what benchmarks are about. To compare system X with system Y, both need to run the same program, not taking advantage of quirks or extensions in either system.