Shutdown is a game which has recently come to light thanks to the guys over at the World of Spectrum and a entry on their website. Taken directly from the World of Spectrum entry, Dean Hickingbottom recalls…
“This game was created at Video Images, a co-operative company formed in 1987 in Scunthorpe by David Bradley, David Colley and Dean Hickingbottom. The original CPC version was coded by David B. and Dean H. at Video Images.
When the company split, Dave B and Dean took the game with them to Clockwize in 1989 and it was sold along with a ZX and CBM64 conversion (by Craig Wight), to another company. As far as I know it never saw the light of day. The company was Palmer Acoustics Ltd of Sheffield (possibly PAL Developments Ltd??) “
The good news for Spectrum owners was that the game was recovered and released on the World of Spectrum, though sadly the C64 version was still at large and was at large for some years. The game looks very promising and something complete which will be very enjoyable.
Craig Wight sadly didn’t have anything of the game any longer, and David Palmer did not recall anything about the conversion. Maybe it was purchased but not deemed as a title that might sell well? We’re not sure.
Luckily in 2015, Dean Hickingbottom found a C64 disk with the entire source code to the game – which was actually converted completely over in only 9 days in total, with the following listed in the source:
;SHUTDOWN V1 – CONVERTED TO THE 64 BY CRAIGUS BAGUS WIGHTUS
; STARTED CONVERTING ON SATURDAY, 4TH OF MARCH 1989,
; FINISHED CONVERTING ON MONDAY, 13TH OF MARCH 1989.
As we were in touch with Craig, we put him in touch with Dean once more – but Craig couldn’t recall how to get things running again. So Dean took it on himself to pick up an old 2500AD assembler/linker that he used at work years ago, diced up the binary with Hexplorer and using 64copy to create virtual files to run virtual disks in WinVice. After a lot of hard work, Dean managed to get the game fully compiled!
And here it is! After 26 years of being lost on an old disk, the game that PAL developments should have released is finally here! Check out the full game for yourself!
It’s another game saved – and another PAL developments related game in the space of about a week! We hope to hear Dean’s full story on Creator Speaks very soon about the work involved in piecing it all together.
Contributions: Peter Weighill, Icon/Remember, World Of Spectrum, Dean Hickingbottom, Craig Wight
Available downloads for this entry
“Shutdown – Re-assembled” Notes
Frank asked me if I’d like to write a few lines regarding Shutdown and since I’m only too happy to blither on about old 8 bit micros (they don’t make ‘em like they used to etc) I thought I’d outline the major bits and pieces that went into re-assembling this old piece of tat from years ago. So…
As stated elsewhere on this site, for the CBM64 version of Shutdown, it was (from the PDS source)…
; STARTED CONVERTING ON SATURDAY, 4TH OF MARCH 1989,
; FINISHED CONVERTING ON MONDAY, 13TH OF MARCH 1989.
and I believe that to be true. My re-assembling of the code has taken significantly longer, partly because the CBM64 was not my computer of choice in those days (I preferred Z80) and partly because these days this sort of thing has to fit in and around everything else, so snatching the odd hour here and there last thing at night is not the best way to proceed.
Anyway, this all came about when Frank (who has been prodding me for years about any old stuff that may be lurking in the vaults) put me back in touch with Shutdown’s CBM author, Craig Wight. Craig and I then got into emailing about our old Clockwize days and then I went to see if I still had any old code snippets from years ago that Craig had had a hand in and re-discovered his CBM conversion of Shutdown, which I promptly emailed to him.
Although Shutdown was sold on CBM, ZX and (the original) CPC format, it was never released so I was hoping that maybe Craig would have a go at assembling it. He did have a quick go but encountered problems and had too many other things to do to give it some serious thought, but as I’d re-assembled some old Spectrum code not too long ago, I thought I’d have a try. After all, you just need an assembler don’t you?
Well, yes you do obviously need an assembler but what if you can no longer use the one the code was originally written on? At Clockwize we used the PDS (Programmers Development System) and I don’t have any of that old hardware these days.
There are two main problems to overcome when re-assembling old code. Firstly, generating the binary and secondly, deploying it. To re-assemble the code, I used the 6502 Macro Assembler by 2500 A.D. Software (circa 1990). The reason for this was that I’ve used their 64180 assembler before so therefore knew roughly how that needed to be set up. Here I hit a small snag in that the assembler and linker, being old MSDOS executables, would not run under my Windows 7 OS. Thanks Microsoft. Fortunately, this is easily sorted by downloading the excellent DOSBOX.
After setting that up, I then did some test code to check I could get a simple binary. Good so far. Next, I needed to massage the PDS code into something I could edit. PDS used a method where eight large text files could be edited, assembled and quickly downloaded (using an extra hardware interface) to your target machine for instant testing. The text files didn’t seem to be standard ASCII text, however Notepad++ loaded them without difficulty. With a little setting up, I even managed to get Notepad++ to do some nice 6502 syntax highlighting to make it easier to read.
When I’d re-assembled old PDS based Z80 Spectrum code, I first had to write a simple DOS app to convert the PDS files to something the assembler would take straight away – converting local labels and lines of hex etc. I didn’t want to go through the extra pain of this with Shutdown and with Notepad++, I didn’t have to. It has a very useful facility where key-strokes can be recorded and played back over and over and I used this to convert each PDS file into something the assembler would recognise. That was a careful job done over a few evenings file by file as one
byte deleted by mistake could crash the entire game or add some oddities to the graphics that would be hard to find and fix.
Once that was done it was a matter of assembling, looking at the errors, fixing them and re-assembling until the errors stopped coming. Linking was a different matter. At this point I realised that the 2500 A.D. assembler does not like multiple ORGs (code origins in memory) in any one file. PDS would let you use many ORG directives in one file but the 2500 A.D. allows one per file, then uses a separate text file to link the blocks together into one final binary. That
meant I had to split the PDS files into separate entities starting wherever there was an ORG, which in the end gave me 14 different files.
Assembling these then gave me more errors and I discovered that the PDS assembler was much more forgiving if the end of one code block overran the start of another. The 2500 A.D. assembler would not entertain that, so I had to weed out the offending code which simply turned out to be extra trailing zeros in map or graphics data which I figured would be harmlessly overwritten when the PDS system originally downloaded the code.
More assembler errors. This time due to the way PDS handled labels. With PDS, everything was pretty much ‘global’ and as such any file could call and access anything in any other file. The 2500 A.D. assembler is much more strict and I had to go through and declare certain functions and variables PUBLIC and then add corresponding EXTERNs (references to external items) to each file that required them. That job seemed to take ages and I had to find out how to make the assembler output errors to a file as there were so many that they kept scrolling up off the screen. Finally and after setting the linker to output binary and not Intel HEX, I had one single code block ready to run.
At this point I had to start investigating the CBM64 to find out how to get the code deployed. It’s much easier to use an emulator and there are plenty of CBM64 ones about but I settled on WinVice as it had a simple monitor and debugger system which I thought may come in handy later. The task now was find out the easiest and quickest way to get a block of binary into a form that the emulator would accept.
Fortunately, I still have a CBM64 Programmer’s Reference Guide which would prove invaluable. With the guide and the net, it seemed that the best thing to do would be to create a disk file which is called a .PRG All I would need to do is prefix my binary with the address at which the code needs to reside. That was easy. Getting the .PRG file onto a virtual disk that WinVice would load was also easy, thanks to an old DOS app called 64COPY – which again had to be run using DOSBOX. 64COPY allows you to create virtual disks (.D64) and then copy pretty much anything onto them but I soon realised you can’t just load 50K of code starting from $0400, from BASIC. The CBM64 is much more complicated than that and has switchable ROMs containing the BASIC interpreter and I/O and Kernal etc. I’d have to write a stub, which when loaded and called from BASIC, would then load the main code having first switched the necessary RAM in and ROMs off.
I then spent some time with the ‘Reffy Guide’ and some old Clockwize CBM disk loader routines trying to reliably get blocks of test code loaded in, but without success. It was a few frustrating evenings before I realised what was going wrong. It turns out that the way 16 bit values are split into high and low bytes in PDS are opposite to most other assemblers I’ve used, including the 2500 A.D. PDS used < for the high byte and > for the low byte of a 16 bit value. So all my address values in the loader were the wrong way round. After fixing those I then had to go through the Shutdown source and swap the relevant < and > symbols in there too.
I added the fixed ‘loader’ routine into the Shutdown source in a free area of RAM (I couldn’t be bothered to do a fresh project for such a short thing) and therefore this block needed extracting to be turned into a separate .PRG file. I also cut the main binary into two separate chunks, either side of the loader. To do this, I used Hexplorer v2.6 which is very useful for selecting and saving chunks of binary, and even converting binary back to ASCII hex.
I finally had three files on a virtual disk – the loader and two code blocks and to my complete amazement, having typed
and after a long wait… (OK, after a bit I used ‘WARP’) the CBM version of Shutdown appeared for the first time in 26 years.
The graphics looked nearly right, there was a scrolling message (the game instructions) but it was all garbage and if you hit certain keys it bombed out, but it was progress! I set up the virtual joystick and the game started but I couldn’t get the character to move and there was some odd flickering going on.
The garbage message turned out to be another PDS to 2500 A.D. issue. CBM64 strings were defined in PDS using a CBM data type, e.g. CBM “Welcome to Shutdown” But this had to be changed to DB “Welcome to Shutdown” for the 2500 assembler. What I didn’t realise at the time was that the CBM64 doesn’t use standard ASCII and PDS’s CBM type did the ASCII to CBM character conversion for you! So I had to mess about and turn the ASCII back into CBM chars which I did with a noddy CBM BASIC program to flip some bits on each character of the text messages. The resulting data was then re-incorporated into the source and on the next test, the messages were readable.
The game ‘bombing out on a key press’ was simply the call to the PDS download/monitor code stub which was always present when using the system. That just needed disabling. This has now led me to believe that perhaps this code was not the actual final FINAL version as that sort of thing would have been removed before delivery to a customer.
The ‘character not moving’ issue turned out to be the 2500 assembler. By default, empty RAM between linked blocks of code was being filled with $FFs and not $00s. The map areas that the character should be able to walk through should have been $00s but that ’tile’ of the map was wrongly being set to $FFs thus making the collision detector think that you were trying to walk through scenery. This was fixed by getting the assembler to calculate the space from the end of one block of code to the start of another and then filling that amount with $00s. There may be an option in the 2500 A.D. linker to fill intervening space with 0s by default but I couldn’t find it! I knew I’d got it fixed when the character started walking around the map, complete with footstep noises!
Fixing the flickering and graphics corruption turned out to be more tricky. I started looking through the source for things I may have missed and spotted a call to an address (an interrupt exit routine) that resides in the kernal which I now knew was occupied by some of Shutdown’s code. I remembered that Craig mentioned that he used to use an ‘Expert Cartridge’ in his development. Of course I had no idea if or how this might affect things – did it alter the RAM/ROM layout perhaps? I didn’t want to spend more time researching Expert Catridges! Anyway, the 2500 A.D. assembler can output a map file which details the locations and lengths of each code block and using this I noticed that the code ORGd in the kernal area could simply be located in some free RAM elsewhere so I’d be able to leave the kernal paged in permanently. This worked and the flickering went away along with some other screen oddities.
Now there was just some graphics being corrupted, namely the red/white barrier visible on the very first screen when the game starts, together with other game tiles deeper down in the map. After a few fruitless nights trying to work this out (and after a holiday) I came to thinking that I needed a debugger – and it turned out that WinVice has one built into it. Using it, I noticed that when the game first started the graphics were fine but somewhere in the setup code, they were being mangled. Setting a breakpoint near the start of the game and then single stepping through the code soon found the issue. Games obviously need to be reset fully after you quit or fail and with Shutdown, the objects that you can carry and doors you can open etc. need placing back in their start positions. For Shutdown, these variables were being saved in a buffer for copying back later at reset. This buffer was hard coded to an address which was now occupied by the graphics I’d moved to avoid the kernal. So, I’d created this bug. Aggh!
Craig had actually been a bit cunning here as he’d used some self modifying code to swap the location of the source and destination of the reset data buffer so he didn’t have to write two routines – nice! All I had to do to fix this one was shift the reset buffer to an area of RAM that I was sure was empty.
The next build, saw the game complete and appear to be fully working.
So, was it worth the effort? Well, it’s not a particularly brilliant game and there does seem to be some quirks and bugs with the character’s collision detection and it is possible to get stuck in the map (at least there is a quit key!) which also leads me to think that maybe this was not the final release but… well…it’s near enough and it’s a piece of CBM64 history that’s worth saving.
Craig has suggested that a soundtrack would help the game and he may be right about that. Actually though, I like the footstep noises and the odd beeps that occur.
To sum up (for anyone who has read this far and not nodded off) I’m sure there must be better and quicker ways to resurrect an old title like this but it was satisfying to complete it without giving up and resorting to expert help! I have learned a lot about the CBM64 and having messed about with it again after all these years, appreciate it more as a high quality, flexible and powerful machine.
Should anyone feel the need to actually try and complete the game, the World Of Spectrum site has a complete map of the game. As a hint to get you started, you first need to ensure you can refill your air tank and you’ll need a key card to make the oxygen station work… good luck (you’ll need it, if only to not get stuck in the map!)
Thanks to Frank, for the occasional prodding and patience, Craig for reminding me of some of old daft things we used to get up to (“Lolly?”) and to Dave Bradley for the fun we had creating Shutdown in the first place all those years ago.