Outpost: Atari. (column) John Anderson.

Welcome to the "Outpost," fellow Atarians. I trust your power lights are on, and you are ready for another excursion into the realm of the Atari Personal computer--a machine with as many possibilities as your imagination can provide. We shall examine just a few of those possibilities here.

First, a quick word to all who have been in touch, as well as those who are thinking about it: keep those cards and letters coming in! I have very much enjoyed hearing from you, and am attempting to aim the content of this column to answer your questions, and cater to your interests. The only way I can effectively continue this policy is if I hear from you. So let me now what material you would like to see, and I will do my best. Okay?

Let's get right on to the matters at hand, beginning with program title card generation for your many programming treasures. Super Text Mode

After a program is written and debugged, it should be cleaned and polished. When you think of all the work you did to get it working, the least you can do is mount it well--and that entails making it look and run right.

The first display a program generates is supremely important, as it sets the tone for all that is to follow. If you have been wanting a professional quality title card to distinguish your programs, here is a routine that will fill the bill. It can be tailored to display your message in a large, custom font, and then to cycle through a veritable rainbow of color. From there, another message can flash into the text window. After the title card has cycled fully, the rest of your program will execute.

Programs that plot and fill character sets into a non-text mode (in this case graphics 7) have appeared in Byte, and Compute! over the past two years. The routine that follows has some new features, and allows you to create your own, customized displays with a minimum of fuss.

If you are short on memory for a specific application, or don't have a disk drive, you might not want to commit many lines of Basic to the likes of this routine. However if you have a disk, the program can run as a separate file, involving your main program file as its final act. It takes about 50 sectors on disk, and is well worth every bit of that space.

The routine appears in Listing 1. I have left the code relatively free of REM statements to conserve memory. If typed in exactly as shown, the program will display the letters A through U on the screen, cycle through the rainbow and text window displays, and then start all over. In order to display letters V through Z, change line of 120 to RESTORE 862. This will at least give you a view of all the letters in the font, so you can ensure that the program has been entered correctly. The only reason the alphabet has been split in this manner is because the screen is capable of displaying only three rows of seven characters at one time.

The program breaks down as follows:

Line 10 initializes, while POKE statements suppress the cursor and move the margins out to 40 columns. It also invokes two subroutiness: the first reads machine language data into a string which will the execute the rainbow segment from a USR call in line 30. The second subroutine reads data which define the placement and choice of characters.

Lines 50 through 70 constitute the secondary message, which will appear in the text window. There is no reason why this font, which is in graphics 0, could not be modified, perhaps along the lines of the program that appeared in the "Outpost" last month.

Line 80 creates a pregnant pause, then starts the whole procedure over again. Before it does so, however, it POKES the attract mode into operation. You may or may not like the effect this creates, but the command shows that color background capability is there. This is also the line from which the rest of another program would take off.

Lines 130 through 230 are really the heart of the program, and exemplify a powerful and efficient manner of reading plotting (as well as other) information from an upcoming series of DATA statements. This handsome approach has appeared in Compute!, though I have improved upon it here.

Briefly, the following happens when reading DATA statements: if preceded by a p, upcoming data pertains to plotting. Read the numbers, PLOT and DRAWTO as necessary.

If preceded by an R, the following data will indicate where the plots should begin (always at the 0,0 point of any letter). These numbers always occur at the outset of a letter plot, and must be manipulated by the user in order to ensure correct placement. The font is "proportionally spaced"; for example, an I is narrower than an M, and care must be taken to lay out words so that spacing between letters is pleasing. Shades of art direction! The first number is the vertical coordinate, the second the horizontal. And remember, the Atari does not use the Cartesian coordinate system, but rather places 0,0 at the upper left-hand corner.

If preceded by an S, the data pertain to sound statements. Thus the user can create a tone for each letter, building into and moving between chords, if so desired, by cycling voices. The first number indicates which voice to use, the second what pitch. I worked exclusively with pure tone (10). By altering the distortion value in line 160, you can experiment with sound effects.

The next data identifier may seem a bit mysterious, as it is not used in the demonstration version of the program. It is a dummy identifier, placed there only for possible use as time delay. As certain letters require fewer steps to draw than others (I as opposed to S. for example, they will plot much more quickly. By padding the DATA statements for the letter I with D's, you would be able to even out its plot time, to create a truly professional-looking display.

If preceded by a letter F, the numbers indicate a following fill statement. These ensure that the insides of each character will be delineated from the outside, so that the rainbow can then well up from within. And if the word END is encountered, the job of this section of code is terminated.

What follows are the somewhat lengthly DATA statements themselves. "Why the jump from line number 230 to 650?" the more observant Atarians out there may ask. "Well, for a good reason," I respond. The line numbers that initiate each letter correspond exactly to their ATASCI code times 10.

An observant but somewhat slower subgroup might ask as a follow-up, "so what?" Well I'm glad you asked that question. In a subsequent version of this program, (which I haven't yet written because I am hoping one of you will do it for me), the user will be able to input an entire message into a character string, and through the use of techniques outlined in the December "Outpost," the program will then modify itself into the specific message, deleting All extraneous material.

