Reverse engineering an old DOS game (part 1 of N)
Vložit
- čas přidán 8. 07. 2024
- Tracing step by step the graphics mode initialization of an old DOS game.
- Get the Cutter IDE here: cutter.re/
- Get DOSBox here: www.dosbox.com/
0:00 Intro
10:20 Bootstrap
16:00 Entry point
23:50 Video card check
43:40 Video mode initialization
50:45 Modifying the palette selection - Věda a technologie
Thank you so much for this. Excellent video. I've been looking to peek into a few DOS real mode games (Interphase, PowerMonger) and this has been really informative, thank you!
41:00 You can tell it was written by someone who was a bit inexperienced. Testing for both lower case and upper case letters is a bit weird. Just whack bit 5 of the int16 return and you'll have a 'to_upper()' conversion. That's the whole point why lower and upper case characters are exactly 32 codes apart ('A' = 65 , 'a'=97)
I thoroughly enjoyed this video. I have learned so much from this. I have tried getting started with looking at old DOS-software I have from back in the days but haven't known how to get set up and to find good documentation. Fantastic content!
Thank you for the video. It helped me greatly in reverse engineering an old DOS application.
I remember this game from back in the day. We wouldn't care about the score - just keep spamming the fire button. As primitive as that is, it worked fairly well especially in the higher levels.
This is cool
The video subject is cool, but unfortunately, everything is small my eyesight can't see everything clearly.
Why didn't you zoom in during the recording?
Good remark! I've actually started adding some zooming in part 2. I'm learning video editing as I'm making this stuff, I hope to improve over time.
With a hex editor/viewer you can easily spot plain text and get an idea of a program's general layout. You should also check whether the binary uses some kind of compression. Possibly the weird way it jumps into the main code at the start is a rudimentary attempt at obfuscating the code.
This game can display the graphics on a secondary CGA if the primary display is MDA, it could be to try to make the computer restart in CGA mode because the user could have turned off the MDA monitor where the game asks if you have a CGA monitor when the computer boots in MDA mode, while the will start directly if the computer boots in CGA mode.
But I don't know if the PC would reuse the equipment settings stored in the BDA on warm reboots or if it would reset them according to the configuration switches.
I don't have an IBM PC and 86Box only allows to use MDA as the secondary display when using MDA and CGA
this game was on the ipod nano
Playing with the BIOS equipment list would have zero effect on a PC 5150. But perhaps one of the clones or later products might be affected by it. The value in 40:10 tells which video mode it boots up into, and is set by the DIP switches on the 5150. But on reboot it always loads the DIP switch values and replaces them in the BIOS area, so nothing is really affected.
When you're talking about a game made by a teenager, though, there may always be leftover cruft that does nothing, but doesn't harm anything and so is never removed. A thorough code review might have caught those odd items so that they could be removed.
Thanks a lot for your comment! Are you talking about the part in 44:00 where the color text mode 80x25 is written back to the bios area? It seems odd indeed because the game being a pc booter, there's no other way to exit but to reboot the computer anyway, and the code is entering graphics mode immediately after anyway.
I also assumed that this code having probably never been reviewed, it is likely to contain a few harmless mistakes.
@@fabricelete5337 Yes, the color text mode is what I was referring to. That value is written at BIOS initialization, so it has no real effect, at least on true IBM PC's, to change it.
it's been a long time since my assembly days but something odd about the code in 0x2c83? maybe there is a wrong disassembly in there because the je 0x2c8a makes no sense, why jump to itself, i have never seen that before. also if the execution jumps in 0x2c83, it can never leave eitherway. strange.
In this codepath, the game has detected that the computer wasn't running a compatible video card. So it prints an error message, and stop execution. This is the point at which it would normally return to the operating system. But Paratrooper was initially released as a PC booter game, where there was no operating system to return to. So it simply locks in place and the user has to reboot the machine.
Just feed the bytecode to GPT, and then ask to decompile, and then converting it to SDL2.