THE apple® GAZETTE
Resolving Applesoft and Hires Graphics Memory Conflicts
Jeff Schmoyer
This article will attempt to divulge solutions to memory usage conflicts that can occur when an Applesoft program becomes large enough to start taking up residence in a Hires screen page. Of course the problems only appear when a program utilizing Hires graphics is executed. Throughout this article, numbers will be used in both decimal and hexadecimal (base 16). Hexadecimal numbers are represented with a dollar sign ($) preceding them, i.e. $800.
First, it is necessary to understand the memory layout of the region of RAM with which we are concerned. Applesoft programs may reside anywhere in memory from $800 to $BFFF in a 48K Apple II. If a disk is being used, the top boundary will be lower, generally $9600. The top boundary is not really important to this duscussion so it will be referred to as the top of memory. It makes no difference where it is.
The two Hires screens are in fixed positions in memory, the first located from $2000 to $3FFF, and the second from $4000 to $5FFF. Figure 1 is a map demonstrating what is known so far.
As may be seen in the drawing, if an Applesoft program is confined to the area from $800 to $1FFF, there is no conflict. This allows 6K of program space.
Now it's time to introduce another variable, variables! Not only does the program itself take up space, but as variables are allocated in the program, they too have to exist in memory.
String variables are no problem. They allocate space from the top of memory down. Plenty of unused space is available in this region.
Simple variables and numeric and string arrays on the other hand, start at the end of the program and move up through memory. If there are enough of them, they will cruise right into the Hires page. If this happens, whenever the Hires screen is altered by an HGR or some other command, the variables in the screen space will be changed or erased!
At this point it can be seen that there is 6K of memory available for the program and simple variables and arrays altogether. Now the space is starting to get tight.
The first solution that comes to mind is simply to switch screens and use the second graphics page instead of Hires page 1. That will free up an additional 8K of memory yielding 4K total.
This is not really a bad way to go except that some Hires features are not fully supported for the second screen, such as the mixed text and graphics mode. For Hires page 2, the four lines of text at the bottom are always filled with garbage. (The lines are not actually full of garbage but that will have to be considered in a future article.) There is also the possibility of needing both Hires screens in the program for animation or some other purpose. So this solution may not be totally acceptable.
One acceptable solution deals solely with the variables. If it can be determined that the program itself does not infringe on the Hires territory, the variables may be dealt with separately. This determination may be made by loading the questionable program, entering HGR, entering TEXT, and then listing the program. (Make sure the program has been saved somewhere first.) If the end of the program is still intact, the program fits in the room available. If it is gone then move directly to the next solution. This one will not do it.
If the program fits and the variables do not, the variables may be easily moved to another region of memory. To do this, as the first line of the Applesoft program enter 0 LOMEN:16384. This line must be executed before any variables are allocated. In this way variables are stored above Hires page 1 and out of the way. If both screens usage are required, 0 LOMEN:24576 may be alternately entered to start variable allocation above screen 2. Be sure to check that the additional program line did not extend the program past the Hires boundary.
If the program itself is too large for the available space, it must be moved to a more roomy area of memory, in this case above the Hires pages. There are two page zero locations which control where an Applesoft program starts, $67 and $68. By altering these locations and reloading the program, it can be run from the new location. These alterations may be made from the direct mode or by a startup program. As long as Applesoft is not reinitialized the changes will remain in effect.
In reality only location $68 in page zero need be changed since $67 will be set to 1 in any case. The necessary poke is POKE 104,96. 104 translates to location $68, while the 96 in hex is $60. This is the high order byte of the new program starting address, $6001. Alternatively POKE 104,64 may be used to locate the program at $4001. This operation has set up the new address for the program to be loaded and run from. For the programs to execute correctly at the new location, one other poke is necessary. The location preceding the program must be set to zero. This would be $6000 for the program at $6001 or $4000 for the program at $4001. POKE 24576,0 or POKE 16384,0 respectively will accommodate this change for programs at $6001 and $4001.
After the program is moved, a ‘dead zone’ is left in memory from $800 to $1FFF. Neither the program nor any of its variables will use this space. Its best use would be for machine language routines and tables.
To reiterate, for a program to load and run above Hires page 1, POKE 104,64: POKE 16384,0 is necessary. For a program to load and run above Hires page 2, POKE 104,96: POKE 24576,0 is necessary.
Remember, the program will not actually be moved by this operation. Only programs loaded and run after this point will be above the Hires screen. Also, reinitialization of Applesoft will reset the pointers to $800. Setting LOMEM as with the previous technique is not necessary and should not be done.
To recap, three techniques to avoid memory conflicts with Applesoft and the Hires screens were outlined. The first is to use Hires page 2 instead of Hires page 1. The second is to move the simple variables and arrays out of the way with the LOMEM command. The third is to change the program start pointers to reset the program load and run point above the Hires pages. There are other ways to accomodate the screens but these few should suffice in most cases.