• Please review our updated Terms and Rules here

The "Ahl Benchmark" of BASIC performance

Ah to clarify, it was just that an 8008-version of BASIC was developed, not necessarily that it was ever used on a Micral-N.

If just any 8008 BASIC would qualify, maybe the SCELBI might be helpful. https://www.willegal.net/scelbi/scelbal.html Supposedly ran on other 8K 8008 machines and there just aren't very many 8008 computers of any type.

The Weaver design ran on an 8008 simulator on an IBM 360. I can't find anything to indicate it ran on a real 8008. Given its need for a CRT, it might have been beyond what most of the 8008 machines could do.
 
Neat, looks like the SCELBAL (BASIC for 8008) has both SQR and RND. But the "Illinois" 8008 version seems to only have SQR - that PDF isn't as searchable, but it didn't seem RND was mentioned.

But reading through that "Illinois" version of 8008 BASIC, section 5 (page 20) is mentions purchasing the floating point package used on the Datapoint 2200. Though it doesn't really clarify purchased-from-who. That's interesting since it is contrast to the "SCELBI world" where its creator (I think it was?) authored a book describing implementing floating point in 8008 assembly (and note that SCELBAL didn't seem to really be available until 1976 - but that's just a date on its manual, maybe it was available a bit earlier).

In section 6 of the "Illinois" BASIC, they do regret that the design was not used on "real-world hardware" (just due to semester time constraints) but they were content in at least proofing that BASIC on a limited capability microprocessor did seem viable (that being from a mid-1974-perspective). I recall the creator of the Micral-N fully acknowledging that their system wasn't really intended as any desktop personal computer, it was more intended as an "embedded controller" for things like toll gates/booths. Similarly I've read that the Intel 8080 was intended for street lights (but not 100% confirm on that).


