Don’t Clog Your Memory With GOSUBs
Perhaps you didn’t know that you can exhaust the memory of your TS 2068 in a surprisingly short time, if you repeatedly use a GOSUB without a corresponding RETURN.
Try the following:
100 PRINT "FREE BYTES: ";FREE 110 LET N-1
120 PRINT AT 3,0;N
130 LET N-N*1
140 GOSUB 120
and RUN the program. You’ll get an OUT OF MEMORY report when N-78.
What happens, of course, is that the the computer saves up all of those addresses that it should have RETURNed to, stacking them neatly in a corner of the memory that it has reserved for this purpose. When that corner is full, you’re OUT OF MEMORY, regardless of how many empty bytes may be lying around elsewhere.
You ean get a bit more of an insight by adding the following line:
10 DIM A(1000)
You’ll see that, although FREE (the number of free bytes of memory) has been decreased by 5000, the number of unrequited GOSUBs that the memory can accommodate is unchanged.
You might liken this effect to an embolus that blocks a strategic blood vessel, shutting down the body even though the rest of the cardio-vascular system is unimpaired.
THE MORAL
Obviously, the first thing to make sure of is to provide a RETURN for every GOSUB you include in the program, But a more subtle point–make sure that the RETURN command ACTUALLY GETS USED. There are two very real possible pitfalls:
First, watch the program itself. It’s all too easy to route the program around that vital RETURN (as the result, for instance, of an IF . . , THEN statement).
Second, be careful not to BREAK the program in the middle of a subroutine. If you have a program that you know you will want to BREAK repeatedly, include a command that will BREAK the operation at some controlled point. Something along the line of:
IF INKEY$=B THEN GO TO . . .
followed by some address that will stop the program without interrupting a subroutine.
Of course, you can also sweep the debris out of that corner of memory by using the RUN or CLEAR instruction, but only at the cost of losing every other bit of data that the computer has saved up for you.
I suppose that the same principle applies to the ZX81/TS1000 as well, but the limit seems to be well above the practical range. I ran out of patience (with the TS1500, actually–I hope that I’m right in assuming that the same rule holds for the 1000) when N got up to 1,200.