Atari BASIC, was it intended as an interim BASIC?

[JamesD]

Atari BASIC may not have been the fastest 8-bit BASIC, but it was by far the most pleasant to program in. Immediate syntax checking, keyword abbreviation, built-in graphics, sound, and controller commands. It was pretty sweet.

I actually don't like immediate syntax checking. Once I got to typing in a program from a magazine I could type pretty fast and more error free the longer I typed. An occasional syntax error would break my rhythm, though I can see it being a benefit if you are writing a program from scratch.

Commodore BASIC, VZ BASIC, MC-10 BASIC, etc... are all Microsoft BASIC and have built-in graphics, so that isn't unique by any means and some versions included controller commands.

Only machines with programmable character sets support custom characters but you can directly type graphics into strings on all of them.

 

My biggest complaint with any BASIC is not supporting ELSE.

That shortens programs a lot but it seemed to be one of the first things dropped to squeeze BASIC into a ROM.

Several versions of Microsoft BASIC drop it as do many non-Microsoft BASICs

[JamesD]

Atari BASIC may not have been the fastest 8-bit BASIC, but it was by far the most pleasant to program in. Immediate syntax checking, keyword abbreviation, built-in graphics, sound, and controller commands. It was pretty sweet.

I guess you probably meant built in functions for drawing lines, etc...

That's certainly a nice feature but it's not unique to Atari BASIC.

 

Microsoft Level III BASIC had that for the TRS-80 Model I in 1978, Applesoft II had that, Extended Color BASIC, Commodore BASIC 3.5 (Plus/4), Sinclair BASIC (Spectrum), etc... so it's not unique.

Level III BASIC also supported software sprites (get and put commands, see the Atari equivalent in a thread I posted years ago), Applesoft II supported shape tables, and Extended Color BASIC supported both though it's DRAW command was immensely more powerful than shape tables since it used strings which are much easier to deal with.

 

[ricortes]

BASIC already had a terrible reputation by 1978 among professional programmers. Real programmers programmed in FORTRAN, COBOL, or C and system programmers programmed in assembly language. The 2600 had been out for a couple of years so even on the 6502 serious programming was not done in BASIC.

 

As has been pointed out, the original 800 and 400 were supposed to come with 8k and 4k of RAM. Adding a disk drive that did more then boot a game disk meant you had to do a RAM expansion and ~doubled the cost of a system.

 

So one of the answers to not making a doorstop was Memopad. So what type of DOS, editor, and compiler are you going to have on a 4k machine? Almost a joke right? Well one of the things BASIC does is give you a lot of bang for your RAM. You could actually do something useful with a BASIC cart and an machine with less then 16k. There were already a number of 'Tiny BASICs' around for precisely this reason. The tokenising process makes for pretty efficient use of memory.

 

Some of the decisions about the BASIC were probably based on a combination of these factors with a little bit of math nerd tossed in. For instance the extra precision of the Atari floating point routines at a cost of speed: It isn't like anybody is going to calculate the atomic mass of an element or do a moon landing with an Atari. Just implementing a command like CONT means you are storing and cataloging everything from variables to line numbers being executed, that doesn't come free. Even the built in screen handler is robust at the cost of speed. The non destructive cursor movement with the character underneath being flashing reverse video? Everything has to be stored and replaced rather then just replaced with destructive white space as you move the cursor. Every time you use a POSITION or LOCATE statement all of this overhead is added to the cost of doing business.

Edited November 15, 2015 by ricortes

[thorfdbg]

 

As has been pointed out, the original 800 and 400 were supposed to come with 8k and 4k of RAM. Adding a disk drive that did more then boot a game disk meant you had to do a RAM expansion and ~doubled the cost of a system.

 

So one of the answers to not making a doorstop was Memopad. So what type of DOS, editor, and compiler are you going to have on a 4k machine? Almost a joke right? Well one of the things BASIC does is give you a lot of bang for your RAM. You could actually do something useful with a BASIC cart and an machine with less then 16k. There were already a number of 'Tiny BASICs' around for precisely this reason. The tokenising process makes for pretty efficient use of memory.

 

Some of the decisions about the BASIC were probably based on a combination of these factors with a little bit of math nerd tossed in. For instance the extra precision of the Atari floating point routines at a cost of speed: It isn't like anybody is going to calculate the atomic mass of an element or do a moon landing with an Atari. Just implementing a command like CONT means you are storing and cataloging everything from variables to line numbers being executed, that doesn't come free. Even the built in screen handler is robust at the cost of speed. The non destructive cursor movement with the character underneath being flashing reverse video? Everything has to be stored and replaced rather then just replaced with destructive white space as you move the cursor. Every time you use a POSITION or LOCATE statement all of this overhead is added to the cost of doing business.

Actually, the reason why you had to add RAM for a disk drive was because most of the RAM (around 3K) was required for the FMS. If Atari would have added this to the ROM, then only disk buffers would be required.

 

However, it's probably likely that this option was not considered because disk drives were considered too expensive to be acceptable for the average consumer, and the professional use would have had the money to invest into a RAM expansion anyhow.

 

Pretty much any Basic implementation of that time tokenized its programs, though to various degrees, so that's not really unique.

 

However, BCD is not really a good choice concerning precision. The precision loss due to round-off is rather maximized by the basis-100 (yes really!) representation, and a binary representation would have been a lot better, and faster. BCD can represent decimal fractions precisely, but that's really as far as the advantage goes. Everything else is worse: Rounding error, speed, ease of implementation...

 

What is correct is, however, that many of the design decisions are really due to the desired robustness of the Basic. Nothing is stored as absolute addresses, so users can interrupt a basic program, add lines, remove lines, add variables and so on, and can *usually* expect that CONT continues execution. With a couple of exceptions...

 

However, even with that restriction, one can do better... Atari Basic was rushed out, not properly debugged, and lacked many optimization opportunities to give it a decent and competative speed.

[ZylonBane]

I actually don't like immediate syntax checking.

 

If you think it's better to not know about any syntax errors until you try to run the program, then you are a weirdo.

 

 

I guess you probably meant built in functions for drawing lines, etc...

That's certainly a nice feature but it's not unique to Atari BASIC.

I meant what I said, smrt guy. Built-in commands for drawing lines AND setting the palette AND playing sound AND reading game controllers. Very few other standard 8-bit BASICs had such a full complement of multimedia functionality.

Edited November 15, 2015 by ZylonBane

[ricortes]

Actually, the reason why you had to add RAM for a disk drive was because most of the RAM (around 3K) was required for the FMS. If Atari would have added this to the ROM, then only disk buffers would be required.

 

However, it's probably likely that this option was not considered because disk drives were considered too expensive to be acceptable for the average consumer, and the professional use would have had the money to invest into a RAM expansion anyhow.

 

Pretty much any Basic implementation of that time tokenized its programs, though to various degrees, so that's not really unique.

However, BCD is not really a good choice concerning precision. The precision loss due to round-off is rather maximized by the basis-100 (yes really!) representation, and a binary representation would have been a lot better, and faster. BCD can represent decimal fractions precisely, but that's really as far as the advantage goes. Everything else is worse: Rounding error, speed, ease of implementation...

 

What is correct is, however, that many of the design decisions are really due to the desired robustness of the Basic. Nothing is stored as absolute addresses, so users can interrupt a basic program, add lines, remove lines, add variables and so on, and can *usually* expect that CONT continues execution. With a couple of exceptions...

 

However, even with that restriction, one can do better... Atari Basic was rushed out, not properly debugged, and lacked many optimization opportunities to give it a decent and competative speed.

 