I guess an Altair or SOL-20 (8080's) running this Ahl Benchmark might be interesting. So, that's a question: the IBM 5100 could run this benchmark in 1975 (with the luxury to both type it in, and see the results on a CRT). I don't know if Bill's 1975 "tape BASIC" had SQR and RND? (I mean the know-how to code those functions was there, but could it fit in that original 4KB BASIC?). Could any micro run this Ahl Benchmark prior to 1976? (I see that Nat advertised the SCELBI as a "mini-computer" in that Marh 1974 QST ad).
 
I guess an Altair or SOL-20 (8080's) running this Ahl Benchmark might be interesting. So, that's a question: the IBM 5100 could run this benchmark in 1975 (with the luxury to both type it in, and see the results on a CRT). I don't know if Bill's 1975 "tape BASIC" had SQR and RND? (I mean the know-how to code those functions was there, but could it fit in that original 4KB BASIC?). Could any micro run this Ahl Benchmark prior to 1976? (I see that Nat advertised the SCELBI as a "mini-computer" in that Marh 1974 QST ad).
http://altairbasic.org/ shows version 3.2 which had both SQR and RND as does the Dec 1975 BASIC manual. There was a version of Gates/Allen BASIC without floating point but that was before it was shown to Altair. For some of the other benchmarks, one would need the 8K version of Altair BASIC to get access to transcendental functions at a reasonable speed.
 
Put together a sort of overview of BASIC keywords, from 1974.

After an initial "core" capability of BASIC, then every system adds keywords tailored to that system - in the case of the 1980s micros, it was to highlight certain hardware capability.
 

Attachments

  • BASIC_Keywords_Overview_REV1.pdf
    145.3 KB · Views: 9
I've long thought it interesting that of all of the microcomputer BASICs, that the IBM 5100 was the only one that implemented the MAT statement. Many other mainframe and mini implementations did include MAT however.
 
Put together a sort of overview of BASIC keywords, from 1974.

After an initial "core" capability of BASIC, then every system adds keywords tailored to that system - in the case of the 1980s micros, it was to highlight certain hardware capability.
You have a pretty big gap between 1982 and 2024. Many of those "new" X16 keywords were in QuickBASIC 35 years ago.
 
  • Like
Reactions: cjs
True BASIC is annoyed at being forgotten. True BASIC provided all the elements, including the full range of MAT functions, of minicomputer BASIC on a micro.

This type of discussion needs the famous wall chart that listed many BASICs and what functions were available to each.
 
Many of those "new" X16 keywords were in QuickBASIC 35 years ago.

Heck, equivalents to most of them were in BASICA/GW-BASIC, or before that, TRS-80 Extended Color BASIC. (And of course Commodore's own BASIC extensions for the C16/Plus4 and the C128 also included graphics and sound commands.) Also, what's with that chart claiming that the original PET BASIC was missing a bunch of commands (RND, OPEN, CLOSE, INPUT#, PRINT#, etc.) compared to C64 BASIC? I assume that's just sloppiness because, well, no, as attested to by this pocket guide BASIC V2 for the PET 2001 was almost entirely identical to the version on the C64, right down to sharing the completely broken garbage collection routines. C64 BASIC is an extremely bad data point to include if you want to talk about the evolution of BASIC because, well, it's not evolved, at all, from a five year older version.
 
Whew, tough crowd :)

The PDF lost the reference links, so here they are:

"Illinois" 8008 BASIC (1974) [an actual SCELBAL/SCELBI BASIC for 8008 CPU didn't become commonly available until 1976]

IBM 5100 BASIC (PALM processor fully emulating System/3 minicomputer BASIC from c. 1967)
(I did get tired and missed a few keywords here that this system does support)

Altair 8800 BASIC (8080 CPU, soon-after became "Microsoft BASIC") [from MITS 1975, fantastic that they have a 100+ page manual about it]
(this reference described both the 4K and 8K variants, and the description of the NULL command is great as it mentions teletypes)

Commodore 2001-8 BASIC (6502 CPU) [this manual is dated Oct 1978]

Commodore CBM(PET) V4 BASIC (c. 1980)

Commodore BASIC V2 ("second release") for C64 (c. 1981)

Commander X16


For comparison, here is the NEC PC-8001 BASIC (while the document is 1981, the BASIC ROM for that system was ready in 1979 -- the manual here is just a subsequent English translation that earlier ROM capability). Note it supports a LINE keyword, even though the system doesn't really have a graphics mode (so using semigraphics).
NOTE: I noticed on the 1975 IBM 5100 with APL, it could plot graphs - it did so using essentially what we would today kind of call "ASCII art" (asterisks scaled appropriately along the x/y axis). But an implementation of BASIC could certainly do a similar thing (interesting in just the idea of "graphically" showing information in the early text-only modes)


For the PET: the 2001-8 predates the V2 BASIC that is on the later 2001-N's (at least to my understanding - it wasn't just a larger screen and keyboard, but updated ROM also).


For the X16, I only meant "new" relative to the C64 that it is commonly compared to - not to imply that it was a pioneer or innovator at introducing those commands (except its exclusive FM/PSG keywords specific to its audio hardware, and of course BANK to cycle through "segments" of 8K at $A000).


The main point was that the "very first" micro BASICs focused on a few essentials, largely borrowed from the minicomputer ancestors - with an implied goal of fitting into 4KB (since the ROM also has to fit the "screen editor" code). And those core features were that you can interactively enter in a program at all (screen editor), and then do "programmable calculator" type stuff. It was early "proof of concept" that those new micros could do actual "information processing" and not just blink lights.

It was after around 1979, as 16KB micros became far more common, that "BASIC's exploded" - not so much in "language design" but in expanding the set of tokenized codes. You essentially can map up to 256 tokens to hardcode into whatever feature of the system you want to support, referenced by some symbolic form of your choice. Like the Color Computer and its keyword additions to change colors and draw graphics - and it was these tailoring's that started to make the BASICs similar but incompatible with each other (which was mostly fine, a lot of generic BASIC-examples books and magazine listings many people could adapt as needed to their system - until PEEK/POKEs were involved).

And I agree on the criticisms of BASIC - it is an "awful language", except I think it misses the point that BASIC isn't really a language. It is essentially the same idea has an assembler - just p-code instead of op-codes (and someone chose some symbolic association of each p-code token -- likewise assemblers aren't standard either, the author chooses those mnemonics for the opcodes). On a system that doesn't yet have a text-editor or a file-system, I think BASIC is a suitable bare-minimum solution to do anything with that system (in a more abstract way -- i.e. to just "PRINT" something, without concern to the dozens of opcodes and port-mapped memory to the CRT to actually make that happen).
 
Last edited:
Are we being a little restrictive on the term "micro" here? I'm sure there must have been a BASIC for the DG MicroNova-CPU machines (e.g. DG Enterprise), for example. Or the BASIC written for Intellivision...
 
True BASIC is annoyed at being forgotten. True BASIC provided all the elements, including the full range of MAT functions, of minicomputer BASIC on a micro.

This type of discussion needs the famous wall chart that listed many BASICs and what functions were available to each.

I wasn't aware of True BASIC - it seems akin to QuickBASIC, in being a more robust structured "actual language." On the X16, they have BASLOAD - it's an unfortunate name, but it has that same intent of doing away with line numbers and being an even-more-symbolic BASIC for that system (BASLOAD programs get processed and interpreted into regular C64 BASIC V2, such that your long variable declarations like "current.x.position" gets auto-assigned to some 2-letter variable per the V2 restrictions -- but users don't really care about that, they just know they can use long variable names now).

But a problem with a singular standard: the "great thing" about BASIC was you scaled to the need of the system. A 2K BASIC just isn't going to have matrix operations, since the system probably doesn't have the RAM capability anyway to do much process with it. Speaking of which: when I say a "4K BASIC" or "8K BASIC" I'm talking about the ROM size of that BASIC. ROMs were still expensive back then (maybe not in the end-user cost of production systems in bulk, but in the development cost of burning new test ROMs - obviously that got cheaper further into the 70s, but for some shops it was a cost concern). So a 4K BASIC cost a certain ROM, and the system might only have 256 bytes of RAM -- which maybe isn't even enough to manage the basic needs of interacting with BASIC. But I see in the wikinote there were a few flavors of True BASIC (Minimum vs Full, for instance)

EDIT: so the general gist/concept of True BASIC I think did survive. It's just, yeah, they lost control of being a unified body to standardize it. Maybe another unfortunate fallout like VisiCalc - software laws just being different before around 1981.
 
Last edited:
Are we being a little restrictive on the term "micro" here? I'm sure there must have been a BASIC for the DG MicroNova-CPU machines (e.g. DG Enterprise), for example. Or the BASIC written for Intellivision...

Fair point - I'll look up what the Wang 2200 had in 1973 for its BASIC. There is a bit of liberty there in "micro" - such as perhaps not literally using a microprocessor, and maybe not necessarily being an "8-bit system." But for sure, "large systems" were running BASIC a decade before "the micros" (but with those line printers, and probably not "boot to BASIC" - I recall the PDP's always had to load it). Still, it's reasonable to say that a 256-byte KENBAK-1 would struggle to handle BASIC in a meaningful way, and it looks like the 8008's also barely handled it. (I suspect because it was probably realized that even if you pulled off a BASIC implementation, resources are still so limited it wouldn't be a very useful thing - as those 8008's maxed out at 16KB without a lot of effort).

EDIT: Here is Wang 2200 from 1976, so I can't really vouch yet on what they had in 1973. There is an IMAGE keyword (which actually the IBM 5100 has that too, a similar thing), a PLOT keyword (I'd suspect similar to the APL PLOT mentioned earlier). But the major thing missing is any trig functions (which is probably reasonable - that business was focused mainly on "string processing" wrapped as "Word Processing", and they did fairly well in that for about a decade). But it's an "expensive system" that puts it out of league of what I think most people would categorize as a "micro" (i.e. it was a business-class machine that did business letter-writing type stuff, not a dainty take-home gizmo).
 
Last edited:
The main point was that the "very first" micro BASICs focused on a few essentials, largely borrowed from the minicomputer ancestors - with an implied goal of fitting into 4KB (since the ROM also has to fit the "screen editor" code).
The very first ones, such as Altair BASIC, didn't include a screen editor because they were accessed over a serial connection, often using a printing terminal such as a Model 33 ASR. There were two versions of Altair BASIC, "4K" and "8K", because it had to be loaded into RAM and a fair number of users had only 4K of RAM. (And the 4K version left only about 700 bytes free, or something like that, for your program if you had only 4K of memory.)

The screen editors came with the next generation, the "1977 Trinity" (PET, TRS-80, Apple II). The MS 8K BASIC, when translated to 6502, actually took up about 9K because 6502 is slightly less compact than 8080 machine language. But that meant 12K of ROM anyway, which leaves plenty of room for the BIOS and screen editor, if there is one. (Actually the TRS-80 did have a "Level I" BASIC version with just 4K of ROM as well as a "Level II" BASIC version with 12K of ROM.)
 
For the X16, I only meant "new" relative to the C64 that it is commonly compared to - not to imply that it was a pioneer or innovator at introducing those commands (except its exclusive FM/PSG keywords specific to its audio hardware, and of course BANK to cycle through "segments" of 8K at $A000).
Isn't X16 BASIC based on Commodore V7 though? The comparison to V2 seems misleading.

And I agree on the criticisms of BASIC - it is an "awful language", except I think it misses the point that BASIC isn't really a language. It is essentially the same idea has an assembler - just p-code instead of op-codes (and someone chose some symbolic association of each p-code token -- likewise assemblers aren't standard either, the author chooses those mnemonics for the opcodes). On a system that doesn't yet have a text-editor or a file-system, I think BASIC is a suitable bare-minimum solution to do anything with that system (in a more abstract way -- i.e. to just "PRINT" something, without concern to the dozens of opcodes and port-mapped memory to the CRT to actually make that happen).
Have to disagree on both points there. BASIC (and assembly) are most certainly languages. Assembler syntax can vary, but opcode mnemonics should match the CPU documentation.
 
