Sunday 28 January 2024

Converting VIC20 Multi-Part Games - Operation Ganymed

Another VIC20 Cartridge Conversion from the Patreon archive.

Operation Ganymed was another early request. It's a better Jupiter Lander than Jupiter Lander, but it is in many parts, with trick filenames etc. and was marked down as "too much work".

The first part has a filename which includes a screen clear and colour change. And yes, that is the spelling, not Ganymede the moon of Jupiter.

This then goes straight to loading a second part, this time with a colour and border change, and no actual name.

The result, after nearly 2 minutes of loading, is a title screen.

After pressing space, the third part starts loading, again with a clear screen filename.

Another minute and we are at instructions.

These do not mention Operation Ganymed(e), but instead seem to be indicating "Lunar Module" might have been the title?

Each screen is a different colour, and you progress through by pressing shift, which is a little unusual.

The final page ends with a "please wait..." as part four is loaded in the background.

Finally the game loads, with the option of playing the game, or changing the colour.

And it plays well, a nicer version of Jupiter Lander.

No mention of Operation Ganymed here either, and again L.M. Lunar Module?

The alternate colour scheme is pretty much the same, just with a black background.


There was a lot going on here. Lots of files with trick filenames and adding it all up, it almost fills the memory three times, the title, the instructions and then the game.

  • Part 1 title screen 561 bytes
  • Part 2 chars data 2050 bytes
  • Part 3 instructions 2017 bytes
  • Part 4 game 3586 bytes

Part 1 is BASIC, and uses a variation of the ON A GOTO type technique to do different things when the program runs for a second time.

I put a breakpoint in the monitor at the point the filename is written to screen and then changed the colour back to blue so that I could see what was going on.

So it seems the second part didn't have a trick filename, the colours were already set to not be visible.

Part2 is called NEWCHRS, and is character data, loaded at $1400. I thought this was character data for the game, but this gets overwritten later on, so it only for the title screen. It's OK, but not sure it was worth the effort. Could have done something similar with PETSCII characters and shaved a few minutes off the load time?

The second pass through the program prints up that title screen and waits for you to press space (or a timeout after 15 seconds which is nice), and then loads part 3 using the plan and simple LOAD command.

Part 3 is again BASIC, and is the instructions.

At the end of the 4th page of instructions, it pokes some code into RAM and then runs it.

This calls the usual KERNAL routines to load the program, but then jumps to the address held in RAM at $0001.

Looking at the RAM, it is set to $1949, which is a reasonable entry point, but when did that get set?

It was only later I realised it was set in this program, in line 20.



Well, I had better look at line 20 in CBM prg Studio, see if that can shed any light on it.

And there we are, the delete characters will overwrite the two pokes with the REM statement. Neat.

Once it loads the game, it jumps to that address and starts the game.

The Conversion Process

This was the first time I had to deal with 4 parts, so I had to copy and paste the copy routine a couple of times. Copy the character data for the title to RAM at $1400, then load the part 1 program to $1001 as normal. I removed the loading routines and jumped back to cartridge ROM as usual.

For the instructions, I modified the end to reuse the "press shift" routine and then jump back to the ROM, where it would copy the final forth part into RAM and jump to the secret start address.

And it didn't work. It displayed the F1/F3 screen and then started the game, but the lander didn't appear and it just hung there.

I wasn't sure what the difference was, maybe some extra routines somewhere? I dumped the whole RAM from the working tape and my broken cartridge versions and compared them.

And there were some differences in the code area.

I did a bit more looking around trying to find out what was going on. It didn't seem like the routine in Cops'n'Robbers where the whole data was XORed before running, just a few changed here and there between what was loaded from tape, and what was currently running.

At this point I had two options.

  1. Investigate further to find out how the code is being modified and replicate that
  2. Cheat.

I couldn't see anything obvious going on, and I had already done a lot of these so I decided to cheat. I just cut out the code block from the RAM dump and loaded that instead, and it worked fine.

I will leave that one last mystery unsolved, since the game is working nicely now. I thought I might revisit it when I wrote this up for Patreon (I didn't). Maybe I will revisit it before I post it to the main blog (I won't). (ed: I didn't)


Penultimate +2 Cartridge

The Penultimate +2 Cartridge is in stock at The Future Was 8 bit, note the new website is

More info in a previous post:


You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. This also includes access to my Patreon only Discord server for even more regular updates.