INSIGHT: Atari

Bill Wilkinson

Tried And True Tools

In keeping with COMPUTE!'s programming languages theme for this month, I'd like to share some thoughts about programming in general and better use of the available languages in particular. I have long contended that, for most purposes, owners of Atari 400/800, XL, and XE computers have all the languages they need. You won't do parallel array processing with a 6502, no matter what language you use, but you can balance your checkbook, keep track of your mailing list, access online services via modem, write a book or two, and (of course) play some games. All of those applications and many more have been written with languages now available for the eight-bit Atari computers. What more can you ask for?

In a previous column I said it would be hard for most users to justify trading up to an ST, an Amiga, or whatever. If anything, I feel more strongly about that now. I still write this column using a good old Atari 1200XL (I like its keyboard best) and an Atari 825 printer (ancient history). Sometimes I wish for an 80-column screen or a hard disk drive--keeping track of 200 floppies is not my idea of fun--but I can't justify the expense for the extra convenience.

The same is true when it comes to programming languages. Admittedly, I'm a language junkie. I love learning new languages and/or tricks with old languages. So it would seem that the ST would be a dream machine for me. Despite its youth, the number of languages either available or coming soon is phenomenal: several varieties of BASIC, Logo, Pascal, C, LISP, Modula-2, COBOL, FORTRAN, Prolog, Forth, and 68000 machine language. There are probably others, too.

Old Machines, New Projects

But for owners of eight-bit Ataris, the situation is far from bleak. Though some of the language implementations are not as rich as those on the ST, we can enjoy Pascal, C, Logo, Action!, Forth, PILOT, 6502 machine language, and some extraordinarily easy-to-use BASICs.

Even though I've been using Ataris for six years now, I still see some interesting projects to do-- projects that I've never done or which I think can be done better. A few examples: How about a terminal program written in Action! that is designed to work well with CompuServe's conference mode? Or a GEM-like interface for DOS? Or a combined spreadsheet/database written in BASIC XE and commented liberally so that even beginners can see the methods used? I know I'll never do all of these, but they are challenges I'd like to tackle.

Rethinking The Problem

Moving to new languages on new machines is not always an advantage. Eor instance, in ST BASIC, strings cannot exceed 255 characters in length. Atari BASIC strings can be up to 32,767 characters long, if you have the memory available. (Yes, ST BASIC allows string arrays, but so do BASIC XL, BASIC XE, and Atari Microsoft BASIC.) There are many other examples.

Another factor is that the speed and power of the newer machines is of little advantage for some applications. Other than missing an 80-column screen, I can use CompuServe or various bulletin boards just as well with my $100 computer as I can with the company's $1,000 machine. Besides, the modem for the $100 computer is cheaper. And by the time you read this, Atari may have released its 80-column adapter for the eight-bit line.

Suppose you're writing a program that does need more speed, however. What can you do other than buy a newer, faster computer? Well, you could buy a better, faster language. That's a lot cheaper than buying a new computer--for which you still might need an extra language or two. On the other hand, maybe you don't have to buy anything at all; maybe you just need to rethink your solution to the problem. Let me show you what I mean.

Program 1 is very similar to one which I found in a recent user group newsletter. The author was responding to a member's inquiry about writing a routine to shuffle a deck of cards. As you know, when BASIC gives you a random number, there's no guarantee it won't give you that same random number twice, perhaps even several times. For a quick example, type the following line and press RETURN: FOR 1=0 TO 9:PRINT INT(10*RND (0)):NEXT I

This asks for ten random numbers in the range 0 to 9. Did you actually get ten different numbers? The odds are very much against it.

The Super Shuttle

Program 1 demonstrates this problem by dealing out an entire deck of 52 cards. As each card is dealt (by suit S and rank R, line 210), its spot in the C (card) array is marked. Then, if the random number generator picks that card again, the pick is ignored (line 230). The only things I added to the original routine are the counters (C and T) which count how many picks it takes to get each card and the entire deck. Can you guess how many picks it takes to get the entire deck? In 50 tests, it took a minimum of 128 picks and a maximum of 457, with the average around 220. The result, as you'll see if you run the program, is that it can take as long as five or six seconds to pick a card.

Now look at Program 2, which does exactly the same job but never takes more than one pick to get the next card in the deck. It works by using a single string (CARD$) to represent the entire deck. When it gets a random number from 1 to 52, the program removes the corresponding "card" from the "deck" (lines 400 and 410). The next time it picks a card, it gets a random number from 1 to 51. Each time the computer gets a card, the range of random numbers gets smaller. Simple. And it works by taking advantage of the string operations in Atari BASIC.

The point of this exercise is to show that sometimes the best way to fix a slow or inefficient program is to rethink it and then rewrite it. I'd be willing to bet that Program 2 on an eight-bit Atari runs faster than Program 1 on an Atari ST. If you have access to both machines, you might want to try it. And try improving your own programs. (Even while writing this column, I found a way to improve Program 2 even more. Can you find it?)

One last comment: Notice the readability of the two programs. Which one is cryptic and which one almost explains itself? Meaningful variable names can add a great deal of value to any program.