Classic Computer Magazine Archive COMPUTE! ISSUE 86 / JULY 1987 / PAGE 52

INSIGHT: Atari

Bill Wilkinson

Three Questions

I have received a fair number of letters from 8-bit owners in recent months, and most people ask one of these three questions: "Where can I find a book that tells me …?" "Do you know of any program that will …?" "How do I convert my Atari BASIC program to assembly language so that I can …?"

Although all your questions are slightly different, I have a few answers that will work for most of you, regardless of the ending you would like to put on any of the questions.

First, it is an unfortunate fact that many of the best books for the 8-bit Atari computers (400, 800, and XL/XE series) are no longer in print. I would like to hope that some enterprising publisher might decide to reprint a few of the best of these in limited editions, but I am not going to hold my breath until that happens. In the meantime, your best bet is to try to track down a copy now, while there are still a few in dealers' hands. What books am I referring to? There are so many books that would make my "nice to have" list that I can't possibly list them here, so, instead, here (reluctantly) is a limited list of what I consider my own, personal "basic necessities" library.

For all programmers:

  • COMPUTE's Mapping the Atari and then either
  • Your Atari Computer by Lon Poole or
  • ABC's of Atari Computers by Dave Mentley

For BASIC neophytes:

  • Atari BASIC for Kids 8 to 80

For assembly language neophytes:

  • Atari Roots by Mark Andrews
  • Programming the 6502 by Rodney Zaks

For those who are really serious:

  • Atari Technical Reference Manuals from Atari and, perhaps the hardest to find:
  • Atari Graphics and Arcade Game Design by Jeff Stanton

Some of these are still pretty easy to find. Others have all but disappeared. Still, every so often I hear of dealers who have a nice stock of one or more of them. For example, you may have read in the May issue of COMPUTE! that B&C ComputerVisions of Santa Clara, CA, has a stock of De Re Atari (which just barely failed to make my essentials list). I have just learned that they also have a good stock of the Atari Technical Reference Manuals. Dealers rarely advertise that they have a certain book—by the time the ad appears, they may be sold out with no way to get more copies. So call around, ask around, check with your local bulletin board, and/or leave a message or two on some of the national time-share systems that have Atari interest areas (for example, Compu­Serve, Genie, and Delphi).

Ask

By now, you probably won't be surprised to find that the answer to that second question is about the same: Ask. About the only kind of programs you can not find for your 8-bit Atari are what I call "heavy-duty" programs. For example, I have yet to see a good, complete civil engineering package. Or an off-the-shelf order-entry system. The primary limitations of these small machines have always been their slow disk I/O speed and limited disk space. (Historically, there has been a more important limita­tion that I'll address in a future column. Ironically, I am writing this column on an 800 XL connected to a Supra 10-megabyte hard disk using ICD's SpartaDOS, and I find that this system now does everything I need. But a large percentage of Atari owners have, only one floppy disk drive, which is simply not enough for most business purposes.)

One amazing aspect of Atari software is the amount of usable public-domain software available. But until you join a user group—or, perhaps, buy a modem and call some BBSs or one of the national time-sharing systems—you will be cut off from this free software.

Converting BASIC To ML

The final question listed above is actually the most interesting to me: "How do I convert my Atari BASIC program into machine language?" The first and most obvious answer: Buy a BASIC compiler. I don't want to belabor this topic now, but you should know that Atari BASIC is an interpreted language. It is not fast. If you could compile your program into machine language, it would run much faster. (Of course, getting a better BASIC interpreter will also speed up your programs.) Remembering my advice above about finding Atari software, you might be able to find such a compiler. But even compiled BASIC doesn't come close to what is possible in assembly language. (Did you notice my shift from machine to assembly language? There is a technical difference between the two, but it is one we can ignore.)

Many, many articles have been written that provide you with handy machine language subroutines that you can call with Atari BASIC'S USR function. For example, also in the May issue, Rhett Anderson presented a set of routines for doing bitwise operations via USR calls. The problem with most of these routines: They all tend to reside in the same hunk of Atari memory (the so-called Page 6, memory locations $600–$6FF, 1536–1791 decimal), so you can use only one or, perhaps, two at a time.

CAPUTE!

What happens when you need about 20 or 30 machine language subroutines? I did a whole series of articles, once upon a time, on writing self-relocatable code, machine language routines that can be loaded anyplace in memory; but it seems I was fighting a losing battle. In truth, though, it may be just as well: If you are ready to use 20 or 30 major assembly language routines, why not write the entire program in assembly language?

To do so, you need to learn two things: First, how to program in assembly language. Second, how BASIC performs its various operations. The first of these needs is answered by the books I mentioned in the first part of this article. And some of those books also go far, far beyond what Atari BASIC is capable of. But nobody seems to have written a book that shows, in a simple direct manner, how to convert the most common and useful operations of Atari BASIC into assembly language.

In particular, the topic of Atari graphics is poorly covered. There have been volumes written on display-list interrupts, player-missile graphics, custom character sets, and so on. But how does one do a simple little PLOT in assembly language? Finding the answer to that is like looking for the proverbial needle in a haystack.

When I first saw how well-designed the Atari Operating System (OS) was, I was impressed. That was more than eight years ago, and I still think it is the best OS in the world of small machines. I think you'll agree when I show you next month how little work Atari BASIC must do to perform such seemingly complex operations as GRAPHICS, PLOT, and DRAWTO.

Atari Laser Chess

A number of lines appear twice in the listing for the Atari version of this game from the June issue. When entering Program 3, simply ignore the duplicate lines 20020–21060 on page 48.

Applesoft Memory Management

The "Readers' Feedback" column from the June issue included a question about moving an Apple­soft BASIC program in memory to the area above high-resolution screen page 1. There is an error in the program line provided in the answer to this question (p. 52). The final command in the line should be RUN rather than LOAD. The complete line should read as follows:

5 IF PEEK(104)<>64 THEN POKE 104,64: POKE 16384,0: PRINT CHR$(4)"RUN PROGRAM"

Font Printer For The IBM PC/PCjr

There are no corrections for any of the programs that accompany this article from the May issue (p. 79). However, the instructions for using the printing segment, Program 2, neglected to mention that disk drive names (A:, B:, and so forth) should always be entered in upper­case. Although the computer understands that A: and a: both refer to the same drive, the program does not. Also, the article states that, when using the same drive for document and font disks, the program will beep twice when it's time to change disks. Actually, only one beep is sounded.