Sunday 2 July 2023

Converting more multipart games for the VIC20 - Cataclysm, Battleground and City Crusher

Following on from last weeks introduction, here are some more multi-part games investigated and converted into cartridge games that can run directly from the VIC20 Penultimate +2 Cartridge.

Cataclysm

This looks a nice simple one, two files in a TAP image. Sort of a reverse Blitz game, this time you have to shoot down the bombers that are attacking your city.

The first part is BASIC, and prints up instructions.

This one does need a bit of explanation, so I will leave these in.

When the third page is displayed, it starts to load the actual game.

It does this by poking some code into RAM at 02A1, and then running it.

In a similar way to Galaxia last week, this sets up a file load which loads the second part into RAM at 1000 (not the usual 1001), and then it jumps to 1700 to start the game.

I edited the BASIC program to remove the file load code and replaced it with a repeat of the "PRESS A KEY" code, and then added a SYS call to jump back to the cartridge loader code to copy and run the game code.

So, for once, that did turn out to be a simple one. Let's hope my luck continues.....


City Crusher

Another one of many Blitz style games that TFW8b seems to like. This looked quite a simple one, two BASIC files in a D64 image, designed for the unexpanded VIC20.

The first is mostly DATA statements and some FOR loops that READ the DATA and POKE in into RAM in the font and colour RAM area. The second is the game itself.

I started off with the simple approach used in Mars Landing, copy the first BASIC program into RAM and run it. The end of the program needs to be changed from LOADing part 2 to doing a SYS call back into the ROM to copy the second program over where the first had been and then running that.

That worked, but parsing the DATA statements and programming the RAM took over 5 seconds, sitting on a blank screen. Not ideal. I could put a "Loading..." type screen up, but I decided it would be better to just replace the first part with some assembler which does the same job.

I fired up the Vice emulator and mounted the D64 image (but didn't auto start it).

xvic -memory none -8 "City Crusher.D64"

I then loaded the BASIC program and found the last two lines, the ones which fed the LOAD instruction for the second part into the keyboard buffer. I deleted those lines and ran the program.

5 seconds later, it had loaded up the RAM and returned to the READY prompt.

Into the Vice monitor, and I saved the RAM to disk. For simplicity, I dumped the whole 64K space.

save "after first.bin" 0 0000 FFFF

0 says write to the current folder, and 0000-FFFF is the address range to save.

The file is in the standard format, so the first two bytes contain the load address, and should be removed to give the pure 64K block of data.

Looking through the BASIC code, it writes to several locations.

POKE56,28

This lowers the end of RAM from 1E00 to 1C00, to free that area for graphics

FORZ=7168TO7679:READX:POKEZ,X:NEXT

This fills a block from 1C00 to 1DFF with graphics data.

FORZ=673TO751:READX:POKEZ,X:NEXT

This puts some code from 2A1 to 2EF

FORZ=319TO414:READX:POKEZ,X:NEXT

This puts some code from 13F to 19E

FORZ=0TO73:READX,Y:POKE37888+Z,X:POKE38144+Z,Y:NEXT

This preloads the colour RAM from 9400 to 9449 and 9500 to 9549.

Finally, the code which loads the second part. This first clears the screen and prints the LOAD command.

FORZ=0TO9:POKE631+Z,13:NEXT:POKE198,10

This fills the keyboard buffer with the return character, and sets the count of characters in the buffer to 10. These will be processed after the program has finished. The screen is already setup with the LOAD command, so that will be executed and part 2 loaded.

In order to make this into a cartridge, I needed to replicate all that, but with fast assembly language routines. I extracted the appropriate sections from the memory dump, and modified the cartridge loader to copy each of those into the appropriate sections of RAM.

Finally, it copies the second part into RAM, relinks BASIC and runs the game.

That all happens in the blink of an eye, much faster than the BASIC loader.

My initial cartridge ROM was 8K, but by shuffling things around I was able to get that down to 4K. There are now quite a lot of 4K cartridge ROMs and PRG files into the Penulitimate +2 Cartridge, squeezing even more content into the ROM.

Battleground

Battleground is another interesting one.

This is a two part loader. The first is just 105 bytes, but it has an unusually load address. Rather than the standard 1001 for an unexpanded VIC, it is loaded to address 02A1. This is mostly unused memory (reserved for program indirects), apart from the last 10 bytes which overwrite some BASIC vectors from 0300 to 0309.

The values are overwritten with the standard values, all apart from two bytes which change the BASIC warm start from C483 to 02A1. So when loading is finished, the BASIC ROM code reads the values at 0302/0303 and jumps to that address. That is normally C483, which prints up the normal READY prompt, but changing these values means it will now call the code at 02A1 instead.

That code writes a lot of values to RAM. The first thing it disables the RUN/STOP key (causing it to lock up), then it resets the BASIC warm start to the normal value.

Next it writes some keys values into the keyboard buffer - L O A D then RETURN. Then R, SHIFT+U (which is a shortcut for RUN) and RETURN again. It sets the number of characters in the buffer to 9 so these will be recognised and processed later.

Then it sets the background and border to white, and the text colour to red.

Next it changes the address of the SAVE routine, so it will not be possible to save the game.

Finally, it jumps to E378 which is part of the initialisation routine. This clears the screen and prints the *** CBM BASIC V2 *** messages and the RAM count, and the READY prompt, all now in red.

The VIC20 KERNAL now checks the keyboard buffer and pulls out LOAD + RETURN and starts to load the actual game (saved with no name).

When loaded, BASIC prints up the READY prompt again and checks the keyboard buffer. This still contains RUN + RETURN, which then runs the game. (OK, it's actually R + shift U).

All of that to stop you being able to SAVE a copy of the game.

However, all you have to do is wind the tape on a bit, so it bypasses the first program, then LOAD the game as normal, and you can then SAVE it? You then have a normal PRG file that I can add directly the the Penultimate + 2 Cartridge, 

Seems a lot of work which must have required a lot of scouring the VIC20 Programmers Reference Guide, and it makes it quite neat I suppose to have it auto start, but I wonder if the "copy protection" would have stopped anyone?



Advertisements

Penultimate +2 Cartridge

The Penultimate +2 Cartridge with these and a host of other games is available to order from The Future Was 8 bit, shipping starting this week.

More info in a previous post:

http://blog.tynemouthsoftware.co.uk/2023/06/penultimate-plus-2-cartridge.html


Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware