atari basic vs commodore

[2600problems]

(i'm new so please inform me if i posted in the wrong spot)

 

commodore famously cut corners during the developments of the vic 20 and c64. I just want your guy's opinions on the BASIC programming language packaged with both these computers and the Atari line

 

how well it was implemented

if it was easy to use

how powerful was it

if you went insane trying to program with it (that last one is a joke)

also, your worst/best memory of it

 

 

 

[BillLoguidice]

To be fair (or not), the BASICs found on the VIC-20, C-64, and C-128 were simple evolutions of the same BASIC found on the original Commodore PET from 1977 (and of course there was basic compatibility between it all). It really only got pretty good (on non-PET computers) in the Commodore 128 version.

 

As for my memories, my first computer was a VIC-20, and my second was a C-64, so I had no real basis for liking/disliking the BASICs. It was just what I had and programmed in. In school, I programmed in BASIC on TRS-80 Model III's and 4's, and eventually Tandy Model 1000's. Those were all logical enough, but again, I don't recall thinking anything really positive/negative at the time versus what I was using on the C-64.

 

I think today, for many of us who have many different types of classic computers, it's a bit different. We have an actual choice. Back then, very few of us had multiple computer brands, or at least not multiple computer brands when they were commercially active/not on clearance.

 

I have yet to program much in Atari BASIC, but would certainly like to at some point (although my list of things to do at some point is vast). It's my understanding it's an excellent BASIC, although there are more challenges to my mind determining which version of Atari BASIC and on which computer model it would be best to program on (I have all the Atari 8-bits).

[fujidude]

I thought Atari BASIC was rather... well basic. But then what can be expected for something whipped together on a tight time-line and an 8KB limitation? It's pretty impressive given the constraints I guess though. Now then... I think another interesting, and related question, is how do the best after market BASIC offerings for the various systems stack up with each other? I've heard good things about Simon's BASIC for the C64 though I have no direct experience with it. I do know that BASIC-XL and XE by OSS for the Atari 8-bit are pretty damn fantastic, as well as Turbo BASIC XL (which has a compiler available too).

[2600problems]

(i'm new so please inform me if i posted in the wrong spot)

 

commodore famously cut corners during the developments of the vic 20 and c64. I just want your guy's opinions on the BASIC programming language packaged with both these computers and the Atari line

 

how well it was implemented

if it was easy to use

how powerful was it

if you went insane trying to program with it (that last one is a joke)

also, your worst/best memory of it

 

 

 

 

atari+jaguar=

[JamesD]

This is based on what little work I've done with various machines. I won't call myself an expert with any of them though.

Commodore BASICs prior to the Plus/4 were of the non-extended variety. By that I mean they didn't have enhancements for graphics or sound.

As far as the core language goes, they were pretty good, but a lot of things required an orgy of PEEKs and POKEs.
The DOS is cryptic. There aren't any commands like DIR, CAT, etc... and file handling is a little more complicated than on some machines.
Simon's BASIC and some sort of fast loader cart or ROM upgrade for the DOS (jiffydos) is in order if you want to make life easier.

Starting with the Plus/4 series, Commodore had a really good extended BASIC.
There are quite a few graphics and sound commands built in. It's a couple graphics and sound commands shy of being the best BASIC I've used though.
It adds some additional looping commands like you'd find with PASCAL.

The DOS has easy to use commands and makes the machine much more friendly.
The Plus/4 BASIC also supports more RAM than other 8 bit BASICs.

The Atari has an extended BASIC, so you can draw lines from BASIC and things like that.
But it also lacks some features. I'd have to compare feature by feature to see if it or the Plus/4 is better, but it's well ahead of the C64.
The biggest drawback is it's string handling. It's very different than other BASICs which makes porting code to/from the machine more difficult.
I haven't used the DOS enough to compare it to the other machines.
The file handling lacks some key commands and you have to resort to calling ROM routines.
Perhaps the biggest drawback besides the string handling is the speed. It's slow.
OSS BASIC XL and XE add commands that improve file handling and they improve the speed.

[fujidude]

Yeah 8KB Atari BASIC did not use the Microsoft BASIC way of string handling (most other BASICs did). It did include commands for graphics modes, plotting, lines, etc., but it lacked any for the player/missile (sprite) stuff.

[Rybags]

Atari Basic you may as well say is 10K actually. Which gave the advantage that some extra commands could be implemented. But much of that functionality is within the OS. Stuff like line-draw and file operations merely passes on the parameters to external routines which do all the work.

 

C64 also includes some Basic related stuff in it's OS so our advantage isn't that great insofar as Rom space. Overall Atari made better use of the default OS and Basic Rom available.

 

Though that said, efficient programming aimed at saving memory will often result in more execution time. Which is what we got. Atari Basic's space efficiency translates to slower execution but probably the biggest problem is the woeful floating-point package which effectively negates the ~ 55% normal speed advantage we have and more. There's also other inefficiencies such as the poorly executed line number search which always starts at the beginning of the program where at least on C= Basic it compares the high byte of the (16-bit binary) next program line # with the target and if the next line# is less it will start the search from the following line.

 

At the end of the day though, Basic is Basic and on a sub 20 MHz computer you don't expect or receive very fast program execution.

Edited December 18, 2016 by Rybags

[ggn]

 

atari+jaguar=

Hey man don't be sad, Jaguar does have a basic .

[thorfdbg]

CBM only licensed the Basic from Microsoft, so there is nothing remarkable that can be said about this Basic dialect. It's just straight Microsoft Basic, so straight that it does not make use of any of the features of the machine. All the basic primitives are there, but only that, and nothing beyond that. No graphics, no sound, nothing.

 

Atari did not license from Microsoft, but contracted SMI to provide a Basic in "last minute". For the short amount of time the Basic was created, it is fairly good, but rather unorthogonal compared to other Basic dialects of its time. The major drawback is that it does not support strings in a very useful way, and string arrays not at all. On the positive side, it supports at least some of the basic features of the machine such as sound and elementary graphics. This is mostly because the operating system supports graphics modes and graphics windows - unlike CBM, which had no support for graphics in its machine whatsoever.

 

[carlsson]

Microsoft BASIC is reasonably fast for its clock frequency, although nowhere near e.g. BBC BASIC which came a number of years later. Many people like to nag about all the POKEs required to access graphics and sound on the Commodore computers. However once you have learned the memory maps of the custom chips, it becomes a walk in the park to transition to machine code a little later. I can't speak for Atari programmers, but I know for ZX Spectrum people it is a completely different world once they need to relearn how to make user definable graphics, not to mention draw lines, circles, causing the beeper to make sounds etc.

 

The above reasoning could be used for the DOS too. It might seem cryptic to open a communication channel to the disk drive and send a text string instead of using a built-in commnd to rename or delete files or format the disk, but once you learned the syntax and the ROM calls into Kernel to set up files, your existing knowledge was easily transferred into machine code. One might argue that BASIC is not meant to be an entry point to machine code programming, but a significant number of dedicated users eventually ended up there. The fact that BASIC V2 lacks a way to display the directory without destroying the program in the memory is a drawback, but Commodore did include a small wedge you could load. Perhaps that is the bit of code I'd primarily liked to be seen incuded in the firmware ROMs.

 

BASIC extentions, no matter if they were first or third party generally had a hard time to take off. In the case of the C64, it didn't help that Commodore themselves marketed multiple extentions overlapping eachother, instead of aiming for just one. Apart from drawing hires graphics, which is cumbersome on the C64, I find most of those commands setting up a sprite or playing a sound to be syntactic sugar, but then again I've already learned all the memory addresses and POKEs required to do that. Actually commands for tracing execution, renumbering lines (including GOTO and GOSUB which sometimes were overlooked), merging multiple programs into one etc are the ones I'd primarily use in an extention, and those are more development tools than commands the final program requires.

 

String handling and variable matrices indeed are some areas where Microsoft/Commodore, Atari, Sinclair and possibly other implementations differ. I've written a bunch of crap games for the Speccy, and sometimes found its way of handling strings and matrices much nicer than the Commodore does it, but also sometimes it can be very cumbersome. I suppose an interpreter that has multiple ways of doing the same thing is asking for a bit too much. I can't recall if there ever was an ANSI standardisation on strings and variables.

 

While the editor only allows lines up to 80 characters (88 on the VIC-20), BASIC on the Commodore can handle lines up to 255 tokens. Some hacks bypassed the editor limit. I understand other BASIC implementations may allow even longer lines, if you are able to fill up more room. This may be one area where various Atari BASICs are superior.

[ricortes]

If you remember that BASIC was developed as a learning or introductory tool rather then something to work in professionally.

 

"how well it was implemented"

Atari BASIC because of its use of floating point math for things like line numbers is slower then it has to be. This was 1979 so there was no clear method of doing things like string handling or how much accuracy was going to be needed in calculations. BASIC came on a cart and Atari BASIC wasn't the only one available. In this sense, the Atari Market chose Atari BASIC as the preferred language over Microsoft BASIC.

 

"if it was easy to use"

 

Atari was easier to use to get at the heart of the machine. This was due in large part because of the OS and various screen modes that were available.

 

"how powerful was it"

 

The feature that makes most programs written in Microsoft BASIC run into problems when translated to Atari are string handling, specifically arrays of strings. This made it so using Atari BASIC to write things like data base programs, RPGs, text adventures, a little harder and more complicated. Once again, as a learning tool in this instance MS BASIC was superior. The feature often used with Atari BASIC is you are allowed to have strings 32k in length. While the advantages of this for advanced programming techniques like embedding machine language code or data in a contiguous and safe block of memory, it was not a good trade off for a beginning programmer.

 

Once again, Atari does have MS BASIC which allows it to run just about anything written in vanilla MS/Commodore BASIC, it is just that practically no one saw an advantage to MS BASIC over Atari BASIC so to this day there are few apps written in it or MS BASIC carts for the Atari compared to Atari BASIC carts.

 

Just for any example, several years ago I found a text adventure game that someone said they had found on a print out and typed in for Commodore PET<?> I plugged a MS BASIC cart into my Atari and I don't recall having to make many if any changes to the code to get it to run.

[JamesD]

A few other ramblings about these BASICs.

Commodore purchased Microsoft BASIC for a flat price for the PET. They had the right to change it but chose not to enhance it until the Plus/4, because you know... money.
Microsoft's BASIC is pretty decent but it varied in several ways on different platforms.
There are some variations in commands, and the 6502 versions are missing some features vs Z80 or 6809 to squeeze the code into ROM.

The OSI version of MS BASIC, used single precision math. I'm guessing they originally planned on supporting single and double precision like the Z80 version, but changed their minds due to the ROM space it would require with the 6502. Other 6502 versions use a precision between single and double.
Single is faster, double is more accurate... so you have a trade off. FWIW, the 6800, 6803, and 6809 versions of Microsoft BASIC also do this.
I think Atari Microsoft BASIC supports single and double precision but I've never used it.

One shortcoming in the core 6502 Microsoft BASIC language Commodore purchased, is the lack of an ELSE statement. IF...THEN...ELSE lets you write code with fewer line numbers. Fewer line numbers can make for smaller code and faster as well. Fewer line numbers mean fewer line numbers to search through for every GOTO or GOSUB. But you probably won't notice unless you have a large program. Since Atari BASIC doesn't have an ELSE either, it's a wash between the C64 and Atari in this respect.
One of the additions Commodore added for the Plus/4 is the ELSE statement. I'm guessing Atari Microsoft BASIC supports it, but I'm not sure.

Another notable omission from Commodore and Atari BASIC is PRINT USING. It allows easy formatted printing of numbers for the screen, files, etc... This is very useful for business software. PRINT USING was also added to the Plus/4 version of BASIC, and I believe Atari Microsoft BASIC supports it.

The line length limitation on the VIC and C64 is due to the on screen editor. Microsoft BASIC uses a buffer for inputting data and lines. Once you hit return while entering a line, it tokenizes the buffer and places it in memory. The screen editor is limited to a certain number of lines on screen (3 on the VIC, 2 on the C64), and the buffer size is designed to match the screen. On the TRS-80 you can cram 250(?)+ characters on a line. The TRS-80 editor isn't as convenient as an on screen editor, but for lines with DATA statements or long strings, it's nice. When combined with the ELSE statement, you can put some pretty complex code on a single line.
Funny thing though, the MS interpreter itself doesn't care so about exceeding the short line length.
If you can tokenize longer lines, it will run the code. The interpreter's line length limit should be similar to the TRS-80.

There are many ways MS BASIC could be sped up, I'm not sure it would fit in the same size ROM though.
thorfdbg was working on an Atari BASIC replacement (BASIC++?) that was significantly faster than Atari BASIC.
Not sure what the status of that project is. I haven't seen posts about it since 2015.

[flashjazzcat]

Altirra BASIC is a ground-up reimplementation of Atari BASIC with faster execution, great compatibility and many useful extras (IF, ELSE, PMG control, etc) which fits into the same 8K ROM space and works with a stock OS if required. I don't use BASIC often but when I do, I use that.

[carlsson]

According to the late Jim Butterfield, Commodore paid Microsoft an additional fee in 1978/79 to get BASIC updated from V1 to V2, and this is when the Easter Egg was added. I'm not sure whether the V4 found in CRTC PETs was rolled out by Microsoft or a derivate by Commodore themselves, but it is the version that got stripped down to the V2 used in the VIC and C64. The linked page mentions at least two source drops to Commodore, so perhaps eventually they learned to alter it themselves. It would also open up for deviations from the Microsoft implementation if new commands and variable structures were added, but perhaps that was no serious issue.

[fujidude]

Altirra BASIC is a ground-up reimplementation of Atari BASIC with faster execution, great compatibility and many useful extras (IF, ELSE, PMG control, etc) which fits into the same 8K ROM space and works with a stock OS if required. I don't use BASIC often but when I do, I use that.

 

Says the most interesting man in the world. Being that you're in the U.K., I'm not sure you'll get the reference, so I'll add something below.

 

[JamesD]

Altirra BASIC is a ground-up reimplementation of Atari BASIC with faster execution, great compatibility and many useful extras (IF, ELSE, PMG control, etc) which fits into the same 8K ROM space and works with a stock OS if required. I don't use BASIC often but when I do, I use that.

The only manual I could find doesn't list ELSE

*edit*

It's not IF THEN ELSE, it's IF ELSE ENDIF

Edited December 25, 2016 by JamesD

[flashjazzcat]

Says the most interesting man in the world. Being that you're in the U.K., I'm not sure you'll get the reference, so I'll add something below.

 

It took me a couple of minutes of Googling to figure out the reference, but yes:

 

[carlsson]

It occurred to me that if a Bosnian and a French form a family and have children, one of them could be named Pascal Bašić.

[fujidude]

It occurred to me that if a Bosnian and a French form a family and have children, one of them could be named Pascal Bašić.

 

Hardy har har.

[sack-c0s]

Commodore basic v2 was great. For me it was the best thing ever.

 

Why? Because if they'd done a 'Proper' basic like the Acorn/BBC machines had then maybe I wouldn't have thought 'Seeing as this is just a glorified assembly language program running at a fraction of the speed I might as well learn to program properly in Assembler' and things might've been very different for me.

[zzip]

Yeah 8KB Atari BASIC did not use the Microsoft BASIC way of string handling (most other BASICs did). It did include commands for graphics modes, plotting, lines, etc., but it lacked any for the player/missile (sprite) stuff.

 

It didn't have explicit PM commands, but you could still put your PM bitmaps into data statements and move them around with pokes to the right places.

[fujidude]

 

It didn't have explicit PM commands, but you could still put your PM bitmaps into data statements and move them around with pokes to the right places.

 

True, but that's kind of like saying any BASIC that can poke a value directly into memory has no or very little limitations. The truth is, once you are getting into manipulating the computer at that level, you pretty much need the same knowledge of the computer's inner workings as is required to just write it in assembly in the 1st place. The point of BASIC is to be suitable for beginners (thus the B in its name).

[JamesD]

POKEs are also a lot slower than specialized commands

[zzip]

POKEs are also a lot slower than specialized commands

 

How is that possible? it's literally sticking a value in a memory location. Two assembly instructions max. (load and store). Most other commands have to do additional operations on the data.

[José Pereira]

POKEs are also a lot slower than specialized commands

How? I'm also seeing like @zzip, isn't there anyother basic word that is more related and direct to Assembly as POKE, maybe USR on A8 or SYS on C64 Basics...