integer variables, yet that is where a significant savings in memory ^J can be obtained. This is particularly true if the program contains
arrays. Consider that, for each element in an array, the number of ^
bytes occupied is as follows: ^j
134
A string array = three bytes plus the length of the string per element.
A floating point array = five bytes per element.
An integer array = two bytes per element.
The contents of many arrays do not require the use of decimal points, but it is easier to code "DIM A( 15)" rather than "DIM A%( 15)."
By using the integer form, you would save 45 bytes of memory.
Suppose you were writing a program to deal a deck of cards and you defined an array to keep track of which cards have already been dealt. That 52 element array could be a string array, a floating point array, or an integer array. Obviously, there is no need for decimals in this example, so the obvious choice would be to use integers. The following program was run three times on the VIC-20, each time changing the type of array (making the variable type in statement 400 correspond to the array).
100
The differences in memory use during these three runs are very dramatic: the first run used a floating point array and occupied 601 bytes; the second run used the string array and occupied 403 bytes;
and the final run, which used an integer array, occupied only 300 bytes. Is it worth the cost of 300 bytes in order to save typing in a
"%" each time the variable is used?
Each of the memory conserving measures outlined so far would be relatively easy to implement using the editing capabilities of the VIC-20 once a program is written and resident in memory. The last few suggestions are harder to implement, and the savings are more indefinite.
If your program contains groupings of instructions that are repeated several times, it would be more memory efficient (and better programming practice) to incorporate those instructions once as a subroutine and GOSUB to them. If such statements are readily identifiable, you can implement this fairly easily with the following
CHAPTER THREE
three steps:
1 - Add a RETURN statement after the first group of statements.
2. Place a GOSUB statement whose object line number is the first line number in the group immediately preceding the group.
3. Add a GOTO statement immediately after the inserted GOSUB statement whose object line number is the statement immediately following the RETURN statement.
Naturally you would delete all other occurrences of the same group of statements and replace them with a GOSUB to the newly created subroutine. This sounds very complicated, but actually is quite easy to implement and is illustrated in the fictitious routine that follows. Assume that the statements starting with line number 650 and ending with line number 710 are repeated several times in the
program.
640 PRINT "ABC"
6 50 A=A+1
660 IF A=9 THEN 700 670 PRINT"MESSAGE ONE"
680 MC=MC/A 690 GOTO
7 00 PRINT "MESSAGE TWO"
710 MC=MC*A 720 IF Q+l=10
You can convert this to a subroutine using the technique described by adding lines 645 and 715 in the following illustration:
640 PRINT "ABC"
645 GOSUB 650:GOTO 720 < = = = = New statement 6 50 A=A+1
660 IF A=9 THEN 700 670 PRINT"MESSAGE ONE"
680 MC=MC/A 690 GOTO
700 PRINT "MESSAGE TWO"
710 MC=MC*A
715 RETURN < === = = New statement 720 IF Q+l=10
Another almost obvious way to decrease the amount of storage your program uses is simply to reduce the size of messages that you display on the television. For example, if your program displays the
word "TOTAL", change it to "TOT". If your program contains cards, instead of spelling out "KING," "QUEEN, "and JACK," simply use a K," Q," and "J," respectively.
Another item to investigate is the use of more economical instruc tions to achieve the same results. Shown below is an example of how you can replace multiple IF statements with a single ON statement. The program does the exact same thing either way you write it, but using the ON statement yields a savings of 62 bytes.
The following statements 300 IF A=l THEN 510 310 IF A=2 THEN 550 320 IF A=3 THEN 600 330 IF A=4 THEN 650 340 IF A=5 THEN 700 350 IF A=6 THEN 750
could be replaced with the single statement:
300 ON A GOTO 510,550,600,650,700,750
Consider using FOR/NEXT loops wherever possible instead of repeating instructions. Suppose you wanted to print a vertical line down the center of the screen. You could program it as:
300 PRINTTAB(10); "1"
310 PRINTTAB(10);"1"
3 20 PRINTTAB(10); "1"
3 30 PRINTTAB(10);H1"
340 PRINTTAB(10);"1"
350 PRINTTAB(10);"1M 360 PRINTTAB(10);"1"
370 PRINTTAB(10);"1"
380 PRINTTAB(10);"1"
390 PRINTTAB(10);"1"
4 00 PRINTTAB(10); "1"
or alternatively you could code:
300 FOR X=l TO 11 310 PRINTTAB(10) ; "1"
320 NEXT X
Again, the same results are achieved, but the FOR/NEXT loop yields a savings of 118 bytes!
CHAPTER THREE
Overlaying
You can sometimes conserve memory by overlays. If your program runs in two separate and distinct phases (that is, one portion of your program completes all its work and then is never executed again), it should be possible to split your program into two sections. Have the last statement in the first section issue the statement "LOAD PHASEII"
(assuming your second phase is named "PHASE II"). When the first section completes its job, the last instruction would load the next phase for execution.
This assumes that you have written PHASEII onto the cassette tape immediately after PHASEI. This is called overlaying; it lends itself well to a disk-oriented system, but there is no reason not to use it with tape also. You should be aware that any variables used in the first phase will not be available in the second phase. (However, even though this should work, the author has not yet been able to do it successfully.)
If you still need memory, you may be able to put some of the data used in your program on a cassette tape and read the data in during program execution. This technique will involve your writing a special program to create the data tape, but in some instances, this can yield substantial memory savings. "Custom Characters for the VIC" (reprinted in this book) contains a program which lends itself very well to illustrating this memory-saving technique.
This program contains a number of DATA statements and is shown below:
170 READ X:IF X>0 THEN 190 180 FOR X=X TO X+7
182 READ J 184 POKE I,J 186 NEXT 190 GOTO 170
340 DATA 7168,24,24,36,60,102,66,66,0 350 DATA 7176,124,34,34,60,34,34,124,0 360 DATA 7184,126,34,34,32,32,32,112,0
600 DATA 7376,0,0,0,0,0,0,0,0610 DATA -1
You would have to write a program to write the data to cassette tape (and ideally you would write the data immediately after the program you saved that will be using that data). The original program can be easily modified to create the data tape, and an example could be:
138
100 OPEN1,1,2,"DATATAPE"
170 READ X:PRINT#1,X:IF X>0 THEN 190 180 FOR X=X TO X+7
182 READ J:PRINT#1,J 186 NEXT
190 CLOSE1
2 00 PRINT"DATA TAPE CREATED"
210 END
340 DATA 7168,24,24,36,60f102,66,66f0 350 DATA 7176,124,34,34,60,34,34,124,0
360 DATA 7184,126,34,34,32,32,32,112,0 600 DATA 7376,0,0,0,0,0,0,0,0610 DATA -1
You would then substitute INPUT# 1 statements for READ statements in the original program, but the results would be the same. If you wanted to use the concept in Mr. Malmberg's article in your own program, but needed additional memory, this technique
would provide you with a significant amount of memory.
The modified program would be:
165 OPEN 1,1,0, "DATATAPE11 170 INPUT#1,X:IF X>0 THEN 190 180 FOR X=X TO X+7
182 INPUT#1,J 184 POKE I,J 186 NEXT 190 GOTO 170
340 REM-NO DATA STATEMENTS-RESULTS IN 3 50 REM-A SIGNIFICANT REDUCTION IN MEMORY
Let's assume that you have exercised all the memory-saving procedures outlined and your program still requires additional memory. The last thing to do is carefully investigate the logic of your program. Are there statements that are never executed (perhaps left over from an initial idea that was abandoned)? Naturally, you should remove them. Are there better ways to implement a procedure that might reduce the number of instructions necessary to accomplish some objective? Sometimes being able to buy backjust five or ten bytes of memory will allow your program to run.
One final point: there are instances when you have worked for hours on a large, complicated program and you decide to save it on a cassette tape. You type in the command "SAVE MYPROGRAJVT,