Video

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!

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

Around 3:30 he mentions if you XOR an old value against a new value, you get the bits that changed.. and it's true: 00 -> 00 = 00; Masked: 0 00 -> 01 = 01; Masked: 0 00 -> 10 = 10; Masked: 1 00 -> 11 = 11; Masked: 1 01 -> 00 = 01; Masked: 0 01 -> 01 = 00; Masked: 0 01 -> 10 = 11; Masked: 1 01 -> 11 = 10; Masked: 1 10 -> 00 = 10; Masked: 1 10 -> 01 = 11; Masked: 1 10 -> 10 = 00; Masked: 0 10 -> 11 = 01; Masked: 0 11 -> 00 = 11; Masked: 1 11 -> 01 = 10; Masked: 1 11 -> 10 = 01; Masked: 0 11 -> 11 = 00; Masked: 0 In the video's example some of the bits were masked. Since it's a timer, as the number increments you could ignore the first x amount of seconds by masking off the first few bits. In my example above, if you used a bitmask of 01 and XOR that (TEST would use a bitmask of 10 instead), it'll take just the leftmost bit. It's a really efficient way of making a simple wait/timer in this case I think, although it may not be high precision depending on CPU speed and other variables. The other disadvantage is the CPU won't do anything else during the loop in this naive case. If you see any mistakes in my comment please let me know.

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.

Oh man, I really hope you continue this series. This is fantastic content.

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!

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)

this game was on the ipod nano

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.

Great videos! I'm also looking into reverse engineering an old dos game, it's in a NE executable, but I've still found your videos very informative. Are you planning on porting this game to a modern platform? Looking forward to the next one!

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.

Just feed the bytecode to GPT, and then ask to decompile, and then converting it to SDL2.

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?

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.

Great videos. I hope you'll make some more. There have been some interesting coding practices in this game, and I see a couple of optimisations that could be made - if they really mattered for performance, but I suspect not. E.g. in this first video when checking for yes/no replies, a small optimisation that could have been made is to take the character code, OR it with 32, and then you only need to test against the lower case character, since an upper case character would then have been converted to lower case. And in this second video when creating the delay loop I don't really see the need to do much more than AND the timer value with 0x3 and see if that results in zero before continuing. It seems a bit convoluted to XOR against the previous value looking for changes in the upper bits.

This is cool