Sunday 11 June 2023

Fun with Crazy Cavey

Last week was the unveiling of the new VIC20 Penultimate+2 Cartridge, and for the next few weeks, I am going to look at some of the behind the scenes developments on the PU+2 from my Patreon.

As part of that, we have been collating lots of new games to add to it. Not just the usual classic cartridge games we have all seen, there is the complete Future Was 8 bit VIC20 release, including serveral new and exclusive titles - more on those in a future post.

We have also been looking for forgotten or overlooked titles. Ones you only had on cassette, ones you can't normally easily play on a VIC20. Hence the reason for all the "rummaging through VIC20 tapes" videos from TFW8b.

One game that was suggested was "Crazy Cavey". This is a quite a nice little platform game for the expanded VIC20.

The problem is, it can be tricky to load. I was told if you did a directory or anything before, it would fail to load. You had to load it first thing, otherwise it wouldn't work.

I wasn't sure what that was about, but I added it to the cartridge in the same way as all the other games and tried it out.

It started, but the background was wrong, and it immediately locked up.

I tried loading it from the file browser and it also failed in the same way.

Confused, I went back to basics (or rather back to BASIC) and tried loading it from there.

It loaded and worked.

I then did as I had been warned not to do and did a directory first, and then tried to load it, and it failed.

What? How? Why?

It seems the telltale of impending failure is when the start screen has characters in the background, rather than all black. But what is going on?

I thought it might have something to do with memory being uninitialised, and having the previous directory listing in memory might have caused a problem?

I added routines to clear the RAM before, I tried 00 and FF, but it didn't make any difference.

I managed to get it to fail in the Vice emulator (where these screenshots are from), by doing the directory before hand.

I also tried typing in a short program instead.

That also broke it.

I took complete memory dumps of the 64K RAM space before load, after loading and at the "HIT ANY KEY" page, both for a successful run and one that failed and tried to work out the differences.

I'll spare you the pain of those. Basically there were runs of bytes in zero page that were 00 in the working version, and different runs in the faulty one that were 20 (space). There were a few bytes different on the stack, and some of the code at the end was different, including the bit that had the JAM instruction that was locking things up.

I had noticed that during a normal load there was some corruption to the top of the screen. I had assumed that was redefined graphics or something, so hadn't thought about that, But what if what was on the screen might have made a difference.

I tried clearing the screen, and then loading, and ooh, it failed in a different way. (N.B. LOAD "CC",8 and LOAD "CC",8,1 make no difference here as the load address in the file is 1001, which is the same as the default)

It is always a good sign when you get something to fail in a different way. It means you must be messing about with the right thing.

Then it hit me, that wasn't graphics on the screen, it was code.

When the LOAD command was lower down the screen, the SEARCHING, LOADING and READY lines eventually caused it to scroll up. And when it scrolled the screen, it was wiping out 22 bytes of code for every line it scrolled up, and moving the rest to the wrong place.

Checking the file, it was indeed too long to fit into the RAM without overwriting the screen. It loaded at 1001 (the normal load address for an unexpanded VIC 20), and ended at 1EA8. The screen was 1E00-1FFF, so the end of the code was corrupting the screen.

(is it confusing that the 1001 here is in hex, but I used 22 in the previous line that was in decimal?)

That was not a problem immediately after a reset, as there would be no scrolling, and the READY prompt appeared just below the end of the code.

Doing a clear screen was also bad because the LOAD command would be too high, and the READY prompt would also overwrite some code.

So it seems if you want to load Crazy Cavey, you need to type the LOAD command after line 6, but not after line 14.

But why was it failing on the cartridge? That didn't type LOAD. That didn't scroll. Why did that fail?

Ah, well, that turned out to be a bit of code I had in place just before it ran the game. It calls a KERNAL routine to setup the VIC chip and other hardware, just like a clean power on. This of course includes clearing the screen. So that was wiping out all the code from 1E00 to the end.

I made Crazy Cavey a special case, any bypassed the screen clearing routine, and it now works every time.

Quite a nice game, I even made it past the first screen and onto the second level. I will enjoy playing that more later......er......I mean, I will have to do some further thorough testing.

It is now also working from the cartridge on real hardware (this time it is an actual photo of the TV)

Well, that was an interesting investigation. I had already started writing a post about how some VIC 20 games get around the memory limitations, but I thought this one deserved a post of it's own since it didn't actually get around them, it spilled over the edge and hoped you wouldn't notice.

If you want to see more of Crazy Cavey, you can watch Rod's play though here:

https://www.youtube.com/watch?v=HpvCFv8wEwU 


Advertisements

Penultimate +2 Cartridge

The Penultimate +2 Cartridge is available to pre-order from The Future Was 8 bit:

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