Hi guys,
I've set myself the task of reverse engineering a few old games. First on the list is Laser Squad. Woo hoo! :)
Anyway, I've got a decent grasp of Assembler but that doesn't mean I'm any good at it. What I'm after is either a hex dump or a conversion to Assembler of the core Laser Squad game plus the data from the mission files. Could someone either tell me how to do it or supply me with those files?
Pretty please?
Also, on a related note, how do I write labels in WinAPE Assembler? Adding a .name=&E020 throws an error claiming it's expecting an instruction.
Quote from: betpet on 12:16, 01 September 10
Hi guys,
I've set myself the task of reverse engineering a few old games. First on the list is Laser Squad. Woo hoo! :)
Anyway, I've got a decent grasp of Assembler but that doesn't mean I'm any good at it. What I'm after is either a hex dump or a conversion to Assembler of the core Laser Squad game plus the data from the mission files. Could someone either tell me how to do it or supply me with those files?
Pretty please?
Also, on a related note, how do I write labels in WinAPE Assembler? Adding a .name=&E020 throws an error claiming it's expecting an instruction.
.name equ &e020 is what you need.
Ok try this:
1. Run game and save a snapshot (old v2 style snapshot)
2. Run a tool like dz80 (www.inkland.org.uk)
3. In options set start to 0, set end to 65535, set file start to 0. set file hdr to 256.
4. go back and do dissassemble
5. Now open file and see mixed opcodes and dissassembly.
Now look over and you'll hopefully see bits you may recognise from other games or see bits and work out what they are doing.
You can also use winape or similar to find the main loop. Break the game and trace it for a bit until you find the main loop.
You can also use winape to find the interrupt handler.
So dissassembly plus running winape and setting breakpoints will help you to find out stuff.
Thanks! That's a great start. How should I go about getting the mission data files from the image?
Quote from: betpet on 12:35, 01 September 10
Thanks! That's a great start. How should I go about getting the mission data files from the image?
I would find where they are loaded into ram.
Then you can also find where the code is to load them.
When in ram, you can test your ideas by poking the memory directly within winape, so you can then discover the form and what the values mean.
Then you may be able to drop in your own data into winapes memory (assemble it into place after game has loaded).
If all works well, the final step would be to work out how it is loaded and encode your data into that form.
But, getting it running within the emu and in a form you understand is a massive part of it!
Thanks again. For anyone interested, here's the disassembled code from the instructions above. Now the hard part - working out what it does!
Bear in mind that a straight disassembly from 0 may not get you usable code, if there is data preceding (or intermingled) with code sections it'll throw the disassembler off. Sitting down with a disassembly from a single point is rarely the most productive way of reverse engineering code.
When doing this sort of thing, I generally prefer to start from identifying key locations in the program. A graphics viewer can often help you locate the sprites, which often eliminates large chunks of memory from needing to be disassembled, as does using a running copy in an emulator to identify where the screen is located and the location of the interrupt routines (easily determined from the interrupt mode and content of the I register).
It's then best to locate the entry point and start disassembly from there and do small bits at a time. Usually working on the startup code will help identify key data locations and it's often relatively easy to locate the main game loop. Using breakpoints and occasionally NOPing out calls to routines can also help I find.
What's the best way to find the entry point?
Quote from: betpet on 13:24, 01 September 10
What's the best way to find the entry point?
Maybe not the best but i'll post my method , which may look obvious , i used it for RD128+ and for R-Type.For me , the best way is the live approach with a debugger like the Winape one.You can first collect some informations about loader with entry point (amsdos header).You can too trace it a bit to see screen configuration , and some clues that will give you an idea about the memory layout.
One of the most interesting thing is to locate the program main loop and to see how the program goes to it.
You can put a breakpoint on ISP (#38 in IM1) and trace the stack to see where ISP will return.After that , trace a bit the stack to locate the main loop.Generaly ,you will find the return address to main loop near the stack base.
When , you'll have located the main loop , you can remove/modify some calls to have an idea if you have absolutely no idea about a function usage , sometimes that allows you to understand some code.
Same thing, when you know where is the main loop , you can trace from entry point to the main loop and will be to find initialization functions.
Woah! That sounds quite fiddly. I'll give it a go :)
Quote from: andycadley on 13:23, 01 September 10
Bear in mind that a straight disassembly from 0 may not get you usable code, if there is data preceding (or intermingled) with code sections it'll throw the disassembler off. Sitting down with a disassembly from a single point is rarely the most productive way of reverse engineering code.
This is true, the dissassembly will contain data that has been dissassembled as z80 instructions.
However, and maybe it is because I have looked at the code from quite a lot of games, I can normally look over the dissassembly and instantly recognise the sprite drawing code, the main loop, the interrupt routine, the music driver too.
The best method is to find the main loop and start to "rem" out the calls and see what they do (replacing cd xx xx with 0,0,0,0), although sometimes more than 1 call will do the whole job (e.g. sprites).
Mostly poking the game at runtime is good and poking the ram when you think you have found the map and seeing it change on the screen (or maybe after you have scrolled).
Quote from: betpet on 12:43, 01 September 10
Thanks again. For anyone interested, here's the disassembled code from the instructions above. Now the hard part - working out what it does!
Looking at the code it has some code left over from the Spectrum version.. this will confuse things a little.
(Some access to port &FE). But most of the code is probably for CPC.
57de is for writing to AY sound chip.
C = register, A = data
57fe is the level loader using direct access to fdc. ends at 5994 (data is written to IY)
There is code for reading and writing here./
12c8 seems to be code to read a key from the keyboard. A = key value
1314 or so reads from the keyboard.
1366 sets up the keyboard for reading I think, it wants to read joystick here it seems
it seems firmware interrupts are active at the point you made the snapshot.
Quote from: arnoldemu on 09:49, 02 September 10
1366 sets up the keyboard for reading I think, it wants to read joystick here it seems
it seems firmware interrupts are active at the point you made the snapshot.
The point I made the snapshot is where the game has loaded and asks whether you want it in French or English. Once you have selected your language, you can select a scenario and load it up.
Very interesting thread, even for us that haven't done any Z80 coding yet :D
Glad you're enjoying. It's a good exxercise for the learner even if it has a steep learning curve. A learned friend at Retro Remakes seems to think the entry point is at &B900. I haven't had a chance to check though.
Quote from: betpet on 08:13, 03 September 10
Glad you're enjoying. It's a good exxercise for the learner even if it has a steep learning curve. A learned friend at Retro Remakes seems to think the entry point is at &B900. I haven't had a chance to check though.
Are you working on a remake, or are you working on a scenario editor for the cpc version?
I am thinking that when the scenario is loaded it will also bring in some code, some specific to the scenario itself and some general (possibly for sprite drawing etc).
I was also wondering if the goal was for a mission editor? Laser squad was one of my favourite games back in the day, though I cant really stand playing it these days (because of the exceptionally poor accuracy of the soldiers).
It's a possibility. I was looking more in the lines of remaking the game in a modern system (using XNA and c#) but with the correct calculations for morale, action points, etc. My findings could certainly be used to create a mission editor at a future date.
A tip you may find useful. You can autoshot at short range but fire long range with decent accuracy. By this I mean that if you had an enemy a few squares away, instead of placing the spray angle on the enemy's head and feet, place a narrow angle next to your soldier and your accuracy will improve significantly as you're aiming close by but the shot keeps going until it hits something (i.e. the enemy)
WinAPE can disassemble a region of memory and provide labels and data sections. I reverse engineered the Frogger using this. You need to define the Data Areas, then select the block to disassemble in the disassembler window and right-click, Disassemble.
Quote from: Executioner on 13:06, 16 September 10
WinAPE can disassemble a region of memory and provide labels and data sections. I reverse engineered the Frogger using this. You need to define the Data Areas, then select the block to disassemble in the disassembler window and right-click, Disassemble.
I've just discovered this feature in WinAPE and must say it's fricking awesome :)
Oooh, how how how! :)
I'm afraid you'll have to tell me like I'm as stupid as I sound ;)
Quote from: betpet on 10:24, 23 September 10
Oooh, how how how! :)
In WinAPE, press the 'Pause' button to open the Debugger. Select the area of memory you want to disassemble:
Click on the start address once
Then hold shift and click on the end address
The selected area will now be shaded light blue. Now right click anywhere in the area and choose 'Disassemble', leave the default 'Output to New Assembler Tab' and press 'OK'.
Now go back to the main WinAPE window and click the 'Assembler' icon and you'll see the code in there all nicely formatted with tags etc. When you work out what a routine does, you can change the tag name and effectively reverse engineer the program.
Awesome! I have a lot of work ahead of me but this should speed things up. Thanks! :D
Quote from: betpet on 12:19, 29 September 10
Awesome! I have a lot of work ahead of me but this should speed things up. Thanks! :D
If you find any interesting routines in there, I'd definitely like to hear about them.
Will do. Don't expect anything particularly quick, I'm still new to all this Z80 stuff. :)
Quote from: arnoldemu on 09:31, 03 September 10
Are you working on a remake, or are you working on a scenario editor for the cpc version?
I am thinking that when the scenario is loaded it will also bring in some code, some specific to the scenario itself and some general (possibly for sprite drawing etc).
UP!(why not :) ). Yes is true, scenario file have the sprites, the map, lists of arms, texts, and the colours of the game.
I found for now:
The map is a matrix of 27x42 bytes. From the left corner to the right line a line. The hex number in the byte tell what are in the map, a wall a tree etc... 1byte=1 square ot the cursor.
It go from &845f to 93fe. Is equal for the seven scenary.
from there,it have a dictionary estyle key ascci code intermediate to found the direction of the sprites, that are all located next to this probably 953f to &bfff. it can be found exactly make a breakpoint in &06F3, HL stores the direction of the sprite to be printed in screen.
Down to &845f-6367 they have misterius stuff, but &63CD-63EA have the guns list for player 1 1 bye= 1 gun FF desactivated, other number is the price of the gun in hex.
&63EB,stores de gun list for player 2 same method as the other list..
&6442-6445,stores your initial money for each level.
The table between &63B8-63&cb is a mistery. activated the first four make one soldier dissapear of the list,but i can't add more activated the other :D.
03EE call &03BD controls the colors of the scenary :)
this is basically the ancestor of X-COM : ennemy unknown.
Completely 2D and a bit speccy ported.
they could have used better palettes to have more interesting variations in the colours, most palettes feel quite monocoloured on CPC.
Still graphic actually use the Amstrad Mode1 properly.
was it inspired by a CGA version ?
Does this game only use 64K ? as often this is quite the sort of game that may use 128k to get more extra contents or sprites variations.
A modern version could even stack even more RAM used I guess.
[attachimg=1]
good point is that the CPC version has a CPC sized screen... 320x200 and not the too often usual 256x192 Speccy thingy.
Was a nice alternative choice to Space Crusade I guess.
(http://www.mobygames.com/images/shots/l/1404-laser-squad-dos-screenshot-movement.gif)
ouch, no CGA/EGA version, VGA only...
(http://www.mobygames.com/images/shots/l/82766-laser-squad-commodore-64-screenshot-the-first-mission.png)
C64 version seems to basically be Spectrum graphics put on CPC/ST sized screen with C64 "non-colours".... quite less flashy than Speccy.
The little highlights of CPC sprites quite add some graphical deepth even if less colours.
What about rebelstar ?
rebelstar © firebird (1986) (http://www.cpc-power.com/index.php?page=detail&num=1773)
are those two games related ?
Also :
(http://www.lemonamiga.com/games/screenshots/full/laser_squad_02.png)
So... they copied both Daleks and Warhammer 40k's space marines...
(http://www.dakkadakka.com/s/i/at/at2/2010/4/29/9df0fdba8facaf2ec735eeb055c91bdb_15543.jpg)
Yes is 64k, the map in the spectrum version is more large that the amstrad version. I think they cut for memory issues. Problably the sprites in amstrad take more memory.
Amstrad have 27y X 42x, and spectrum have 49y X 79x
damm i want port the spectrums maps :(.
Not only rebelstar exist another game that drink of the two and early the good x-com.
lords of chaos © blade software (1990) (http://www.cpc-power.com/index.php?page=detail&num=1316)
I think laser squad is a evolution of rebelstar. But i thinks the first version developed is the spectrum.
May be quite interesting to compare both CPC and Speccy version of all those games.
They often had to both do ports and cut corners, and the R-type 128 project showed that it can be quite good AND interesting to also have a look at the Speccy version.
Speccy version would often feature more contents because all the graphics are less expensive in RAM and the screen RAM would also take a lot less space.
So you could often fit even more stuffs inside a speccy48 than in a CPC464.
Also perhaps more games would use the speccy128 specs instead of just plain 48k... while Amstrad games wouldn't even try at 128k.
speccy48 : perhaps 7k are used by screen... lets you about 40k
Graphics are somethings like 1bit per pixels.
CPC464 in 320x200x4 : screen uses 16k so it lets you with 48k... all graphic datas may weight twice if no trick is used...so 16k of graphics on speccy would become 32k on CPC... ouch.
But yeah according to world of spectrum, the game is 48k.
spectrum version may also have some level editor tools...
Laser Squad - World of Spectrum (http://www.worldofspectrum.org/infoseekid.cgi?id=0002813)
http://maps.speccy.cz/maps/LaserSquad.png (http://maps.speccy.cz/maps/LaserSquad.png)
ok after a quick check :
= font characters are in 1bit per pixels... so there are some conversion routines and colouring routines, may use the firmware perhaps...
= graphics are in non-compressed 2bpp aka true mode1, at least during game. This also means they could easily be modified
[attachimg=1]
according to CPCpowers, Rebelstar and Lords of chaos were done by same dude... found no info about the LaserSquad dude/coder (haven't searched a lot to be honnest).
and the game could really use some better palettes on CPC anyway...
as you can see on the exemple i posted, they use pastel red and pastel Magenta which are quite very close colours... you wouldn't get actually visible extra colours from the ditherings and miss some contrast.
O.k i made a error with the windows calculator. And I obtained wrong memory range in the spectrum
I have port the asasains 2 map sucefully from spectrum to the cpc only coping the matrix. So it share a lot of code with the cpc.
But in the screen in game that say is true, the speccy need more scrolls per line to go from one side to another of the screen a lot more.
Anyway how is supossely the hombrew levels work in spectrum, i can't play it in emulators the keyboard not respond wtf..
Mission Downloads | Laser Squad (http://www.laser-squad.co.uk/downloads/)
Is impossible the game use firmware calls, i have ported it to the gx4000 because they use a custom call with the disk. And he load the levels from 636d to c36d killing the firmware ram range, inclusive the low ram in 0000 is used by the game.
About the colours, we can change it easy as i know the call put it, whats the perfect combination?. :).
QuoteBut in the screen in game that say is true, the speccy need more scrolls per line to go from one side to another of the screen a lot more.
the CPC screen is larger so it displays more so you cover the map with less screens...
and yep, a lot of Z80 codes are somewhat the same because.. CPC and speccy can be qutie similar...
Perhaps a look at MSx version could also be fun.
For the "firmware" I was more thinking of some classic routines to convert the 1bpp fonts into somethings... a bit the way the basic could handle inks and letters from mode2 characters/letters into mode1 or 0...
For the colours... well... would need some mockup time.
Also may be even bester if some tiles can be modified as well.
So ok, mockup time... will see if I can do a few tries.
Basically the many palettes from Head Over Heels can be suitable for this sort of game...
I can port the speccy extra maps to the cpc +o- Some maps only change the maps. Other change the sprites in the spectrum,that the amstrad converted to the laser squad native sprites.(examplea a wall modified to normal wall or a un big tree in to three arbusts.
But the problem is the weapons i can view the russian guys change a pistol for example to a explosive. But i don't know how cpc knows is a explosive o a normal weapon. So explosive is in level 3 probably is in the game, but desactivated.
I can active a weapon in the list slot desactivated thats is empty.inclusive change the sprite associated to these slot, but not the weapon. its the only mistery to port the games perfect that resits me..
For example, This is a port of the spectrum level 20 return to moonbase. That not need modification, as he only change the map.
And the other is the 1 map called mafia,it lost the key sprite.(the cpc not have it, but the the text is o.k cpc reload it to "none" sprite ). some sprites in door open. I can add the droid of in the spectrum, but not the explosive.
In the example of mafia I activate all slots, you can buy a death body, but i want put a explosive jeje.
ok fast first try...
Basically I tried a bit to add some dithered zones with both medium colours.
Also switch to quite different colours (Dark Cyan and Orange) into a quite classic Mode1 palette.
Pastel yellow can be switched to white too I guess or kept that way.
Not a lot of edition, it is a first try.
[attachimg=1]
I should redo the sprite/tiles sheet because as it is it is not quite just, but still it can show some potential with less monocoloured palettes and some slight touches of "extra dithered hues" for a few surfaces/details.
It is to notice that this is the exact sort of game that could quite benefit from a PLUS version in order to have a "Switchblade" type of use for the Hardsprites.
Also to use a display with info-zone on the right of the screen quite prevents the use of some rasters as used in Space Crusade.
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=1999&slot=2&part=A&type=.png)
Not that it would add a huge lot, but basically a CPC can tap into quite more exotic or even larger resolutions provided you are in turn-based gameplay and can get some 128k RAM specs.
some 256x256 or 320x240 or 320x256 or even 360x256 sized display could be great despite heavy.
But this would then be more ambitious than a simple mod of existing engine.
Exist somewhere a app that can import the spectrum sprites to amstrad sprite format?.
Quote from: dragon on 20:57, 10 August 19
Exist somewhere a app that can import the spectrum sprites to amstrad sprite format?.
Take a look 'ere
https://github.com/tonyt73/AGD-Studio
and here
https://jonathan-cauldwell.itch.io/multi-platform-arcade-game-designer
Ran across this when looking for something else:
http://oldmachinery.blogspot.com/2016/02/multipaint-for-drawing-c64-zx-spectrum.html (http://oldmachinery.blogspot.com/2016/02/multipaint-for-drawing-c64-zx-spectrum.html)
I have now the general structure of the levels. I'm in the way of make a crappy generic level creator for each amstrad level.
A bunch of org xxx. That separate the zones. That when compiled generated the amstrad original levels files.
I'm not know what all table indices do, but at least the general structure.
Regions, nodes, arm peligrosity, patrol routes. Regions peligrosity etc...
If anything like the game and want help decoding all the options that permit the levels files is welcome.
Can be good if anything dominate the spectrum. To make a spectrum general structure and disect the differences with the amstrad to help to port the scenarios.
Wow! Unfortunately, my life took a turn in a different direction and this fell by the wayside for me. I'm amazed there's still interest in this despite it all happening for me over 10 years ago. I still have the code I wrote for some of the tools I used. I'd love to get back into this and I have the core of the engine I was planning on using in place. It's unfinished by a long way but it can process rules and allow the addition of many more quite easily.
I'd love to put this together in Unity and the code I have written is in C# so should just work in Unity as an added DLL.
I love some of the things you've done guys! Kudos!
Heh, indeed almost 10 years to the day, this must be the slowest-burning thread in here :D
I'll see you all in another 10 years. I'm looking forward to what you've produced ;)
Caught somewhere in time...
;D
Quote from: Gryzor on 14:03, 14 July 20
Heh, indeed almost 10 years to the day, this must be the slowest-burning thread in here :D
Rats, so this is older than Silly Programming Ideas....
Time to talk to another Doctor, Who will listen to my problems! :D
Quote from: betpet on 14:05, 14 July 20
I'll see you all in another 10 years. I'm looking forward to what you've produced ;)
Get started, Steve ... you have until Monday to finish it :P
Too bad that the disassembly didn't progress further. I would've loved to use that as basis for a Spectrum Next version ;)
Interesting thread. :)
I've been reverse engineering Laser Squad too. I've been using CPC Analyser, which is helping quite a bit. I'll try to make my disassembly public at some point.
There is a very short video of me starting to reverse engineer it here. Hopefully it should give an idea of how the tool can help facilitate the reverse engineering process.
Laser Squad starts 6 mins in.
(https://media3.giphy.com/media/NrF0O24dP5NuYund2x/200w.gif?cid=6c09b9528yez2ho92m6hrufiigbslr6egbfwyazub8l5px5o&ep=v1_videos_search&rid=200w.gif&ct=v)
I love how this game is nearly 40 years old and we are still showing it love! I really need to pull my finger out and get back to some of this!
Quote from: crabfists on 13:04, 02 August 23Interesting thread. :)
I've been reverse engineering Laser Squad too. I've been using CPC Analyser, which is helping quite a bit. I'll try to make my disassembly public at some point.
There is a very short video of me starting to reverse engineer it here. Hopefully it should give an idea of how the tool can help facilitate the reverse engineering process.
Laser Squad starts 6 mins in.
Hi crubs that is yours?.
https://github.com/Colourclash/LaserSquad