atari basic vs commodore

[Keatah]

The little bit of experience I had with both BASIC's.. I liked Atari better.

[José Pereira]

If you had C64 and because of its large, comprehensive and well explaining book that came with the computer you can, and also because of its hardware specifications, that you in days can design, put and move sprites (x,y) on screen, text and colours also, sounds and music,... by just for/let/next/data and poke does all that in all their gfxs modes, sprites size and moving, channels and notes.

With a couple of basic words you do all and on the end without thinking you are learning quickly and easily the machines adresses.

Anyone easy understand let/for/next/goto/gosub/return and this together with poke is all that is needed for anything, even (x,y) positioning.

This is maybe the reason why more people on C64 easily went to Assembly, Poke a,b is like a sta/lda...

 

Of course that on the A8 we also easily understand these words common to all Basics and we could get many things in all the gfxs modes like draw a line(s) but we don't had a book like that one of the C64. I had wrote many Basic listings but never/ever put a value on a poke adress and never understood why on the magazines were those large listings that had only a for/read/usr/next and then hundred of data lines that in the end and if all was entered good was an 'et voilá here's a game'.

And that's why some years later when a friend show me and gave me a photocopyed large book of Assembly I tried and even take it with me on a vacances to my grandparents village on an August that instead of playing soccer and other things I stayed allmost inside the house and never got anything.

Yeah, I know that maybe also a reason was that I never met anyone that coded anything seriously and in Assembly back then on any 8bits and even later on the 16bits and the MS-DOS.

 

And like me also my ZX's friends only displayed text and plot/draw lines.

Yes the A8 and Sinclair have really this similarity in their Basic that ended up beeing the same type that ours only/main differences are ours different gfxs modes and the own machines hardware specifications...

Edited January 26, 2017 by José Pereira

[JamesD]

 

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.

 

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

How? I don't think you understood the statement. My meaning was a bit different than your interpretation.

 

First, to address the top response "Two assembly instructions max". POKE doesn't just require a simple LDA STA type of operation. BASIC is an interpreter. That argument demonstrates a complete lack of understanding what is involved.

Executing a POKE requires reading the token, jumping to the POKE routine, parsing the address and value (is it a literal?, variable?, must it call another function to return a value?). Intermediate values have to be stored in RAM or on the stack. It may even have to convert between floating point and integers if a variable is involved. It isn't like machine language AT ALL in what goes on. You are kidding yourself in thinking it's like machine language.

 

To clarify my original point.

A built in specialized command is going to be faster than trying to duplicate it with POKEs.

The one significant advantage the C64 truly has over other machines is more advanced sprite hardware. It's pretty easy to use POKEs for that... but step outside that box and it's not so pretty.

Draw a line with POKEs. By all means... I'll wait.

And POKEing in machine language will probably require 50 to 100 POKEs before you can even use it... not to mention all the lines of DATA statements required.

In the 80s, If you didn't happen to have a magazine or BBS with a LINE function you could download, you'd better be able to write it yourself.

Bresenham line functions can be found all over the place now, but good luck in the early 80s.

Just calling the USR function after your line function is entered requires multiple POKEs to set the parameters before making the actual call.

A command like LINE(X1,Y1)-(X2,Y2),PSET (CoCo Extended Color BASIC syntax... not that familiar with Atari) is going to be faster.

And a more extreme example might be DRAW on the CoCo. DRAW can draw a screen filled with lines in seconds from a single statement. I had a Sylvester the cat graphic about 1/3 the height of the screen that drew in under a second just from a couple strings containing commands to move Up, Down, Left, Right, etc... It would probably take over 50 calls to a USR LINE function to draw the same thing. It's going to be slower and I've never seen the equivalent on the C64.

Plus I think I was drawing lines on the screen of my CoCo within the first half hour after hooking it up. No way you were doing that with bitmapped graphics on a C64.

[zzip]

 

How? I don't think you understood the statement. My meaning was a bit different than your interpretation.

 

First, to address the top response "Two assembly instructions max". POKE doesn't just require a simple LDA STA type of operation. BASIC is an interpreter. That argument demonstrates a complete lack of understanding what is involved.

Executing a POKE requires reading the token, jumping to the POKE routine, parsing the address and value (is it a literal?, variable?, must it call another function to return a value?). Intermediate values have to be stored in RAM or on the stack. It may even have to convert between floating point and integers if a variable is involved. It isn't like machine language AT ALL in what goes on. You are kidding yourself in thinking it's like machine language.

 

