The "Ahl Benchmark" of BASIC performance

[Chuck(G)]

My recollection is that the tokenizing in MS BASIC-80 is not the same as that of GW-BASIC for the PC.

 

[voidstar78]

BTW, I run my NEC systems at the Japanese 100V. Today I just tried them at US 115V, and got exactly the same numerical and timing results. I thought maybe they'd run a tad faster with the extra +15V - after all, my train sets are like that Of course my trains also start going backwards if I reverse the polarity - I won't try running my CPU backwards.


And I just realized the original article in 1983 also lists a Mattel Aquarius. The Aquarius+ is a modern remake of that Z80A based system (and it gets the same numerical results as the original, albeit slightly faster at 1:11sec versus the original 1:17sec; the modern Aquarius+ has native VGA out and USB keyboard support, maybe that stuff relates to this timing difference from the original?)
<https://rumored.com/2023/09/12/aquarius/>

 

[Eudimorphodon]

BTW, I run my NEC systems at the Japanese 100V. Today I just tried them at US 115V, and got exactly the same numerical and timing results. I thought maybe they'd run a tad faster with the extra +15V - after all, my train sets are like that

Please reassure us all this was a joke.

I mean, I dunno, there were a few really brutally primitive single board computers like the JOLT 6502 that used free-running R/C oscillators instead of crystals, I guess they would probably run a bit faster if you overvolted them… but if you’re using anything other than a completely unregulated wall wart to supply VCC the voltage coming out of the wall shouldn’t translate straight through…

 

[voidstar78]

Well I have backup of both NEC's. But after meeting a few folks who also tried it - yeah, they are Japanese spec 100V, but are running fine on US 115V outlets also. I do wonder if running the tape unit at 115V might influence the speed of that, making it start to fail to load things. But no intentions to run it long at 115V, I just wanted to verify this benchmark had the same timing result in doing so. I keep a 100V down converter for all the main unit, tape, and its CRT. But those NEC have a pretty massive PSU, it goes along that entire bulge at the back, the full width of the unit. (so no, didn't expect it to influence the processing timing - just would have been surprised if it did)

 

[Chuck(G)]

I doubt that the line voltage of +15 above nominal will have any effect.
Doesn't the NEC 8000 series have its own BASIC? Seems to me that I've got some 8" floppies that deal with that.

 

[Eudimorphodon]

I do wonder if running the tape unit at 115V might influence the speed of that, making it start to fail to load things.

Only if the tape drive is running off an unregulated power supply where changes in the input AC voltage can directly affect the voltage supplied to the tape motor. You might get that in a sufficiently cheap external tape deck, but probably not one built into a computer.

 

[cjs]

I doubt that the line voltage of +15 above nominal will have any effect.

Actually, I seem to recall that there were a few Japanese computers out there, perhaps including the PC-8001, that had switching PSUs that actually would deliver the wrong voltage to the system if run on 115 V instead of 100 V. But I could be wrong about that.

At any rate, most Japanese computers, at least the cheaper ones, use linear regulators, so you'll never see a difference there except a very minor bit of extra heat output.

Doesn't the NEC 8000 series have its own BASIC? Seems to me that I've got some 8" floppies that deal with that.

Well, yes in the sense that most vendors have their own version of BASIC, but no, in the sense that NEC did not write their BASIC de novo but licensed MS-BASIC and then modified it.

 

[Eudimorphodon]

Well, yes in the sense that most vendors have their own version of BASIC, but no, in the sense that NEC did not write their BASIC de novo but licensed MS-BASIC and then modified it.

According to a link referenced earlier documenting different flavors of BASIC tokenization NEC apparently did enjoy adding their own special flavor to things: according to them all the other machines related to the Kyotronic-85 (Olivetti M10, Tandy 100/102/200) used the same tokens, but NEC’s versions (8201, 8300) for some reason used different token values.

(Other than that it sounds like they’re almost the same.)