A hint at a possible approach: 1) find out what letter the user wants, 2) LIST CHR$ (user's letter) *10+2, give it a new line number (how about that gap between lines 230 and 650), then re-enter the line. Do this for +4, +6, and +8, and you will have the entire letter re-entered. Preset R (origin) and S (sound) values that the user can fiddle with later. There will be plenty of time for that, what with the time saved not saving to edit the whole thing by hand. Then have the program automatically delete lines 650 through 904 completely. Voila, a custom title card, in minimal memory.

I'll go so far as to spice the deal--the first group of programmers to meet this challenge with a running self-modifying title card generator, will get a shot at reviewing new Atari software for Creative--software we will supply and you and keeps. How is that for an offer a hacker can't refuse? Disk Utilities Want to learn more about how your disk drives work? Need a way to retrieve data from crashed disks? Want to look at and alter disk information sector by sector? Interested in backing up your disks? If your answer to any of these questions is yes, you are a candidate for a disk utility package.

Every time I have been about ready to write something on disk utilities, another package makes its appearance. The latest I have had a chance to become acquainted with is Diskey from Adventure International. This packs the most features I have yet seen in a disk utility, and is accompanied by a rare bonus: sparkling, well-written documentation by the software author himself. The tutorial value of the manual alone makes the package worthwhile.

But just wail until you see the software. Disk maps are presented simultaneously in hexadecimal and ASCII format. The software allows for sector-by-sector data examination and alteration. It provides tools by which to salvage damaged disks. It provides functions to compare, copy, reformat, search, create disk files from tape autoboot files, erase (write zeros), disable verify, calibrate drive speed, and manipulate disk directories as well as DOS files.

Another unique function of Diskey is its ability to flag "dead" disk sectors. This is a capability previously unavailable in any disk utility I have seen. Though the potential for misuse is there, author Sparky STarks stops short of spelling out a means to write bad sectors. He states strongly in the manual foreword his equation of software pirates with common thieves.

As a learning tool, Diskey is superlative. The documentation and software work in tandem to provide the most solid disk tutorial you can find anywhere. And, hard as it may seem to imagine, even the driest stuff is presented in a fresh, almost breezy manner.

Diskey is more than a professional utility: it is obviously a labor of love. There are many more features in the software than would have been necessary to create a salabe package. For over 50 reasons (the product has over 50 separate commands), Diskey very quickly attained a pre-eminent position in my utilities box. How about an assembly language tutorial, Mr. Starks?

Obviously, you must have a disk drive to run the package; in addition, you must have at least 32K and Atari Basic. The system is optimally configured, however, with a 48K system, two drives, and an 80-column printer like the Atari 825.

The package lists for $49.95. For more information, contact Adventure International, Box 3435, Longwood Fl., 32750. (305) 830-8194. Poking Around

This part of the column was initiated as an attempt to respond to the many questions we have received at the magazine concerning Atari memory map locations, and ways of "tweaking" them.

I have at least three letters from Atari Basic hobbyists, all asking the same question: how can Basic programs be

made unlistable?   First of all, let me go

on record as one of the category of folks who believe in keeping things listable wherever and whenever it is feasible to do so. The problem of code theft is not nearly as acute in Basic as it is in machine language, nor is that diehard pirate going to be deterred by the mere fact that a program is unlistable in its usual environment. My feeling is, in the spirit of enlightenment, if other people stand to learn something from a bit of my code, more power to them.

That disclaimer having been duly filed, let's look at the only tried, true, and simple method I have seen to help protect your precious Basic files from prying eyes.

Most approaches I have seen to rendering Basic programs unlistable are unsatisfactory. Last month I noted the memory locations you can alter to disable the BREAK key. (A quick aside--a couple of folks wrote in telling me they experienced problems disabling BREAK. The POKE commands must be reasserted often. For instance, POKE again after every graphics mode command. If you put enough sets of them in your program or stick them right places in the main loops, you will effectively disable the key.)

I have not found a way to disable the RESET key, but with the command POKE 580,1 you can make the key into a "true" reset: that is, pressing the key will initiate a cold start, as if the system has been powered down and up again. This will flush any resident program from memory. To return to the normal RESET mode, POKE 581, 1.

The trouble with merely disabling these keys is that the program can still be listed before it is ever run. Still another approach I have seen converts program listings into control characters or variables into carriage returns. Likewise, the fixes do not become operative until the programs are run. If the user asks for a LIST directly after loading, a full listing will be obtained.

How then, to protect a program before it can be listed? The answer lies in the creation of a "RUN only" file. This type of file can not be LOADed or ENTERed, nor can it ever be LISTed. It executes prefectly in every other respect, but can only be invoked with the command RUN"D:FILENAME", (or RUN "C:" if you are using a cassette-based system). In order to create such a file, appends the following line: POKE PEEK (138)+256 * PEEK (139)+2, 0: SAVE"D: FILE-NAME" : NEW

It does not matter if the line is at any time executed by the main program; the code therefore remains unaffected in any way. It is imperative, however, that the line be the chronologically last line of code. When you are ready to protect a program (that is, do not intend to alter it any further), type this line with a higher line number than any other in the program, choose a filename, than GOTO the line. Listing 2 is a working example.

That is all there is to the technique: "RUN only" files can be simply generated to disk or tape. Attempts to do anything other than RUN will result in a nasty case of system lock-up. And yes, even autorun files can be protected in this manner. Scuttlebytes

Well, we have finally managed to confirm the existence of the Atari 600, and have heard that at least two Atari plants are currently tooling up to produce them. The 600, as its model number implies, will fill the gap between the Atari 400 and 800. It was rumored that the machine would be unveiled at the Winter CES in Las Vegas. It will sport 48K standard, and a full-stroke keyboard. Owners of 400s and 800s need harbor no fears of obsolescence: the 600 will be completely compatible with its predecessors.

Many Atari types are awaiting with curiosity the final verdict on the Commodore 64, which features graphics, sound, and gaming capilities very much akin to those of Atari computers. Atari has, in the meantime, added to its busy legal docket a suit against Commodore, concerning the design implementation of Commodore joysticks, which are for use with the VIC-20 and all latest generation machines. It seems the sticks are not only Atari-compatible, but nearly identical in many respects.

Atari, which patented its stick when the VCS was first introduced in 1977 and improved the design several times since, claims patent infringement. The Atari joystick connector has set an informal design standard in the industry. The Colecovision videogame uses an Atari-compatible format, and it was rumored that the new microcomputer, to be released by Apple, this year will also make use of Atari-compatible digital sticks. But compatibility and patent infringement are two separate concepts. Joysticks

While we're on the topic of joysticks, let me tell you about two hot sticks we've been playtesting. The first is the Pointmaster joystick. This stick has an extra long handle with built-in grip and handle-mounted trigger button, making it perfect for "flyer" games like Star Raiders and Protector II. The stick is very much like the one in the stand-up aracde version of Zaxxon, and once you play a few games of Raiders with it, you won't want to use anything else. Conversely, the stick is cumbersome in maze games like Jawbreaker or MBAFAS ("move back and forth and shoot") games like Threshold. Still, at $17.95, it offers a real boost to your, "flyer" game collection.

For more information, contact Discwasher, 1407 North Providence Road, Columbia, MO, 65201. (314)449-0941.

The other sticks we looked at, called Game Mate 2, are pretty nearly regulation Atari sticks, with one big difference: they are wireless, and work by remote control. My main fear was that there would be a time lag between the movement of my hand and what I saw on the screen. I experienced no such sensation--the sticks seemed as fast as any I had ever tried. My only reservation is their size. They are quite, bulky, and take a while to get used to.

With the VCS, the console power supply plugs into the Game Mate receiver unit, and then into the VCS console. For the 400 and 800 computers, however, an additional 9-volt power supply is a necessary purchase. Each stick also takes a 9-volt transistor battery. The units operate at distances of up to 20.

Complete with receiver and two sticks, Game Mate 2 lists for $99.95, but I have already seen this price substantially discounted. If the luxury of wireless sticks is appealing to you, this product will assuredly not disappoint.

For more information, contact Cynex Manufacturing Corporation, 28 Sager Pl., Hillside, NJ, 07205. (201) 399-3334. Games

Smoothly we seque from sticks to the games played with them. We have confirmed 400/800 versions of Galaxian and Defender in ROM form from Atari. Both games are spin-offs from the new 5200 model videogame. The 5200 may yet prove to be a boon to owners of Atari computer systems, if it spurs game development common to all machines. Galaxian has already been demonstrated, and is a solid implementation. One can only hope that Defender will be up to snuff.

Datasoft also has an ambitious project on its drawing boards right now: Zaxxon for the Atari. We can't wait.

I must admit it: when I first heard that Big Five Software was releasing a game for Atari, I sort of chuckled. Somehow I assumed that because Miner 2049'er was from one of the best TRS-80 game houses, it would probably run in graphics 5. Did I make a mistake. Miner 2049'er, in ROM cartridge format, is bound to be one of the runaway hits of the year. With superlative graphics, humor, and 10 completely different screens to master, the game leaves Colecovision's Donkey Kong pale by comparison.