Outpost: Atari. (column) John J. Anderson.

Outpost: Atari

The baseball season is in full swing, so to speak, and no one here is surprised about the Mets, but I wish the Yankees would get their act together. It is not so much the pennant hopes going up in smoke, as the thought of seeing Martin leave in tears yet again. It makes me sick to my stomach. I expect next season Steinbrenner will bat clean-up.

Last time around I intimated that this month's column would bear some very good news for Atari computer fans. These loyalists, I dare say, have been somewhat comparable lately to baseball fans in Muddville. That means keeping up the enthusiasm despite the nasty strikeouts.

If you have been poised on the edge of your seat, racked with concern, anxious, sweaty palmed, waiting for a homer in home computers from Atari, you won't be disappointed. Yessir, folks, there will be a new beginning, and at least some of the facts are in.

The Atari 1200 has been benched. Riddled with compatibility problems, beset by severe video signal woes, a gaggle of petty compromises, and generally reviled by the community of Atari users, production of the 1200 XL machine was suspended some time ago pending a "policy reexamination.' Happily, that reexamination resulted in Atari pulling the 1200 XL off the market entirely and permanently. The last of the machines are now on the shelves.

In showing the courage to admit their sizable and costly error and to choose a new lineup, Atari has shown some class ane the first signs of intelligent life we have seen in some time. Let's hope they keep it up.

In the interest of good will, I won't rehash my beefs about the 1200. It is gone; it is of the past. Let's put it behind us.

And let's take a fresh look at the future. After a rather humorous, albeit bizarre detour, Atari home computers are moving in the right direction once again. That is moving ahead, especially in terms of competitive pricing, while wisely leaving some proven formulas untampered with. Bravo, boys. Here is the roster, as of press time: [...]

Now don't you agree that news like this is good news indeed?

Oh yes, and just a little bit more to brighten your day--your third-party cartridges will fit in these new machines. It just might be that Atari has come around.

We will soon find out.

Our guest tutorial this month is from Fred Pinho, author of the game program "Medieval Combat,' which appeared in the May 1983 issue of Creative. Fred is very knowledgable about Atari memory conservation, among other Atari topics. In the balance of this installment of the Outpost, he will provide insight into a very powerful technique for compacting data and saving a great deal of annoying load time.

Before I surrender the rostrum, I must thank Alfred Publishing, and specifically Joseph Cellini, for allowing us to reproduce Appendix B from the booklet "Understanding Atari Graphics.' This is the only reference I have seen that provides a keypress to ATASCII chart, which is necessary to take advantage of Fred's data technique.

And so here is Fred. If you wish to correspond directly with him, his address is 676 Rollingwood Way, Valley Cottage, New York 10989.

One straightforward way to load numerical data into a computer is to READ the data value and POKE it into the desired memory location. An example of this method is shown in Listing 1. Though easy to program, it is memory inefficient and runs relatively slowly. This method requires anywhere from three to five bytes for each data number stored. Why? Each number given in the program requires one to three integers plus a comma in the DATA statement. This, and the memory location used for final storage, add to three to five bytes.

If you run the program in Listing 1, you will see how slow this procedure can be (87 seconds to load 6000 bytes). The same thing is accomplished by Listing 2 in only two seconds! I once wrote a program that required about 9400 numbers to be loaded for use in a graphics routine. This took forever to perform (about five minutes). If also consumed excessive amounts of precious memory (even 32K can be used up quickly). I was able to keep memory usage to this level only because some of the data were repeated and thus did not have to be listed in DATA statements. By contrast, the method shown in Listing 2 cut the loading time to 25 seconds and saved roughly 8K bytes of memory.

The method shown in Listing 2 depends on two techniques. First, represent equivalent rather than by the actual numerals. This reduces memory use by eliminating the comma in the DATA statement and cutting the bytes used to represent the number in the DATA statement to one. It also allows you to pack more data into each program line. This saves additional memory by eliminating additional line numbers and DATA statements.

Entering the graphics symbols is more time-consuming than typing the number. However, it is not too difficult if you use the tables shown here. In these tables, each key stroke required to generate the appropriate symbol is detailed. Be careful to observe the following notes otherwise you will find errors in your data.