To clarify my original point.

A built in specialized command is going to be faster than trying to duplicate it with POKEs.

The one significant advantage the C64 truly has over other machines is more advanced sprite hardware. It's pretty easy to use POKEs for that... but step outside that box and it's not so pretty.

Draw a line with POKEs. By all means... I'll wait.

And POKEing in machine language will probably require 50 to 100 POKEs before you can even use it... not to mention all the lines of DATA statements required.

In the 80s, If you didn't happen to have a magazine or BBS with a LINE function you could download, you'd better be able to write it yourself.

Bresenham line functions can be found all over the place now, but good luck in the early 80s.

Just calling the USR function after your line function is entered requires multiple POKEs to set the parameters before making the actual call.

A command like LINE(X1,Y1)-(X2,Y2),PSET (CoCo Extended Color BASIC syntax... not that familiar with Atari) is going to be faster.

And a more extreme example might be DRAW on the CoCo. DRAW can draw a screen filled with lines in seconds from a single statement. I had a Sylvester the cat graphic about 1/3 the height of the screen that drew in under a second just from a couple strings containing commands to move Up, Down, Left, Right, etc... It would probably take over 50 calls to a USR LINE function to draw the same thing. It's going to be slower and I've never seen the equivalent on the C64.

Plus I think I was drawing lines on the screen of my CoCo within the first half hour after hooking it up. No way you were doing that with bitmapped graphics on a C64.

 

But every basic command is also tokenized and needs to be interpreted to, so that part is a wash. But most are more specialized and require additional processing than poke does. For example on Atari you can change colors with a setcolor command, or poke. The setcolor command has to compute the chroma + lumence values you passed, so it's going to be a little slower than just poking the value in.

 

The line drawing command you gave is a complex function and not something you would want to do with pokes, I agree. But Atari does have line drawing functions in basic (drawto), so you don't have to.

 

I was specifically referring to working with PM graphics. From my recollection, it's a poke to a single location to make them visible, another single poke to position them horizontally, pokes to color registers to change their color. Those things wouldn't be faster with specialized commands. Vertical positioning on the other hand would be because that involves moving multiple bytes.

[fujidude]

 

Those things wouldn't be faster with specialized commands.

 

But specialized commands are easier and more accessible to beginning programmers. Once you are a more advanced programmer who knows how the machine ticks under the hood, you can use something far more quick than BASIC such as C, assembly, or in the case of Atari; Action!. And those all beat the piss out of any BASIC interpreter in terms of performance. So once again: the primary design goal of BASIC is to be easy to use. In other words, it doesn't matter how much you can accomplish with peeks, pokes, or machine language subroutines if they are cryptic, non intuitive, and difficult for beginner or very casual programming, which they are. In fact, the design goal is better served with high level easy to remember commands even if they are slower than poking etc.

[zzip]

 

But specialized commands are easier and more accessible to beginning programmers. Once you are a more advanced programmer who knows how the machine ticks under the hood, you can use something far more quick than BASIC such as C, assembly, or in the case of Atari; Action!. And those all beat the piss out of any BASIC interpreter in terms of performance. So once again: the primary design goal of BASIC is to be easy to use. In other words, it doesn't matter how much you can accomplish with peeks, pokes, or machine language subroutines if they are cryptic, non intuitive, and difficult for beginner or very casual programming, which they are. In fact, the design goal is better served with high level easy to remember commands even if they are slower than poking etc.

 

But another design goal is to keep basic compact enough that it doesn't take too much memory from the user. If all those commands didn't fit into 8K, they'd probably have to go to a 16K ROM which means the Basic programmer would lose 8K more RAM. (out of only about 33K that basic was already restricted to) Atari Basic was already pretty comprehensive in the commands it had. PM graphics is one of the few areas it didn't address at all.

 

Later Atari Basic interpreters got around this problem by producing bank-switch cartridges (OSS), or using the extra 16K under the OS that basic normally can't touch anyway (Turbo Basic). But the problem with the later solution was it meant it wouldn't work on the 800, and it couldn't work with SpartaDos which also used this area of RAM.

 

Anyway, I thought it was Commodore BASIC that gets criticized for relying too much on PEEKS and POKEs, not Atari's?

