Our first game this issue is Cliffhanger, which I can boast is available for the BBC and Acorn Electron at long, long last. Yes, it took me a few seconds to type that - but getting to the point where I could state such has taken over 100 hours of my life. The game was serialised in the magazine Input but I can quite confidently assert it has never seen the light of day ever before. But why? It's not a difficult game to play, it's not even particularly impressive, despite the claims Input made on its behalf at the time.

The answer is a complicated one, and in this article (Note: There are full playing instructions on screen!) I can only hint at the hell of typing up and debugging this game. Often when entering a listing from a magazine you are faced with one or two problems. A few missing lines, or even characters, and the program becomes completely useless. Listings purely as a hexadecimal machine code dump are particularly error-prone - typing one F instead of E and you are faced with having to trawl through pages of correctly copied code to find that one slip that makes the game unplayable.

But, wow, Cliffhanger was really something else!

Originally published in 23 parts, it appeared in Input as "the best game", the one worth going to all the trouble of typing in. A platform game with flying birds, hissing snakes, rolling rocks, title screen, background music and a rising sea level. An arcade extravaganza on your home computer. Input not only published the listing but also extensive notes on all of the machine code routines. This was done on the (dubious) premise that its readers would be able to learn machine code as they put the program into their micro. Unfortunately, I suspect precisely the opposite was the case. I would hazard a guess that Cliffhanger caused readers to sweat blood, clutch at their shirts in despair, throw their computers into television screens and rip up their Input issues in a psychotic rage. I know - because I've been there!

How did Input get it so wrong and cause so many people to give up? Well, let's get on to the specific way that it published Cliffhanger. Firstly, it is a complicated machine code program being published in a generic computer hobbyist magazine. Of course you can't just hammer the same machine code into a Tandy, a Commodore 64 or a BBC/Electron. So each issue of Input had to present different listings for different computers. Then they had to follow through with that, because each machine code listing is going to work in a different way, so they needed completely different articles to describe what each version of the game was doing. Result: four different articles, four different pieces of code (and means of testing!), with the reader left to figure out what exactly applies to his particular machine.

Then add the editorial policy. Input was not, I repeat not, produced by printing out the working code from a computer! It was an upmarket glossy and the code for each article must have been laboriously copied by hand into a desktop publishing package by Input's team. Now, whilst copying text is relatively straight-forward - with spelling errors, etc, easy (for an educated person) to catch - the same cannot be said for a sequence of LDA, PHA, BEQ and BEN instructions. And what about the # and & characters? They are not interchangeable; LDA #98 means Load the Accumulator with the value 98, LDA &98 means Load the Accumulator with the contents of memory location 98! I'm sure Input's editorial team did their best, but lots of errors got through. So that piece of code its readers were laboriously typing into their machines was incorrect as printed there on the page. What sort of chance did that give them?

Next let's talk about the programming style. Cliffhanger was constructed to work with a cassette-based machine - yes, that's right, 23 parts of source code to be loaded in one after another from cassette and to be compiled to create the executable game. Just stop and think about this. To create this little 19K game from Input, you were banking on 23 pieces of code, typed up from bugridden text, all loading from tape and, in linear fashion, executing flawlessly to create the executable game... You would need about 45 minutes of cassette tape just to hold the information! Hadn't Input heard of disc drives? Well, yes, it had because it published several articles about them - but Cliffhanger's programmer utilised the area of memory reserved for the operation of disc drives as part of the game - so you simply could not use disc to compile it! In fact, only with the very clever programming techniques now given to us by BeebEm did I manage to compile using disc and that was long, complicated and incredibly frustrating.

Next let's think about the index, or list of errata. Input realised almost as soon as it started that it was publishing bits of Cliffhanger that didn't work. So it published an index of 'corrections' that needed to be made to the code. But, a few months later, it re-ran the whole of the Input magazine from issue 1, this time making some, but not all, of the corrections that it, or its readers, had identified. So you now had two possible 'versions' of the magazine itself out there in circulation. Hence if you came to it, like me, second hand from a number of different sources, you weren't sure whether you've typed a version that needed to be corrected or not. Oh, and of course Input made mistakes in its corrections too!

So finally, having caused complete pandemonium, Input published in its last ever issue a complete memory dump of the whole Cliffhanger program, and said "Examine the code in your micro's memory and check it against all these hexadecimal numbers (four pages worth!) and if any of your numbers are wrong, change them and then it will work". Alas if you took them up on their offer - the memory dump was another 'copied by hand into desktop publishing package' article, punctuated by even more errors than the original executable you had created!

I first took a look at Cliffhanger back in 1998, typing up the 23 parts one by one on a real Beeb. The magazine versions I had came from an Electron enthusiast, who had annotated some of the code with corrections he had discovered himself, adding yet another consideration when typing it up. i.e. are his corrections in fact correct, or had he made mistakes elsewhere in the code? On running it, after many many hours work, I got the title screen and instructions, but when the main cliff screen appeared, the main hero fell straight through the platform on which he was standing. I tried every permutation of the code I could find at intervals over the next few months, even sending out the incomplete version to fellow, more intelligent BBC/Electron enthusiasts but it seemed hopeless. The fact the game was corrupted when BREAK was pressed, and then it needed to be reloaded from tape, was just far too frustrating for anyone to bear.

Finally this year (2010) I turned to the hexadecimal dump, poking all the hex numbers into their corresponding locations (a task which tooks days, not hours) and finally crossing my fingers when I executed the CALL instruction, only to find the game crashed completely after displaying the title screen.

So how did I get it finally fully working? Well, to cut a long story short, I loaded the hex-dump-compiled version of the program into memory (not the memory reserved for the disc drive - natch!), and overwrote different sections of it with the original parts as published in the 23 issues, then tested execution. This makes the process I followed sound extremely simple and I can hear you all shouting immediately, "Well, even I would have thought of that!". Let me assure you it was not, by any means, that simple. Such was the prevalence of bugs in the listing that overwriting sections solved one problem but introduced another. Just getting the instructions to appear took over three hours, chopping and changing snippets of code fragments within code fragments. The screen display simply refused to appear correctly no matter what I did, until I replaced the whole of the hex dump for that particular section. Whereas the collision detection worked perfectly on the hex dump version, but crashed completely when the score updating routine was added. Parts 10 and 17 - as published in the magazine - always crashed the game completely!

I ended up with around five different executables of the final program. All had bugs of a different nature. One crashed at Game Over, one placed the holes in the wrong place, one did not update the number of lives after death, etc, etc. In the final few minutes these were almost merged trial-and-error style until a version appeared which had every part working. To do this required images of two double-sided discs with BeebEm retrieving pages of machine code from one, CHAINing the BASIC procedures from parts on the other one, and rewriting the main file over and over again. A lot of *RENAMEing also went on - thank goodness for the function keys!

If you do check out the finished game now, you'll be able to see just how much work went into producing it, because I have left all of the files used on the disc itself. Many of you will probably just treat it like any other game, load it, play it for a few minutes and then forget about it. As I said introducing this article, the difficulty putting the Cliffhanger game together means you will never have been seen it before. I may review it as a game in its own right at some point in the near future. However, this article sets it in its correct context; that of the most difficult program to bring to you that you could ever imagine...!