The "Ahl Benchmark" of BASIC performance

[cjs]

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

There are five links to three different source code files and two specific points within them back in message #37.

 

[Eudimorphodon]

There are five links to three different source code files and two specific points within them back in message #37.

And I read those links, but the tone of some of your replies seemed to strongly imply that, for instance, you had original historical documentation from Microsoft about, say, the exact origins and evolution of the 6809 port compared to the 6800 version.

I will freely admit that I'm not remotely conversant enough with assembly language to pick through assembly listings for three different CPUs (Only one of which is actually something like like original source, the other's a disassembly) that came out at wildly different times and perfectly reconstruct a family tree of what was ported from where, so... again, I dunno, maybe you in fact are, but pardon me for finding a claim like "the 6809 port is completely separately derived from a later version of BASIC-80" a little remarkable. There are certainly a few specific places where the CoCo/Dragon version is "more advanced" than the MC-10 version; one easy place where it resembles the more complex Extended/Disk MBASIC-80s is it supports 2-byte tokens, no doubt for the same reason. (IE, Color BASIC was designed to be upgraded to Extended Color BASIC, which in turn was extensible to Disk BASIC... which means it has to support a lot more tokens up front.) But is that a consequence of it being a "separate port", or is it simply the same techniques being applied by MS when growing a "small" BASIC into a "big" one?

(I looked, but cannot find in any easily consumable form those FLEX versions of BASIC that were mentioned in the catalog. I feel like it's very possible that Microsoft may have made a 6800 version of BASIC using the "Extended" feature set or, conversely, a "small" 6809 BASIC, that would resemble MC-10 BASIC more than CoCo BASIC does, might have existed, but if they ever did they're now mostly lost to history. All we have is these snapshots, it's not like we have an archive of Microsoft's revision control system from 1975 through 1984 to pick through.)

One last observation before, yeah, sure, whatever, you win, I'll shut up:

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.)

Just wondering, before you threw this out there as some kind of evidence that 6800 and 6809 BASICs aren't related because CoCo extended BASIC is "fancier", and therefore must be an independent port of BASIC 80, did you do the same with BASIC-80? I just took a look at the source code for Microsoft BASIC-80 5.2, the extended disk version for CP/M circa 1981-ish, on Winworld. There is of course a lot of reformatting (BASIC 5's source is set up for a macro assembler) and some functions have been elaborated to the point they're mostly unrecognizable, but there are also blocks of code in it that are straight out of Altair 4K BASIC. GOSUB and RETURN, for instance, are almost entirely unchanged. Kind of seems like Microsoft just sort of grew these things organically.

 

[cjs]

I will freely admit that I'm not remotely conversant enough with assembly language to pick through assembly listings for three different CPUs (Only one of which is actually something like like original source, the other's a disassembly) that came out at wildly different times and perfectly reconstruct a family tree of what was ported from where, so... again, I dunno, maybe you in fact are, but pardon me for finding a claim like "the 6809 port is completely separately derived from a later version of BASIC-80" a little remarkable.

Well, that's the crux of our disagreement, I suppose; based on four years of on-and-off dabbling in MS-BASIC source and disassembly for three (four if you count Z80) CPUs, and now 6809 as well, across several different versions of MS-BASIC, and having done some of this disassembly myself, I feel I have a sense of how MS did these things, and I find it not at all unlikely that MS would port their current 8080 BASIC to 6809 rather than cross-assemble an old version of BASIC from 6800 to 6809, producing a massively inefficient (both in speed and space) version which would take a lot of time and effort to optimise, only to end up with an older version of BASIC anyway.

I suspect your opinion here might be due to not being conversant with assembly: if you go do some 8080, 6800 and 6809 programming I think you'll readily see why a translation from 8080 makes a lot more sense than a translation from 6800. (The key here is that the 6800 has only one index register, whereas the 8080 and 6809 have, effectively, multiple index registers; what this means will become obvious if you do some programming on each of these three systems.)

