Memory utilization with the Atari Home Computer can be difficult. Much of the memory is commandeered by the operating system, the resident cartridge, or the DOS, leaving very little under the direct control of the programmer. This gives the programmer very little freedom in laying out memory utilization for a program. With proper planning this need not be a serious problem.

PAGE ZERO

The most important RAM for any assembly language programmer is page zero. Page zero is absolutely essential for pointers and is very useful for heavily used variables, because code written for page zero variables is more compact and runs faster. Hence the assembly language programmer wants to know how many locations on page zero can be stolen for his own use. This appendix will not cover the use of page zero locations as they are defined and used by firmware. Instead, it will address only their use when the firmware's function is disabled or ignored.

The lower half of page zero (addresses $00-$80) is reserved for use by the operating system. The 128 bytes here are required for the entire array of services that the operating system provides. Most programs will use only a portion of those services. Thus, many locations in this region will not be used by the operating system during the program's execution. In particular, the 43 bytes from $50 to $7A are used only by the screen editor and display handler. Most programs will use custom display lists with their own display handlers. These 43 bytes would then become available during program execution. Similar reasoning applied to other locations dedicated to special functions would free even more.

Unfortunately, there is a major flaw in this reasoning. The software department at Atari is constantly evaluating the performance of the operating system and making changes in the code. There are now two versions of the operating system -- Rev A and Rev B. They are functionally almost identical; software that runs under Rev A will almost certainly run under Rev B. More revisions are contemplated and it is highly probable that the under utilization of those 43 bytes will be corrected in future revisions of the operating system. Thus, any software packages that steal those 43 bytes, or any other bytes from the lower half of page zero, will probably malfunction if run under a future operating system. Therefore, commercially offered software should not steal any bytes from the lower half of page zero.

The programmer must look to the upper half of page zero for free bytes. These 128 bytes are reserved for use by the cartridge. If no cartridge is in place, they are free. If a cartridge is in place, some bytes will be reserved for the programmer. The BASIC cartridge leaves only 7 bytes for the use of the programmer -- $CB through $D1. The programmer who must have more page zero bytes has only one option: the bytes used by the floating point package ($D4 to $FF). These 44 bytes may be taken if the floating point package is not used by the programmer's routines and if those routines do not themselves call the floating point package. The programmer does not have unlimited use of these bytes; they must not be used by any interrupt routines, as such routines might strike during a floating point operation called by BASIC. There are no other bytes on the upper half of page zero usable by the programmer.

The programmer working in the BASIC environment is seldom interested in the high performance and compactness that page zero offers; after all, if high speed and compactness were primary concerns, the programmer would not have chosen BASIC as a delivery language. The programmer most interested in large amounts of page zero is the assembly language programmer. A pure assembly language program does not need any cartridge installed to run; therefore it should have access to all 128 bytes of the upper half of page zero. In practice this is not quite so simple, for an assembly language program must be debugged, and the only convenient way to do this at present is with the debugger in the Atari Assembler-Editor cartridge. Assembly language programmers will note with chagrin that this cartridge only reserves 32 bytes for their own use. While this is entirely adequate for virtually any program it is not enough to sate the appetite of a high-performance program. There are 30 more bytes that are not used by the debugger portion of the cartridge. These are: $A4, $A5, $AD, $AE, $DB through $E5, $EA through $F1, $F5, $F6, $F9 through $FB, $FE, and $FF. If these bytes are used the programmer must not return to the Editor or the Assembler or bad things may happen. Furthermore, the mini-assembler inside the debugger must not be used.

If you use other cartridges or disk based languages, you are on your own. Many of these systems use even more of page zero.

ABSOLUTE RAM

Another problem the programmer faces is presented by the DOS. It is very desirable to write programs that run on either 16K cassette systems or 48K diskette systems. Unfortunately, such systems have very little free RAM in common, for the DOS and DUP would almost fill the RAM of the 16K system. There are several solutions to this problem. One is to produce two different versions of the code, a disk version and a cassette version. The two programs would be orged to different locations. This means that customers who buy the cassette version will not be able to transport it to a diskette if they upgrade their systems.

There is another way. Page six is common free RAM for all systems. Variables and vectors can be placed on page six and used by cassette-based software or diskette-based software. A directory of routine addresses can be computed and placed at run-time onto page six. Machine language routines can then jump through the page six directory to the routines elsewhere in RAM. The technique can be difficult to execute; it is not recommended for large assembly language projects. Its greatest value is with medium-size machine language routines (about 1K-2K) embedded inside BASIC programs.