The tokenising statement was meant as a general statement for all platforms as it is routine in the implementation of BASIC. For example I believe Tom Pittman wrote a 2k BASIC for the COSMAC. Even today if you wanted to put a lot of functionality into a small memory footprint, BASIC or FORTH would probably be the tools of choice. Understand I am a big fan of structured programming so I wouldn't want to return to those days. I'm pretty sure there were BASIC compilers on CP/M systems at or about the time Atari entered the market. I don't really count speed as part of the reasoning behind the decision so much as BASIC just being something they needed as an ~adult version of MEMOPAD.

 

The 6 byte floating point numbers in the Atari are more accurate then the 4 byte floating point for just about every other system. Probably would have been better to have double precision option but defaulting to only using the more precise format was OK. More of a problem with using floating point for things like line numbers since you would never need a GOTO 40.456 statement.

 

One of the things I was told by an Atari insider was there was a 1:1 ratio of disk drives sold to Atari computers. That was probably the reason why the XLs were discounted to ~$100 but the disk drives always stayed ~$200. Kind of 'would you like cheese on that burger?' up sale marketing strategy. They probably made more money selling memory upgrades and disk drives then they did on the computers until Commodore came along and spoiled it with 64k computers.

 

It is kind of interesting to the nerd portion of my ethos, what kind of compiler/OS they could have had with 4k Atari 400 w/disk drive. An boot disk editor that runs in 4k, ditto for the compiler and debugger. A lot of people did start off with an ASM/ED cart and a cassette. Probably would have been much like that except a little faster I/O. A disk based tiny C that ran on a 4k Atari 400 in 1979 would have been neat for bragging rights. Sector based file I/O with designated portions of the disk for source and output maybe?

[JamesD]

If you think it's better to not know about any syntax errors until you try to run the program, then you are a weirdo.

I notice you cut off the rest of what I said.

 

Is calling someone a weirdo considered a personal attack?

 

I meant what I said, smrt guy. Built-in commands for drawing lines AND setting the palette AND playing sound AND reading game controllers. Very few other standard 8-bit BASICs had such a full complement of multimedia functionality.

You said graphics... you weren't specific.

And "standard" wasn't part of your original statement.

It's not like it helped Atari outsell the C64 or Apple II.

[kool kitty89]

 

If you think it's better to not know about any syntax errors until you try to run the program, then you are a weirdo.

Using a key (or key combination) to perform a syntax check rather than it being immediate and automatic might be more useful. Of course, some people (perhaps a lot of people) disabled the keyclick beeper line because they found it annoying and distracting as well. (the beeper's probably more useful on the A400 for those who don't touch-type, but not a big deal otherwise)

 

 

One of the things I was told by an Atari insider was there was a 1:1 ratio of disk drives sold to Atari computers. That was probably the reason why the XLs were discounted to ~$100 but the disk drives always stayed ~$200. Kind of 'would you like cheese on that burger?' up sale marketing strategy. They probably made more money selling memory upgrades and disk drives then they did on the computers until Commodore came along and spoiled it with 64k computers.

Similar tactic to what CBM was aiming at when they dropped the C64 to selling at/below cost with common/necessary peripherals making up the difference. (along with CBM published/licensed software sales)

That might be one of the better arguments for why the 600XL was discontinued too and the 800XL wasn't priced moderately higher (like $150, still well below the C64's typical $200 ish SRP in 1984). 64k Ataris were more likely to bait disk drive sales than 16k Ataris, especially in the short-term when Atari Corp needed to push up revenue ASAP. (still, the 600XL would offer a cheaper entry level option still driving SOME disk drive sales and much more so driving cart software sales, especially games -very, very few of which used more than 16k RAM)

 

