29

Most major computer manufacturers/distributors in the 70's and 80's included BASIC with their computers. Some (as answers to this great question have detailed: Why was BASIC built into so many operating systems?) even dropped you into a BASIC prompt immediately upon turning the computer. However, there were some slight differences between BASIC that was shipped with Atari, Apple, Commodore, and Tandy computers (for example).

Why did these different dialects of BASIC evolve?

During that time, the underlying hardware for each model of personal computer did vary greatly. But is it unreasonable to think that BASIC should have been able to abstract those differences? Or was each version different for other reasons (hobbyist vs. business, etc.)?

  • 4
    they didn't evolve. they were made from scratch – Jasen May 14 '16 at 20:43
  • 6
    FWIW, those were not "early versions of BASIC". BASIC dates from the mid-sixties. – Drew May 27 '16 at 2:11
  • Which dialect of BASIC should be the one to use? – Thorbjørn Ravn Andersen Dec 16 '18 at 19:06
32

There are multiple reasons.

First, there was no standards body publishing an official definition of the BASIC language (initially the closest thing to a standard was the Dartmouth version for mainframe computers, eventually the 'de-facto' standard became Microsoft's version simply due to market share). This left people free to fill in perceived gaps in the language however they liked.

Second, different computers had different I/O systems and capabilities and therefore required at least some adjustment to be made. Because of the differences, and the fact that different people/groups were making the adjustments, you ended up with different commands being added (or the same command being added in different ways). This was especially obvious in commands like LOAD and SAVE (e.g. CLOAD "x" versus LOAD "x",1 to load from cassette) but could also be seen elsewhere, such as in graphics commands or record-based I/O features.

Third, different computers operated under different design constraints. If you are trying to fit BASIC into a 4KB ROM you are going to have to leave some things out (like floating-point arithmetic). If you have 8KB or 16KB available you can include more of the standard BASIC features and even have room left to add your own manufacturer-specific enhancements.

There are many other reasons but these are among the more significant.

Regarding abstraction: it turns out to be very difficult to do unless you already know in advance what the future direction of the language will be and can plan for it. When a language grows 'organically' (as BASIC did) you often discover too late that your initial approach wasn't the best, but for compatibility reasons you can't go back and change it.

  • 5
    A very good answer. The variants were tailored to match the underlying hardware as well as possible, so while general concepts carried over, anything specific, like graphics, IO, sound, and everything that provided "operating system" commands was implemented from scratch for given system, leading to a wild variety. E.g. Spectrum's exceptionally lousy keyboard necessitated a BASIC that would require as little typing as possible. – SF. May 12 '16 at 20:57
  • exceptionally lousy? there were worse rubber keyboards... ISTM that Sinclair decided not to parse text into tokens – Jasen May 14 '16 at 20:42
  • What I find perhaps most curious is that microcomputer BASICs didn't consistently handle "real-time" keyboard I/O. At a recent vintage computer fair, I was playing with an Altair 680 whose owner said there was no way to do character-at-a-time I/O from within BASIC. I would guess there should be some combination of peek/poke that could serve that purpose, but I don't really know. Any idea? – supercat May 15 '16 at 22:36
  • 1
    @SF.: The Altair 680 I was using had no way of knowing when a key was released, since it was connected to an ASR-33 teletype which sent a serial character at 110 baud on each keypress. – supercat May 16 '16 at 13:22
  • 4
    "perceived gaps in the language..." Of which there were many. Dartmouth BASIC was meant for teaching an intro-to-computing class. It was training wheels for computer programming. By the time you were able to comprehend GOSUB, you were supposed to already be transitioning to FORTRAN or COBOL or whatever real programming language you were expected to learn. – Solomon Slow May 18 '16 at 12:20
12

Although there were standards for BASIC available — ECMA-55, January 1978 [PDF], ANSI X3.60-1978 — development timelines were so short for home computers that manufacturers had to scramble for what they could get, but also tweak a few features so a BASIC demo could show off some of the computer's new features in the showroom.

Commodore's BASICs were notoriously feature-free, as Jack Tramiel didn't want to keep paying Microsoft for updates. In the UK, the BBC's education requirements meant that the Acorn BBC micro had to have a really solid BASIC. Millions of computers were sold on the convenient fantasy of "being educational", so a solid BASIC was important. International projects such as BASICODE attempted to standardize on top of all of the variants.

The only home computer (that wasn't sold as a game console) I know of that didn't use BASIC was the Jupiter Ace. It used Forth.

  • I'm not convinced with the statement Tramiel didn't want to pay for MS updates ... they could do it by themselves, but this would had took too much time to accomplish (even MS had to). They showed up later with CBM BASIC 3.5 and 7.0 and confirmed that they can do a lot of fancy things. Many improvements (updates) were ready to use since BASIC 4.0 right before a C64 hits the market, but I think it was only the minimalistic ROM layout and the lack of time CBM's BASIC 2.0 got so widely distributed by means of VC-20 and C64 models which settled the commonly know reputation as a poor BASIC variant. – Johann Klasek May 17 '16 at 16:36
  • I'm told that Tramiel makes the comment in this video, but I haven't been through all 92 minutes of it yet: computerhistory.org/events/video/75 – scruss May 18 '16 at 16:19
  • Sneaked through to the whole 92 minutes but Jack only mention how he bought MS BASIC: Gates wanted $3 per unit, but Jack was only able to give a fixed price of $5000 - it's rumored that this was it Jack was hated by MS later. ;) - see minute 34. Didn't found any other reference - or overlooked it. However, even they settled with $3 per unit, this wouldn't probably neither automatically include "updates" nor additional features. And again, BASIC 4.0 existed already before VC-20 and C64 and they left even the 4.0 features off intentionally for space reason. What else? – Johann Klasek May 19 '16 at 18:22
  • @JohannKlasek: The design of the VIC-20 could probably have accommodated another 4K of ROM easily (the machine had two 8K chips and one 4K chip) and I'm not sure how much bigger than that BASIC 4.0 would have been. RAM footprint may have been an issue, though it doesn't seem Commodore made any effort to minimize low RAM usage. The VIC-20 has 5K of RAM, with 3.5K available. Compare that to the Atari 2600 BASIC--128 bytes of RAM, but 64 available on a system that can show code in one window, variables in another, and output in a third. – supercat Oct 6 '16 at 16:20
  • @JohannKlasek: (though in fairness to the VIC-20, it can display 506 characters of output without counting against its 3.5K available, while every character in the 2600's output window counts against its 64 total bytes available) – supercat Oct 6 '16 at 16:21
8

I'll speak to the Atari BASIC issue.

MS BASIC for the 6502 was ported directly from the original 8080 code. On the 8080, the code was well under 8 kB, which allowed the complete BASIC interpreter and a number of OS-related extensions to be burned onto a single 8 kB ROM chip. On the 6502, where the machine code is not as compact, the code came in at about 7900 bytes, which didn't leave much room for anything else.

So MS decided to make two versions for the 6502, one at 7900 bytes with the original 6-byte floating point code, and a new version at about 8900 bytes that used a larger 9-byte format for floating point numbers. The later was intended to be used in 12 or 16 kB systems. These were known as the "8K" and "9K" versions, respectively.

When Atari licensed the 6502 version it was for a new console design that used 8 kB ROM cartridges. They decided to start with the smaller 7900 byte version, but they also wanted to add new commands to access the graphics and sound capabilities. In spite of (apparently) considerable effort through 1978, they failed to get all of this onto a single ROM.

One interesting feature of the original Atari 800 was that it had two cartridge slots. This was originally intended to solve this problem; one would hold the basic interpreter, and a second optional cartridge would include another set of commands to extend it. At some point they dropped this concept - which is good because it would have meant that the extended commands would never be available, as most of the machines sold were 400's which didn't have the second slot. It was really not well thought out. Some time later such a cartridge did appear, the Monkey Wrench, but these were very rare.

So instead they went looking for 3rd party companies that could fit a BASIC into a single cart. Sheppardson Microsystems (SMI) eventually won the contract. To make it fit, they dropped MS's system for handling strings and replaced it with a much simpler system using character arrays. They also moved several portions of the code out of the cartridge and into a separate OS ROM. This left the original OS shipping on two ROMS, an 8k with most of the system, and a separate 2k with the floating point routines.

This worked fine, and let the BASIC come in at just under 8 kB even with extensions like GRAPHICS and SOUND. But it also meant the BASIC was incompatible with the MS varieties. For instance, there were no LEFT/MID/RIGHT functions, which made porting MS programs rather hard. Also, because strings were arrays, you could not make "an array of strings", which was another widely used concept in many MS programs.

The original contract was signed sometime in the summer of 1978, and called for the final version to be delivered by April 1979. There was a bonus clause if they finished it early. Atari was planning on announcing the machines at the January 1979 CES show, so they were going to show their working-but-too-large MS version and then sell the machine starting that summer with the SMI version.

But what happened is that SMI worked hard and delivered a beta version in October so they could capture the bonus. Atari took that version to the CES. In the few months between delivery and CES, SMI found and fixed a number of bugs, one very nasty one in particular. However, when they delivered the update, they found that Atari had already started burning the October version to ROM, and so all the early machines shipped with the buggy version.

So that's the long version of why Atari BASIC is so different - basically because it is not from the same original code as most others which were licensed from the same original code base.

WAX ON

With the benefit of hindsight, we can say that the SMI supplied BASIC was terrible. In addition to being incompatible and buggy, it was, simply, very poor quality.

Many simple ways to speed up the code were not implemented, and the floating point routines were extremely slow, as they were not ported from the somewhat better MS versions.

As a result, Atari BASIC was by far the slowest of the 8-bit era. It always finished at the end of the Byte and CC benchmarks, even below a number of hand-held calculators!

Several replacements were offered over the years. Of particular note is TURBO-BASIC XL, which was fully compatible, offered a number of great extensions, and still fit into the same 8kB - in fact, you had about another 1700 bytes free for code! An unchanged Atari BASIC program would run three to five times faster in TURBO, putting it near the top of those same benchmarks. And then there was the compiler...

A number of the concepts in TURBO have not been used in other BASICs, and it would be interesting to see them ported over.

  • Very entertaining read, thanks for taking the time to write it out. You mentioned something other answers forgot, which is time constraints. – Rui F Ribeiro May 13 '18 at 17:20
  • I'd be surprised if most of Turbo-Basic XL's concepts weren't used in GFA-Basic, as they were both written by the late Frank Ostrowski. – scruss May 13 '18 at 22:14
  • @scruss - indeed, but I'm more curious what it would do to one of the MS offshoots. – Maury Markowitz May 14 '18 at 13:08
3

My very first computer was a TI Basic (Texas Instruments). Great little machine, came with cartridges you could plug in to play games. When you first booted up you were in Basic. I remember a few years later getting a Commodore 64 and that the instructions booklet that came with it had lots of different BASIC commands. They also included a bunch of programs you could just type in and save. These two machines were very different. The Commodore had a 5" floppy drive while the TI had a cassette tape player as a drive. I think a lot of the differences in hardware probably drove the different versions of BASIC.

  • Interestingly, although Commodore and TI BASIC's are both versions of Microsoft BASIC, TI BASIC actually had much better support for disk drives, in that it had file access structures that could support random access (OPEN #1 "DSK1:FILE" RELATIVE, INPUT, FIXED : INPUT #1 REC 10 A,B,C:CLOSE #1 for example reads three numbers from the middle of a file), which were entirely lacking from Commodore's version (and most other versions), which only supported LOADing chunks of data into memory on an all-or-nothing basis. – Jules May 13 '18 at 18:47
  • (Unfortunately, the TI disk drives were much more expensive than Commodore's, so fewer people had them available.) – Jules May 13 '18 at 18:49
  • @Jules That's not true. Commodore disk drives had relative access files from DOS 2 onwards. Commodore Basic <4 had no disk specific commands at all - you opened a special channel on the IEEE bus and printed commands to it which the disk controller would interpret directly. – JeremyP May 14 '18 at 15:59
  • @JeremyP: A curious omission from Commodore Basic was the lack of a command to attach console input to a file until further notice. The GET# command was implemented by attaching console input to a file, reading one byte, and resetting input to the console; when using disk I/O, this would result in a "talk" and "untalk" being sent to the drive for every byte, totally dogging performance. – supercat May 16 '18 at 19:01
  • @supercat Yes, I know all about that. When I was doing a project for my O level Computer Studies, I used GET# to read records from my database (because it was more flexible in terms of the length of records) and it was, as you put it, dog slow. My Dad told me to forget about flexibility and use INPUT# instead. The speed up was astonishing. – JeremyP May 17 '18 at 10:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.