Atari Languages

Opening the mailbox has become a bit like Christmas, with users sending in their latest code and accomplishments, plus new product announcements. Here's some of the best we have seen.

Drew Holcomb sends a very nice graphics demonstration (Listing 1) which is worth the five minutes it takes to type in.

Thomas Marshall (those of you on the CERL PLATO network system know him as marshall/phystemp) sends in the fine program in Listing 2 which uses the DLI routine from the December column. It puts a 128-color menu onscreen, then allows the user to move a cursor around the colors. When the user settles on a color and presses the button, the decimal value of the color (for use in SETCOLOR) appears in players on the top and bottom of the screen. There are some very nice techniques being used here; the program deserves a good look. Thanks Tom.

Dennis Baer (868 Main St., Farmingdale, NY 11735) has Algol for the Atari. According to his letter, it supports all I/O and graphics also. He also has a word processor for the Atari written in Algol. Since there are quite a few folks familiar with Algol, you might want to get in touch. He mentioned he is interested in beta-testing his product.

The Young People's LOGO Association wants to hear from people interested in Atari Pilot. Contact them at 1208 Hillsdale Dr., Richardson, TX 75081. They have a very good newsletter and a great deal of interest in the Logo language.

Atari in Europe

Finally, Nigel Haslock in Switzerland wrote to give me details of the European Ataris. Software houses may be quite interested in this information. He writes:

I have also received a great deal of mail concerning piracy and disk copy protection, which Nigel mentions. He tells of not being able to fix US-version Atari programs to work on the European Ataris because of the copy-locks placed on them. He has a good point.

There is a European market looking for software. Besides the obvious language problems, software houses have another worry--will their software work as it is with a PAL TV?

Atari has provided a hardware location to determine if a given machine is PAL (European) or NTSC (North American); it looks as if it's time to start writing software to check it.

Atari Basic

For those of you with new Ataris, here is a short and highly opinionated discussion of the various languages available for your use. It may serve to clear up some of the confusion you may have over which language is best for you to buy and use. Doubtless, there will be those who will disagree with me; feel free to write and let me know if you do.

Atari Basic, in the 8K cartridge is the original language for this system, developed in a great hurry for the unveiling of the new Atari machines back in 1978. Like most things done in haste, it lacks something. In this case, speed and the fixing of obvious bugs were neglected to the point where the whole product was compromised.

All arithmetic done in this Basic is done in 6-byte BCD. While this gives great accuracy, it also slows execution to a crawl. Atari 8K Basic is the slowest Basic I have ever used. To be sure, all computers have a tradeoff between memory use and speed, but this is a little ridiculous.

Add to this the many known bugs that will crash the machine, the slowness and occasional inaccuracy of the floating point operations, and numerous other flaws, and it just isn't much of a language. It could have been done better.

Unfortunately, so much of the available software uses the Basic, and even the bugs (remember the old saw about "documented bugs" becoming features in the next version), that Atari can't fix it. We're stuck with it. Too bad.

For speed reasons, it is just about impossible to write professional software in Atari Basic; any assembly program runs so much faster than the Basic that there is no comparison. Games written in Basic are easily identifiable by their slow speed.

In all fairness, the Atari Basic cartridge was meant for small Basic programs, not the huge amounts of code it is sometimes asked to execute, so it must be forgiven. The overall design structure is just wrong for fast program execution.

In conclusion, I wish it were better, but we are stuck with it. Great things have been done with the computer in spite of the Basic, and many Atari users have been forced to 6502 Assembler because of it.

Speaking of which...

Atari 8K Editor/Assembler

The 8K Editor/Assembler is a close relative of the Basic cartridge. It is absolutely unacceptable for major software development. I can remember delays of up to an hour assembling large programs, and I have heard many other horror stories. This cartridge is also 8K and has bugs.

For instance, any CPY instruction hangs the TRACE function. This cartridge has inspired many software houses to come out with their own assemblers, some of which are very good. The Atari cartridge has a handy debugger, but as an assembler, (how do I put this tactfully?) it is useful only for assembling small subroutines for Basic.

One good thing about the Basic and Assembler/Editor cartridges is that there are now books designed to help the beginner get going with both of them. This is a good way to learn about the Atari and to get started but don't limit yourself to these products once you are past the beginning stage. Another advantage is that they are cartridges, so you don't have to buy a disk drive or more memory in order to run them, as is the case with most other languages.