[fujidude]

 

But another design goal is to keep basic compact enough that it doesn't take too much memory from the user. If all those commands didn't fit into 8K, they'd probably have to go to a 16K ROM which means the Basic programmer would lose 8K more RAM. (out of only about 33K that basic was already restricted to) Atari Basic was already pretty comprehensive in the commands it had. PM graphics is one of the few areas it didn't address at all.

 

Later Atari Basic interpreters got around this problem by producing bank-switch cartridges (OSS), or using the extra 16K under the OS that basic normally can't touch anyway (Turbo Basic). But the problem with the later solution was it meant it wouldn't work on the 800, and it couldn't work with SpartaDos which also used this area of RAM.

 

Anyway, I thought it was Commodore BASIC that gets criticized for relying too much on PEEKS and POKEs, not Atari's?

 

I can't speak for everyone, but I think they both get a fair share of criticism for that and I think they both could have used improvement. Apparently a lot of C64 and Atari8 users agreed, or else products like Simon's BASIC (C64), BASIC-XL, BASIC-XE (both Atari8), etc. wouldn't have sold. True, XL & XE were bank switchers, and I don't know about Simon's, but look what Avery Lee (Phaeron) has done in just 8K non banked! And he I'm sure he didn't have the resources Atari did back when they decided to get a BASIC for their machines. Although admittedly Atari got themselves into a tight schedule and Avery has had all the time he has wanted for Altirra BASIC, plus the benefit of a long period of time to learn about all the dos, donts and tweaks that allow it to be the good performer in a small package that it is.

Edited January 28, 2017 by fujidude

[phaeron]

True, XL & XE were bank switchers, and I don't know about Simon's, but look what Avery Lee (Phaeron) has done in just 8K non banked! And he I'm sure he didn't have the resources Atari did back when they decided to get a BASIC for their machines. Although admittedly Atari got themselves into a tight schedule and Avery has had all the time he has wanted for Altirra BASIC, plus the benefit of a long period of time to learn about all the dos, donts and tweaks that allow it to be the good performer in a small package that it is.

 

You're right, I didn't have the resources that Atari did back then -- I had a lot more! I had: a much nicer development environment, a practically instant macro assembler, a debugger more powerful than an In Circuit Emulator (ICE), a version control system, a reference implementation, an entire library of existing BASIC programs to test against, and the entire Internet to search for algorithms.

 

While the extended commands are nicer and friendlier, it is true that some of them are actually slower than PEEK/POKE. Others are faster because they're expensive to emulate otherwise, like MOVE and the bitwise operators, and others like BGET/BPUT are just a PITA to implement with USR. The one extended command I absolutely had to have, though, and the one I never forgave Atari for omitting, was the DIR command. The C64's way of faking a BASIC program for LOAD "*",8 was terribly goofy, but at least they didn't make you reload a DOS menu just to get a directory listing from the disk. If you were using stock DOS 2.0S with write verify on and a MEM.SAV file, this took F O R E V E R.

 

In the end, Atari BASIC was a little nicer than CBM BASIC V2, but both were still slow and limited. Applesoft BASIC actually worked better for me than either of those two, because the built-in monitor in the Apple II made it so much easier to enter assembly language fragments. I never had a viable setup to write assembly language programs for either the Atari or the C64 at the time, only being able to do so over a decade later with emulators.

[JamesD]

 

But every basic command is also tokenized and needs to be interpreted to, so that part is a wash. But most are more specialized and require additional processing than poke does. For example on Atari you can change colors with a setcolor command, or poke. The setcolor command has to compute the chroma + lumence values you passed, so it's going to be a little slower than just poking the value in.

 

The line drawing command you gave is a complex function and not something you would want to do with pokes, I agree. But Atari does have line drawing functions in basic (drawto), so you don't have to.

 

I was specifically referring to working with PM graphics. From my recollection, it's a poke to a single location to make them visible, another single poke to position them horizontally, pokes to color registers to change their color. Those things wouldn't be faster with specialized commands. Vertical positioning on the other hand would be because that involves moving multiple bytes.

Ultimately it's going to depend on what you are doing.

Do you have to poke more than 1 value to do what you want?

If the answer is yes... the complex command will probably be faster in most cases since it skips returning to the token handling.

Don't be surprised if setting the color through the complex routine is comparable to the poke. It depends on how complex the conversion is.

