Classic Computer Magazine Archive ANTIC VOL. 2, NO. 11 / FEBRUARY 1984


Autoboot with a ghost at the keyboard


Picture the following. Seated at your Atari computer, you insert the BASIC cartridge and turn the system on. The normal sequence of events ensues, whereupon the familiar prompt "READY" appears on the screen. Suddenly, you hear the keyboard clicking, as if invisible fingers were pressing the keys, and the words "OR NOT, HERE I COME!" appear. More clicking follows, and you see direct-mode commands to BASIC being typed in and immediately executed. You may even find that your disk drive or cassette machine has been activated to LOAD or RUN files! Is it a ghost? No, it's just Fast Fingers (FF), a revolutionary new concept in autoboot programs for the Atari.


An autoboot program is one that is automatically executed when the computer is powered on. If you use DOS 2.OS in a disk-based system, you're probably aware that DOS looks for a program named AUTORUN.SYS upon booting. If AUTORUN.SYS exists on the disk, DOS will attempt to load and run it as a machine-language program before transferring control to a cartridge or loading DUP.SYS. If your system is cassette-based, you may have run autoboot programs by pressing and holding [START] as you turn on the computer.

The most common type of AUTORUN.SYS program, available as a one-sector file on the DOS 2.0sS Master Disk, loads the RS-232 handler from the 850 interface if it's turned on. Another common type executes a line of BASIC commands by taking temporary control of the screen editor. Fast Fingers works by taking control of the keyboard instead, and lets you preprogram an entire sequence of keyboard entries (including cursor and screen editor controls and the [RETURN] key) to be executed as the autoboot file. The autoboot file can be executed with any language, including PILOT and the Assembler Editor cartridge, or even in MEMO PAD mode!


Type in the Fast Fingers listing below very carefully. Use TYPO to check for typing accuracy, and SAVE a copy and put it away for safekeeping before you RUN the program.

Now RUN it. The first prompt requests that you enter an input-device specification. For now, enter K for keyboard (a colon isn't necessary since there is no filename in this case). Next, the screen clears and the READY prompt appears. Don't be fooled - the program is still running. At this point, every keystroke that produces a legal ATASCII character is being recorded.

If you are using cassette, type CLOAD [RETURN] [RETURN] RUN [RETURN]. If you're using disk, type RUN "D:GAME [RETURN]. (Don't type a period after [RETURN], though.) You may replace GAME with the name of any BASIC tokenized file you wish to run.

Now both cassette and disk users should hold down [CTRL] and press [3]. This generates an end-of-file code, and terminates your input. A message is now printed that tells you how many keystrokes were recorded.

The next prompt asks whether you're using cassette or disk. Respond with C or D. If you're using disk, make sure the disk to which AUTORUN.SYS is to be written is in the drive. Next, both cassette and disk users should press [RETURN].

One of FF's special features is that it lets disk users append their AUTORUN. SYS file to one that already exists (e.g., the standard type that loads the RS-232 handler). If an AUTORUN.SYS file is present on the disk when you press [RETURN] (after the most-recently-described prompt), you'll see the prompt "APPEND?" Responding to this with Y appends your file to the end of the previously existing one. A possible application for this is loading the RS-232 handler and then automatically loading and running a terminal program. You could even have FF set your terminal configuration and dial a number for you!

The next two prompts ask for the load and patch addresses. Press [RETURN] for now to use the default parameters. These will be discussed more fully later in this article. The last prompt asks for a speed value between one and nine. The fastest speed, One, means that keystrokes will be typed in at a maximum rate of sixty per second at boot time. Speed Nine types one key every four seconds. Press [RETURN] for the default speed of Three.

After you press [RETURN] for the speed prompt, the program will write the boot file. Cassette users should make sure that you've depressed the RECORD and PLAY buttons on your recorder; when the computer beeps twice, press [RETURN]. When this is finished, the "real" READY prompt appears. At this point, cassette users should CSAVE a BASIC program without changing the tape's position. Disk users should make sure that your disk contains the game program and DOS files.


Turn everything off, including the 850 interface. Insert the cartridge into the computer. Then insert the cassette, rewind it and press the PLAY button. Next, hold down [START] and turn on the computer simultaneously. You can release the key when you hear the beep. Now press [RETURN]. The autoboot program will load and execute, whereupon the following sequence should occur (if you followed the example and typed in CLOAD and RUN previously):

1. The command CLOAD will appear on the screen as if it were being typed in on the keyboard. Accompanying keyclicks will sound, and [RETURN] will be pressed.

2. The computer will beep, [RETURN] will be pressed again and the BASIC program will load.

3. After the program is loaded, the command RUN will appear, [RETURN] will be pressed and the program will start.


The disk booting procedure is quite simple. DOS, when loaded, loads and executes AUTORUN.SYS, which takes over the keyboard and runs your program with the command previously given, RUN"D:GAME.