Isn't X16 BASIC based on Commodore V7 though? The comparison to V2 seems misleading.

The x16 Wiki and GitHub describe it as being derived from BASIC 2.0 for the C64 and they link to a repo they forked as the start.

That said, the Wiki also says best. effort was made to retain token compatibility for like-additions up through Commodore V10, so you could certainly describe it as *convergent* with V7.
 
For the PET: the 2001-8 predates the V2 BASIC that is on the later 2001-N's (at least to my understanding - it wasn't just a larger screen and keyboard, but updated ROM also).

No.

The original “chicklet” PETs that shipped with ROM 1.0 mostly ended up being upgraded to V2, which came out *around* the time they started offering the 2001N, but the two machines were compatible enough to run the same BASIC. (The 2001N is the machine that’s externally the same as a 2001 other than having a real keyboard in place of the calculator pad and built in tape deck.) Almost all the differences between the two versions are bug fixes; among other things the IEEE-488 driver is completely broken in 1.0.

BASIC *4* came out with the “large screen* PETs, and includes a fixed garbage collector plus extensions mostly aimed at making disk usage less arcane. It won’t work on the 2001 only because the original motherboard can’t accommodate the additional ROM space needed. (A 2001N can run it fine.)
 
And I agree on the criticisms of BASIC - it is an "awful language", except I think it misses the point that BASIC isn't really a language. It is essentially the same idea has an assembler - just p-code instead of op-codes....
Have to disagree on both points there. BASIC (and assembly) are most certainly languages. Assembler syntax can vary, but opcode mnemonics should match the CPU documentation.
Yes, BASIC and assembler are both languages. And no, BASIC is not at all the same idea as an assembler; for all its faults it's still a high-level language. In particular, if you leave out comments, macros, the specific names of symbols, and suchlike, there's a near isomorphism between assembly language and machine language; the same is not at all true of BASIC. (There are many very different sets of machine code that are valid representations of a BASIC statement; you can't "disassemble" BASIC that's been compiled to machine code and get back what is effectively BASIC source code.)

