I have converted a lot of cassette games to cartridge format for inclusion on the Penultimate Cartridge. Some well known, some more obscure and not easily available, so it is hopefully bringing these games to a new audience.
When doing these, I have found a few where it has just not worked, or has looked like too much work, and these have been put to one side.
It is time to dig some of these out and try again.
Cops'n'Robbers
Cops'n'Robbers is a cassette game that was requested to be added to the Penultimate Cartridge for the last release, but was held back as it looked like it would take a lot of work to convert.
Like many cassette games for the unexpanded VIC20, the program is split into multiple parts so the title and instructions can be displayed and then overwritten by the game which usually needs the full amount of available RAM on the unexpanded VIC20.
This one looked like it might be a little more work as it was in three parts.
The first sign of trouble as a trick filename. The file is saved with a clear screen character at the start of the filename, so when it is printed it clears the screen before printing the rest of the name.
The first part was designed to be quick to load, and just shows an appropriately gold coloured title page whilst part 2 loads in the background.
Part 2 displays several screens of instructions and then loads part 3, which is the game.
Parts 1 and 2 were in BASIC, but part 3 was "written in machine code". Examining the file on tape, it was a bit odd, it seemed to be invalid data.
The load mechanism was also not very clear, it appeared to be jumping to some code after the end of the BASIC program.
So that one was put to one side until I had more time.
I still don't have more time, but this one was requested again, so I had another go.
Another Go
The first program is fairly simple, set the screen colour, print the title and then load part 2.
And the way it loads part 2 is oddly simple.
It uses the LOAD command.
Odd because surely if it was that simple, why did all of these games use various convoluted mechanisms when you could just use LOAD? Copy protection maybe?
The two POKE commands set $2D and $2E, the address of the end of the program which is also the start of space used for variables etc. They are set to $186A (which happens to be the end of the second program). It then does a clear to reset using this new value and does the LOAD.
I was interested to try this out, so I wrote a couple of sample programs.
I rewound the tape and loaded and ran the first program, it automatically loaded and ran the second one, with no fuss or searching or loading messages, it just worked.
Odd, I now don't understand why all of these other games do not use this mechanism. I remember thinking (and maybe writing in one of the previous posts) that Commodore BASIC could have done with the equivalent of the BBC BASIC CHAIN command. Little did I know that it didn't need that as the LOAD command did the job.
I repeated the test without the POKE commands or the clear, just LOAD. And that also worked.
Just seems odd to me that if that mechanism exists and works, why go to all the fuss some other programs do with putting things in the keyboard buffer and hiding text and trick filenames etc.
Anyway, back to the game. We now have the second part loaded.
It shows a second title screen for a few seconds, accompanied by a fanfare, The prints up the instructions.
Five pages of them, with "press a key" between them.
At the end of that, another title and "wait for tape to load".
It appears there was going to be an "Instructions Y/N?" prompt, but that has been commented out.
Then it loads Part 3. It does this by jumping to some code after the BASIC program. This would have been a patched PRG files to add the code onto the end.
The first part copies the rest into safe RAM at $02A1 (where it will not be overwritten when the next program is loaded). It then jumps to that code.
The relocated code does the familiar series of calls to the KERNAL routines to load a program.
Then it does another odd thing. It jumps to $0352. There shouldn't be any code there, it is the cassette buffer. Ah, OK. This is using the buffer overrun for secret code again. Neat. The same as Falcon Fighter - http://blog.tynemouthsoftware.co.uk/2023/07/converting-even-more-multipart-games-for-the-vic20.html
This hidden code explains why the third part looked odd. It reads a byte from $1000 (the loaded program), exclusive OR's it with $2F and then writes it back. This continues with all the bytes up to $1E00.
It changes it from nonsense
To hopefully less than nonsense.
And then runs it.
The Conversion
Converting this was a bit more work than usual. Since this was loading from ROM, there was no need for the small title screen program to be displayed whilst loading the larger program containing the instructions, but I did like the gold title screen, so wanted to keep that.
I decided the easiest option was to write a new BASIC program, taking most of the first and second to make a single title / instructions program.
I reused the commented out "Instructions Y/N?" prompt to the first title screen, although I had to change the code to check the response properly (the commented code would not have worked).
If you press Y, it goes on to display the 5 pages of instructions then loads the game.
If you press anything else, it just goes directly to loading the game.
Loading that is done in the same way as I have before, a SYS call to jump back into the cartridge ROM to copy the game into RAM.
I saved a copy of the decoded game and used that, to avoid having to XOR the data.
All of those together fit neatly into an 8K cartridge, ready for the next update to the Penultimate Cartridge.
Advertisements
Penultimate +2 Cartridge
The Penultimate +2 Cartridge is in stock at The Future Was 8 bit, note the new website is TFW8b.com
More info in a previous post:
Patreon
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.