RE:CODE - Converting BASIC games to 6502 assembly
Article #2: Introducing Downhill Ski Jump
Arrived late? Read the first article here
So now we’ve decided what the plan of action is, let’s dive straight in. The best place to start is to just play the game and see what happens. Let’s fire it up…
Article #2: Introducing Downhill Ski Jump
Arrived late? Read the first article here
So now we’ve decided what the plan of action is, let’s dive straight in. The best place to start is to just play the game and see what happens. Let’s fire it up…
We start off with a, well, odd little ditty that plays when it first loads and we’re unable to start the game until it has finished. That’s something that we can definitely fix. But then…
...well look at that intro screen - a colour wash in BASIC, eat your heart out Laxity! We can definitely do something with that when we start to improve the game. The top graphic looks based on original PETSCII chars so we need to bear that in mind should be wish to alter the charset in any way. There’s a level selector too, so we’ll need to look out for something around that in the code. Down the bottom of the screen we have what looks like the main player sprite (expanded) with basic two-frame animation, and a flash effect on the ‘push fire to start’ message.
On to the game then and we start with a little beep, beep, beeeeep sound effect which is nice and we’re off. We’ve got a nice little sound effect for when the skier turns in the snow, definitely using the noise waveform. There’s also a sort of timer ‘beep’ repeating with a little ditty played every ten beeps.
The next thing to note is that this game is hard, although some of that may be down to the quality of my controller meaning the skier response is a bit slow. We can see that the player sprite has three frames: left, right and crashed. The rest of the graphics look like they’re made up of chars - mostly because a BASIC programme wouldn’t be able to multiplex sprites! So we’ll need to grab all of these from the BASIC data statements.
The collision detection is quite unforgiving so we can assume that it’s using the standard sprite to data collision register (see later). The scrolling is also very simple and makes use of the built-in screen scroll that triggers when a character is written to the bottom right-hand corner. We will definitely want to do something different with that, although a full screen vertical scroll is very processor heavy. However, there is definitely scope for trying to implement a nice vertical smooth scroll when we look to improve the game.
Other things to note are that the player sprite only moves in the X direction, except when you crash at which point it moves down the screen. We appear to have three lives - although there are no player stats on the screen to tell us this or anything else (something else to improve upon).
The game over sequence involves an ambulance moving across the bottom of the screen - it doesn’t look like they used a sprite for that as it flickers as it moves, suggesting chars being erased and redrawn. We get a nice little ambulance sound effect to go with it.
Finally we end with a screen telling us how we died and the distance we travelled, along with a rather simple version of Chopin’s Funeral March. We have what looks like a high score at the bottom showing longest distance covered.
So lots of information from that first run through, but really we need to get further into the game without dying. So how do we do that? Cheat of course!
You’ll see I mentioned above that it looks like the sprite to data collision register is used, so a quick look up on that memory address shows that it is held in memory location 53279 ($D01F). A search of the BASIC listing doesn’t turn up anything for that address, but we can see in line 15 that the variable V is set to 53248 ($D000) and then used as an offset for a number of pokes. So what we need to look for is V+31, and it’s not far into the code before we find a PEEK of that very address. A simple REM statement will sort that out…
So lots of information from that first run through, but really we need to get further into the game without dying. So how do we do that? Cheat of course!
You’ll see I mentioned above that it looks like the sprite to data collision register is used, so a quick look up on that memory address shows that it is held in memory location 53279 ($D01F). A search of the BASIC listing doesn’t turn up anything for that address, but we can see in line 15 that the variable V is set to 53248 ($D000) and then used as an offset for a number of pokes. So what we need to look for is V+31, and it’s not far into the code before we find a PEEK of that very address. A simple REM statement will sort that out…
Voila! No more collision detection. Right, let’s have a proper run through of the levels now…
So now we can see the variation in levels, and hear different sound effects for each of those levels. There’s quite a bit of variation here, we have trees, houses, zig-zag things, narrow passageways, um, mushrooms and er, ants? Anyway, there are a number of chars we’re going to have to grab for each of those levels.
All in it looks about 11 levels/stages long before it starts to repeat. Another thing I noticed afterwards is that if you leave the title screen for a short while then it enters a “demo” mode where it basically runs through the levels with the player sprite turned off (so we didn’t need to cheat after all!). That’s another thing for us to look out for in the code.
So now we have our rough gameflow outline:
- Initialise
- Title Screen
- Demo Mode (screen move)
- Game Mode (player move, screen move, player collision, sound)
- Change level/stage
- Player Crashing & ambulance
- Game over & high score
As we get into the code more this may increase/decrease but it provides an outline for us to work on for now, and also gets us thinking about the different sections as we explore the BASIC code. Which is exactly what we’ll be doing in the next article…
Next up: Breaking down the BASIC part #1