Mission: Moon already out of memory – How to move video memory to another memory bank

I’m almost done with Mission: Moon (check my last post here). Yesterday I was adding some intro screens, fancy text, etc… When I tried to run it once more, bad things started to happen – things that when you see, you know you are putting code over something important.

After some digging, I realized that the game has grown to big and it was overwriting all my sprite definitions and other stuff. When I first started I put all eight sprites after the address ~15,000 to have enough space, but unfortunately it wasn’t enough. My program has around 12kbytes and the Commodore has around 38kbytes free, right? So it is easy to fix that, right? Move the sprites up, right? Wrong!

Well, half-wrong. The final solution is really to move the sprite’s data up, so the BASIC program will have more space to run. The problem about is that you can’t simply put your sprites definitions wherever you want. In theory you can load them wherever, but they won’t be seen by the VIC-II chip.

A little bit of theory here. A program like Mission: Moon uses the default video memory (the same you see when you turn on the computer), the default character definition set and sprites, and all of that is managed by the VIC-II, which can only address 16kbytes of memory. What that means is that, even having a lot more RAM available, your video memory, character set and sprites have to reside in the same 16kbytes bank. The Commodore 64 has four banks with 16kbytes each, and by default all the video-related stuff is set on bank #0. This is why the video memory starts at address 1024 by default. Try to poke the letter A on the screen and you see what I’m talking about:

POKE 1024,1

I didn’t know that when I started the game, but I knew that my sprite’s data should be placed anywhere as long as it would be possible to address them using an eight-bit value (0-255). For example, by default the first sprite is addressed at memory position 2040 (all eight sprites use address from 2040 to 2047). The value that you poke into this address multiplied by 64 will be the address where the sprite data is located.

For example, in my game I first decided to put the sprite as high as possible, which means using the values from 248 to 255, and poke those values into the address 2040 to 2047. Bear with me, I was young and foul at that time (a week ago).

So POKE 2040,248 would mean that my first sprite data should be added to the address 248*64, or 15782. Each sprite uses 62 bytes of data, so to make it easier to understand, I’ve built the Multiplan spreadsheet below:

It is the easiest way to not get lost in all those addresses

As you can see, I really set my sprites to be located almost at the end of the bank #0. It is good for a lot of programs, but as it grows, you could face the same problem I did: the program outgrew the initial space and now it uses part of the memory where my sprites are stored.

The solution for me is to move my sprites to another 16k bank, and to do so, I also need to move my video memory and character set to the same bank. Doing a bit o research, I’ve found an article on The Transactor magazine volume 5 ed 6 p.45, where it is explained how the Commodore video chip is organized, and how to easily move those VIC-II resources from one memory bank to another.

I also used the excellent book The Anatomy of the Commodore 64 from Abacus Software, where the authors explanation helped me understand the sprite organization when using a different memory bank other than bank #0. I recommend to check the section Memory Areas for Sprites.

Based on that information, I understood that the previous addresses 2040 to 2047 are actually the last eight addresses of the video memory. Remember that by default, the video starts at the address 1024 and ends at the address 2047.

With that I mind, I have to do three things to allow my BASIC program to grow freely:

  • Set the VIC chip to use bank #2 instead – I’m choosing bank two because the standard character set is already available there, and since I’m not creating my own, I will have only to take care of the video memory and sprites.
  • Tell the computer that my video is now in the new memory location
  • Change my program to put the sprites in the new memory bank

If you want to know how it goes, subscribe to the blog, or follow me on twitter to know when the next post is available!

Author: Paulo Garcia

2 thoughts on “Mission: Moon already out of memory – How to move video memory to another memory bank

Leave a Reply

Your email address will not be published. Required fields are marked *