That said, if that 1:1 ratio was less immediate and had a lot of initial owners sitting without disk drives (even in the mid 80s), that market strategy would take a bigger hit to revenue in the short run unless sales volumes REALLY went up. (in 1984 with Atari Corp's surplus of existing hardware, selling at/below cost to generate revenue would make some sense up to the point of getting close to shortages ... or unless the price drop didn't improve sales volumes much at all -ie sell nearly as many at $130-150, end up making the same or more income and use only slightly more warehouse space for the unsold units) I haven't seen detailed sales figures for that period though, but it'd be really interesting to see how well the price-slashing worked for sales. (I know it had a big impact in the UK/Europe at the time, but I mean in the US alongside the C64 and CoCo II and such)

Edited November 16, 2015 by kool kitty89

[+MrFish]

Using a key (or key combination) to perform a syntax check rather than it being immediate and automatic might be more useful.

 

There's an easy way to delay syntax checking: type your program in a text editor instead of the interpreter.

[FifthPlayer]

I actually don't like immediate syntax checking. Once I got to typing in a program from a magazine I could type pretty fast and more error free the longer I typed. An occasional syntax error would break my rhythm, though I can see it being a benefit if you are writing a program from scratch.

 

That makes you in the minority then. Nearly all of the magazines came up with their own checksumming utilities that would check your work as you typed in the code from the magazine - it's carrying the syntax-checking idea idea one step further. I used Compute!'s checksum tool a few months ago to type back in my own program that was published in their magazine 30+ years ago.

 

The popularity of the checksum tools suggest that "check as you go" was the preferred approach for many. I definitely appreciated syntax checking in Atari BASIC when I wrote code for it.

[ZylonBane]

You said graphics... you weren't specific.

 

I said "graphics, sound, and controller".

 

Whatever it is you're trying to do, you're doing it badly. And with a suspiciously flat affect.

[fujidude]

 

Nearly all of the magazines came up with their own checksumming utilities that would check your work as you typed in the code from the magazine - it's carrying the syntax-checking idea idea one step further.

 

It certainly is fair to debate the merits of immediate vs. delayed syntax checking. But, comparing magazine type ins and their check sum schemes isn't in the same league. The breaking of rhythm, or distraction from mental code flow is a valid point. I mostly prefer immediate syntax checking if available, but there are times when I do not. And, as Mr. Fish pointed out, for those times one can use a plain text editor. Magazine type-ins though are not a creative programming process. They are really just a data entry task. So there is no mental flow to distract.

[snicklin]

I did enjoy the full screen editor. It's a shame that it didn't have scroll bars back then though!

[JamesD]

 

That makes you in the minority then. Nearly all of the magazines came up with their own checksumming utilities that would check your work as you typed in the code from the magazine - it's carrying the syntax-checking idea idea one step further. I used Compute!'s checksum tool a few months ago to type back in my own program that was published in their magazine 30+ years ago.

 

The popularity of the checksum tools suggest that "check as you go" was the preferred approach for many. I definitely appreciated syntax checking in Atari BASIC when I wrote code for it.

Well, it is how modern programming with compilers is done. It would depend on how good a typist you are which approach you prefer.

*edit*

Well, technically a compiler checks the entire program for errors before you run it where you could end up with a piece of code with a syntax error in BASIC that you don't know about for some time, so that's a bit in between the two approaches.

Edited November 16, 2015 by JamesD

[JamesD]

 

I said "graphics, sound, and controller".

 

Whatever it is you're trying to do, you're doing it badly. And with a suspiciously flat affect.

The problem is you are looking for some ulterior motive that doesn't exist.

 

The post you got angry over was just me correcting the graphics part of my earlier post.

I was trying to point out that those features are in no way unique to Atari and the complete lack of support like the VIC20 and C64 is actually the exception rather than the rule.

Even the first Apple II had commands to draw lines and read the paddle controllers.

 

 

You get mad at me because you somehow think I was trying to misrepresent what you said and then you took something I said way out of context and throw in an insult.

Oh the hypocrisy.

Edited November 16, 2015 by JamesD

[flashjazzcat]

