Chuck(G)
25k Member
My recollection is that the tokenizing in MS BASIC-80 is not the same as that of GW-BASIC for the PC.
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
I do wonder if running the tape unit at 115V might influence the speed of that, making it start to fail to load things.
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.I doubt that the line voltage of +15 above nominal will have any effect.
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.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.
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.)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.
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 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.
Probably they just didn't do the extra work and rewriting to preserve token compatibility, per above.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.)
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.)
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.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?
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).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?)
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.Why do you think the cpu matters here?
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.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?
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....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 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.
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).
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.)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.
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.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....
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.You have perfect knowledge of this? I’d love to see the docs.
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.)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?
I have never seen any evidence otherwise, and why would MS write a whole new 6800 BASIC when they already had a working one?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....
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 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....
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.
I have sources that I have read. (And that you could read.)But... I don't really get the impression you have documentation for the contrary either.
No, that's a pretty bad misreading of what I'm saying.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.
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).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.)
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.)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....
Yes, that's pretty much what I've been arguing all along.....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.
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).(* 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...)
I have sources that I have read. (And that you could read.)
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.)