ATARI'S CINDERELLA

The second half of the saga

by FRED PINHO

This is the second part of a two-part tutorial on the Atari computer Operating System. The program listings run on all Atari computers.

Welcome back! Last month, in part I of this series, we covered the Atari Operating System (OS) in general and several sections of the OS in detail. In Part II, we'll continue our exploration of each of the main components of the operating system.

THE I/O SYSTEM

This element of the OS is critical to the functioning of the computer as we know it. No matter how powerful a microprocessor is, it's essentially useless if it can't communicate with external devices such as a cassette recorder or TV screen. Atari has set up its central input/output I/O system in a very efficient manner. For example, data transfer is handled in the same way regardless of which peripheral device is involved. A new peripheral can be handled by simply adding a new device handler (a program that communicates with the peripheral) to the OS.

The I/O system is composed of a number of sections: the central I/O routine (CIO), the serial I/O routine (SIO) control blocks (IOCB's), and device handlers. The CIO is the entry point ior most I/O performed by the computer. It routes I/O requests to the correct device-handling routine.

At the heart of this versatile system are the Input/Output Control Blocks (IOCB's). There are eight of these, each of which is 16 bytes long. BASIC, or the programmer, sets up a specific IOCB for each desired I/O command. Then a call is made to the central I/O routine. Presto, it's done! All BASIC commands that involve I/O to a device, including the monitor screen, are actually performed by the CIO. These include such commands as PLOT, DRAWTO, PUT, GET, PRINT and LIST.

IOCB #0 is reserved for the text screen editor. IOCB #6 is used for screen graphics statements (remember the PRINT #6 commands you use to print to a GR.1 or 2 screen?). IOCB #7 is used for LPRINT and program loading and saving. But IOCB's #1-5 are always available for the programmer's use. And much can be done with the standard BASIC commands. The OPEN command tells BASIC how to set up an IOCB for subsequent use. Then you can PRINT, LIST, PUT, etc. to the specific device controlled by that IOCB. However, the CIO is capable of even greater computing power. Unfortunately, the use of machine language is required to access these computing capabilities. BASIC can be used to set up the IOCB for such extended operations, but a short machine-language routine must be used to call the CIO via the USR command.

BASIC'S LIMITATIONS

A limited data-movement capability is available through BASIC (via commands such as OPEN, GET, PUT, etc. ). However, GET and PUT affect only one data value at a time. What do you do if you want to SAVE or LOAD a large amount of data in one operation? Say, for example, that you want to save and retrieve a picture drawn on your graphics screen. The CIO has the capability to do this, but, unfortunately, BASIC does not support this valuable application. It can, however, be accomplished through BASIC if you use a short machine language routine that directly calls the CIO. This technique is illustrated in listing 2 (Listing 1 appeared in Part 1).

TRY THIS

Lines 31010-31310 of Listing 2 give BASIC the ability to rapidly save and retrieve an entire graphics screen to disk or cassette. Lines 31050-31160 save the screen data; lines 31200-31300 retrieve it. Type RUN and the computer will create a simple drawing and ask you if you wish to save or load a screen. Be sure that your disk or cassette is ready, and then request save. When the operation is finished, type in the following: GR.5:GOTO 31020. The screen will clear and once again you will be asked to choose either save or load. This time, request a load. Voila, it's done! If you use a disk, the screen will load quickly. With the slower cassette, you'll see the screen load in sections.

This program is written for Graphics Modes 2-8(i.e., only the graphics modes that use a text window). Lines 31060 and 31230 exclude the 160 bytes that contain the text window data. Also, please note that the program saved the graphics mode value. On loading, this value is checked against the existing graphics mode to insure that there is no mismatch. Finally, the color registers are also saved. As a result, your creation is saved and loaded with the colors of your choice rather than with default colors.

SYSTEM VECTORS

Of all the computer jargon words, "vector" caused me the most trouble when I was new to the field. It was used very often and never explained. Basically, a vector is a pair of memory locations that contain the address of a specific machine-language routine. When the microprocessor needs to run the routine, it goes to these memory locations to find the required address.

The Atari OS is loaded with vectors (both in RAM and ROM). The RAM vectors handle most of the interrupt routines and the disk and cassette boot code. The vectors stored in ROM contain addresses to crucial OS routines and devicd handlers. RAM vectors can be changed to force the microprocessor to do the programmer's bidding; ROM vectors are fixed and cannot be changed. (The exceptions to this are the ROM vectors for device handlers. During initialization, these vectors are copied into RAM. As a result, the programmer can change addresses or add new addresses in the handler vector table.)

TIMERS

A number of timers are built into the Atari OS. The six that are located in RAM are called software-system timers. These timers are updated during the Vertical Blank Interrupt (VBI). During the VBI, the count in each timer is either incremented or decremented by one. Since this update occurs roughly 60 times per second, the minimum time delay that can be programmed via these timers is 0.0167 seconds. For most of us, this is more than adequete. Incidentally, a sixtieth of a second is commonly called a "jiffy."

The timer that is most readily accessible through BASIC is the real-time clock (RTCLK). This count-up (incremented) timer is located at memory locations 18-20 and occupies three bytes. Location 20 is the least significant byte and is the only one that is incremented during each VBI. When location 20 "overflows" (or goes one past its maximum value of 255), location 19 is increased by one. Similarly, when location19 overflows, location 18 is increased by one. Note that when a memory byte overflows, it automatically resets to zero. Thus, when RTCLK reaches its maximum value, it automatically resets itself. A count in each register is linked to human time as follows:

Memory Location---18--------19--------20
Seconds Per Count--1094----4.272----0.0167

To use this constantly-counting timer, POKE zeros into the three memory locations. Then PEEK them and convert the values as in the following example:

Total Jiffies = 65536*PEEK(18)+256*PEEK(19)+PEEK(20)
Total Seconds = Total Jiffies/59.92334

Note that we do not divide by 60. I've used the actual VBI time interval, which is close enough to 60 for most purposes. (Listing 3 is a short BASIC program that illustrates the use of the RTCLK.)

The other five software timers are accessed primarily through machine language. All of them are two-byte, count-down timers (maximum count = 18 + minutes). Timers 1 and 2 cause the OS to run on a machine-language subroutine when they have counted down to zero. This is very handy, since the timer counts unobtrusively in the background while your main program goes about its business. Then, when the timer counts out, your subroutine will automatically do its thing. This is performed during the VBI, so any graphics change will be sharp and clean.

Timers 3-5 simply set a flag byte to zero when they count out. By checking this location, you will know when time is up. These three timers can be accessed directly from BASIC. Due to BASIC's slowness, the timeout check will be rough, but adequate for many purposes. A short demo is given in Listing 4.

Atari offers you an embarrassment of riches, since there are also four timers in the POKEY chip. These "hardware" timers can be used for time intervals much shorter than a sixtieth of a second. They are count-down timers that generate IRQ interrupts and are normally used to generate sound. However, skillful programmers can subvert them to their own purposes.

FLOATING-POINT PACKACE

This set of OS routines provides the computer with extended arithmetic capabilities. The central processor, the 6502 chip, has limited talents. All it can do is add, subtract and compare two numbers. The higher arithmetic functions, such as multiplication, division and exponentiation, must be handled by machine-language programs that are built around the 6502's capabilities. It would have been inefficient to have required that each language loaded into the computer carry its own floating point package, so Atari installed a special chip in the OS cartridge to take care of this task.

The term "floating point" simply means that you can do math with fractions and decimals. Integer BASIC's are available for some computers. These allow only whole numbers to be used (-128. 4. 3600). There is a price one pays for the increased computing ability provided by the floating-point package: speed. Floating-point BASIC's are slower than integer BASIC's. (Note that Atari BASIC converts all numbers, even integers, to floating-point notation. Thus, you can't gain the speed of an integer BASIC by using only integers in Atari BASIC.)

CHARACTER SET

Also located in the OS ROM cartridge is the so-called character set. The computer does its thing via the binary number system. But very few, if any, humans can communicate meaningfully in this way. So, for the convenience of the human user, the computer converts each number (0-255) to a special character (letter, number, etc.) for display on a peripheral device. The standard convention for this conversion process is called ASCII (American Standard Code for Information Interchange). Atari has modified its code slightly; the Atari version is ATASCII. In essence, each character in the ASCII or ATASCII character set is represented by eight bytes that tell the computer how to display that character. The character set is often fixed in ROM, and a "hard" character set is all that many computers have to offer. However, the Atari allows the programmer to change the character set for his own purposes. Many games use redefined character sets to create their exciting graphics. The basic method used is to copy the ROM set into RAM. Once in RAM, the character bytes can be altered to match your needs. By POKEing into a single memory location, you can instruct the computer to use your character set rather than the ROM version.

EMERGING FROM THE CAVERNS

I hope that this short presentation has given you a better understanding of Atari Operating System. I've also tried to suggest how much Atari computing power is available to the knowledgeable programmer. Much of the power of the Atari OS is available only through machine language, but you don't have to write whole programs in machine code. Wondrous things can be accomplished within the BASIC universe via short machine-language routines that are accessed by the USR command. There is much to explore in the murky caverns of the OS. Have fun!

Fred Pinho is a biochemical research engineer and self-taught programmer who is interested in BASIC and assembly language. The Atari 800 is his first computer.

CINDER1.BAS Download

CINDER2.BAS Download

CINDER3.BAS Download

CINDER4.BAS Download