Well, it seems to me that a commentator remarked that he found Atari BASIC appealing because it combined graphics support with sound control, abbreviation, immediate syntax checking, etc. Nowhere do I see an assertion that graphics commands were unique to the Atari, nor that graphics commands on their own are the sole reason the commentator preferred Atari BASIC. Yet the rebuttals have comprised lists of other BASIC dialects which include graphics commands, and the repeated assertion that such things were not "unique" to the Atari.

[JamesD]

Well, it seems to me that a commentator remarked that he found Atari BASIC appealing because it combined graphics support with sound control, abbreviation, immediate syntax checking, etc. Nowhere do I see an assertion that graphics commands were unique to the Atari, nor that graphics commands on their own are the sole reason the commentator preferred Atari BASIC. Yet the rebuttals have comprised lists of other BASIC dialects which include graphics commands, and the repeated assertion that such things were not "unique" to the Atari.

Yup, I was making an observation which he seemed to take offense to.

 

Was I implying Atari BASIC was nothings special? It was better than some versions and worse than others.

He singled out features he seemed to think made it good and I was pointing out they were pretty normal and his response confirms my interpretation of what he meant.

 

...

I meant what I said, smrt guy. Built-in commands for drawing lines AND setting the palette AND playing sound AND reading game controllers. Very few other standard 8-bit BASICs had such a full complement of multimedia functionality.

 

You seem to have left off this:

 

 

If you think it's better to not know about any syntax errors until you try to run the program, then you are a weirdo.

...

We just had a difference of opinion and that was the response.

 

What I said he didn't fully quote and called me a weirdo for. The boldface text is all they quoted. Notice I said why and that I could see the benefit of it.

Did that really deserve an insult?

 

I actually don't like immediate syntax checking. Once I got to typing in a program from a magazine I could type pretty fast and more error free the longer I typed. An occasional syntax error would break my rhythm, though I can see it being a benefit if you are writing a program from scratch.

..

[Bryan]

Having worked with several BASICs back in the day, I loved Atari's syntax checking and full screen editing and I felt naked without it. Maybe a seasoned programmer might prefer something different, but I think it was a fantastic environment for the beginner (which, I would argue, is really the target customer for a pack-in language).

[Rybags]

The fullscreen editing was unmatched by any OS. One annoyance of the syntax checking was the highlighting which could get you into trouble sometimes since Basic doesn't like certain stuff done in inverse.

The error messages are somewhat unhelpful but even having 2 letter messages instead would have eaten valuable space from other things, and you soon enough memorized the more common ones.

[FifthPlayer]

 

It certainly is fair to debate the merits of immediate vs. delayed syntax checking. But, comparing magazine type ins and their check sum schemes isn't in the same league. The breaking of rhythm, or distraction from mental code flow is a valid point. I mostly prefer immediate syntax checking if available, but there are times when I do not. And, as Mr. Fish pointed out, for those times one can use a plain text editor. Magazine type-ins though are not a creative programming process. They are really just a data entry task. So there is no mental flow to distract.

 

Checksum schemes are very relevant to immediate-mode syntax checking. In both cases, they're designed to tell you that the data you've just entered is incorrect - as soon as possible.

 

The OP who first objected to immediate-mode specifically said it was a hindrance to data entry for type-in listings.

[FifthPlayer]

Well, it is how modern programming with compilers is done.

 

Nearly every modern programmer I know uses a syntax-highlighting editor of some sort that immediately points out typing errors - the modern version of immediate-mode syntax checking. And lot of them prefer IDEs that will identify many simple (and not-so-simple) programming errors well before they attempt to run their code.

[JamesD]

 

Checksum schemes are very relevant to immediate-mode syntax checking. In both cases, they're designed to tell you that the data you've just entered is incorrect - as soon as possible.

 

The OP who first objected to immediate-mode specifically said it was a hindrance to data entry for type-in listings.

I don't remember ever using one of those utilities that performs a checksum on what you type to see if it matches the magazine.

For long lists of hex numbers for machine code that would be perfect though.