You might want to benchmark individual cases to see which is faster.

 

One small correction is in order for one of my comments.

The Atari USR function allows passing parameters without additional pokes.

[zzip]

 

I can't speak for everyone, but I think they both get a fair share of criticism for that and I think they both could have used improvement. Apparently a lot of C64 and Atari8 users agreed, or else products like Simon's BASIC (C64), BASIC-XL, BASIC-XE (both Atari8), etc. wouldn't have sold. True, XL & XE were bank switchers, and I don't know about Simon's, but look what Avery Lee (Phaeron) has done in just 8K non banked! And he I'm sure he didn't have the resources Atari did back when they decided to get a BASIC for their machines. Although admittedly Atari got themselves into a tight schedule and Avery has had all the time he has wanted for Altirra BASIC, plus the benefit of a long period of time to learn about all the dos, donts and tweaks that allow it to be the good performer in a small package that it is.

 

Well we do have better development tools today. When Atari Basic was created, Mac65 didn't even exist yet. Plus a programmer who is a 6502 wiz and has a passion for his/her project is going to achieve better results than some hired help back then for whom writing a BASIC interpreter was just another job

[+slx]

The best BASIC of contemporary home computers was probably BBC BASIC which could do inline assembly (although in a funny mix requiring to run sections twice with a loop to resolve labels) and had a sophisticated system for OS calls which were extensively documented. It had structured programming constructs and AFAIK even graphics commands abstracted from actual screen resolution. It would be very interesting to port this to the Atari, although that power came with the penalty of large size (16K ?) which left very little free RAM when using hi-res graphics.

 

I always wondered why Atari didn't license BASIC XL for the XEs, making it the V2 standard for Atari BASIC.

[zzip]

 

 

I always wondered why Atari didn't license BASIC XL for the XEs, making it the V2 standard for Atari BASIC.

 

I don't think they cared enough, they were more focused on the ST at the time. The XE line did little more than maintain compatibility with the XL line, apart from the 130XE memory upgrade. Adding a new basic would have broken compatibility. I recall it being a frustrating time for 8-bit users as Atari did the bare minimum to support the line

[fujidude]

I always wondered why Atari didn't license BASIC XL for the XEs, making it the V2 standard for Atari BASIC.

 

Because Mr. Jack would never spend a penny for a product that he already owned, even if what he owned was very inferior. Don't spend anything you don't have to. You can argue that was the right approach at the time, or not, but it's how he ran things.

[+slx]

 

Because Mr. Jack would never spend a penny for a product that he already owned, even if what he owned was very inferior. Don't spend anything you don't have to. You can argue that was the right approach at the time, or not, but it's how he ran things.

 

After listening to the ANTIC podcast for several thousand kilometers of commuting I do now understand the reasons. Jack Tramiel was after low production costs, not optimum quality. Considering the success of the C64 he might have been right as people didn't mind a very old and limited BASIC there (and in later years the percentage of people using their home computers for programming probably dropped anyway).

[zzip]

 

After listening to the ANTIC podcast for several thousand kilometers of commuting I do now understand the reasons. Jack Tramiel was after low production costs, not optimum quality. Considering the success of the C64 he might have been right as people didn't mind a very old and limited BASIC there (and in later years the percentage of people using their home computers for programming probably dropped anyway).

 

Yes, and also "built-in Basic" was a differentiating factor between home computers in the early 80s, but by the time Jack bought Atari, everything had basic, so it was no longer a competitive advantage that sold systems. People were starting to be interested in "what applications can it run?" rather than "does it have basic?", so there was no financial reason to invest in that.

 

And if anyone thinks Atari Basic is poor, ST Basic was much worse (and not built-in-- it felt like it only existed to check off a box). If you wanted to write Basic applications/games on ST, you bought GFA or STOS basic.

[+slx]

And if anyone thinks Atari Basic is poor, ST Basic was much worse (and not built-in-- it felt like it only existed to check off a box). If you wanted to write Basic applications/games on ST, you bought GFA or STOS basic.

 

That (and a girlfriend) were probably the reasons I mostly dropped out of programming after changing from the 800 to the ST. Over here one got a free copy of Omikron BASIC a few months after buying the Atari (as far as I remember because Atari BASIC did not really work correctly, at least with my Mega ST).

[JamesD]

