xavier wrote:Vic20 memory get hard in case of expansion is in use ...
Not really. I'm following up this with a slightly longer post. Sorry in advance for that.
It all boils down to what contiguous address range in RAM is available for a BASIC program and its variables, what address range of RAM is accessible for the VIC chip and whether these two address ranges might collide and need to be separated.
The addressable memory for the VIC chip is fixed, and doesn't change regardless what external expansions are there: only the RAM at addresses $0000..$03FF and $1000..$1FFF and the character ROM are 'visible' for VIC. $0000..$03FF are used by the OS. So for the text screen, it makes sense to place it at either end of the range $1000..$1FFF to maximize the amount of contiguous RAM for BASIC:
1. Actually, on an unexpanded VIC-20, BASIC uses $1000..$1DFF, and the text screen is placed at $1E00 so it can be left there, when the smallest available RAM expansion, +3K, is added.
2. The +3K RAM expansion is mapped in at $0400..$0FFF, BASIC uses $0400..$1DFF, the text screen keeps its position at $1E00. It would not be possible to move the text screen to $0400 and let BASIC use $0600..$1FFF instead!
3. When a +8K or bigger RAM expansion is present, it is mapped to $2000 following. To maximize the available space for BASIC, the text screen is therefore moved down to the lower end of the range $1000..$1FFF accessible by VIC. BASIC starts at $1200 and extends all the way up to what the RAM expansion delivers ($3FFF for +8K, $5FFF for +16K and $7FFF for +24K).
I put a diagram of these 3 cases into the sticky thread "
VIC-20 Memory Layout" - see the boxes for
BASIC memory.
If there is a +3K RAM expansion present alongside a bigger RAM expansion, the text screen still can't be moved down to $0400. The lowest possible address again is $1000. The bigger RAM expansion takes precedence, thus the +3K RAM expansion is blocked from use by BASIC, which is also reflected in the number of BYTES FREE (it stays the same as for +8K/+16K/+24K without the extra +3K). But the RAM is still there, and can be used by machine language programs, for example.
The 8K address range at $A000..$BFFF (BLK5) can't form a contiguous block with the 'main' RAM in any case, and thus likewise isn't shown as extra BYTES FREE if it's populated with RAM. It's still usable by machine language programs.
With user defined graphics, VIC not only needs to read text screen data from its restricted memory range, but also the character matrixes of the user defined graphics. It must be ensured, that the user defined graphics do not collide with the BASIC program or its variables: when the program POKEs the character matrixes from DATA lines, it could inadvertently overwrite itself; likewise the variables (especially strings) might overwrite the character data that has already been defined in RAM.
There are mainly two techniques to keep character data and text screen separated from the program and its variables:
1. Lowering the roof. That's what's being done with
POKE55,...:POKE56,...:CLR. That method is mainly used on an unexpanded VIC-20, or with a +3K RAM expansion. The memory arrangement then is:
|program/variables|character data|text screen|. The BASIC program itself stays at the same place.
2. Raising the start of BASIC. That method is necessary, as soon as a bigger RAM expansion (+8K or more) is there. If done otherwise, lowering the roof would completely block the RAM expansion from BASIC use (again, text screen and character data need to reside in the range $1000..$1FFF!). Raising the BASIC start is rather difficult to do (to say the least) from an already
loaded and running BASIC program, as the program itself and its variables would need to be shifted in memory, and lots of pointers would need to be adjusted
while it is running. Instead, the BASIC start is adjusted before. Either manually (those POKE and SYS incantations), or with boot loaders (and lots of simulated keypresses), and then the program is loaded to and run from a place, where it again cannot collide with either text screen or user defined graphics. The memory arrangement then is:
|text screen|character data|program/variables| or
|character data|text screen|program/variables|.
Finally, some remarks about how the addresses 43/44, 55/56, 641/642 and 643/644 are used by BASIC and KERNAL:
- directly after a reset/power-on, the KERNAL scans the available contiguous RAM address range 'around' the internal RAM, corrects it for the aforementioned restrictions of the VIC chip, and stores the result in 641/642 (bottom of RAM, RAMBOT) and 643/644 (top of RAM, RAMTOP)
- when BASIC is cold-started after reset/power-on, it takes the value in 641/642, adds 1, and writes the result to the BASIC start pointer in 43/44; it then copies the value in 643/644 to 55/56 as pointer to 'end of memory for BASIC'. A 0-byte is placed right before the BASIC start to signify a line end for the interpreter, and then a automatic NEW command writes another two 0-bytes directly behind - this is actually an empty BASIC program! That's why you see 3583 and not 3584 BYTES FREE in the start-up prompt (and PRINT FRE(0) gives 3581).
Now it is possible to execute most parts of the reset routine, excluding the RAM check, with SYS64818 - instead providing own, redefined values for 641..644. As 641 and 643 most probably contain a zero from an earlier (power-on) reset, most often only 642 and 644 (and 648 for the screen base) are changed. So instead of POKE642,30:POKE0,108:POKE1,0:POKE2,192:SYS0, the line:
would have the same effect: returning you to the start-up prompt, with slightly less available memory, which has been protected for the program to use text screen and character data. As you have noted, that method is particularly unfit for a batch procedure, as the executing program is stopped, and even cleared from memory.
Changing 43/44, and POKEing the 0 in front of it, won't make it necessary to restart BASIC, so it can be done as batch. With a boot loader, two methods are possible:
1. PRINTing two lines with
POKE43,...:POKE44,...:POKE....,0:NEW and
LOAD"...",8 and executing both with simulated key presses. That's how you implemented it in your posting before.
2. PRINTing just
LOAD"...",8, and changing 43/44 from *inside* the program, which however comes in effect only just as the NEW is executed! Simulated key presses ({HOME}, and {RUN} -> LOAD + CR + RUN + CR) then execute the LOAD command and autostart the client program. This method requires much less thought on the screen layout:
Code: Select all
10 PRINT"{CLR}LOAD"CHR$(34)"..."CHR$(34)",8"
20 POKE631,19:POKE632,131:POKE198,2
30 POKE43,...:POKE44,...:POKE....,0:NEW
POKE642,... is not necessary here, as no BASIC cold-start is performed which would re-init 43/44 from 641/642. But you definitely would want to define the low-byte of the BASIC start pointer. In your concrete case, the boot loader then looks like this:
Code: Select all
10 PRINT"{CLR}LOAD"CHR$(34)"MEURTREM1.PRG"CHR$(34)",8"
20 POKE631,19:POKE632,131:POKE198,2
30 POKE43,1:POKE44,30:POKE7680,0:NEW
Greetings,
Michael