It's just too tedious and you can loose your place on the page of the magazine.

 

 

Yeah, it was when I was typing in listings from magazines I felt the syntax checking would bother me.

The data entry description is pretty accurate, I wasn't really thinking about the code so much as the characters or words and wasn't looking at the screen repeatedly. Just type an entire page and then give my eyes a break.

 

I had to take typing in Junior High, before I ever touched a computer and spent a couple years typing my own code in computers at school before I got my own computer.

By that time I was a pretty good typist and could enter magazine programs pretty quickly without a lot of errors.

If you have to deal with an occasional syntax error you are looking away from the magazine, then you have to find your place again, etc...

 

There are good and bad points to either approach and i you aren't a good typist I can see the immediate check being better.

It also has the advantage of finding all syntax errors where ones found at runtime might not show up right away. If some little used piece of code doesn't happen to run before you think you are done debugging it could rear it's ugly head much later.

 

Just remember, if you screw something up but it is syntactically correct it still wont find that.

 

 

Nearly every modern programmer I know uses a syntax-highlighting editor of some sort that immediately points out typing errors - the modern version of immediate-mode syntax checking. And lot of them prefer IDEs that will identify many simple (and not-so-simple) programming errors well before they attempt to run their code.

Most syntax highlighting doesn't detect errors so much as it looks for language keywords, open/close scope, etc...

Some can provide some level of help with syntax for function/method calls when you are entering code which is very helpful but still no substitute for the compiler's checking.

Without a language with strong type checking it really can't do a full syntax check anyway.

The main thing is that you can just type away and go back and deal with errors later if you want.

 

[ZylonBane]

There are good and bad points to either approach and if you aren't a good typist I can see the immediate check being better.

 

No, there are only good points and no bad points, and what you said above doesn't even make sense. A good typist would (presumably, in your head) never make mistakes, so syntax errors would never be an issue.

 

Nah I'm kidding, I know you tacked that last part on there just to be smug.

[JamesD]

 

No, there are only good points and no bad points, and what you said above doesn't even make sense. A good typist would (presumably, in your head) never make mistakes, so syntax errors would never be an issue.

 

Nah I'm kidding, I know you tacked that last part on there just to be smug.

Actually I didn't but whatever floats your boat.

[kool kitty89]

 

No, there are only good points and no bad points, and what you said above doesn't even make sense. A good typist would (presumably, in your head) never make mistakes, so syntax errors would never be an issue.

 

Nah I'm kidding, I know you tacked that last part on there just to be smug.

 

I'm pretty sure I get what he's saying and a lot of it has to do with personal brain functionality (including ease of distraction). I've actually taken to drafting essays either in plain text editors or in word processors with error detection/correction disabled due to how much faster I can type that way. Then go back and spell/error check things (while also visually inspecting for errors the program fails to catch) after the fact, or at least after a large block has been typed.

 

It's the difference between 50+ WPM and ~20 WPM, or even slower as errors tend to be compounded when I get distracted. For me at least, it's a hyperfocus related behavior.

 

On the note of the keyclick beeper I mentioned earlier: this distraction problem (for me at least) is less significant for that given the beep is tied to the general flow of things just like any other keyclick sound. (and the pitch/tone isn't THAT much more annoying)

 

The very subtle red underlining used in firefox's spellcheck system is actually a good example of something not TOO distracting and easily able to be habitually ignored once you're used to it. (full inverted highlighting makes your own lines of text much harder to read -throwing off allignment as well as breaking flow)

 

 

 

Having worked with several BASICs back in the day, I loved Atari's syntax checking and full screen editing and I felt naked without it. Maybe a seasoned programmer might prefer something different, but I think it was a fantastic environment for the beginner (which, I would argue, is really the target customer for a pack-in language).

That's true for most dialects of BASIC in general, whether they're pack-in or not, granted some are more specialized for ease of learning and the like. (Microsoft's QuickBASIC seems to be like that)