 |
 |
|
|
|
Die! Alien Slime – A Misunderstood Epic... with a bit of a problem
By Jason Daniels
» Download the new, fixed version of Die! Alien Slime
A little history
Pagoda Software was a games design team around in the later half of the 1980's. It was just two guys – me, Jason Daniels, designer and C64 programmer and my old friend Tom Lanigan, designer, graphic artist supreme, computer musician and sound-effects wiz. Pagoda created three titles: Autoguard, Blip! Video Classics and Die! Alien Slime. Of those only two were published, Video Classics and Slime, Autoguard was actually never finished (you can read all about Autoguard in a previous article on C64.COM).
So, Die! Alien Slime... It was 1988, Autoguard was shelved indefinitely and Blip! Video Classics had been written, published and we had finally made some money out of the business, albeit a tiny amount. We intended our next game to be a full-price title in the hope of earning a bit more cash this time around.
The genesis of the idea
Tom and I were both big fans of James Cameron's sci-fi war movie Aliens, released a couple of years previously in 1986. We also enjoyed the arcade game Alien Syndrome, released in 1987, which was obviously heavily influenced by the Cameron movie. The Commodore 64 conversion of Alien Syndrome had only just been released so we were keen to try it out. The developers had done a pretty decent job of porting it to the C64 but we were disappointed that it was a multi-loader. This meant that, on completing each level, you had to wait whilst the next level loaded from tape which was a bit tedious and killed the tension of the game somewhat. Also, if your character was killed outright or the tape load failed (which did happen) you would have to rewind the tape to the beginning and start again, which was a bit of a drag.
As much as I liked Alien Syndrome I thought we could create a game influenced by the Aliens movie that had a bit more depth, a bit more scope and that built up the tension over a longer period of time, and without the tape-loading breaks. The idea I eventually came up with also incorporated aspects of the original Alien movie directed by Ridley Scott back in 1979. Tom liked the basic premise and we decided to go forward with it.
Tom and I have always had a rather ambitious streak when it came to games design (Autoguard is a testament to that) and our big ambition on this project was to create a huge environment in which to set the game in order to introduce a strong element of exploration and mapping. We were, critically, also determined to do this in a single-load game, no multi-loading at all, just load the game, play the game and, perhaps, finish the game, the datacorder doesn't get another look-in. I think it's fair to say we certainly achieved that in the finished game – the Die! Alien Slime map has to be one of the biggest single-load C64 maps ever! It really is vast but also quite varied and detailed.
The story
The narrative of the game goes along the lines of... You are the last surviving crew member of a giant military research ship on the outer reaches of the galaxy. One of the projects taking place on this vessel was the development of weaponised alien DNA (big monsters to you and me). As usual, the whole thing gets out of hand and the monsters go on the rampage, killing all the crew (except you) and generally making the place untidy. The ship becomes crippled and starts drifting out of controlled space. Your character wants to kill all the nasty monsters and get out of this hell-hole alive. The only way to do this is by activating the emergency escape shuttle by (conveniently) setting the ship to self-destruct. Hey-presto! Two birds with one stone.
Playing Slime
Setting the self-destruct on a multi-billion dollar spacecraft has not been made easy. Scattered around this huge vessel are nine special computer terminals called Destruct Terminals (or DT's), each of which has to be found and activated (in any order). However, before any of these DT's can be activated the player must find the DT Security Pass and then use one of the many non-destruct computer terminals dotted around the ship to actually allow the DT's to be activated. Incidentally, although the destruct terminals and non-destruct terminals looked basically the same, the destruct terminals had distinctive beacons next to them to set them apart.
Some of the DT's were in parts of the ship that could not be immediately accessed for various reasons like locked doors, transport blocks and energy barriers. Placed around the ship were various keys and computer disks that, when found could be used to either unlock, switch on or switch off these various obstacles. Once the nine DT's had been activated the player had to find the elevator (which also needs a disk to activate it) to descend into the lower engineering level. There they would find the tenth and final DT which, when activated, would begin the destruct countdown sequence. That countdown was the time the player had to rush back to the lift, ascend to the main level and then find their way right back to the point at which they started the game. Once there they could board the now active escape shuttle and get the smeg out!
Sounds simple enough but there were a few obstacles. There was a time limit for a start, remember the ship is drifting away from controlled space. If the player takes too long to leave, the escape shuttle would be out of range of any rescue. Then there's the small matter of the whole place crawling with alien DNA monsters of various types, some nastier than others. Of course they all had the common trait of wanting to hurt you, either by spitting great gobs of acidic goo or just bumping in to the hapless player fool enough to get close to them. Fortunately the engineering level has none of these creatures to hamper you. Unfortunately, it does have a...... (now that would be telling!).
Of course it wouldn't be much fun if all you could do was run away from these beasts like some yellow chicken. No, we give you guns! Admittedly, the gun you start with is a bit rubbish but think of this as a motivation to start exploring the ship and find one of the more powerful weapons that have been carelessly left around for anybody to pick up. Our favourite is the laser but there are also shotguns, machine guns, flame throwers, blasters and rocket launchers. Each has it's strengths and weaknesses be it in range, rate of fire or damage. There are also, about the ship, a limited number of man-portable energy shields. Using one of these will absorb damage instead of the player but they can only take so much before they are depleted and you're back to getting your butt kicked.
The lost art of mapping
One very important aspect of Die! Alien Slime's game play that should be considered in the context of the time it was made was mapping. These days mapping of any game with exploration elements is carried out automatically within the game and can be viewed instantly on the screen. Back in the 8-bit era, in-game mapping was virtually unheard of, due to the limitations of available memory and processor speed. Most games with a large play area required you to map them manually with pencil, paper and judicious use of the pause button.
In fact, mapping was seen by many as a feature of a game. So much so that players would spend hours drafting intricate and beautifully illustrated maps that they would send into computer games magazines which would publish them in the next issue. Mapping a game was a serious business back then.
As the title of this section suggests, mapping is a lost art now and hasn't really been relevant for decades. This can frustrate some modern players as they see the need to map a game manually as a very frustrating and unappealing activity. Die! Alien Slime is a mappers wet-dream – the play area is huge and varied and the need to map is almost obligatory.
Developing the game
Up to the point we started work on Slime I had written code using the various 6502 development programs published by Oasis Software, beginning with White Lightning, through Machine Lightning and finally the Ocean published Laser Genius. Initially I used these packages on a Commodore 128 and then later a Commodore 128D, a machine which, in my view, was the pinnacle of 8-bit hardware. Both these computers had a built-in machine code monitor which was very handy for debugging. I started working on Slime with the Commodore 128D/Laser Genius combo but early on we decided to push the boat out and invest in a PDS.
For those who don't know, PDS or Programmers Development System, was the top-notch software development system around in the late eighties and early nineties. It consisted of an interface card that was put in an IBM-compatible PC, a lead that would connect the card to the target computer, in this case a commodore 64/128, software and manuals. With PDS you developed code using a fairly sophisticated editor/assembler on the PC and then downloaded it directly to the target computer where it could be run, monitored, step-traced etc. Needless to say this sped up code development enormously. Mind you, PDS wasn't cheap – we payed £632.50 for ours and that's without the PC, that cost another £1000+ for just a 12mHz 80286 with 640K RAM, 5.25" floppy-drive, EGA display and NO hard drive! Remember this was in 1988.
Even with the help of the PDS the game still took over six months to develop as cramming so much into a single load took a great deal of work both in terms of the coding and the graphics/music/sound effects. In fact, there were a couple of features we originally intended to have which were either cut-out or cut-down because of lack of space or for better gameplay.
The first was that we were going to have a simultaneous two-player option but that was dropped early on due to the code overhead and not having enough sprites. The second was interesting in that it was originally going to be a major feature but ended up being reduced to a mere cameo appearance, Alien Slime! Yes, the Alien Slime of the game's title was a real entity within the game. Imagine a carpet of slimey, gooey spherical globs that slowly expanded and, whilst not being able to harm the player, would impede their movement making them vulnerable to attack by the alien DNA monsters. You could shoot the slime and it would recede but would start to grow again once your attack ceased. The idea was that the ship would gradually fill up with this stuff making the game harder to complete the longer you took. It was a nice idea but it totally unbalanced the playability of the game and, again, the processor and code overhead of constantly generating slime was too much for the C64's poor old 1 MHz CPU and limited RAM. There are a couple of patches of slime left in the game but they don't grow any bigger and don't grow back once they have been shot. They are a major pain in the bum when the player first discovers them though.
In the development of Die! Alien Slime Tom and I used a couple of third party programs that I would like to acknowledge.
Shoot 'em Up Construction Kit (SEUCK) by the Sensible Software guys – Obviously Slime is not a SEUCK game but we did use SEUCK as a tile, map and sprite editor. Tom would design on SEUCK and then I would rip the data and incorporate it into my code.
Ubik's Music by Dave 'Ubik' Korn – This was a superb budget SID tracker program that was very sophisticated but fairly easy to use. The main benefit for us was that it could generate a self-contained code and data module that could be incorporated into your own machine code program and which just needed to be run on a regular interrupt (I used the NMI to keep it tight). Music and sound effects could then be triggered by writing values to a small handful of memory addresses. It probably wasn't the most memory efficient method but it saved me a lot of time and effort because I didn't have to write my own SID routines. Tom has an amusing story about just how good Ubik's Music is, have a read of Tom's interview here on C64.COM.
Actually, whilst we are talking about the music/sound effects, I really must mention Tom's title theme for Die! Alien Slime. I know I'm biased but it really is one of the best pieces of C64 music I have ever heard. It's certainly the best sci-fi horror theme ever on the C64 and a real hidden gem in the massive field of SID music. If you get the opportunity please have a listen to it, it's fairly long but it's important to listen all the way through as the music changes and develops throughout. Hopefully, we or someone else will put it on YouTube in the not too distant future.
Slime release
As I mentioned previously we had intended Die! Alien Slime to be a full price game and, if it had been 1987, it probably would have been. Unfortunately, by the time Slime was finished, it was 1989 and things were a bit different. The Amiga 500 and Atari ST had been around for a few years and 8-bit was starting to look a bit old-hat. Full price new releases on 8-bit formats were becoming scarce and were largely restricted to licenses of movies or well-known arcade games. Original 8-bit games were now almost all on budget labels, and so it was with Die! Alien Slime. We got a publishing deal with Virgin Mastertronic on their 'Plus' label being sold at £2.99, one step up from the bottom rung £1.99 games.
The game was converted to Spectrum and Amstrad, neither of which I have really played. I've heard it said that the Spectrum conversion of Slime is considered one of the worst Spectrum games ever! It certainly doesn't look or play much like the original though I have seen the map for it and, though different from the C64 map, it's still impressively big. I did briefly work with the programmer of this abomination and he informed me that it was a real rush job. The Amstrad version at least looks like the C64 because, I believe, the C64 graphics were ported straight over. However, the smooth full-screen scrolling of the C64 version has been replaced by a simple flick screen routine, yuk!
Unfortunately Slime did not sell in huge numbers, I think it was around 25,000 units across the three formats. The royalty on a £2.99 game was pretty paltry so, yet again, we made very little money for our efforts. It was soon after that we decided to call it a day on Pagoda Software as starving for your art is not in the slightest bit glamorous.
A misunderstood epic
No one could accuse Die! Alien Slime of getting a good review, 'cos it didn't. There are some reasons for this – the first is lazy reviewing...
Okay, STOP THERE, is this the artist lambasting his critics because they just do not understand his art or his genius, and... blah, blah, blah, self-indulgence, blah, blah. Well okay, there might be a little bit of that but hear me out.
Like I said, lazy reviewing. Remember, this was 1989, most people were interested in the latest 16-bit game, who cares about some long-winded 8-bit budget title that looks like an Alien Syndrome clone and plays like a really bad Alien Syndrome clone. This was a big part of the problem with the perception of Die! Alien Slime, people automatically thought it was an Alien Syndrome clone. Now there are aspects of it's gameplay that are very similar to Alien Syndrome but it really is a totally different gaming experience. Alien Syndrome was a hard-and-fast arcade shooter where as Die! Alien Slime is an exploration/mapping/puzzle game in which you also happened to kill lots of alien monsters. The shooting aspect was almost secondary in Slime, exploring the ship, working out how to get through it, mapping it, getting into the atmosphere of it, that was what Slime was primarily about.
Another thing that didn't help was the instructions, though I do partly take the blame there. Mastertronic asked us to provide some notes for the game instructions and me being a bit on the verbose side, gave them a small pamphlets worth including the background story, explanation of features and keyboard controls. Whoever was dealing with our game at Mastertronic obviously took one look at what I had done and thought "That'll do!" and they used them pretty much verbatim as the final instructions. We didn't know they had done this until the game was actually published. We assumed, wrongly, that the game would have been properly play tested with my notes used as reference only. I'm pretty sure my notes could have been tweaked into something more player friendly and better explained what you actually had to do to play the game.
Of course this problem has become even more acute with more modern online reviews where people are playing downloaded versions of Slime on an emulator with no instructions at all! They start playing the game, without a clue what to do, it looks a bit like Alien Syndrome so they play it like Alien Syndrome which soon gets tedious because they end up wandering around this endless ship constantly shooting aliens without any apparent point or resolution, it's boring and they hate it.
The good news is that I have read some forum comments from people who played Slime properly and understood the type of game it is and really loved it.
The 'bit of a problem'
There is a sting in this tale, which is one reason why I have written this article in the first place. This article is the first in a series about how I am fixing the code of Die! Alien Slime because, you see, every, single, copy, is... BUSTED!
Die! Alien Slime – The 2nd Bit... Fixing the Problem
Recap
We ended the last episode on the cliff-hanger of every single published copy of the Commodore 64 version of Die! Alien Slime being busted.
No idea what I'm talking about? Then please read the first article "Die! Alien Slime – A Misunderstood Epic... with a bit of a problem" above and all will become clear.
The Problem
Anyway, it's true, every published copy of the C64 game has a fault. After completing 90 percent of the game and activating the lift that takes you down to the engineering level the game screen goes blank (as it should), the lift sound-effects play (as they should), the game hangs (as it shouldn't).
Truth be told, Tom and I only discovered this problem ourselves about four years ago and we were a little shocked. The game we had given Virgin Mastertronic in 1988 had certainly been fully tested by us and was fully working. My first theory to explain the problem was that Virgin Mastertronic's fast-loader code, which reduces tape loading times to levels that don't allow you time to make a cup of coffee and a sandwich, had corrupted some of the game code or data. Unfortunately there was no quick or easy way to find this out or, more importantly, to fix it.
So we didn't.
Pagoda Software, The Return
Tom and I have been talking about getting Pagoda Software going again for years, and for most of that time it has been just talk. Then last year (2015) we started to take the whole idea a bit more seriously. We knew it would have to be a gradual process, after all, neither of us have done any games design in decades and I haven't done any serious coding in over 20 years. Plus we both have established lives that can't just change overnight to suit our new direction. I decided I needed a project to get me back into that coding mentality and I knew without a doubt that fixing Die! Alien Slime was the perfect candidate. Here was an opportunity to re-learn my coding skills with code I was at least vaguely familiar with and, at the same time, remove a long-standing blemish on a project that has always meant a lot to both of us.
Fortunately, I still have my PDS development system for the C64 on which Die! Alien Slime was originally created, albeit with a different PC (an old Amstrad PC1640) to my original system. Even more fortunately it all still works. Unfortunately, I don't have any of my original PDS files for Die! Alien Slime. I do still have a folder full of notes and code listings for Slime but the printouts only covered about a third of the total code, plus they were not final versions of the code, and they were very poorly annotated. In other words, the listings were not of much use.
Raiders of the Lost Code
It was time for a bit of code archeology. The only complete code source for the game was on the published cassette and, somehow, I would have to extract it.
On the face of it, that may sound easy, just load the game perform a warm-reset and bob's your uncle, you have the code left in memory to be saved using a machine-code monitor. Problem is, Slime was such a huge game that I had to cram it in all sorts of little nook and crannies of the C64's RAM, and when you reset the machine a lot of this stuff gets overwritten by the system. Now there may have been ways around this but, as I mentioned, I had not coded in some time so I am not currently a hot-shot C64 hacker. No, I decided on a different approach – to use the total coolness that is the Commodore 128D.
The Commodore 128D, and the Commodore 128, have 128K of RAM but, like the C64, it's 8-bit processor can only address 64K at any one time. So the C128D has a Memory Management Unit (MMU) that can page in and out the two banks of 64K memory as well as the various ROM's (Kernel, BASIC, character set). These two 64K banks of RAM are referred to as Bank 0 and Bank 1. Normally the machine defaults to Bank 0 and when it is in C64 mode, where the C128D effectively becomes a C64, it also defaults to Bank 0. My idea was to, somehow, get the program loaded into Bank 1 of RAM and then reset the machine which would default into Bank 0 leaving the contents of Bank 1 totally untouched, cunning plan huh!
After reading my C128 programmers reference and doing a bit of online research I wrote a small routine that, when run from the C128D's built-in machine code monitor, would reset the machine into C64 mode but with C64 mode operating in Bank 1. I could then load the published cassette of Die! Alien Slime as normal, but into Bank 1, and then reset the machine back into the machine-code monitor (which would default to Bank 0). The whole of the Die! Alien Slime code and data would now be sitting, unchanged, in Bank 1 of the C128D's memory.
My next problem was how to get the Die! Alien Slime code and data into the PDS. Normally there is a small "downloader" program that runs in the C64 that enables communication between it and the PDS. Problem is, the C64 downloader program was not compatible with the C128D. Altering the downloader program to work with the C128D was not too difficult because, at a hardware level, much of it works the same as the C64. However, the downloader program had to run from Bank 0 RAM on the C128D but had to be able to access the information in Bank 1. To do this I had to rewrite the downloader program to enable bank switching between Bank 0 and Bank 1. Fortunately, the C128D is designed so that the first 1K of RAM is accessible from either 64K RAM Bank, it's called "Common RAM". Problem is, the downloader program is about 1/2K in size and unused space in that 1K of Common RAM is very limited.
My solution was to divide the Downloader Program into two parts. The bulk of it resides in Bank 0 RAM outside of that 1K of Common RAM but there is a subroutine that handles reading and writing data from either RAM Bank that is small enough to sit in the upper part of the Stack memory. The Stack is 256 bytes within that first 1K of memory (Common RAM) that is used by the processor as temporary storage. Generally speaking and certainly in the case of my downloader program most of that 256 bytes is never used and can safely house my little downloader subroutine. Control could then pass from the main downloader program in Bank 0 to the subroutine when Bank 1 needed to be accessed.
It worked! And I was able to upload the entire Die! Alien Slime code and data into the PDS. Job done, you may think, just find the corrupted code and repair it, you may think, easy peasy, you may think. Oh no, the hard bit isn't over, the hard bit is just beginning!
Tune into C64.COM for the next "I'll try not to make this too techy but, hey!, this is about fixing code so there has to be some tech – and I don't know any jokes" episode, coming soon.
Die! Alien Slime – The 3rd bit... Bug Chasing
Where's Your Head at? (at? at?...)
At the end of the previous article I had extracted all the code and data of the game and uploaded it into my development system. However, it's important to get a perspective on what I was actually working with here. First off, forget all that crap they show you in the movies when someone hacks code – what I had was not streams of nicely labelled code complete with handy labels and lots of nice annotations telling me exactly what every line does. At first blush all I had was over 60,000 numerical values, nominally presented in hexadecimal (base 16, which uses the numbers 0-9 and the letters A-F to represent it's units) and that's it!
Somewhere in that 60,000 or so numbers was some which were the wrong value and they had to be changed to the correct value in order to make the game work the way it should. Did someone say needle in a haystack! Where to start?
Previously I said I had an old folder of notes and listings from when I first wrote the game. Unfortunately the listings, as I mentioned, were largely useless but I did have a few things to help me along. Probably the most important asset I had in translating all this raw information into something more understandable was an original memory-map for the game. The memory-map is a diagram most programmers draw to show how the computer's memory is allocated to the different parts of the program. It shows what sections are code and where the various data types are stored (screen graphics, sprites, music and sound-effects etc.). This was crucial as it gave me the start addresses of the sections of code which I could use with the PDS' disassembler to translate the raw numbers into assembly language. This at least made it, to a programmer, vaguely readable.
Avenger Assembles
Now I'm not going to get into the intricacies of 6502 assembly language ‘cos, unless you're really into that sort of thing, it's pretty dull. The point is I now had several very long lists of instructions, most of which had a memory address next to them showing the memory location on which the instruction operated. Of course, the purpose of most of those memory locations in relation to the game itself were still a mystery to me but it was a start.
The next thing I did was divide the long lists of instructions into more manageable chunks by finding the start addresses of various self-contained sections of code called "routines". This was mainly done by starting at the beginning of each long list of instructions and looking through them line by line for the instruction "JSR" which stands for "Jump to SubRoutine". Each address next to these JSR instructions was, usually, the start address of a routine. With this information I could go to that address in the code and mark it with a temporary label to discern it as the start of a routine. This took a while as, it turns out, there are over 110 distinct routines in the Die! Alien Slime code. Obviously, at this stage, I had little idea what specific role each of these routines actually performed.
After that, I took each routine in turn and looked through the code for any branches and jumps to addresses within the confines of the routine itself (as opposed to jumps to other, separate routines). When I had found all such instructions in a routine I would replace the explicit branch/jump addresses with "local labels". Local labels are a handy facility provided by the PDS editor/assembler that make the destinations of the branches and jumps much easier to see which, in turn, made the code of each routine easier to understand.
Handling the Variables
The last action I took at this initial stage was to go through all the notes and listings I had in my original Die! Alien Slime folder and try to find the name and purpose of as many variable locations as I could. Variables are vital to most programs and deserve a little explanation. A variable is a designated memory location that can contain one of many values but the value it contains at a particular time will depend on what is happening in the execution of the program at that time. For example, you may have a game where the player has six lives, it's likely there will be a memory location that has the number six written to it at the beginning of each new game. This memory location will then be decremented through the course of the game every time the player looses a life. Routines are able to read this variable at any time in order to know how many lives the player currently has left. Chances are there will be a routine that checks to see if that variable drops to zero, in which case the program knows it's game over as the player has no lives left. It's normal practice when writing code to assign alpha-numeric labels to these variables in order to make their purpose easier to discern. So, in our example, a label like PLAYERLIVES might be equated to the memory location of that variable. From then on, any reference to the label PLAYERLIVES in the code would give that variable's memory address in the final assembled code. The important point here is that if you know what a variable does you can replace it's memory location in the code with an appropriate label and that makes the code much easier to read and understand.
Die! Alien Slime has several dozen variables and, initially, I had no idea what any of them were for. Going through my notes and listings, I managed to glean the purpose and label name of a small handful of them. Again, it wasn't much but every one made the routines in which they appeared a little easier to understand.
Captain Slog
I had done all I could to make the code readable, now I had to actually start reading it. The only way I could find out the purpose of the variables and routines contained within Die! Alien Slime's code was to slog my way through the routines one line at a time and work out what the code was actually doing.
Although trudging through code like this can be rather monotonous and more than a little mind-bending, at least in this case it was serving a dual purpose. Firstly, I was trying to track-down the faulty code but, secondly, I was familiarising myself with not only my own programming technique but also how to program the various aspects of the Commodore 64 itself. There were a lot of "Oh Yeah!" moments when a particular quirk of the C64's architecture or one of the support chips, like the VIC-chip, came to light. It was like gradually pushing open a rusty, cob-web strewn door to my past and revealing more and more of the memories hidden behind. I was considering again things that hadn't crossed my mind in over twenty years.
Mind you, my brain is not what it used to be. At my peak, in my early-twenties, I could literally hold thousands of lines of code in my head and recall it perfectly. This is why I never really bothered properly documenting my code. These days I have trouble remembering what I had for breakfast so you can imagine the problems I was having thinking my way through hundreds of lines of undocumented code. On the plus side, I do have some advantages over my younger self – my problem solving skills are much better, I'm more methodical, more patient, more organised and I have a much longer attention span. All these things helped me battle on through this complicated maze of instructions despite the frequent headaches this induced.
Right Back At Ya'
My everyday life only allowed me to work on this project part-time but, after a couple of months, I was making progress. The code was getting more organised and readable and I was working out the identities of more and more variables.
One essential goal was to be able to download the code and data from the PDS back into the C128D (in C64 mode) and have it run the game. This might seem like a given seeing as the complete program had already been uploaded but in organising, labelling and, in a few small areas, actually improving the code, small typos and address misalignments had crept in. In almost any program it only takes one single value to be incorrect and parts of the program or even the whole program can cease to function. As such I had to spend a period of time looking for these sorts of errors and gradually getting the version of the program on my PDS running on the C128D. However, once I had achieved that I was able to really start tracking down the source of the original problem, the problem which caused the game to hang when the player tried using the elevator down to the engineering level.
Is this a stand-up fight, Sir, or another bug-hunt?
As a first step in hunting down the bug (faulty code) I needed to know what general area of the program it lived in before I could hone in on it. The quick and easy method I used to do this was to use the two lines of code shown below:
!1 INC $D020
JMP !1
The first line increments the value held in the memory location $D020 which controls the colour of the screen's border. The second line simply jumps back to the first line (!1 is a local label). When the program hits this code it goes into a never-ending loop with the screens border constantly changing colour, giving the multi-coloured lines effect seen with many fast-loaders. Obviously the program can not advance past this piece of code it just keeps going round and round changing the colour of the border.
What's the point of that, you may ask.
Well it's a great way of finding out if the program reaches a certain portion of code before it reaches the bug. You just put these two lines at a certain point in the code and run the program, if the program halts and the border colours are cycling then you know that all the code up to that point works fine. You then move the two lines to a later portion of code and repeat. You keep doing this until the program stops but the border colour is NOT cycling, at that point you know you have hit the bug but you now have a much better idea of what portion of the code it lives in. Of course, it is slightly more complicated than this because of loops, subroutines and interrupts but the basic principle is sound.
Using this method I managed to track the bug to the raster interrupt routines. The raster interrupt is a part of a program that is triggered every time the screen is redrawn. The lines of the TV screen are counted by the C64 hardware as they are drawn and when the count reaches some predetermined value an interrupt is generated. An interrupt is where the processor stops what it is currently doing and starts running a different piece of code, when it is finished it picks up where it left off in the main program and carries on. Interrupt routines are used for aspects of a program that must be run on a strictly regular basis like sprite-multiplexing, smooth screen scrolling or sound-effects and music.
Now that I knew where to look, I studied the interrupt code very carefully, as far as I could see it all seemed fine. The only unknown was the jump to the subroutine that handled the music and sound effects. As I mentioned in the first article in this series, for the music and sound effects we used a third-party utility called Ubik's Music which generates it's own code module that you can use in your machine code program. This self-contained module is controlled by putting values in just four memory locations – one to start a particular song number, the other three to control the individual tracks played by each of the SID chip's three voices. Ubik's routine then just needs to be called on a regular basis, usually from a raster interrupt. To test if Ubik's routine was the source of the problem I simply removed the Jump instruction to Ubik's and then ran the program. Obviously there was now no sound but, I'll be damned! now the game seemed to be working fine, the bug was definitely in Ubik's routine.
This was both good news and bad. It was good news because I now knew for sure where the bug was, bad news because Ubik's Music routines were not my code so I had no idea at all how it worked or what it's data structures were.
In a way this was one step forward and two steps back!
Stay tuned to C64.COM for the thrilling conclusion to this adventure in retro-programming! Coming soon!
Die! Alien Slime – The 4th bit... Resolution
This is a Journey into Sound
At the end of the last article I had discovered that the bug was somewhere in the Ubik's Music code and data module, the workings of which were almost a complete mystery to me.
The weird thing was, the sound and music all worked fine through the first 90% of the game. It was only when you reached the elevator towards the end of the game that the fault occurred. This indicated to me that the fault was not in the Ubik's music program code but in it's data. There must be some particular sound effects data that was unique to the elevator that had become corrupted so that when the Ubik's Music program tried to use that particular data it crashed. The problem, as I mentioned above, was that I had no idea of the structure of the Ubik's Music data or even where it was stored in the portion of memory occupied by the Ubik's code module. I had no choice but to disassemble the Ubik's Music code and work my way through it as I had already been doing with the rest of the Die! Alien Slime code. Of course, I now faced the same problems all over again, no labels for variables, no code documentation and, because I wasn't the original author of this code, absolutely no familiarity with the techniques used or style in which the code was written. Yes it looked like Captain Slog was back for a sequel!
Bugsplat!
The upside of the situation with reading the Ubik's Music code was that I didn't necessarily need to understand the workings of the whole program, I just needed to work out the data structures and where they were stored. I could then, hopefully, go through the Ubik's data and find the parts that were corrupted. I started to work my way through the code using many of the techniques I have already mentioned like looking for JSR commands to determine the start of routines, using local labels to make the code easier to read and trying my best to separate data areas from code areas. I must confess, progress was very slow. Ubik's Music is a highly optimised piece of code designed to do it's job as efficiently as possible in the smallest amount of space. Unfortunately the techniques used to achieve this efficiency tend to be complex, to say the least, with very little linearity. This can make the code very difficult to fathom when you have no references for it at all.
I was starting to get a bit despondent, I had put in all this work to get to this point and, in some ways, I felt I was back at square one, except with a program that would be even harder to try to work out. Then I spotted something...
In amongst the hundreds of lines of assembled Ubik's Music code I spotted something odd in a section that I hadn't reached yet, some DB's. What are DB's you ask, well during the conversion of raw code into assembly language, if the assembler program comes across some values that do not translate into legal instructions, it simply lists the anomalous values with a DB next to them. DB stands for DataByte and is basically just the assemblers way of saying "here's a value and I don't know what it does", it will keep doing this for consecutive values until it comes across values that do translate into legal instructions. So there in the middle of this program code is five lines of DB's with values next to them, very odd. Of course, it could just be the memory locations of some variables used by that section of code. However, the normal technique is to keep these variables at the end of a routine to avoid confusion and these were definitely in the middle of the code. I had a closer look at this section of code, particularly the instructions that preceded and followed the cluster of DB's. These instructions definitely implied that there should be other instructions between them and not the five DB's. Could it be that the problem was in Ubik's coding rather than some corrupted data?
In order to check this I loaded Ubik's music itself into my C128D (in C64 mode) and created a blank code module with no data at all, just the Ubik's coding. I then analysed this code with the PDS and checked the area around those five mysterious databytes, what do you know, they were different! In this new Ubik's module the values translated into actual instructions. I noted these instructions down, reloaded the Slime code and replaced the DB's with these new instructions. The code was then assembled and downloaded into the C128D (in C64 mode). I went to the PDS' machine code monitor screen from which I could type the jump instruction to start the program running. The Die! Alien Slime title screen appeared and the music started playing, all as normal. I now had to play through the game to almost the end where the player steps into the elevator to go down to the engineering level. Here they would set the final Destruct Terminal to start the self-destruct sequence and then leg-it back to the escape shuttle. Fortunately I was using a temporary cheat mode which meant my player could not be harmed so reaching the elevator was not too challenging.
I moved the player onto the elevator. I pressed the key to activate the elevator. The screen blanked and the elevator sound effects sequence started as they always have. The elevator ended it's journey and... here was the moment of truth. The engineering section sprung to life on the screen with the ambient sound effects rumbling away nicely in the background. I moved my player off the elevator pad, everything was working as it should!
Fanfares sounded inside my head, I'd done it, the game was fixed!!
Post
The sense of relief I felt after this was quite palpable and a little emotional. All those months of twisting my brain until it hurt and it all came down to those five little bytes.
What had caused this error in the first place? We'll never know for sure but it certainly wasn't anything to do with the fastloader as I first suspected. My guess is that, during the mastering process there was some tiny glitch – a small power-spike or maybe a tiny defect in the oxide of the mastering tape that affected just that minuscule part of the program. I imagine the game may have been play-tested after it was mastered but unless the tester played almost to the end they would not have spotted the fault and so it slipped through to every copy of the C64 version of the game.
But now that bug had been found and stomped! Now the game is fully working as it had been when we handed it over to Virgin Mastertronic back in 1989. Now we can make the fixed version of the game available to all to play and, hopefully, enjoy.
As well as the fixed version of the game I am also making available a revised and extended version of Die! Alien Slime's original instructions. This new instruction manual will also include a mini player's guide with some hints and tips on completing the game. We may also, at some point, publish a map but to really get the most out of Slime you should try and create your own.
The game will initially be available from C64.COM, no doubt more will be added over time.
The Future for Pagoda Software
Tom and I have plans to re-launch Pagoda Software as a developer of quality games software on both new formats and old. I have a great love of creating software for the retro formats particularly the Commodore 64/128 and I have some ambitious ideas for new C64 games. Of course, one day I'm also going to have to tackle finishing Autoguard!
Thanks for reading and watch this space!
For up to date information about Pagoda Software, please follow our Facebook page: www.facebook.com/pagodasoftware.
We also hope to have our website up and running in the not too distant future: www.pagoda-software.com.
Of course the great relationship between Pagoda Software and C64.COM will continue after this article, so please keep visiting C64.COM regularly for interesting C64 news and articles and, no doubt, more Pagoda Software related material.
A big thank you to Andreas Wallström and C64.COM from both Tom and I for being so supportive of Pagoda Software, cheers!
» Download the new, fixed version of Die! Alien Slime
» Go
back to the articles
|
|
|
|
|
|
|
 |
|
|
|