But at any rate, if you think your opinion is more supportable, do feel free to go do some research and come out with some actual support for it, rather than just sniping at me with, "That doesn't sound plausible to me." I've already given you a repo that contains actual MS source and partial disassemblies for five different versions of MS-BASIC, and links to three more, plus links to considerable ancillary information. So far you've given us an MS-BASIC catalogue and an MC-10 BASIC disassembly that shows a lot of similarity to my Altair 680 BASIC disassembly. (And thanks for that, of course.)

But is that a consequence of it being a "separate port", or is it simply the same techniques being applied by MS when growing a "small" BASIC into a "big" one?

One thing you'll notice if you read the source code and disassemblies across various versions and CPUs is that MS tends toward changing and reimplementing as little as possible in the code base. They'll go use an inefficient way of doing things on the 6800 or 6502 because it's the way it was done in the 8080 code from which the 6800 and 6502 code were derived, rather than rewrite it to be more natural for the port.

From more than 25 years as a professional programmer on modern systems, and having done some programming for (and a lot of disassembly and reverse-engineering on) late-70s and early-80s microcomputer systems, this makes a lot of sense. Writing code is about the third highest-cost activity in software development: reading code and testing it are both more expensive, and testing is significantly more expensive in an era where a lot of the testing is done manually instead of by writing automated test suites. (There's a reason that anybody who promotes extensive refactoring will insist that a comprehensive, frequently run automated test suite is absolutely essential.) So if testing is expensive, and you don't have an easy way to push a button to see if you blew some edge case with a change, "if it ain't broke, don't 'fix' it" is a very good approach to take.

Just wondering, before you threw this out there as some kind of evidence that 6800 and 6809 BASICs aren't related because CoCo extended BASIC is "fancier", and therefore must be an independent port of BASIC 80, did you do the same with BASIC-80? I just took a look at the source code for Microsoft BASIC-80 5.2, the extended disk version for CP/M circa 1981-ish, on Winworld.

Why, yes, I did happen to do that. The MS-BASIC 5.2 source that you saw in the repo I linked (at least, if you looked at the names of the top level directories) is there for a reason, after all.

...but there are also blocks of code in it that are straight out of Altair 4K BASIC. GOSUB and RETURN, for instance, are almost entirely unchanged.

Yes. I've known this for years, and you will find this all over the place. I believe you see this sort of thing for the "if it ain't broke" reasons I described above. (You, of course, are free to propose other opinions on what's going on there.)

 

[voidstar78]

Any thoughts on why the Tandy Model 102 was so relatively-slower than the rest of these systems? The 80C85 based portable from mid-1980s. I don't have a Model 101 to compare, or the NEC equivalent. This system ran on AA's batteries, and the "C" meant CMOS (and lower power) - right? But is the Model 102 "slow" because of whatever build of BASIC it used, or hardware compromises? Note that floating-point results suggest it had a pretty high accuracy - so at least appears you're gaining something at the cost of that longer runtime.



And related to Tandy - I've always found it interesting that the 1981 IBM PC used the same cassette interface as the 1980 CoCo (that DIN plug, which also the TRS-80 used). I've supposed that Microsoft started their development effort for the CoCo maybe in 1979 (maybe '78)? That includes a 6809 port of BASIC - related to what you guys have been discussing. And given how fast (and how "hush-hush") the IBM PC development was - I've wondered if Microsoft leveraged that recent 1980 product development experience (BASIC on a 6809, and its tape support) when helping to design and integrate the IBM PC? And just associated with that, perhaps Microsoft proposed to "just use the same tape system that Tandy used" - which conveniently maybe helped retain a lot of the same code for the CoCo BASIC? (or at least to borrow the timing characteristics - of writing/reading to tape).

Another thought I've had is, maybe the inclusion of the cassette support in the IBM PC 5150 was just a "red herring" to throw off anyone trying to figure out exactly what IBM was up to. One could just guess "oh they're just building another 8-bit micro like the many dozens of others-- looks it's got a cassette, just like all those others, no big deal." OR - considering that IBM didn't yet have disk drive support, or the software support for it, or had finished writing and testing the BIOS. Perhaps the early tape support was critical for that early development, so they could test aspects of the system? Meaning - they could flash a ROM during early development, but it still might be nice to load stuff into RAM via "something" (tape,) and POKE in some test code. (given there was probably some months, and developers spread across areas who maybe didn't have disk drive hardware)

Just speculations on my part, but that commonality of the cassette port component amuses me - that parts from my CoCo (the cassette cable) can be shared with the 5150 (and the CoCo joysticks can be shared with the Tandy 1000-series).

 

[cjs]

And related to Tandy - I've always found it interesting that the 1981 IBM PC used the same cassette interface as the 1980 CoCo (that DIN plug, which also the TRS-80 used).

That is curious, though perhaps not that surprising; it could well be that IBM decided to re-use an existing popular pinout (it was the same on pretty much all TRS-80 models IIRC) rather change it for no good reason.

Japan had a similar thing happen. The NEC PC-8001, though the third home computer to come out in Japan (after the Sharp MZ-80K semi-kit and the Hitachi Basic Master), used a DIN-8a connector for the CMT and almost every Japanese home computer after that, regardless of manufacturer, used that same connector and pinout, despite there never having been any formal agreement about this that I can find. (A similar thing happened with the DRGB outputs.)

I've wondered if Microsoft leveraged that recent 1980 product development experience (BASIC on a 6809, and its tape support) when helping to design and integrate the IBM PC? And just associated with that, perhaps Microsoft proposed to "just use the same tape system that Tandy used" - which conveniently maybe helped retain a lot of the same code for the CoCo BASIC? (or at least to borrow the timing characteristics - of writing/reading to tape).

I don't know if MS or Tandy wrote the CMT support for the PC, but it is, IIRC, in the PC BIOS, not in the ROM BASIC. But though the connector is the same, the CoCo and IBM PC tape formats are different. The bit-level formatting is not too dissimilar: the CoCo does 0 and 1 with one cycle each of 1200 and 2400 Hz, whereas the PC uses a single cycle of 1000 and 2000 Hz for the same. But at the blocking level it changes: CoCo uses a sync leader of 128 bytes of alternating 0/1; PC uses 256 bytes of all 1s; the block format itself is somewhat different (not that there are a huge number of choices for this); and the CoCo uses a 1-byte checksum on each block whereas the PC uses a 2-byte CRC. Also, the hardware is slightly different: the CoCo uses a 6-bit D/A for output, whereas the PC (again, IIRC) just does a standard square wave.

Still, these aren't dissimilar enough that it's totally unlikely that they were derived from the same original code. I just have no evidence of where or when MS might have written that code. It's worth keeping mind that in the early years of MS-BASIC, at least, all this stuff was considered "BIOS" or "vendor provided" or similar.

As for the Model 102 being slower, that's kind of interesting. The Model 100 and NEC PC-8201 are on my list of Stuff To Disassemble, but that sadly is a longish list so I have no idea when I'd get to it.

 

[krebizfan]

The Model 100 used a 600 ns ROM. The IBM PC ROM was rated at 250 ns. A number of efforts at speeding up the Model 100 line include replacing the ROM with a faster one.

The cassette format for the IBM PC has the Apple II frequencies (1000 Hz and 2000 Hz) but the 256 byte leader is similar to the Model III's 1500 baud mode. The Apple II had a special frequency just for the leader. It looks like IBM took the standard FSK system and tried to make something that was easy to implement with the PIT but not an exact copy of any other cassette format.

 

[kb2syd]

The Model 100 used a 600 ns ROM. The IBM PC ROM was rated at 250 ns. A number of efforts at speeding up the Model 100 line include replacing the ROM with a faster one.

Replacing a ROM with a faster rated one will not increase performance in any signifigant way. The hardware was constructed to expect the data from the ROM at 600ns. Putting a 250ns ROM in there will only make the ROM have the data sooner.

I hear comments like this a lot. Replacing 150ns RAM with 120ns RAM will get you a system with slightly more expensive RAM.

 

[cjs]

Replacing a ROM with a faster rated one will not increase performance in any signifigant way.

True, but I don't see how that's relevant. (I am guessing you probably do agree with krebizfan that speeding up the Model 100 could include replacing the ROM with a faster one.)

 

[kb2syd]

True, but I don't see how that's relevant.

Just debunking a popular myth. Off handed assertions of fallacies are a pet peeve.

(I am guessing you probably do agree with krebizfan that speeding up the Model 100 could include replacing the ROM with a faster one.)

As a small step in the process, I guess it would be warranted.
I've been a Model 100, 102 and 200 owner for decades. Speed was never a consideration for me.

As for the various assertions about barious BASIC flavors...
It's my experience that Micosoft, and many other software vendors, would often take the fastest way out to get a new product shipping, with little regard to the efficiency on the new processor.

 

[cjs]

Just debunking a popular myth. Off handed assertions of fallacies are a pet peeve.

Fair enough, but why debunk fallacies that nobody has brought up?

 

[kb2syd]

Fair enough, but why debunk fallacies that nobody has brought up?

Post #46 specifically mentions an attempt to speed up a computer with a faster ROM. Pointing out that it doesn't work.

 

[cjs]

Post #46 specifically mentions an attempt to speed up a computer with a faster ROM. Pointing out that it doesn't work.

Post #46 specifically and carefully says, "A number of efforts at speeding up the Model 100 line include replacing the ROM with a faster one." [Emphasis mine.] Which was what I was pointing out when I suggested that, "you probably do agree with krebizfan that speeding up the Model 100 could include replacing the ROM with a faster one."

Which I'm still pretty sure you do, right? Replacing the ROM with a faster one, along with some other changes (obviously dropping some wait states or something similar), could speed up the computer, no?

 

[kb2syd]

Added to my ignore list.

 

[Eudimorphodon]

Post #46 specifically and carefully says, "A number of efforts at speeding up the Model 100 line include replacing the ROM with a faster one." [Emphasis mine.] Which was what I was pointing out when I suggested that, "you probably do agree with krebizfan that speeding up the Model 100 could include replacing the ROM with a faster one.

I don't really believe in adding people to ignore lists... ironic, I suppose, considering I've gotten under a few skins in my times, enough so that this is probably the pot calling the kettle black, but... dude, really? Why are you doing this? The comment you're going to the mat over here was clearly in reference to people who believe that just swapping a faster memory part for a slower one alone will speed up an older computer. Which is a very common misconception. (Right up there with people also believing that swapping in a faster rated CPU will also magically speed up a computer without having to, you know, do any other work.) I will grant that, sure, you're right, the prompt for this comment wasn't *excluding* also doing a clock speed-up mod or whatever, but... sometimes people just like to pitch into a conversation, and what they said was not wrong.

Jumping down my throat for an offhand one sentence comment and turning it into a massive mind-reading exercise about how people working at a company 40 years ago made coding decisions is, I dunno, maybe a defensible chance to show off juuuuust how much fiddling you've done with old code, to the point that it gives you psychic intuition, and I guess I'll hope you really enjoyed it, but... this is something else.

You're a really smart guy and clearly have a lot to contribute, but, eh, I guess roll how you wanna.

 

[krebizfan]

https://forum.vcfed.org/index.php?threads/update-on-my-trs-80-model-100-cp-m-rig.78460/ is a thread that incorporates the idea of a faster ROM as part of the upgrade. Agree with it; disagree with it; it is what it is.

Replacing slower memory with faster memory can result in a faster system if the process reduces the wait states required. That was much more a 90s thing since earlier systems rarely permitted changing the wait states. In a forum post, one does not include all the potential caveats one might mention in a formal report.

 

[Eudimorphodon]

https://forum.vcfed.org/index.php?threads/update-on-my-trs-80-model-100-cp-m-rig.78460/ is a thread that incorporates the idea of a faster ROM as part of the upgrade. Agree with it; disagree with it; it is what it is.

Critical line in that thread:

On an M100, to double the speed to 4.9MHz, you also need faster RAM and a faster main ROM.

IE, just as was pointed out here, you don't need the faster memory unless you up the clock speed. This point might have been slightly buried in that thread by the fact that in it the OP did swap the ROM for a different one when replacing the 80C85 with an NSC800 (Z80-compatible) CPU initially running at the stock 2.5mhz... but that ROM change was because the code needed a patch to deal with the new CPU.

And sure, with more modern systems it's a base assumption that any memory that's not on the same die as the CPU is going to run at some fractional rate of maximum speed. But it's also of note that since the mid-90's generally things like RAM DIMMs have a little configuration EEPROM on them that tells the memory controller what their optimal settings are, so even if you're not a hacker going into the BIOS and turning the knobs there is in fact a reasonable expectation that just swapping one DIMM for another will have some kind of effect that isn't going to be true when you're talking about a bare DIP chip.

EDIT: Maybe here's the easy way to explain why the response was not wrong: In most lingual communication separating cause from effect is important. In the case of a computer like a Model 100 a "faster ROM", IE, the need to replace the original with one, is an effect that may result from speeding up the computer. It is not a cause of speeding up the computer.

Putting Z-rated tires on your straight-six Dodge Dart will probably not have much, if any effect, on the vehicle's lap time around the Nürburgring. But you might need to put Z-rated tires (and a slew of other suspension-related upgrades) on that car before attempting said lap after replacing the original engine with a 426 Hemi. Z-rated tires are an effect of the cars' higher performance, not the cause.

 

[cjs]

IE, just as was pointed out here, you don't need the faster memory unless you up the clock speed.

Well, as a blanket statement, that is wrong. If your memory is slow enough that wait states are being inserted, merely removing the wait states will also require faster memory. (Given how slow that ROM is, this is what I had assumed that krebizfan was talking about, though tweaking other things is also a fair enough way of increasing speed of access to memory.)

And sure, with more modern systems it's a base assumption that any memory that's not on the same die as the CPU is going to run at some fractional rate of maximum speed.

This is not something relevant just to modern systems. In fact, it's as old as home computers themselves. The first MITS PROM board (and one of the earliest S-100 bus boards made), the 88-PMC, had options for adding zero to three wait states to handle slower PROMs. This wasn't a theoretical consideration: it was based on actual published timings for Intel 1702 and 1702A PROMs. (And, of course, part of the reason for the particular and rather complex clock and memory access design of the 8080, as compared with the 6800 and similar systems, is to work with slower memory without having to introduce wait states.)

The comment you're going to the mat over here was clearly in reference to people who believe that just swapping a faster memory part for a slower one alone will speed up an older computer.

Yes, but it also implied that krebizfan was making that mistake, whereas any reasonably charitable reading of what he said showed that he was not making that mistake. kb2syd could have started the message with, e.g., "I know you understand this, but for others that don't," or something similar, rather than implying that krebizfan was posting something Wrong On The Internet.

And from the continuing conversation, I am reasonably sure that kb2syd simply didn't properly read krebizfan's post. kb2syd is triggered by someone making claims that just swapping a ROM for a faster one won't speed things up; I'm triggered by people who imply others are wrong without properly reading their posts. We all have our quirks, I guess.

Jumping down my throat for an offhand one sentence comment and turning it into a massive mind-reading exercise about how people working at a company 40 years ago....

I'm sorry you took "That's no surprise at all to me" as "jumping down your throat." But I felt, based on my knowledge, that it was worth offering an alternative to your theory.

...I dunno, maybe a defensible chance to show off juuuuust how much fiddling you've done with old code, to the point that it gives you psychic intuition, and I guess I'll hope you really enjoyed it, but... this is something else.

There's no need to get nasty here. Your theory is, objectively, at least as much based on "psychic intuition" as mine. And I rather feel that the whole discussion was a case more of you jumping down my throat with the ferocity of your defense of your theory, and why mine must be wrong. I don't mind being challenged to explain why I feel my theory is more plausible, but aggressive statements such as, "You have perfect knowledge of this? I’d love to see the docs" are unnecessary, particularly when you have no documentation for your argument, either.

And also, complaining about me not providing sources and links when I did provide sources (and far more than you did) rather grates.

 

[Eudimorphodon]

But I felt, based on my knowledge, that it was worth offering an alternative to your theory.

There's no need to get nasty here. Your theory is, objectively, at least as much based on "psychic intuition" as mine.

Look, man, I'll own that this whole thing is my fault or whatever if it puts an end to this. All I'm going to say here is that I thought I was reasonably clear about not positing anything I said as any more than a theory, while there's this ring of "See, I know the obvious facts from sources that you could totally read yourself if you weren't so dumb"(*) that mysteriously comes across in your tone to some people, and I guess I fell victim to getting riled by it. Which was wrong. I mean, clearly you're just operating at a level so far above us that you can't understand what we might need to pick out of that link to prove your point when you say something like "oh no, this code is obviously a port of this other code.

My last and final technical thoughts about those links you're grated about:

In post #37, where said links were dropped, you just pointed out the command tables are different and then basically asserted that meant they were from entire different ports of a source tree... without apparently noticing that the 6809 version wasn't any closer to the newer version of BASIC-80 you claim it must be from. (I'm the one who pointed out shortly afterwards, hey, it looks like the major driver of token order is how the parser works, and this was *long after* I'd already conceded that, sure, if they'd *wanted* the same tokens in the two BASICs they would have had to go out of their way to do it.) And then later you throw out stuff like this...

I suspect your opinion here might be due to not being conversant with assembly: if you go do some 8080, 6800 and 6809 programming I think you'll readily see why a translation from 8080 makes a lot more sense than a translation from 6800. (The key here is that the 6800 has only one index register, whereas the 8080 and 6809 have, effectively, multiple index registers; what this means will become obvious if you do some programming on each of these three systems.)

But at any rate, if you think your opinion is more supportable, do feel free to go do some research and come out with some actual support for it, rather than just sniping at me with, "That doesn't sound plausible to me." I've already given you a repo that contains actual MS source and partial disassemblies for five different versions of MS-BASIC, and links to three more, plus links to considerable ancillary information. So far you've given us an MS-BASIC catalogue and an MC-10 BASIC disassembly that shows a lot of similarity to my Altair 680 BASIC disassembly. (And thanks for that, of course.)

Which, you know what? Again, I'm not disputing a 100% positive fact that you've had *way* more experience with 8 bit assembly than I have, but nonetheless... I'm sorry, this seems like it's in bad faith? I mean, I honestly have to ask you: Did you actually spend any time yourself comparing that MC-10 disassembly to Color BASIC? By happenstance there's a link in the top of that disassembly, to this PDF of "Color BASIC Unraveled", and... I get it, I'm a complete moron, but just sitting here poking through the extensively annotated disassembly of the 6809 version in that PDF and comparing to the 6800 version (which used it as a source to help get the labels reasonably consistent, so it's *way* easier than that awful repo of the Dragon 64 code), and... it looks very much to me like there are extensive swathes of code that are very much alike.

Sure, hitting the books I also see some 6809 optimizations, like how Color BASIC uses PULS B, X, PC to restore registers at the end of some of its drivers (like the keyboard) instead of three separate PULB/PULX/RTS instructions. But... come on, really? This is the hill you're dying on to make the claim that this is a separate port of the 8080 source? Or did you just make that whole claim up to be argumentative and blow smoke? I mean, clearly *all* the versions of Microsoft BASIC have a strong family resemblance, but... again, whatever, I suppose ultimately it doesn't matter.

Going back to my offhand comment that started this whole stupid thing it's quite clear that the correct answer boils down to is "sure it would have been possible to make the tokens match, but it would have required inefficient changes to the parser, which expecially would have been waste because the CoCo has two byte tokens, which the MC-10 would have never needed". There was zero need to invoke all these weird assertions about the histories of the codebases, at all, but... eh. Whatever.

Thank you for the argument I guess. At least I learned a few things.

 

[cjs]

In post #37, where said links were dropped, you just pointed out the command tables are different and then basically asserted that meant they were from entire different ports of a source tree... without apparently noticing that the 6809 version wasn't any closer to the newer version of BASIC-80 you claim it must be from.

Neither I nor (as far as I can tell) you have the source code or a disassembly of that two-year newer version of BASIC-80, so I don't see how either of us could have noticed how close or far it was.

I honestly have to ask you: Did you actually spend any time yourself comparing that MC-10 disassembly to Color BASIC?

And I will answer honestly: yes.

By happenstance there's a link in the top of that disassembly, to this PDF of "Color BASIC Unraveled", and... I get it, I'm a complete moron, but just sitting here poking through the extensively annotated disassembly of the 6809 version in that PDF and comparing to the 6800 version (which used it as a source to help get the labels reasonably consistent, so it's *way* easier than that awful repo of the Dragon 64 code), and... it looks very much to me like there are extensive swathes of code that are very much alike.

Yes. That's exactly what you'd expect, since all versions of MS-BASIC, for all CPUs I've seen, have extensive swathes of code that are very much alike. You can see this between Altair BASIC-80 and Altair BASIC-68, and even the early 6502 BASIC. That's why the 6809 and 6800 versions having similar code is very much not any real indication that the 6809 version was via a port of the 6800 version rather than the 8080 version.

What this really needs is a comparison with a contemporary BASIC-80 from around 1978, but I can't find a disassembly of one off-hand. (I do have a start with the PC-8001 ROM, but there I've done only a bit of the BIOS, none of the BASIC.)

This is the hill you're dying on to make the claim that this is a separate port of the 8080 source?

I am saying it seems more likely than not. What I'm not clear is why you are dying on the hill that it must be a port of the 6800 source. Are you convinced that would be easier somehow? I, as someone who's written software for all of the processors involved, believe that it would be more difficult. You of course, are free to believe otherwise, based on whatever you know about these processors and what you've read of the source and disassemblies for various MS-BASICS.

Or did you just make that whole claim up to be argumentative and blow smoke?

No. I just wanted to point out that there's an alternative, plausible belief to your clearly very firm belief that the 6809 was ported from the 6800, rather than the 8080. I am not clear on why you are so insistent that this is absolutely impossible. (Perhaps you don't believe that it's absolutely or nearly impossible, but that's the way you're coming across.)

There was zero need to invoke all these weird assertions about the histories of the codebases, at all....

Well, I think it started with your statement, "...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?" which I (perhaps incorrectly) interpreted as making a claim about the history of the 6809 codebase that I find somewhat dubious.

 

[voidstar78]

I work with a bunch of engineers. One day, I was talking about some modifications I had made to the ECU fuel map of a Honda I had long ago - and one of the engineers nearby said "why would you do that? those engineers spend hours of time and millions of dollars testing and perfecting how that engine should be built, you think you can improve their fuel map?" And I was a bit surprised about that. I wanted to say something along the lines of "we're engineers to, and when a schedule comes due, we cut corners like everyone else does" (within reason, ofc) or "mass produced engines are cheap because they're all built and tuned to 'good enough'" But instead I went on to explain how I had bored out the intake and exhaust ports, polished them up, changed injectors, and to run smoothly it just needed a new fuel map to go along with all that.


I had a similar encounter (different place and different engineers) regarding "lapping" of a CPU. I explained I had spent like 6 hours of sanding, putting a mirror polish on both my CPU and its heatsink. And a fellow engineer commented, "but Intel spent billions perfecting the top of their CPUs. If there was a benefit to lapping don't you think they'd be selling their CPUs like that, since even a 1% gain would give them a competitive advantage?" And I pondered a bit, and said "No, they needed a place to put their labeling while also protecting the copper core. They slap on some cheap tin, it's a place to put their logo and labeling, and the heat/performance/cost falls wherever it falls." And while Intel engineers are generally respectably brilliant, at the end of the day: schedule comes due and they just release what's good enough for the masses. BTW, there was a website so hostile to the very idea of lapping a CPU -- about how the build up static electricity would simply ruin a perfectly good CPU-- they consistently deleted my reviews about the experience. On the otherhand, maybe they considered it a State Secret, and were just trying to maintain the Crown Jewel


I'm not sure how any of that relates to BASIC and its performance. Other than, as others have said, when it comes to interpreted languages: utility is way more important than performance. I've always wondered what flavor of mainframe-BASIC that Young Gates encountered -- and while he railed about not copying "his" BASIC, and yet he was gifted hours and days of time on a mainframe. But to his credit, some novel work was done in having a stripped down 8KB version, and porting to the 6502 (which sure Paul Allen helped a lot).

But I've come across a rumor of an earlier BASIC from 1974 for an earlier micro: the Micral-N (for the 8008, apparently by students at the University of Illinois). I'm curious if anyone saw or has seen such a thing?