The above products are supported by a company called Optimized Systems Software, located in Cupertino, CA. OSS also markets a 16K disk-based Basic known as Basic A+ and an assembler in their operating system called EASMD. Lo and behold, Basic A+ and EASMD are so close to the original cartridge code that they even have the same bugs.

The Basic is just as slow, but it does have new commands for handling players and missiles and disk I/O. It is a big step up from the original Basic, but still needs work. I would like to see integer variables and something to speed up the execution?

Microsoft Basic

Atari Microsoft Basic is the Basic that Atari should have released initially. It is a 19K disk-based Basic. Add to that about 8K of DOS which must also be booted with it, and the result is 21K of user memory available for the programmer on a 48K system or only 13K on a 40K system.

That could be hard to live with. For instance, if you go into graphics 8, you have only 13K left on the 48K system, and only 5K on the 40K system. Still, Microsoft Basic is a very powerful and convenient language to use, and I have found few bugs in it. But don't get it unless you have 40 or 48K.

Microsoft Basic has integer variables which are very fast, PRINT USING for business applications, and 4- or 8-byte accuracy (whichever you select), which speeds everything up. It is very much like TRS-80 Basic or Applesoft. Best of all, it has several nice features for player missile graphics, character set redefinition, and other Atari-specific capabilities.

I like it, and try to use it whenever I have to do anything serious in Basic. While the bootup process takes a while, the time saved in program development is worth it. Any professional developer should seriously consider Microsoft Basic.

A 16K single cartridge (yes, you can put 16K on a single cartridge, check the hardware manual for details) version of Microsoft Basic is planned, but some features, such as renumber or PRINT USING, may still have to boot in from disk. More on this later; things haven't settled down yet.

Microsoft has extremely good documentation which looks even better when compared to the original Basic document. It was this documentation that was responsible for the delay in delivering the product; the disks have been ready to ship for some time but the manuals weren't. Considerable time and effort have gone into them, and it shows. Good job.

Atari Macro Assembler/Editor

The Atari Macro Assembler/Editor is a very, very powerful disk-based assembler, which is a joy to work with. Light years beyond the original cartridge, it is extremely fast; it will completely assemble 100 pages of code in six minutes. It features support for independent files with Include, macros, systext files, and raw speed. I have discovered a few trivial bugs in it, but this is one product I can rave about without reservation. I have worked with it for more than four months and like it better each time I use it.

If you have any serious assembly language programming to do, get the Macro Assembler/Editor.

The Editor is also quite nice, and is being sold through APEX. It is a powerful and reasonably fast editor for developing text with no line numbers. This allows easy input of data, since you need not bother to strip off extraneous line numbers. Pascal, the assembler, and future goodies rely on the editor to generate source text.

Atari Pascal

Atari Pascal is brand new, and not reviewed yet. It is not a UCSD Pascal, but those of you who like Pascal might want to look it over and send me comments.

Atari Pilot

The Atari version of Pilot is a pretty clean implementation of the famous educational language. I have not done much with it but the feedback I have gotten is all good. The documentation in particular is extremely well done.

Forth

To understand "Why Forth?" you must look at some basic programming philosophy. Many languages are unsuitable for serious software development work. For most high speed games, for example, even Microsoft Basic isn't fast enough. For business applications Pilot is out, and so on.

Well, Forth is difficult to describe, but let me try: it is a stack-oriented language which you define yourself. You start with a basic set of commands (input, output, arithmetic), and define your own commands (called words) from there. The language executes extremely quickly, compared to everything except assembler, and once you get into it, is much easier to write and debug, which drastically cuts development time.

Assembly language provides the ultimate in speed and machine control, but is not much fun to work with. Even with the very good macro assembler, debugging assembly code (especially without very good debug tools) is a frustrating, time consuming process. Forth helps the user get away from that.

The Atari is a very good machine for Forth. There are so many unique hardware features that a generic language such as Basic isn't good at handling them all, but Forth is.

You can define language commands to deal with players and missiles, character sets, vertical blank interrupts, and whatnot. Each user's Forth thus ends up growing along with him.

Sandy and I had been thinking of going to Forth, but it seemed like too much effort to get started. There were even two Atari Forths on the market: QS Forth and Pink Noise Forth. Yet I had a difficult time following QS Forth, even with its reasonably good instructions, and it seemed more a generic Forth implementation than an Atari-specific Forth. So we waited.

