!General Information
Author: Brian Moriarty\\
Language: ACTION! \\
Compiler/Interpreter: ACTION! \\
Published: ANALOG Computing #16\\
----
!!!A New Language for the Atari!
Atari users have a surprisingly wide selection of programming languages from which to choose. We've got three dialects of BASIC, four C compilers, eight or nine FORTHS, a pair of Pascals, PILOT, Logo, WSFN, a Lisp interpreter, numerous 6502 assemblers and a couple of hybrids like BASM and Mirth. Not bad for a "game machine," eh?
Leave it to Optimized Systems Software to come up with yet another way to tell your Atari what to do. OSS has been the leading purveyor of alternative operating systems and languages for the Atari since before I can remember. __Action!__ is only the first of a whole new line of OSS products that's been causing quite a stir in the Atari underground. It's been touted as the first programming environment developed specifically for the 6502, and the fastest high-level language available for the Atari. These are pretty strong claims which, after playing with the system for several weeks, appear to be totally justified. As you are about to read.
!!New! Improved!
In syntax and overall structure, __Action!__ bears a strong resemblance to Pascal, C and other members of the Algol family. It's a procedure-oriented language featuring global and local variables, user-definable functions, parameter passing and powerful structures like DO loops, FOR-TO, WHILE, UNTIL and IF-THEN-ELSE. Three basic data types are recognized: 8-bit BYTEs (or CHARacters), 16-bit signed INTegers and 16-bit unsigned CARDinals. The system also supports a variety of extended data types including pointers, subscripted arrays, strings and records.
{{{
AND Fl OR UNTIL = (
ARRAY FOR POINTER WHILE <> )
BYTE FUNC PROC XOR # .
CARD IF RETURN = > [
CHAR INCLUDE RSH - >= ]
DEFINE INT SET * < "
DO LSH STEP / <= '
ELSE MOD THEN & $ ;
ELSEIF MODULE TO % <
EXIT OD TYPE ! @
Listing 1.
Reserved keywords
}}}
__Listing 1__ includes all of the keywords reserved for use by the __Action!__ system. These are used to declare variables, define new procedures and/or functions and to control the operation of the compiler. BASIC veterans will note with alarm the total lack of keywords that do interesting things in and of themselves, like SETCOLOR or DRAWTO. They're missing for a very good reason. Unlike BASIC, __Action!__ does not limit your programming to a limited number of safe little commands. It invites you (indeed, ''forces'' you) to invent the commands you need to solve problems yourself. The keywords in __Listing 1__ are the tools the system gives you to, in effect, write your own language. If this prospect doesn't excite you, maybe BASIC has been holding your hand for too long.
{{{
Print PrintE PrintD PrintDE PrintB PrintBE
PrintBD PrintBDE PrintC PrintCE PrintCD PrintCDE
PrintI PrintIE PrintID PrintIDE Put PutE
PutD PutDE InputS InputSD InputMD Open
Close XIO Note Point Graphics SetColor
Plot DrawTo Fill Position Sound SndRst
SCopy SCopyS SAssign StrB StrC StrI
Break Error Zero SetBlock MoveBlock
Listing 2.
Library procedures.}}}
Don't get the impression that __Action!__ leaves you completely on your own, though. The cartridge includes a library of useful I/O, graphics and system-level routines that you can use to start building more elaborate programs. __Listings 2__ and __3__ will give you an idea of what's available. The resemblance of many __Action!__ library words to Atari BASIC commands is intentional; the kindly folks at OSS want to make your transition from BASIC to __Action!__ as painless as possible. This concern for familiarity unfortunately extends to the __Action!__ graphics library, which offers exactly the same (limited) access to the hardware as Atari BASIC. Other weak points of the cartridge library include inadequate control over memory allocation and a mysterious lack of support for the Atari's built-in floating point math package.
{{{
InputB InputC InputI InputBD InpuCD InputID
GetD Locate Paddle PTrig Stick STrig
SCompare ValB ValC ValI Rand Peek
PeekC Poke PokeC
Listing 3.
Library functions.}}}
Most of the elements in an __Action!__ program are delimited by space characters - as many as you like! You don't have to keep track of line numbers, semicolons, brackets or any other nuisances that can make you feet more like a bookkeeper than a programmer. Just follow a few simple rules regarding commas and parentheses, and you're all set. __Action!__'s modern design encourages a wide-open style of program composition, with plenty of freedom regarding the use of blank lines, upper and lower-case characters, indentation, comments and other flourishes that improve readability and make coding more fun.
!!A four-part system.
Internally, the __Action!__ system consists of four distinct modules. There's an ''editor'' for creating and modifying program source text, a ''compiler'' which translates source text into executable machine code, a ''run-time library'' that supports the compiled code (described above), and a ''monitor'' which acts as a switchboard between the other three modules and (if you're using a disk drive) DOS.
A very important distinction between __Action!__ and every other compiled language for the Atari is that these modules do not have to be loaded in separately from disk. All four are tucked away inside the SuperCartridge, safe from accidental erasure and ready whenever you need them. Further, the system is arranged so that your source text and compiled code can reside in memory at the same time. This self-contained design combines the performance of a compiled language with a degree of interactiveness usually associated with an interpreter. A stroll through the modules will show you what I mean.
!!The editor.
Somebody at OSS once told me that the text editor in the __Action!__ cartridge was originally going to be marketed by itself as a word processor. It isn't hard to believe. There are so many features and options in the __Action!__ editor that I can only touch on the most interesting here.
__Action!__'s editor uses your TV as a virtual window into a text area that can extend well beyond the edges of the screen. Unlike the standard Atari screen editor, you can type up to 240 characters on a single line with no cursor wraparound. How? When your cursor reaches the right edge of the screen, the line you're working on (and ''only'' that line) starts to coarse-scroll to the left. You can keep right on typing until a buzzer informs you that you've reached the rightmost position in that line - the right "edge" of the text window. Move your cursor back towards the left, and the line scrolls to the right until you hit the left edge of the window. This design neatly eliminates the usual confusion between "logical" and "physical" lines of text.
Hitting CTRL/SHIFT/">" or "<" instantly moves you to the rightmost or leftmost character in the current line, respectively. You can also change the maximum width of the text window to any convenient value, such as how many characters will fit on your printer.
The __Action!__ editor allows you to create a second text window, co-resident in memory but otherwise completely independent from the main window. The 2-window editing mode is represented visually by a split screen, with the bottom half of the image devoted to the auxiliary window. You can jump back and forth between the two windows and transfer blocks of text if desired; the editor remembers where you were working in each window and automatically returns you to that point when you return. Additionally, you can save, load or delete text in one window without disturbing the contents of the other. That means, for example, that you could load a library of routines into the auxiliary window, review them and copy the ones you need into your main program, which has been in full view the whole time! Sure beats LISTing and ENTERing lines of BASIC, doesn't it?
Other noteworthy capabilities of the __Action!__ editor include global search and replace, instant access to the beginning or end of a file and the ability to delete, move and copy, selected blocks of text. The block move and copy functions are implemented so nicely that I have to tell you about them. When you hit the SHIFT/DELETE keys, the line you're working on disappears, just as with the Atari screen editor. But the line isn't gone forever. It's being held in a buffer, waiting to be moved or copied to anywhere else in your text window(s). Simply move the cursor to a likely spot and hit CTRL/SHIFT/"P" (for paste) to dump the contents of the buffer. Several adjacent lines of text can be sent to the buffer by repeatedly "deleting" them with SHIFT/DELETE. __Action!__'s method of picking up and dropping blocks of text feels very natural if you're used to the Atari screen editor, and it also eliminates the annoyance of losing a line of work by accidentally hitting SHIFT/DELETE. Incidentally, you can automatically undo any changes you have made to a line of text by hitting CTRL/SHIFT/"U".before leaving the fine. Luxurious.
Before you toss out your __AtariWriter__ cartridge, let me point out a couple of small but irritating problems in the __Action!__ editor. There's a feature called tagging which allows you to mark any location in your text by assigning it a unique one-character identifier. You can later return to that point in the text at any time by calling its ID code. It's a good idea that, unfortunately, isn't pulled off particularly well. If you set a tag in a line and change even a single character in that line, the tag disappears. This restriction (which is documented) considerably reduces the usefulness of the tagging option, to say the least.
My other gripe is with the way the cursor appears to flash and jump around the screen when it is being moved up or down, as if it isn't sure where to go next. The solid command line on the bottom of the screen also seems to jerk occasionally as you cursor around. Minor cosmetic points, perhaps, but an unstable cursor seems out of place in this otherwise superb little text editor.
!!The monitor.
After you've put the finishing touches on an __Action!__ program and saved it out to disk, what next? Press the CTRL/SHIFT/"M" keys simultaneously and you'll find yourself staring at a barren white bar across the top of your screen. This is __Action!__'s monitor, the central interface between the editor, compiler, machine and user.
Monitor functions are invoked by typing a one-character code letter. You can select various compilation options, save and load compiled programs, examine the values of variables and memory locations and trace the execution of your programs. You can even use the X (execute) directive to interactively test almost any procedure or function. This capability is very unusual (and useful) in a compiled programming language.
!!The compiler.
Unlike Atari BASIC, which compiles each line of program text as it is typed, __Action!__ requires that your program be explicitly translated into machine code before it can be executed. This isn't nearly as formidable as it sounds. All you have to do is type the letter C from within the __Action!__ monitor.
The compiler accepts source text from either the editor (default), or from a text file saved onto cassette or disk. If you've been using both text windows, __Action!__ will compile only the text in the window you last edited. Compilation is almost unbelievably rapid, especially when the source is the editor. I've never seen __Action!__ take more than a few seconds to compile even a fairly large program that was in the editor. Small programs are compiled before you take your finger off the RETURN key. You can optionally instruct the compiler to list each line of source text to the screen or a printer as it is being compiled. This slows the compilation considerably, however.
A compile error causes the system to display the line where the error occurred, along with an error message number. Surprisingly for an OSS product, there are no English error messages. If you re-enter the editor after a compile error, you'll find the cursor obligingly positioned over the questionable spot in your text.
Successfully compiled code is executed by typing the letter R (run) from within the __Action!__ monitor. If you're accustomed to the leisurely pace of Atari BASIC, get ready for a shock. OSS isn't kidding when they say __Action!__ is fast.
!! How fast is fast?
Execution speed is very important to Atari programmers. Why? Because much of the software written for the Atari relies heavily on graphics, where a few extra machine cycles in the wrong place can make the difference. between a spectacular special effect and an interesting but unmarketable demo. High speed isn't likely to hurt a non-gaphics program, either. This is in accordance with Moriarty's Maxim: ''It is much easier to slow down a computer program than it is to speed it up.''
A number of attempts have been made to devise a universal method for comparing the speed performance of computer languages and hardware. In September of 1981, ''Byte'' magazine published an iterative number-crunching algorithm called the __Sieve of Eratosthenes__, which calculates all of the 1.899 prime numbers between 3 and 16.384.[1] The __Sieve__ has since become the informal industry standard for clocking the speed of microcomputer languages.
__Listing 4__ is an implementation of the __Sieve__ in Atari BASIC. It requires 19.490 jiffies or approximately 5½ minutes to execute on an unmodified 48K Atari 800 system. I recognize that __Listing 4__ is not the most efficient way to write the __Sieve__ in Atari BASIC, but it is the clearest and most portable way, and that's what counts in this application. You might like to try rewriting the __Sieve__ for better speed performance. I've achieved improvements of better than 30% with tricky recoding.
{{{Listing 4.
10 REM * ERATOSTHENES SIEVE
11 DIM FLAG$(8191)
12 POKE 559,0
13 POKE 19,0:POKE 20,0
14 COUNT=0
15 FOR I=1 TO 8191
16 FLAG$(I,I)="T"
17 NEXT I
18 FOR I=0 TO 8190
19 IF FLAG$(I+1,I+1)="F" THEN 27
20 PRIME=I+I+3
21 K=I+PRIME
22 if K>8190 THEN 26
23 FLAG$(K+1, K+1)="F"
24 K=K+PRIME
25 GOTO 22
26 COUNT=COUNT+1
27 NEXT I
28 TIME=PEEK(20)+256*PEEK(19)
29 POKE 559,34
30 ? COUNT;" PRIMES IN"
31 ? TIME;" JIFFIES"
}}}
[#1]
%*Jim Gilbreath, "A High-Level Language Benchmark." ''Byte'', VI, 9 (September 1981), pp. 180-198.