Reorganising 8k RAM?

Mayhem · Post by **Mayhem** » Wed Jul 13, 2011 6:14 pm

Courtesy of Rob O'Hara, I've gotten a few disk images of Vic20 stuff from the CUON archive he made available. There are some Compute games in there I haven't got archived, plus it's allowed me to add credits to a bunch I did have but didn't know where they came from.

Anyhow, one game that needs 8k to load refused to run properly. It wasn't until I managed to find the issue in question scanned online, that I discovered I needed to type in the following before loading it:

POKE 44,28: POKE 43,1: POKE 28*256,0: NEW

My question is... what can I do (easily!) so that I can load in the game (via Gamebase) without the need to type that in first?

Mike · Post by **Mike** » Thu Jul 14, 2011 1:07 am

You need a boot loader for this, similar to what is used for VICtoria:

Code: Select all

1 REM ** BOOT LOADER
2 DN=PEEK(186)
3 PRINT"{CLR}POKE43,1:POKE44,28:POKE28*256,0:NEW"
4 PRINT"{2 DOWN}LOAD"CHR$(34)"file name"CHR$(34)","DN
5 POKE631,19:POKE632,13:POKE633,131:POKE198,3:END

In line 4, replace 'file name' as appropriate. The PEEK of address 186 establishes the device number where the boot loader has been loaded from, and so ensures the next file is loaded from the same device number.

It prints the line with the POKEs and the LOAD command on screen, and then fills the keyboard buffer with HOME, RETURN, and SHIFT+STOP, i.e. RUN. The second simulated keypress moves the BASIC start as intended, and the third simulated key press will overtype the already present LOAD command (doing no harm), loading the game, and then issue RUN to start the payload. The POKEs in line 3 can also be adjusted to other requirements of space 'below' the BASIC program.

That technique is fundamental for using redefined characters in BASIC programs with 8K or more of RAM expansion.

Another way would involve a BASIC stub, allowing to single-file the game again. However, unless the character set and eventual ML programs have already being POKEd into place, that method wastes a lot of (disk) space between the stub and the payload.

Mayhem · Post by **Mayhem** » Thu Jul 14, 2011 7:40 am

Cheers... after I posted I found another program on one of the disks that did something pretty similar to that, so I guess I know why it was included heh. Between these disks and the scans of Compute books I've gotten online, I think I might be busy for a while... anyone fancy doing some typing?

Mike · Post by **Mike** » Thu Jul 14, 2011 8:04 am

Mayhem wrote:I found another program on one of the disks that did something pretty similar to that, ...

At least it has been documented here for now. Once again.

The lack of knowledge of how to use UDGs in BASIC with a memory expansion of 8K or more has often enough served as bad excuse for not to use RAM extenders at all (the other reason being the shifting screen memory - geez, what is complicated about that??).

Mayhem · Post by **Mayhem** » Thu Jul 14, 2011 10:10 am

Indeed. The other program on the disk I found set up very similar screen commands and POKEs so I guess it was designed as a header for people wanting to use UDGs with 8k RAM.

The game itself occupies 17 blocks, so I had originally thought it might use 3k (as a few games from Compute! did) but that fell over entirely on loading, so I tried 8k. Got it running and then found the game was overwriting itself, which is why you need to relocate it via those POKEs first.