Two things changed our minds: 1) The book Starting Forth by Leo Brodie, from Prentice-Hall, which is simply superb and easy to read (complete with really, really good illustrations), and 2) VALForth, a new Forth based on figForth, which is currently being sold by APEX.

VALForth has commands designed especially to take advantage of the features of the Atari. It also includes a character set editor, easy player graphics, a very nice screen editor, and several other useful features. We were shown a preliminary version, and after reading the Starting Forth book, could dive in immediately and do things.

The transition is reasonably painless, and the power of the language unfolds around the user; I'm very happy to be working in it and we plan to write our next game in VALForth. The stack orientation is easy to get used to, especially if you just consider the stack data as part of the instruction set format.

The development speed of Forth has not been overlooked by Atari. Atari's Coin-Op group has a semi-legendary "Coin-Op Forth" which is supposed to be quite something to use. The Atari demo disk with the "Disco Dirge" background music is all "coin-op Forth." Rumor also has it that many of the new Coin-Op games are written in Forth (Battlezone, for one). This wouldn't surprise me; it's a powerful language.

As a point of philosophy, we feel that as Atari programmers we began in Basic, moved to 6502 Assembly for speed, and now, after experiencing assembly debugging, are moving to Forth to reduce the amount of time we must spend on programming. We have great hopes for VALForth and what we have seen already is very worthwhile.

Listing 1.

WHEELS 

5 REM WHEELES WITHIN WHEELS BY D. HOLCOME
10 GRAPHICS 23:Y=INT(RND(0)*16):FOR X=708 TO 711:POKE X,Y*16+12:NEXT X:COLOR 1:DEG
20 FOR X=1 TO RND(0)*4+2:A=INT(RND(0)*5)*1000+2000:POKE 77,0
30 B=(INT(RND(0)*11)*INT(RND(0)*5)^2-79)*INT((RND(0)*2)-1)/(A/1500)+79
35 C=(INT(RND(0)*4)*INT(RND(0)*5)^2-47)*INT((RND(0)*2)-1)/(A/1500)+47
40 D=0:E=INT(RND(0)*3)-1:IF E=0 THEN 40
50 FOR Y=0 TO A STEP 15:F=F+E:IF F<1 THEN F=3
60 IF F>3 THEN F=1
70 COLOR F:D=D+0.08:DRAWTO B+D*COS(Y),C+D*SIN(Y)
80 NEXT Y:NEXT X
90 FOR Z=0 TO 9
100 A=RND(0)*16:B=RND(0)*9+4:C=RND(0)*30+10
110 FOR X=0 TO 1500/C
120 FOR Y=0 TO 2:SETCOLOR Y,A,B:FOR F=0 TO C:NEXT F
130 SETCOLOR Y,0,0:NEXT Y:NEXT X:NEXT Z:GOTO 10

Listing 2.

COLOR128 

