There is not one but two reasons why everyone able to code should join C64 'Cassette 50' Charity Competition! This post will try also to explain why instead of focusing on the other project (Meonlawel), I followed this path and have joined the competition.

First of all, my main motivation was to support Special Effect Charity. Thanks for this initiative! Under Commocore label, I thought about making my games partly careware but I didn't come up with a plan yet as my projects are still not on this stage.

The second thing is about the limitations of this competition...

Limitations

Let's talk about the lim... limes... about the challenges! Code must fit under $1000 memory location. Also, code cannot write to memory locations above $1000 except $D000 - $DFFF area. This means that it has to be 4kb in total. But not the whole 4k is available... Some of the memory locations below $0400 are used by BASIC and KERNAL. You can disable BASIC but what you cannot do is disabling KERNAL. And only simply because you cannot change IRQ vectors in $FFFE/$FFFF which just breaks the rules. And this makes this competition a little bit harder and challenging. In order to use more space, not only you have to know all the areas which might be affected by KERNAL, but if you really want to use them, your potential relocated code must be defragmentated. At the end of this post, I am sharing the memory map I managed to fill with the Ms Lily's Haunted Shop game code .

Overcoming limitations

 This is why coding in assembly, with less than 4kb of memory available, for ~1MHz computer from 1982 still makes sense... to me at least. It's fun. How much can you do? And this was my first project in assembly I've used with KERNAL being turned on. Normally, the very first line of code in my projects is just to disable KERNAL and get the control over the whole machine. So, I have to say: I've learned more than I thought I know about Commodore 64. As I speak, I am finishing another game for the same competition (called "Red Is Blue"), and it's a great journey!

So, as some of the things didn't fit, I will cover some tricks I've used in order to save some bytes. At the end there was not a single byte left, so yes, I was optimising and stretching the game with more stuff as long as I was able to go. This is my third competition in a row so I've got some basic experience with optimising things already. And I started from a luxurious space of 16k game for RGCD 2019 competition where I submitted Swarm 16k, followed by a 4k game for Reset64 4k competition in 2020 where I submitted Bring back my bones 4k.

But let's get back to Ms Lily's Haunted Shop... A quick disclaimer: I didn't use any illegal opcodes. I'm too afraid to use any of LAX and SBX and everything which is available on the 6510 CPU "black market". That was my own challenge I believe to use only well-known and "legal" opcodes. But I gonna better try with some of these illegal ones in the future.

I used a small trick to use only a half of a sprite bank, so instead of 2 sprites I was able to squeeze 4. Simple, but extends the gameplay.

For the music, I created a custom music player which does only what need to do and plays patterns so I can combine them and save some additional memory. I also used a limited number of notes in a lookup table. All that small changes really saves bytes... actually saves the project!

Some of the tables like creating a power of 2 table, or screen location tables are also generated during the initialization. This needed to be compared with the static tables, and apparently, in most of the cases, generating these tables take less space than just having them out of the box.

What didn't fit?

Well, I think everything's there what I wanted or... I am rather not going back to talk about it :D. I should probably spend more time in the music department and make a better song. However while testing the game I get used to these few quickly created patterns so much that I just left it as it is! It's a haunting tune, an earworm. I need a break for a month to say if it was a good tune or rather a bad one.

I didn't manage to squeeze the name of the game, a simple title screen, a game over screen. I didn't get Shallan's autoload code to work in my Vice 2.4. It was just crashing, so the game code starts not from $0400 but from $0519 as Vice emulator is able to autoload it when code is below $0519 (as the screen location is affected already by LOADING and RUNning which overwrites the game code).

Some love

I hope you'll find this post interesting, or somehow informative, but in any case, I wanted to share my enthusiasm and thank to organizers for this initiative. Be sure to check other games as well! As the initial idea was to create a game in the spirit of 1983's infamous Cascade 50 compilation, I really wanted to create something which doesn't need to be fun to play at all. It could look rather awful, having basic aesthetics, sounds simplistic, and be quite frustrating perhaps. But while playing with the code I started playing the actual game. In the end, I put more love than initially anticipated, and aimed to create something simple and finished. Still, I hope I've met at least one of these criteria! Let me know what do you think?

Also, big shouts for Twitter users who suggested some titles for this game. The original post is here. I didn't expect so many funny titles and word plays! Some of them: Boot Stomp, Wander Wanda or Wanda Wander, Wandering Wanda's Wondrous Wander, Shooty McShoeFace, If the shoe fits, or... All Your Boots Are Belong To Space Wizard. Actually I've used a wizard in the story so thanks for this! As my wife recently watched some documentary about minimalists (not the ones who use toothbrush for everything, but just a regular ones), in a split of second I came up with a wizard called Minimalis from Abandonia land, who wants to conquer Fulfilia. And it was the last missing bit (or rather byte) why this wondrous lady was wandering over this mad shop. Thanks!

Signing off!

Ms Lily's Haunted Shop memory setup

Initial PRG location before running: $0519 - $07f6

• $0002 - $0070 Variables
• $0071 - $008f Reset game procedure (relocated on init)
• $0090 - $00ff <unused> this area is affected by KERNAL
• $0100 - $011f Stack (limited to $1f on initialization)
• $0120 - $01ce Song notes
• $01cf - $01ff <unused>
• $0200 - $021f Item move mode and bounce tables
• $0220 - $0227 power2 table (generated on init)
• $0228 - $022f power2 inverted table (generated on init)
• $0230 - $026e Reset room procedure (relocated there on init)
• $026f - $02a6 <unused> but this area is dangerous (e.g. around $0277)
• $02a7 - $02ec Animate explosion code (relocated there on init as there was no more free memory to fit it under $0801)
• $02ed - $030c Clear screen procedure, displaying text "ROOM" (relocated there on init)
• $030d - $0313 <unused>
• $0314 - $0315 IRQ execution address
• $031a - $03a5 Bullet tables (this memory is usually occupied by execution addresses of KERNAL methods, but hey, we're not using them at all!)
• $03a6 - $03b1 Stage cleared text line 1 (relocated there on init)
• $03b2 - $03bd Stage cleared text line 2 (relocated there on init)
• $03be - $03bf <unused>
• $03c0 - $03ff Item dynamic sprite (copying sprite from source $0f40+ to this location for each room)
• $0519 - $07ee Init code (executed only once and overwritten after execution by drawing on this screen location)
• $07e8 - $07f4 Screen row lo positions table (generated on init)
• $0800 - $080c Screen row hi positions table (generated on init)
• $080d - $080e Item sprite colour by mana table (generated on init)
• $0801 - $0f3c Program
• $0f40 - $0fff Sprites