 |
 |
 |
|
|
|
 |
 |
 |
THE PC CONVERSION |
||
 |
 Why?During 1990/1991 I went through a sudden bout of ZX Spectrum nostalgia. Having owned a Spectrum since '84 and it being my first computer, I was missing it a little. I dug out my Spectrum 128k but then decided to buy a Spectrum +3, well what the hell! I did a little bit of programming on it, wrote a few game routines, sprite routines etc. I started converting a lot of the games to disk, some of which required a little bit of hacking on my behalf. Anyway, back in the 80's I used to do a lot of hacking and got a lot of pokes etc. published in various magazines. I have always been interesting in the inner workings of games and I pride myself on being a very good reverse engineer. Lords of Midnight was always one of my favourite games and so I decided to reverse engineer it; just out of curiosity. |
| The
development The +3 is not the ideal environment for such as task so I brought in the help of my trusty PC. I linked my +3 and PC through the PC parallel port and the +3 RS232 port which I bought a special cable for. I used Hisoft Devpac to print a disassembly of the newly hacked binary files to what it thought was a printer, and my PC captured the info and wrote it to a file. The next stage was to clean up the file into an editable and readable form. I've now got a 10000 line z80 assembler file, complete with un-disassembled parts that need hand disassembling, on my PC that means diddly squat. I spent the next two weeks working out what the program was doing. I put in meaningful routine names, added comments, gave memory addresses variable names, added equates, formatted data into ASCII, inline data and bin files. By the time I had finished I had a fully compilable z80 file that would probably compare favourably to Mike Singleton's original! This was the biggest reverse engineer I had ever done, I even fixed a few bugs! Not only did I know how the program functioned but I had managed to create fully documented source code. Not bad from a Spectrum Binary File. |
| The
conversion It was only at this point that I became interested in actually converting this code to work on a PC. I started thinking about doing a rewrite and then finally came up with a simple solution. A work colleague and myself set about writing a program that would do a literal z80-8086 conversion. It works on a similar concept to emulators the difference being in that an emulator has to do real time conversion, our program would do a one off conversion. This actually has its own problems. Emulators can have the luxury of having routines for commands, we wanted a straight z80/8086 opcode swap. The code had to look the same even though the mnemonics were different; we had to match up mnemonics and registers across different processors. We wrote the program over a couple of days and did the conversion, then spent the next few days ironing out certain translation problems. After about a week we had a fully functioning conversion program and so did the conversion again. |
| The
graphics The next problem was the display; I could convert all the graphics and GFX routines to be PC specific but that would probably add another few weeks onto the conversion. By this stage I had already decided that should the conversion work then I might do a complete ground up rewrite possibly to work under windows, so I didn't want to spend too much time with the graphics. The final decision was to again work like an emulator. I allow the program to still write to what it thinks is a spectrum screen. The programs are compiled to allow a memory region between 16384 and 23296 in the data segment. The game writes directly to this as normal; no need to change any calculations etc. I wrote a routine to interpret this memory and then write to a VGA screen. After all the major drawing routines I then make a call to this routine and the screen is displayed. It isn't the quickest method but it was time saving. If your machine has a decent graphics card then the transfer is done in well under a frame and so the update is flicker free but slower graphics cards might show a slight affect like a blind being closed - but it doesn't detract. |
| The
new platform The program was now semi up and running on a new platform. All was left to do was to iron out certain hardware dependent routines. A few internal routines for random numbers, keyboard etc. New save and load routines and a new printer dump option - espson compatible printers are supported. A little bit here and there and the game was finished from start to finish in under a month. Not bad - Doomdark's Revenge only took two weeks after that!!!!! I sat back and played the game to make sure it worked. Oh, and added a feature for the character selection - something that tells you that a character is dead or can't move. |
| The
end result The game is faster. It's still about 48k! The panoramic views are brilliant. Movement is a smooth glide. Night processing is almost instant. The game could have been faster again should I have chosen to optimise it, but I was only doing a conversion... a rewrite was yet to come! The conversion is so faithful to the original that if you could transfer a Spectrum save game file, you could probably use it - apart from a small header at the front of my save game files. |
| The
future I would still like to write a Windows version with many new features that would enhance the gameplay. The code for Doomdark's Revenge almost lends itself to being changed into a two player network game! |
|
|
|
 |