19000 REM The following subroutine can
19001 REM be added to program 5 of
19002 REM ATARI OUTPOST in the December
19003 REM issue of Creative Computing
19004 REM It addes utility to displaying
19005 REM the 128 colors available to
19006 REM the Atari. By plugging a
19007 REM joystick in port 1 the sub-
19008 REM routine will give you the
19009 REM specific number one needs to
19010 REM poke in the color registers.
19011 REM
19020 REM POKE 708,XXX COLOR 0
19021 REM POKE 709,XXX COLOR 1
19022 REM POKE 710,XXX COLOR 2
19023 REM POKE 711,XXX COLOR 3
19024 REM POKE 712,XXX COLOR 4
19025 REM
19030 REM In program 5, be sure to add
19031 REM 410 GOTO 20000
19032 REM
20000 X=105:Y=8
20010 A=PEEK(106)-24:POKE 54279,PMBASE=256*A
20020 POKE 559,46:REM DOUBLE LINE RES.
20021 POKE 623,4:REM PLAYFIELD OVER PLAYER PRIORITY
20022 POKE 53277,3:REM TURN ON PM GR.
20030 FOR III=PMBASE+384 TO PMBASE+1024:POKE III,0:NEXT III:REM CLEAR P-M GR....
20040 POKE 53248,X:REM PL 0 POSITION
20041 POKE 53249,X+16:REM PL 1 POSITION
20042 POKE 53250,X+32:REM PL 2 POSITION
20043 POKE 53251,X-32:REM PL 3 POSITION
20044 POKE 53252,X+48:REM MI 0 POSITION
20045 POKE 53253,X+56:REM MI 1 POSITION
20046 POKE 53254,X+64:REM MI 2 POSITION
20047 POKE 53255,X+72:REM MI 3 POSITION
20050 POKE 704,53:REM PL 0 COLOR ORANGE
20051 POKE 705,65:REM PL 1 COLOR RED
20052 POKE 706,145:REM PL 2 COLOR BLUE
20053 POKE 707,27:REM PL 3 COLOR YELLOW
20069 REM PLAYER SIZE: 0=NORMAL, 1=DOUBLE,3=DQUADRUPLE
20070 POKE 53256,1:POKE 53257,1:POKE 53258,1:POKE 53259,3
20071 POKE 53260,255:REM SAME CONVENTION BUT 2 BITS FOR EACH MISSILE SIZE
20080 REM *** PRINTS MISSILE NOS. ***
20090 CHR=17:II=0:FOR III=PMBASE+512+Y TO PMBASE+519+Y:POKE III,PEEK(57344+CHR*8+II):II=II+1:NEXT III
20091 CHR=18:II=0:FOR III=PMBASE+640+Y TO PMBASE+647+Y:POKE III,PEEK(57344+CHR*8+II):II=II+1:NEXT III
20092 CHR=24:II=0:FOR III=PMBASE+768+Y TO PMBASE+775+Y:POKE III,PEEK(57344+CHR*8+II):II=II+1:NEXT III
20093 FOR N=PMBASE+512 TO PMBASE+1024 STEP 128
20094 FOR M=16 TO 0 STEP -1
20095 POKE N-M,255:NEXT M:NEXT N
20096 XO=125:XN=125:YO=93:YN=93:COLR=255:Y=8:GOTO 20170
20099 REM ***** JOYSTICK ROUTINE *****
20100 MOVE=STICK(0):IF STRIG(0)=0 THEN 20230
20105 IF MOVE<>7 AND MOVE<>11 AND MOVE<>13 AND MOVE<>14 THEN 20100
20110 IF MOVE=14 THEN YN=YO-3:COLR=COLR-2:IF YN<0 THEN YN=93:COLR=COLR+64
20120 IF MOVE=13 THEN YN=YO+3:COLR=COLR+2:IF YN>94 THEN YN=0:COLR=COLR-64
20140 IF MOVE=11 THEN XN=XO-40:COLR=COLR-64:IF XN<0 THEN XN=125:COLR=COLR+256
20150 IF MOVE=7 THEN XN=XO+40:COLR=COLR+64:IF XN>141 THEN XN=5:COLR=COLR-256
20170 LOCATE XO+10,YO,CO:CN=CO-2:IF CN<0 THEN CN=CO+2
20180 COLOR CO:PLOT XO,YO:DRAWTO XO+5,YO:PLOT XO,YO+1:DRAWTO XO+5,YO+1
20190 COLOR CN:PLOT XN,YN:DRAWTO XN+5,YN:PLOT XN,YN+1:DRAWTO XN+5,YN+1
20200 XO=XN:YO=YN
20220 GOTO 20100
20230 FOR N=0 TO 3:POKE 704+N,COLR:NEXT N
20235 REM DISABLE COLR FOR PM PRINT
20240 IF COLR>99 THEN CHR0=16+INT(COLR/100):CHR1=16+INT((COLR-(CHR0-16)*100)/10)
20241 IF COLR>99 THEN CHR2=16+COLR-(CHR0-16)*100-(CHR1-16)*10:GOTO 20300
20250 IF COLR>9 THEN CHR0=16:CHR1=16+INT(COLR/10):CHR2=16+COLR-(CHR1-16)*10:GOTO 20300
20260 CHR0=16:CHR1=16:CHR2=16+COLR
20300 II=0:FOR III=PMBASE+512+Y TO PMBASE+519+Y:POKE III,PEEK(57344+CHR0*8+II):II=II+1:NEXT III
20310 II=0:FOR III=PMBASE+640+Y TO PMBASE+647+Y:POKE III,PEEK(57344+CHR1*8+II):II=II+1:NEXT III
20320 II=0:FOR III=PMBASE+768+Y TO PMBASE+775+Y:POKE III,PEEK(57344+CHR2*8+II):II=II+1:NEXT III
20500 GOTO 20100
20890 REM
20900 REM If you change graphics modes
20901 REM from here, suggest you
20910 REM FOR N=0 TO 7
20920 REM POKE 53248+N,0

Table of Contents
Previous Section: Questions & Answers
Next Section: Getting Along Without TAB