The best BASIC of contemporary home computers was probably BBC BASIC which could do inline assembly (although in a funny mix requiring to run sections twice with a loop to resolve labels) and had a sophisticated system for OS calls which were extensively documented. It had structured programming constructs and AFAIK even graphics commands abstracted from actual screen resolution. It would be very interesting to port this to the Atari, although that power came with the penalty of large size (16K ?) which left very little free RAM when using hi-res graphics.

 

I always wondered why Atari didn't license BASIC XL for the XEs, making it the V2 standard for Atari BASIC.

I'm not sure I agree with calling it the best BASIC.

It was certainly fast, had some unique features, and supported additional looping commands.

But BBC BASIC lacked numeric formatting (PRINT USING), some of the more advanced graphics commands (CoCo's DRAW), and lacked advance music commands (CoCo PLAY), didn't support as much RAM as the Plus/4 (except BAS128), etc...

Ultimately... best for what?

 

A built in assembler is certainly nice to have, but the syntax seems a bit odd to me.

That may be nice to have, but the end result is easy enough to achieve without it.

Frankly, external assemblers support more advanced features and more standard syntax.

 

[+slx]

A built in assembler is certainly nice to have, but the syntax seems a bit odd to me.

That may be nice to have, but the end result is easy enough to achieve without it.

Frankly, external assemblers support more advanced features and more standard syntax.

 

 

Of course its usefulness depends on what you set out to do. My reasoning was based on little Johnny Englisch with his BBC having a nice and easy method to include some 6502 machine language in his BASIC program in a way that was much easier to understand than a couple of DATA statements or some graphics symbols in a string. Of course that wouldn't match MAC/65 or even Assembler/Editor and would not do for larger projects but 99% of Atari kids like me did not have either, at least in the early Atari days. The way it was set up on the BBC made the step into ML easier than most other computers.

 

But then, the BBC was basically built with teaching computers in mind and was in many ways an antithesis to the Atari, with lots of external ports, easy access to the motherboard for internal add-ons and programs delivered on plain ROM chips.

 

Don't get me wrong. I love my Ataris, the BBC falls into the "interesting then, now able to afford one" category.

[JamesD]

My very first assembly program used DATA statements and POKEd a USR function into a string.
Not that hard with the right book.

[flashjazzcat]

The inline assembler may have had severe limitations but as a learning tool I think it was pretty good. My first attempts with assembly language on the Atari (while I was using the BBC Micro at school) were conducted using data statements only because I didn't have an assembler at the time. In those circumstances, I would have availed myself of an inline assembler if Atari BASIC had offered that. In an ideal world, one would have already bought MAC/65 as a teenager, but I had to make do with what I had at the time at home (which was nothing for a while).

[JamesD]

Commercial assemblers were expensive. I think ones for the CoCo started at $50.
I remember using a BASIC assembler and disassembler from magazines.
*edit*
That would be about $125 in today's dollars.

Edited February 5, 2017 by JamesD

[flashjazzcat]

Yep: I eventually used some assembler written in BASIC until I finally shelled out for the Atari Macro Assembler. That was great but wouldn't run under SpartaDOS X, so I fixed the bugs in Charles Marslett's A65 assembler and added a macro preprocessor, etc. That (and typing in SpeedScript) was my introduction to big, stand-alone assembly language projects.

[Rybags]

$50 for an Assembler isn't too bad. I wanted Mac-65 on cart but only ever got a dodgy disk version, the cartridge version once landed here would have been closer to $150. Even the crappy Atari AsmEd was about $70.

 

I remember a few times just doing hand assembly. It's not too bad except for the branches and forward jumps.

[JamesD]

$50 for an Assembler isn't too bad. I wanted Mac-65 on cart but only ever got a dodgy disk version, the cartridge version once landed here would have been closer to $150. Even the crappy Atari AsmEd was about $70.

 

I remember a few times just doing hand assembly. It's not too bad except for the branches and forward jumps.

It was Radioshack's ROM cart editor assembler.

The disk based macro assembler I got in college was $100

I probably should have bought one of the $30 tape assemblers and spent the rest on a C compiler.

[zzip]

My very first assembly program used DATA statements and POKEd a USR function into a string.

Not that hard with the right book.

 

Same here. My book even had a type-in Assembler written in basic to help with the task. I wrote several ASM programs with it. But when the programs got too large, it was unmanageable. (no macros, no debugging tools, etc..)