Not that different tokenization on otherwise nearly identical versions of BASIC is uncommon. The version of Color BASIC in the TRS-80 MC-10 is from a user perspective nearly identical to that in the regular CoCo, and the cassette formats are compatible, but the tokens are scrambled. (You can only transfer programs saved in ASCII format.) Not sure why they did that, other than possibly to remind you that anything that might have machine language string-packed into it would fail hard. (Different memory maps and CPUs.)

 

[Chuck(G)]

FWIW, here's list of BASICs that might be interesting to benchmark. Has any mentioned Locomotive BASIC, etc.?

Liste von BASIC-Dialekten – Wikipedia

de.wikipedia.org

And this doesn't include mainframe BASICs, such as CDC BASIC for Cyber systems: http://www.bitsavers.org/pdf/cdc/cyber/lang/basic/

 

[Chuck(G)]

The curious thing is that on the CDC STAR/CYBER 200 series, we had assembly, Fortran, IMPL, and APL, but I don't recall ever seeing a BASIC. Maybe BASIC isn't a language for vector supercomputers...

 

[cjs]

According to a link referenced earlier documenting different flavors of BASIC tokenization NEC apparently did enjoy adding their own special flavor to things: according to them all the other machines related to the Kyotronic-85 (Olivetti M10, Tandy 100/102/200) used the same tokens, but NEC’s versions (8201, 8300) for some reason used different token values.

Oh, you're talking about the 8200 series, not the 8000 series. (The PC-8001 and PC-8201 are completely different machines, and years apart.)

I have little doubt that NEC would have modified the Kyotronic-85 BASIC to make it slightly more compatible with its BASICs for the PC-8001 series and PC-8801 series. I've not looked at the particular source they were using, but MS-BASIC typically assigns token numbers by the keywords' order in the keyword list, so any change to the keyword list will change the token number assignments for that keyword onward.

Not that different tokenization on otherwise nearly identical versions of BASIC is uncommon. The version of Color BASIC in the TRS-80 MC-10 is from a user perspective nearly identical to that in the regular CoCo, and the cassette formats are compatible, but the tokens are scrambled.

That's no surprise at all to me, given that the two BASICs are based on completely different base source code (MS 6800 BASIC vs. MS 6809 BASIC.)

Not sure why they did that, other than possibly to remind you that anything that might have machine language string-packed into it would fail hard. (Different memory maps and CPUs.)

Probably they just didn't do the extra work and rewriting to preserve token compatibility, per above.

 

[Eudimorphodon]

That's no surprise at all to me, given that the two BASICs are based on completely different base source code (MS 6800 BASIC vs. MS 6809 BASIC.)

There are major differences in token order for all the various 6502 versions of MS-BASIC, which are all derived from the same core source. (Nor was MS particularly consistent with tokens in the various versions of 8080/Z80 BASIC) The encoding is basically arbitrary (which you pointed out yourself), and if Radio Shack had wanted them to match I’m sure it would have been trivial to make it so.

Possibly they just didn’t care about the order. Or, and this does seem kind of reasonable, they intentionally broke loading tokenized programs to discourage trying to run commercial programs sold for the CoCo that would *probably* break anyway. In any case I doubt the CPU was a significant factor.

 

[cjs]

In any case I doubt the CPU was a significant factor.

Oh, so the MS 6800 and 6809 BASICs use the same keywords in the same order in the token table? Yeah, if that's the case, they would have had to take action to make them incompatible, rather than take action to make them compatible.

 

[Eudimorphodon]

Oh, so the MS 6800 and 6809 BASICs use the same keywords in the same order in the token table?

This is a really odd statement. We just pointed out that the tokens are different for various versions of BASIC on other CPUs, are you asserting that the different breeds of BASIC-68 and BASIC-69 should somehow be more consistent? (Or less? Or… what?) Why do you think the cpu matters here? Also… fwiw, the 6809 isn’t object code compatible with the 6800, sure, but Motorola pushed *source* compatibility between the two as a feature (as Intel did with the 8086/8080), so… do you really think the two code bases would be completely unrelated?

