Part 4: Studying SID
It’s been over a year now since I started work on my platform game, and there is still plenty of work to do on it. I would never have imagined it would take me this long to make a Commodore 64 game, but I constantly find myself revisiting things that I thought previously completed to improve them. I’m without a doubt past the 50% progress marker now anyway, which is definitely a positive.
And on another positive note, Bear has found a really nice home with new Commodore 64 game developers Pond Software. Pond’s first release earlier this year, ‘Spaceman Splorf: Planet of Doom’ is a very polished score chasing game with excellent sound and graphics and can be downloaded for free from:
You can also read about Pond’s upcoming releases, which include entries for the 2016 Reset 4kb Game Coding Competition, which I would encourage any C64 coders to take part in!
Details of the competition can be found here:
The Sound Interface Device
I’m sure at some point everybody has been impressed by a piece of music played by the Commodore 64’s SID chip. Over the years there have been many names associated with squeezing excellent pieces of music from the three sound channels of the SID – Rob Hubbard, Ben Daglish, Jereon Tel, Steve Rowlands… Look them up on YouTube if you still need convincing.
Before I started writing my C64 platform game, I had a small amount of knowledge of how the SID chip worked having read about it in various books and magazines. When it came to making use of it in my own programs however, I only really managed to get the most basic of sounds working. For some games this is absolutely fine (my Snake clone had small noises to indicate picking up, crashing and starting the game, and also a very simple tune when the game first loads), but for other more complicated games it really is deemed unacceptable for a C64 game to not have some cool music and sound effects.
This was the case with RockMaze, my first attempt at creating a C64 game. I can’t remember if I ran out of time, or if I failed at attempts to get sound effects working, but either way the game ended up being completely mute. When I was asked recently if I would like to contribute to the Reset magazine cover disk, I thought this would be an ideal time to read up on the SID chip once again and try to add some music and sound effects to RockMaze.
After a quick internet search, I found a book with a good introduction to C64 sound here:
After some research and experimentation, I managed to get a few sound effects triggering on the various events of RockMaze. A very useful discovery I made during this experimentation was that the key to interesting sound effects was not just to set up a sound and trigger it, but to change the various values of the sound whilst it is playing. This opens up a whole new world of possible sounds with the SID chip and really explained why I was only able to get very basic effects working before.
I was really impressed how much more alive the game felt once these sound effects had been added, and it now seems very strange when I play the old version of the game without them – a little like watching a clip of a film with and without the incidental music.
With the sound effects added, it was time to look into getting some music playing on the title screen of the game. This is something I had managed once before, but the routine I wrote was only capable of playing very basic sounds and changing the note, plus it was limited to one different sound for each of the three channels.
What I really needed was a ‘tracker’, a piece of software that lets you program notes and sounds as complex as you are comfortable with into the channels of the sound chip. I had used a tracker before on the Amiga called OctaMED, so I decided to have a search around and see if anything like this was available on the Commodore 64.
I found that there were a few different trackers available, some were PC based and some ran on the C64 itself, but the one that really stood out for me was called SIDTracker64 and is available for the iPad. The fact that it works on a very portable device was a big plus for me – it would allow for composing C64 tunes virtually anywhere. The other major selling point was the interface – being touch screen based meant that there was no need to learn any commands or shortcuts, and the keyboard and dials for adjusting sounds are all there on the screen making it very easy to get started.
Of course, the most important feature would be to get the music that is created in the tracker playing on an actual C64 so that it could be used in games, and fortunately this is supported in the ‘export’ options (the music can be exported in .PRG format for the C64, .SID which is a popular format for some C64 music players or .WAV which can be played in most media players).
I found that I was able to make a piece of music for the RockMaze title screen very quickly using the default instruments supplied with SIDTracker, and after a quick e-mail exchange with the developers I figured out exactly how the .PRG music playing routine works, which allowed me to get the music working in my game.
A call has to be made to a subroutine to initialise the SID chips sound channels (which in this case is JSR $1000), and then a call needs to be made to the music player subroutine every screen refresh (JSR $1003), which is best done inside of an interrupt routine to keep the timing of the music stable.
If you would like to have a go at the updated RockMaze game, which also features new graphics and some new levels, it can be downloaded from CSDb.
Having learnt the basics of creating sound effects and music, I decided that this would be a good opportunity to start adding them to my platform game. I used SIDTracker again to write a title theme for the game, and then started to look at the ‘instrument’ section of the app as a way of designing sound effects. This taught me a lot about the various registers of the SID chip and the effect that they can have, as adjusting the dials and changing the different settings was a great way of experimenting and instantly hearing the outcome.
At this point however, I realised that to keep to the quality and standard I wanted for my game I needed a more complex sound effect routine than the one I had written to play the effects in RockMaze. I also became aware that it wouldn’t be the most memory efficient way of inserting music into my game, because exporting a .PRG file for every piece of music would mean that there would be a music player for each file, when there only really needed to be one (I eventually plan to have various tunes throughout the game, including a theme for each area of the game).
This led me to start looking at other C64 trackers, and also searching for a sound effects routine / player that could be used for games. A very popular suggestion was to use a PC based tracker called GoatTracker, which features support for multiple pieces of music and also features a sound effects player.
It took a little time to get to grips with GoatTracker, as although it is obviously based around the workings of the C64 SID chip, the interface is much different from the touch screen based SIDTracker. There is good (and very detailed) documentation available with it though, as is a help page within the program itself.
I was able to put together the theme tune that I had already written for the game by reconstructing the instruments from SIDTracker. After exporting the music as a binary file, I imported it into my project in CBM .prg Studio, and then changed the music initialising and playing calls to point to the new music. An important step to remember here is that when using a music player that will play multiple pieces of music within a game, there is also one extra step before initialising – loading the ‘A’ register with the number of the tune to be played.
To utilise the sound effects routine, a sound effect is created as an instrument and then saved to disk. This can then be converted into a sound effect using a tool called ins2snd.exe (which is provided with the GoatTracker program download). Once converted, the binary file can then be imported into your project, and can be played by loading the ‘A’, ‘Y’ and ‘X’ registers with the start of the sound effects location in memory and the number of the sound channel you would like it to be played on, and then jumping to the sound effect subroutine.
A couple of things to note are that sound effects will only play whilst GoatTracker is being used to play music, so if sound effects are required on their own, you must first create an empty tune that will only play silence.
If the sounds are to be played during music, it is best to pick a sound channel for them that is not used as the lead instrument for the current tune. This enables them to have their maximum effect whilst still keeping the main part of the tune intact, or another option is to design a tune that only uses two channels, thus keeping one channel free for sound effects.
Unlike the other game code which updates what is happening on screen, the music playing routines can be timed to execute at any place in the screen refresh (as long as it is the same place in the refresh every time to keep the music stable). As mentioned previously, changing the border colour before and after the execution of code is a great way to see how much time the code is taking to execute, and how much time in the screen refresh is left for other code to be added.
You can see where code is happening by looking at the border of the screen above; the red coloured areas show whereabouts in the screen refresh I have code executing, and the white areas show free space in the refresh.
One last thing I would like to mention in this instalment, was when I decided to test my game in NTSC mode recently. Everything I had done in my project so far was tested with a PAL C64 and the Vice emulator set up to run in PAL mode, which refreshes the screen at 50 times per second. NTSC mode however, refreshes the screen 60 times per second and actually has a little less screen space to compensate.
This means that anything timed to run at a certain place on the screen, is going to happen 20% more regularly, or in other words the game will run 20% faster! Upon testing my game in this mode, it just didn’t seem ideal. I had timed all of the sprite movements and animations to run at a certain speed, so it just looked strange to me. Plus, the music was playing faster and this was causing glitches in the sounds of the instruments.
A screenshot of the game running in both PAL and NTSC modes show that the amount of screen space is reduced in NTSC, and some of my code is executing too early, causing a disruption in the HUD at the bottom of the screen. I also discovered recently from a game tester that the amount of screen space is reduced again when using a CRT TV, meaning that I really don’t have as much room to display sprites in the borders as I thought.
To compensate for the speed difference between the two modes, I first set up a flag to detect which model of C64 the game was running on (register $02a6 will show as 0 if the machine is NTSC, and 1 if it is PAL). I then set up a frame counter, which increases every frame refresh from 0 to 5, and adjusted my main code loop to refrain from moving and animating the sprites every time the counter hits the value 5 on an NTSC machine. This ensures that the sprites only move / animate every 5 frames out of 6, bringing their speed down by 20% and equal to the PAL machine.
Unfortunately the sprites will not move quite as smoothly as they do on PAL, as instead of moving every frame they move for five frames and then stop for one frame, but this should only be noticeable for the very keen-eyed.
With the game speed rectified, it was time to look at the music speed. Rather than go back to GoatTracker and adjust the music speed to suit NTSC, I decided to set up the music playing interrupt to adjust it’s trigger position every time it plays. By moving the trigger point of the interrupt down the screen by 20% every time it has played, it ensures that the music is delayed enough so that it plays the same speed as the PAL version.
The notes of the music actually play at a higher frequency, so the tunes will sound slightly different, but they will at least be at the correct speed.
One thing remained to get the game completely working on an NTSC machine – some of the collectables, and the bottom half of the HUD wouldn’t fit on to the smaller screen size. This was an easy fix to move the collectables down a little, but the HUD needed to be reworked, which is actually something I was planning on doing anyway to give it some polish.
I reduced the information shown in the HUD, added some colour cycling (glowing) to the text, made the lives icon blink and the score counter bob up and down.
Below is a screenshot of the new HUD. Bear in mind that the colour glow and animation looks much better in motion, which will show next time I get around to making a new trailer for the game!