One interesting experiment is to have Fast Fingers type in a program for you, then RUN it and respond to prompts. When in record mode, type in a short program that requests user input, then type RUN, and then type a response for the programmed input. Note that, when in record mode, immediate-mode BASIC commands do not take effect. While you're typing in the program, try using cursor controls to change a line after it's been entered. When the autoboot program executes, you'll see your program being entered, edited, RUN, and responded to, as if by a ghost!

If you've written a menu-oriented program that requires keyboard input, FF provides an ideal auto-demonstration mode for showing someone how the program works. Fast Fingers can provide an entire sequence of keystrokes that demonstrate the program's various features, and the original program need not be modified at all.

Librarians for user's groups will find this next application to be very useful. By creating an autoboot file that consists of pairs of commands, such as LOAD "D:filename [RETURN] and CSAVE [RETURN] [RETURN], you can transfer groups of disk files to cassette automatically, while leaving the computer unattended!


At the first prompt (for input-device specification), you may supply the name of an alternate input device, such as C or D:filename. This allows you to prepare and save a text file for use with Fast Fingers beforehand. If you supply an alternate specification, Fast Fingers will load the file and display it on the screen.


The default load address for cassette systems is 1792 (decimal); for disk systems it is 13312. The initialization code that installs the patch (57 bytes), the patch itself (56 bytes), and the keystroke data (one byte per keystroke) are loaded at this address. Thus, the number of contiguous free bytes needed to load the program is 113 plus the keystroke count. If, for example, you're using cassette and your application requires the RS-232 handler, which loads at 1792 (decimal), you must specify a higher load address such as 4000 (decimal).

The "patch address" is the address at which the FF machine-code routine (the patch) and the keystroke data are stored. The default value is 1536 (decimal), which is the start of page 6, an area of memory that is usually free for programmer's user. If your program uses Page 6, or your keystroke count exceeds 200, you must locate a patch elsewhere. One possible location would be above a lowered RAMTOP.


Every sixtieth of a second (or one "jiffy"), after the monitor has finished drawing one frame, the Atari Operating System (OS) generates a Vertical Blank Interrupt. This period of time is very short by human standards, but it's long enough for the computer to take care of a number of important housekeeping operations. One such task is to check the keyboard for a keypress. Whenever a key is pressed, the corresponding hardware keycode of that key is stored in location 764 (decimal). When the OS is asked to input a character from the keyboard, it gets the keycode from location 764, converts it to an ATASCII character, and sets location 764 to 255, which means that the key has been read. FF also monitors location 764 during the vertical blank. If it finds a 255, it gets the keycode for the next character from its data buffer and places it in location 764. This makes the OS think that a key has been pressed. FF continues to do this until the data buffer is empty, whereupon control is passed to BASIC or the current application.


FF will work only with legal ATASCII characters. Therefore, the following keystrokes should not be used: [CTRL]-[1], [CTRL]-[3] through [CTRL]-[0], [CTRL]-[?], [CAPS/LOWR], the inverse key, all keys with both [SHIFT] and [CTRL] pressed, and the [SHIFT] and [CTRL] keys pressed alone.

FF supports lower case by automatically generating a keycode for the [CAPS/LOWR] key the first time a lowercase letter is used. It will remain in the lower-case mode until it reaches the end of the keycode data. Upper case will still work, though, because the keycodes imply that [SHIFT] is being pressed.

Inverse video is also supported, but it creates a minor problem. When input data alternates between inverse and normal characters, FF generates a keycode for the inverse key. But if the switch between normal and inverse video occurs at the beginning of a line in BASIC, the character after this keycode occasionally goes undetected by the system at boot time (when higher speeds for key presses are used). I haven't been able to discover the reason for this. Possible solutions are to press the inverse key before pressing [RETURN] on the previous line, to make the first inverse character optional (such as a space), or to use a slower speed.

FF can call the MEMO PAD (the command is BYE), but cannot return to BASIC by itself. It can also call DUP (the command is DOS), but it will be deactivated when it returns to BASIC.

When entering text from the keyboard in Fast Fingers, you need press [ESCAPE] only once to invoke that character, rather than two times as is usually the case. To make FF produce only one [ESC] keystroke, remove the following two statements from line 310 of the program:

B$(L)= CHR$(28):L = L + 1

If you want to use the end-of-file key-code ([CTRL]-[3]) in your data file, change the Q=160 in line 350 to Q=154 and press [CTRL]-[,] when the EOF keycode is desired. FF cannot simulate a press of the [BREAK] key.

While the autoboot program created by FF is running, the keyboard is disabled to prevent a conflict with the keycodes coming from FF. You can change this with POKEs to locations 16 (POKMSK) and 53774 (IRQEN). POKE both with 64 to enable the keys, 128 to enable [BREAK], 192 to enable both, and 0 to disable both. The keyboard is automatically re-enabled when FF runs out of keystroke data.


Your imaglnatlon is the only Iimit to Fast Finger's possibilities. Given FF's practically automatic implementation, it's an easy matter to make your computer execute any command sequence, run programs, or simply perform acrobatics with the cursor. Turning on your computer was never so much fun!

Requires 16K RAM

Listing: FASTFING.BAS Download