If someone actually has on hand documentation for… I dunno, whether the versions of BASIC for FLEX 6800 and FLEX 6809 could load each other’s tokenized formats that might be an interesting data point, but otherwise I imagine it’s going to be a very deep dive into some very obscure computer platforms to try to figure out if the CPU architecture was some kind of a barrier to arranging the token lists to be compatible between two computers that have different CPUs but otherwise have syntactically nearly identical languages and compatible tape formats.

 

[cjs]

This is a really odd statement. We just pointed out that the tokens are different for various versions of BASIC on other CPUs, are you asserting that the different breeds of BASIC-68 and BASIC-69 should somehow be more consistent? (Or less? Or… what?)

I am asserting that the token assignment to keywords is unlikely to be the same because the source bases are much further apart. The 6800 BASIC was derived from a very early version of 8080 BASIC, and the 6809 BASIC from a later one (as far as I'm aware).

Why do you think the cpu matters here?

Because the 6800 and 6809 BASICs were written at different times in the development of MS-BASIC, and so are more likely to have different token tables.

Also… fwiw, the 6809 isn’t object code compatible with the 6800, sure, but Motorola pushed *source* compatibility between the two as a feature (as Intel did with the 8086/8080), so… do you really think the two code bases would be completely unrelated?

No, I think the code bases will both be extremely similar to the 8080 code base, as the 6502 code base was, to the point where they often do things less efficiently to continue using the 8080 style of doing things.

...I imagine it’s going to be a very deep dive into some very obscure computer platforms to try to figure out if the CPU architecture was some kind of a barrier to arranging the token lists to be compatible between two computers...

The CPU architecture isn't a barrier in the slightest, as is made clear by the link I gave in my last message. But you'd have actually to do the work to make that happen, because the token lists are by default different as various versions got changed over time.

The important thing to remember here is that token assignment is not done by the developer saying, "I'll assign token $81 to ELSE." The developer just lists off all the keywords and the token number is automatically assigned.

 

[Eudimorphodon]

The important thing to remember here is that token assignment is not done by the developer saying, "I'll assign token $81 to ELSE." The developer just lists off all the keywords and the token number is automatically assigned.

Okay, sure, but first off: even if the token order of the CoCo (which came *first*) was determined at random *and* it has more command words than the MC-10 it’s not unusual, looking at the token lists for BASIC-80 variants, for there to be gaps in the token list. If they’d wanted compatibility they could have had it.

Secondly, in light of the fact that despite the fact that the machines aren’t that much alike Tandy *did* go out of their way to make their cassette formats compatible (remember, these machines have basically entirely software defined cassette systems; if they didn’t care *at all* it would undoubtedly have been easier for them to let it run at a different effective baud rate or whatever) it, again, begs at least a little speculation about whether it was a conscious decision or not.

To be clear, it simply being an oversight/don’t care combined with possibly saving a little ROM space is probably the reason, not active sabotage, but it’s still a little odd. Tandy’s usual mode of operation up to this point was zero backwards compatibility if a computer was a “new line”.

The 6800 BASIC was derived from a very early version of 8080 BASIC, and the 6809 BASIC from a later one (as far as I'm aware).

You have perfect knowledge of this? I’d love to see the docs.

And… also, how does this align with the fact that the syntax is almost 100% identical between MC-10 and CoCo Standard Basic, but the *latter* came out three years earlier? Are you saying all subsequent 6800 versions were 100% derived from a single forking event that happened with the first port of BASIC-68 for the Altair 680, and then, when they were asked for a 6809 BASIC, they completely de novo’ed a new pristine fork of BASIC-80 despite Motorola offering automated 6800 source translation tools just like the ones that everyone who’s ever looked at the GW-BASIC source is positive Microsoft used for that? No cross pollination at all? Neat.

 

[cjs]

Okay, sure, but first off: even if the token order of the CoCo (which came *first*) was determined at random *and* it has more command words than the MC-10 it’s not unusual, looking at the token lists for BASIC-80 variants, for there to be gaps in the token list. If they’d wanted compatibility they could have had it.

The CoCo came before the MC-10, yes, but I am quite sure that the 6809 BASIC came long after the 6800 BASIC because the latter was first done in 1976 for the Altair 680, two years before the 6809 was released. (I doubt it saw much development after that, but you might find evidence otherwise.)

Secondly, in light of the fact that despite the fact that the machines aren’t that much alike Tandy *did* go out of their way to make their cassette formats compatible (remember, these machines have basically entirely software defined cassette systems....

Translating the existing CoCo 6809 software CMT routines to 6800 seems to me easier than writing new ones from scratch; so rather than going out of their way, I believe they did the easiest thing and just did that.

You have perfect knowledge of this? I’d love to see the docs.

I don't, but it seems a lot more likely to me that Tandy simply licensed the existing MS 6800 BASIC than translated their copy of the 6809 BASIC to 6800. As for the 6809 being more advanced, you can compare the Altair BASIC disassembly (only partially annotated) with the Dragon BASIC source and see what you think. If you just want to check out how different the token tables are (keeping in mind that the former is code directly from MS, and the latter code licensed from MS that contains licensee modifications), you can check out the RESLST tables from the 6800 and the 6809 versions. Note that they're quite different. The 6800 version is somewhat closer to the 8K 6502 table, though.

And… also, how does this align with the fact that the syntax is almost 100% identical between MC-10 and CoCo Standard Basic, but the *latter* came out three years earlier?

They're all based on the same original MS 8080 BASIC. The syntax shouldn't be different except for licensee's local modifications. (And I would not be at all surprised if, for facilities not provided by MS, Tandy decided to add the same ones with the same syntax to both the CoCo and the MC-10 three years later.)

Are you saying all subsequent 6800 versions were 100% derived from a single forking event that happened with the first port of BASIC-68 for the Altair 680....

I have never seen any evidence otherwise, and why would MS write a whole new 6800 BASIC when they already had a working one?

...and then, when they were asked for a 6809 BASIC, they completely de novo’ed a new pristine fork of BASIC-80 despite Motorola offering automated 6800 source translation tools....

It's hard to say if they started with an automatic translation of the 6800 code or just wrote up the new version based on a later 8080 version of the time. But if they did they former, they certainly did a lot of 6809 optimisations on it anyway; you don't get LEAX or STY instructions out of an automated translation tool. But as regards discussion of whether tokens should be the same or not, you can look at the two keyword tables I linked above and see how different they are (and also examine the closer similarity to the 6502 table).

And, of course, you should feel free to compare the keyword table in the Altair 680 6800 source above to that in the MC-10. You tell me how different they are.

 

[Eudimorphodon]

But as regards discussion of whether tokens should be the same or not, you can look at the two keyword tables I linked above and see how different they are (and also examine the closer similarity to the 6502 table).

And, of course, you should feel free to compare the keyword table in the Altair 680 6800 source above to that in the MC-10. You tell me how different they are.

What would be a far more useful, and fairer, comparison, would be to compare the BASIC sources for BASIC-68 and BASIC-69 that would be expected to be more similar. Here's a Microsoft software catalog from 1980. Both BASICs are lumped together, in a single one paragraph blurb, that describes both as supporting "all the language features of Microsoft BASIC-80". This doesn't read much like they're two completely separate lines of development, but, sure, that's reading a lot into one little blurb. But... I don't really get the impression you have documentation for the contrary either.

Essentially it seems like it's what you're arguing is the 6800 versions of what Microsoft describes as the "same" BASIC would be expected to always have perfect conservation of code between the first version ever produced and what might very possibly be the last. This isn't the case with any other version (Altair BASIC and MBASIC-80 get off on the wrong foot right away, starting with a single byte offset and rapidly diverging from there), and unless we could actually find the source for a different version of 6809 BASIC there's no reason to believe that there's any closer family resemblances in that line either.

Anyway, it's kind of remarkable just how much you're blowing up an offhand comment. I simply find it "interesting" that Radio Shack made these two systems based on different CPUs but clearly intended to have a "family resemblance" *partially* compatible but not entirely, and was musing on whether it was intentional or not. (And really, I probably lean towards "not", they just packed them both in whatever order seemed efficient at the time.)

EDIT: So I found a disassembly of MC-10 BASIC, and if you compare it to both Color BASIC and Altair 680 BASIC it's not a good match for either one. Without doing statistical analysis I'd say my gut feeling is the Altair 680 version is roughly the closest to how several versions of 8080 BASIC order their keywords and both the 6800 and 6809 versions of Color BASIC differ about as much from MBASIC-80 as they differ from each other. TL;DR, it looks like MS just didn't think this was important. And, they're probably right, most BASICs have options for doing ASCII transfers anyway.

(* A comment I found in one of these BASIC disassemblies noted a parser limitation in which if you had two BASIC commands that start with the same letters you need to put the longer one first in the table. Assuming this is a common factor it would probably explain why you really start seeing changes when BASICs start adding machine-specific graphics and sound commands...)

 

[cjs]

But... I don't really get the impression you have documentation for the contrary either.

I have sources that I have read. (And that you could read.)

Essentially it seems like it's what you're arguing is the 6800 versions of what Microsoft describes as the "same" BASIC would be expected to always have perfect conservation of code between the first version ever produced and what might very possibly be the last.

No, that's a pretty bad misreading of what I'm saying.

Anyway, it's kind of remarkable just how much you're blowing up an offhand comment. I simply find it "interesting" that Radio Shack made these two systems based on different CPUs but clearly intended to have a "family resemblance" *partially* compatible but not entirely, and was musing on whether it was intentional or not. (And really, I probably lean towards "not", they just packed them both in whatever order seemed efficient at the time.)

Right. And they most likely started out in different orders, meaning that RS would have had to do active work to get the MC-10 BASIC into the same order as the 6809 BASIC. If you look at the whole thing as, "let's not do significantly more programming and changes to the MS code than we have to," that explains everything from the tape code being the same (they re-used their CoCo code, translating it to 6800) and the tokens being different (they used whatever was in the MS code, with minimal changes, and MS changed their token order between the different CPUs, and probably somewhat even for different versions for a specific CPU).

EDIT: So I found a disassembly of MC-10 BASIC, and if you compare it to both Color BASIC and Altair 680 BASIC it's not a good match for either one. Without doing statistical analysis I'd say my gut feeling is the Altair 680 version is roughly the closest to how several versions of 8080 BASIC order their keywords....

Did you compare the other, non-system-specific code? The first two routines I checked between the Altair 680 BASIC and the MC-10 BASIC, STROUT and copy/LBLE1FE, were identical. (There are some 6803 improvements, there, though, such as replacement of ADDB+ADCA with ADDD in Z02EA/GETSTK.)

....and both the 6800 and 6809 versions of Color BASIC differ about as much from MBASIC-80 as they differ from each other. TL;DR, it looks like MS just didn't think this was important. And, they're probably right, most BASICs have options for doing ASCII transfers anyway.

Yes, that's pretty much what I've been arguing all along.

(* A comment I found in one of these BASIC disassemblies noted a parser limitation in which if you had two BASIC commands that start with the same letters you need to put the longer one first in the table. Assuming this is a common factor it would probably explain why you really start seeing changes when BASICs start adding machine-specific graphics and sound commands...)

Ah, right; I'd forgotten about that. Yes, that's a second (and more forceful) reason for token changes, though it doesn't really affect the changes that happen even in the first half dozen tokens (such as the move of GO/GOTO in the early BASICs).

 

[Eudimorphodon]

I have sources that I have read. (And that you could read.)

And you could put in links/citations to share and enlighten us all instead of just asserting things, I dunno…

Did you compare the other, non-system-specific code? The first two routines I checked between the Altair 680 BASIC and the MC-10 BASIC, STROUT and copy/LBLE1FE, were identical. (There are some 6803 improvements, there, though, such as replacement of ADDB+ADCA with ADDD in Z02EA/GETSTK.)

So, uhm, the evidence says that they *both* kept old code that does the job *and* yet also continued to improve and optimize as opportunities present themselves? Wow.

Anyway, whatever. If you actually have those links I’m too burned out on this topic to care anymore for a while.