Mini Memory Screen Dump to Module

Summary

These two routines will save a graphics screen to minimemory and recall a graphics screen from minimemory to the screen. If the battery is good enough the graphics will remain in the module even when you unplug it. Here we are not using the module's file handling but placing the data directly into a memory address in the module. These are just the routines, you will need to add them to programs and call them as you need to.

Dump screen graphics to Mini Memory storage

LOAD to Mini Memory 
1000 CALL INIT 
1010 FOR T=0 TO 750 STEP 24 
1020 CALL PEEKV(T,A1,A2,A3,A 
4,A5,A6,A7,A8,A9,B1,B2,B3,B4 
,B5,B6,B7,B8,B9,C1,C2,C3,C4, 
C5,C6) 
1030 CALL LOAD(T+29000,A1,A2 
,A3,A4,A5,A6,A7,A8,A9,B1,B2, 
B3,B4,B5,B6,B7,B8,B9,C1,C2,C 
3,C4,C5,C6) 
1040 NEXT T 
1050 FOR T=1024 TO 2041 STEP 
20 
1060 CALL PEEKV(T,A1,A2,A3,A 
4,A5,A6,A7,A8,A9,B1,B2,B3,B4 
,B5,B6,B7,B8,B9,C1,C2) 
1070 CALL LOAD(T+30000,A1,A2 
,A3,A4,A5,A6,A7,A8,A9,B1,B2, 
B3,B4,B5,B6,B7,B8,B9,C1,C2) 
1080 NEXT T 
1090 END 

Load screen dump back from mini memory storage

and then to restore the screen from mini memory:

READ FROM MINIMEMORY AND RESTORE TO SCREEN:
100 CALL CLEAR 
110 FOR T=1024 TO 2041 STEP 
20 
120 CALL PEEK(T+30000,A1,A2, 
A3,A4,A5,A6,A7,A8,A9,B1,B2,B 
3,B4,B5,B6,B7,B8,B9,C1,C2) 
130 CALL POKEV(T,A1,A2,A3,A4 
,A5,A6,A7,A8,A9,B1,B2,B3,B4, 
B5,B6,B7,B8,B9,C1,C2) 
140 NEXT T 
150 FOR T=0 TO 750 STEP 24 
160 CALL PEEK(T+29000,A1,A2, 
A3,A4,A5,A6,A7,A8,A9,B1,B2,B 
3,B4,B5,B6,B7,B8,B9,C1,C2,C3 
,C4,C5,C6) 
170 CALL POKEV(T,A1,A2,A3,A4 
,A5,A6,A7,A8,A9,B1,B2,B3,B4, 
B5,B6,B7,B8,B9,C1,C2,C3,C4,C 
5,C6) 
180 NEXT T 
190 GOTO 190

Directly addressing memory

CALL PEEKV reads values from VDP RAM - that is where the screen contents and character definitions are kept - and in TI Basic, also your program.

CALL PEEK (no V) reads values from CPU RAM - the console on its own has only 256 bytes (actually in the CPU chip). In this program it is used to look at CPU RAM in the Mini Memory module.

CALL POKEV places values into VDP RAM while CALL LOAD places values in to CPU RAM.

The format is: 
CALL PEEK(memory location,value,value,value  etc) 

The first value is that in the memory location, the second value is that in the next highest memory location, and so on.

Although not used here, you can also split the commands by using a null string, e.g.

CALL PEEK(location one,value,value,"",location two,value) 

So let's have a look at those two listings (and see what is wrong with them!):

Explanation- Save graphics to module

LOAD the graphics to Mini Memory:

CALL INIT clears the CPU RAM and ensures you don't trip over anything already there.

Lines 1010 to 1040 look at the screen contents, details of which are in VDP RAM at location 0 to 767 (32 x 24) with 0 at top left and 767 at bottom right. The values stored in these locations are the ASCII code plus 96 (e.g. A is 161).

I have used several locations in each CALL for greater speed. The CALL LOAD places these values into the Mini Memory CPU RAM - the actual address used is not important so long as the address used is actually IN the Mini Memory! (location 28672 to 32767 - ALL numbers used here are decimal). Having placed the values into Mini Memory, they will stay there even when you switch off - until you initialise or replace them. The can be saved to save - with verify function.

So - we have read the screen and placed it into the Mini Memory.

Now lines 1050 to 1080 read the character definitions from VDP RAM and place them into the Mini Memory.

Character definitions for ASCII 32 to 96 are held in memory locations 1024 to 1535. Each character definition takes up 8 bytes. We can infer that the "lower case" characters are initially derived as they are not defined. When you define a character over 96, the definition uses a higher memory location, from 1536 up. The highest memory location used in character definitions is thus 2040.

Now the information is in Mini Memory it can be recalled to the screen by reversing the process - reading Mini Memory and placing the values in VDP RAM.

Explanation - restore graphics from module

DISPLAY

The DISPLAY program does just this - moving values from one location to the other, to recreate the screen. I have first transferred the character definitions and then placed the characters onto the screen.

What about the value stack

Note A: In this example if you have used characters 97 and 98 you may notice something odd. In normal use memory location 1536 up is used for the VALUE STACK (e.g. variables), and if you define extra characters with CALL CHAR the value stack is automatically moved up to make room for the extra definitions.

In this case we have only moved the definitions to this area of memory - we have not instructed the computer that the value stack starts at a higher address - so it carries on using 1536 up - messing up our definitions for CHARs 97 and 98.

You could get round this by forcing the stack higher by using:

FOR T = 97 to 159 
CALL CHAR(T,"0") 
NEXT T 

before you move the data from Mini Memory to VDP.

If there are no redefined characters

Note B: If you do not have redefined characters you need only transfer VDP addresses 0 to 750. If characters ARE defined you need only transfer the data for the redefined characters - ASCII 32 is in 1024 to 1031 etc, up.

Other notes

Note C: The programs given take 25 seconds to recreate the screen, which is the same as using CALL CHAR for every character and then using 24 PRINT statements. This way is much easier to save redefined characters.

Note D: Once in Mini Memory the data can be quickly saved to cassette using the EASY BUG commands "S" and "L" for locations (hex) 7000 to 7FFF. You will be able to use the tape-verify option, and not much tape is used.

This example is given to show you something the Mini Memory is capable of - it is not the best solution to every problem!