There is one limitation to this method; you can't use it directly for the values of 34 and 155. These ATASCII values are the codes for quotation marks and for the RETURN function. You can't type these directly into a string because the Atari will treat them as string and line terminators. The easiest way to get around this problem is to load a space from a DATA statement into the desired string location. Once the string has been accepted by Basic, the string can be modified via the CHR$ function to add the desired value. As long as you don't PRINT the modified string, all is well. For example:

Formula:

The second technique, which speeds up program execution, is simply the reading of a whole string of characters at once rather than byte by byte using READ and POKE commands.

After you have loaded your data as strings, there are many things you can do that are not immediately obvious. Strings are a very economical form of data storage. Consider that each value in an array or matrix consumes six bytes of memory while string storage takes one byte. If you are working with large amounts of data, the savings can be considerable. For example, a 20X20 matrix would normally require 2646 bytes for data storage. Remember that Atari Basic always assigns a zero element to an array or matrix so that 20X20 is really 21X21. The same amount of data could be stored in a string in 441 bytes. Of course, the saving in memory is not quite that good since the string technique requires more complex code than direct use of matrices. You will come out way ahead, however.

As it stands, this technique can only handle data in the range of 0-255. This is not a severe limitation since these values are the ones required for graphics work. With a little further programming effort, two byte string values can be stored. These would provide a data-value range of zero to 65,535.

How does one access a string as if it were a matrix? It isn't too diffcult. Assume an R by C matrix (R=rows; C=columns). Remember that we actually have R+1 rows and C+1 columns due to the zero elements of the matrix. What string position corresponds to the matrix element (X, Y)?

String Position = X{C+1)+Y+1 Note that the above is for single-byte numbers. A similar analysis can be developed for double-byte numbers. The data value stored in the string can then be recovered via the ASC function. As an example, for a 2 x 2 matrix where the (1,2) element is desired:

Formula:

A very powerful technique, using "data strings,' involves forcing the computer to place the desired string data into a location specified by the programmer rather than by the computer. This is not an easy task, but it can be done. To accomplish it requires a knowledge of how the Basic system keeps track of strings. Basic sets aside two tables (among others) in memory called the Variable Value Table (VVT) and the String/Array Table (SAT). The location of the VVT is stored in memory locations 134 and 135 and is found by the following: 256*PEEK(135) + PEEK(134). Eight bytes are reserved for each variable declared in the program (variables include scalar, array and string variables). For a string variable, the bytes are assigned as shown in Table 1.

The String/Array Table is an area in memory reserved by the computer to accommodate string and array data. The size of this table is determined by the programmer through his dimension statements. This table normally resides in memory above the Basic program.

With the above information in mind, we can proceed to bend the computer to our way of thinking. Listing 3 gives a simple program that stores data in six strings and then locates another set of strings in the screen display data area. Then, by use of the Basic string manipulation commands, data are scrolled horizontally across the screen. The data movement is jerky by machine language standards but still impressive and useful when compared to the other techniques available in Basic.

Of course, you can go to the "playermissile' system to get easily programmed horizontal scrolling. But note that the player width is only one byte. Even if you link the four players together, the maximum width is only four bytes. With the string techniques, however, the horizontal "width' of your graphics data is limited only by the memory capacity of the Atari.

This string-modification technique can also be used to provide rapid vertical motion for a "player' in the player-missile graphics system. To move a player vertically, the player data must be continuously relocated within the player memory area. Using PEEK and POKE is excruciatingly slow. The use of strings, however, provides the capability of rapid movement. See George Blank's "Out-post: Atari' in the April 1981 issue of Creative (pp. 194-196) for a full explanation of this technique.

If you try to print your graphically loaded strings to the screen to check the results, you will get an unpleasant surprise. Your graphics symbols will probably include some editing characters. These will perform their function when printed to the screen, causing your string to perform strange gyrations. The result will be an incorrectly printed string.

The best solution to this problem that I have found is to convert the graphics symbols back into ATASCII data and print them. An example for a 360 character string is given below.

Formula:

This will print out your original numerical data for checking. If you wish to print to the screen rather than to the printer, simply replace P: in line 100 with S:.

Table: Listing 1. Loading time about 87 seconds.

Table: Listing 2. Loading time about 2 seconds.

Table: Keypress to ATASCII chart.

Table:

Table: Program Details.

Table: Listing 3.