C64 development lessons learnt!

Thought I'd share back to the community my lessons learnt when developing for the C64.

My first attempt, I used KickAssembler - but took me a looong time to get nowhere useful. Next attempt using the LLVM toolkit and VScode. Got a lot further - but very quickly ran into performance issue with the scrolling.

AGPX / Yorme64 IDE

This IDE is a transpiler from BASIC style language. Is great, because creates a consise language (more macro based) - and lets you focus on creating the game. The Oscar64 compiler option is a must for performance.

However, there were a few ‘bugs’ that i had to work around in the generated cpp (if anyone knows how to get hold of the developer -  I know he says he not developing this anymore - but he has put out another release since saying that!)

1. Actormaps In order to use more that 1 actormap, you can only USE MAP <index> or USE SCREEN MAP <screen index>, from a member function on the ‘Game’. Otherwise it doesn’t work. In the generated cpp, each Level implementation is generated it’s own copy of ‘static const word  __actorsMapsStartIx__[1] = {0};’ with only one item - with offset 0.
2. Sprite Multiplexer This is awesome - especially along side the scrolling code. Had tried so many times to do this myself, but was never perfomant enough. However, there are some issues (especially if your auto scrolling). If you have (and is hard to avoid), any virtual sprites on the limits of the ‘Y’ axis  - you can some quite intense flickering and CPU bogging. The multiplexer is a list of virtual sprites, then as the raster beam moves down the screen, we reposition the hardware spites (like from a pool) to the virtual sprite position. Allowing more than the limited 8 on the C64. My initial thought was to loop round all the virtual sprites on every frame, and hide those near the edge of the screen. Two issue with this: 1) Show/Hide sprite doesn’t trigger the raster code to consider a change (__spriteChanged__), and 2) The actual mutiplexer doesn’t exclude hidden virtual sprites. To fix this, I needed to ‘patch’ the cpp code after generation. Then all was good!

Deflemask (soundtrack):

Deflemask is awesome, one of my preffered chiptune trackers for sure. The only issue, is the C64 ‘ROM’  or SID export:

- is non-relocatable
- init at address $1106, play at address $1000
- you need to capture and restore the cpu register ($01) when calling $1000

I gave up in the end, and wrote a dfm2sng.py (to goatracker2) converter. Wasn’t perfect, but gave me the flexibility i needed.(supported SFX too)

Hopefully next version of Deflemask will create a more useful (relocatable!) ROM output for C64. Ideally with SFX support.

Happy to share any code snippets for anyone interested!