Opcode mnemonics are part of the syntax, and very often don't match the CPU documentation. I can't remember whether which of LDA A,#0 or LDAA #0 is official Motorola 6800 syntax—I think the former—but many programs use the latter and there's no issue there. For a less trivial example, I use only Z80 mnemonics for 8080 programming, even through they don't match the documentation of the 8085 CPU on my trainer board where I run them.

The key again is isomorphisms: there is a strict one between an 8080 opcode and its operands and its 8080-syntax assembly language representation, and the same between an 8080 opcode and its operands and its Z80-syntax assembly language representation. So all three represent the exact same thing, and you can derive any one from any of the others.
 
First ones, of those trying to base on a microprocessor.
Isn't X16 BASIC based on Commodore V7 though? The comparison to V2 seems misleading.

V2 was what they (8GB) got the license for and mostly what they started with on the X16. But, for example, that is why RESTORE was in red - the RESTORE on the X16 supports a line number parameter, which the original V2 did not. So, it is "closer" to V2 in a lot of ways, but then obviously with a lot of their own chosen extensions.

And I was checking out basic-1.901439-09-05-02-06.bin in VICE, and sure it seems there is a lot more there than the old manual mentioned (or maybe I overlooked some other section that referred to the other keywords). So fair, that 6502 port of MS-BASIC seemed fairly complete early on (and V4 BASIC on the PET grows to 12KB from 8KB, while all the EDIT ROMS remain at 2KB).
 
Back
Top