DOS game “F-15 Strike Eagle II” reverse engineering/reconstruction war stories
neuviemeporte.github.io
neuviemeporte.github.io
The combination of janky PC hardware, paper-thin MS-DOS operating system and prehistoric development tooling makes for an environment where anything goes. Real mode segmented memory and large memory models utterly confuse Ghidra's analyzers and decompiler, most common modern reverse-engineering tools either do not support 16-bit MS-DOS executables or have third-rate support.
It is more art than science in a way that I don't think reverse-engineering later software can match.
Also, even if the program as a whole required more than 64KB of data, if you knew you required no more than 64KB of data for objects of type X, then you could use 2 byte pointers for all type X objects, with a fixed data segment. X here might, for example, be strings.
When you only have 256KB of RAM to begin with, the odds that all data overall, or at least all X object data for some X, will fit in 64KB is quite high. And if you have a lot of pointers, halving their size makes a big difference when you have so little memory.
Whereas 8086 is a 16-bit architecture with an extended address space.
The use of segmentation to enable a 16-bit architecture to address more than 64K was not original to the 8086, many 16-bit minicomputers (e.g. the PDP-11) used the same basic idea, although the specific implementation Intel chose was rather unique
Part of why the 8086 was 16-bit not 32-bit, was to make it easier to port software to it from the 8080, which was an 8-bit architecture with 16-bit addressing. It also was likely one of the reasons why the 8086/8088 was cheaper than the 68K, which is part of why IBM chose it over the 68K for the IBM PC
Under DOS, the (primary/initial) code segment acts as the PID. So overlapping segments enabled less memory fragmentation and more memory for child processes. If your program used less than 64 KB, then the part of 64KB it didn't use could be made available to child processes to use. Important in the early days, where some programs were structured as a main executable (which displayed the main menu), and then separate child executables for each menu item–the main menu executable would stay in memory while the child executable ran. (Overlays were more efficient, but also more complex for the developer.)
People call DOS a "single-tasking" operating system, but that wasn't entirely true – processes could spawn child processes, it is just the main thread of the parent process was suspended while the child process ran, unless the child process turned into a TSR. Also, child processes could use interrupts–or even just CALL FAR (if you could get the target address somehow)–to make upcalls to APIs exported by their ancestors, which is a way ancestor processes could be reinvoked even while suspended. COMMAND.COM's INT 0x2E API is an example (something I wish Unix shells had–a child process can modify the parent shell's environment, by calling an API to make it run a built-in command).
Not standard terminology, but personally I think it should be called "semi-multitasking". CP/M-80, by contrast, was a truly single-tasking operating system – only one process could fit in memory at a time, and instead of TSRs which were just normal processes which had returned to their parent without being removed from memory, you had RSXs which were a radically different type of thing from a normal program. (Normal programs are allocated at the bottom of memory, RSXs from the top down.)
(Did CP/M-86, CP/M-68K, CP/M-8000, get closer to MS-DOS in this regard than CP/M-80 did? Obviously MP/M went further than mainstream MS-DOS ever did.)
With a single flat address space, programs need to be either position independent (not possible at all on 8080), load at a fixed address, or include some type of relocation info. The DDT debugger in CP/M started with a "loader" which moved the rest of the code to the top of memory, aligned to a 256 byte "page" boundary. There was a bitmap of which bytes of the code referred to a page number (i.e. the high byte of an address), so those could be fixed up. With MP/M, every program had to be in such a format, minus the loader, which became part of the operating system.
x86 memory segmentation is sort of a middle ground between that, and virtual address spaces for each process. No security of course, but at least some degree of isolation in case of bugs, and the convenience of having fixed addresses within each segment.
Did CP/M-86 support child processes though?
Also, did CP/M-86 support TSRs? I thought it supported RSXs which just like CP/M-80 were in a different format and manipulated by different APIs than normal programs, whereas under DOS any program can turn itself into a TSR at any time, you can't tell when you start it whether it is going to turn itself into one (unless you know what its code does, of course)
Looking at https://www.seasip.info/Cpm/bdos.html#144 I see BDOS function 144 (P_CREATE), for creating subprocesses, was implemented on MP/M and Concurrent CP/M – but I don't see any mention of it being implemented on (non-Concurrent) CP/M-86.
CP/M-86 1.1 (but not 1.0) supported BDOS function 47 (P_CHAIN), for launching a new program – but like exec() on Unix, or the BASIC CHAIN statement, it terminated its caller before launching the new program.
That said, PC-DOS/MS-DOS 1.x didn't really support subprocesses either. There was no documented API for creating them. The program loader was actually in COMMAND.COM, and while it called the DOS kernel to allocate memory for a new process (the undocumented API INT 0x21,0x26), COMMAND.COM was responsible for actually loading the .COM or .EXE from disk into the process' memory (including relocating .ees), so creating a child process required duplicating a large part of COMMAND.COM's code. In DOS 2.x, the image loader was moved into the DOS kernel, and a public API to spawn a child process (INT 0x21,0x4B) was added. COMMAND.COM also implemented its own API to start a child process (which would be a child of itself not the caller), INT 0x2E, but I don't believe that was there in DOS 1.x either.
> With MP/M, every program had to be in such a format, minus the loader, which became part of the operating system.
You are talking here about the CMD executable format?
MP/M used PRL files: https://www.seasip.info/Cpm/prl.html
From my own review of https://bitsavers.org/pdf/digitalResearch/cpm-86/CPM-86_Syst... – the section on CHAIN (PDF page 160) says CHAIN frees the memory of its caller, which isn't consistent with returning to it after execution is complete.
However, it also describes (PDF page 60) function 59 (PROGRAM LOAD), which can be used to load a child process. Like DOS 1.x, spawning a child process is somewhat of a manual process, you apparently have to use function 59 to load the CMD file, functions 51 and 52 to set the default DMA base and offset (which CCP normally does for you), and then manually do a far jump to the start of the program. At least, unlike DOS 1.x, the image loader is in the BDOS kernel not CCP.
But, this is not unique to 8086 CPU architecture, this function is also implemented by CP/M-68K–which (I believe) relocates all executables as it loads them – see PDF page 106 of http://www.bitsavers.org/pdf/digitalResearch/cpm-68k/CPM-68K... - (it is also implemented by CP/M-80 3.x, but there it can only load RSXs not standard executables.) And I believe CP/M-8000 implements it too
> And BDOS function 0 with DL=1 will exit while keeping the program resident in memory.
Yes, you are right, I wasn't aware of that. Now I read more about this, my impression is RSXs are CP/M-80 only, and CP/M-86, CP/M-68K and CP/M-8000 use TSRs instead.
With 256 byte paragraphs, you would have been able to address 16MB instead of 1MB in real mode.
But then they repeated the same mistake with the 286, again!
As I pointed out in my other comment, the full 64KB would have made it harder to support child processes under DOS.
Suppose I have 300KB of free conventional memory, and run an 8KB program (something like a menu program, for example.) If it starts a child process, that child process has about 292KB of free conventional memory to use. With your idea, it could only have 236KB, because even though the parent process only needs 8KB of memory, it would consume a whole 64KB.
I don't know the first thing about 3D programming. I tried to follow a book on writing a ray-tracer from scratch just to see if I could pick up the principles and do it myself, but I got frustrated by the ambiguity of the approach. Like I was trying to use Ruby with Rspec, but I'm not even sure if I'd run into a performance issue or not be implementing the interfaces correctly.
I just want to know what method was used. Maybe 3D projection?
https://en.wikipedia.org/wiki/3D_projection
Microprose had 3D flight simulators going back to 1984 on Atari 400/800, Commodore 64, and IBM PC. That's really impressive.
https://en.wikipedia.org/wiki/Hellcat_Ace
Kind of like how Myst was able to deliver ultra-high resolution 3D images in a video game in ways that had never been done before, even though it was really just a point-and-click slideshow with embedded videos and scripted interactions (Hypercard)... Hellcat Ace provided an experience far ahead of its time.
Speaking of those machines, I'd love to see someone deeply reverse engineer the pseudo-voxel/fractal landscape engine that Lucasfilm Games invented for Rescue on Fractalus, Koronis Rift, etc. It still seems completely magical that they could pull that off on a machine with those specs.
Starting from zero, you might start at a high level and work your way down. Do a simple polygon flight engine using OpenGL and your favorite high level language of choice. Then write your own polygon rasterizer that you can overlay versus the OpenGL rendering as a reference. Then maybe rework it in pseudo 8-bit code (C constrained to only unsigned char variables, or similar), which should translate directly to assembly language on the target of choice. On a real 8-bit machine, unless you want low single digit frame rates, you probably have to pull a lot of dirty tricks. Maybe a 16-bit platform would be a better choice. This is speculative - I learned 3D (to a novice degree..) on a 486 PC under 16-bit DOS using C and assembly for inner loops (bitblts, texture mapping).
There's something about the aesthetic of late 80s PC flight sims (F-19 Stealth Fighter, LHX Attack Chopper, etc.) and their flat shaded polygon graphics that feels in vogue right now. Check out Thunder Helix on Steam.
Anyway there's definitely a magical feeling writing graphics code when you get your first feeling of realistic movement and rotation in 3D space working. Hopefully the ubiquity of ultra-realistic doesn't diminish that sensation too much.
F-15 is not pseudo-3d at all.
Flight simulators were early innovators in proper polygon based graphics. Partly because there were so few polygons they could get away with the painters algorithm. Partly because the instrument panel could cover a large chunk of the screen. But mostly because players of flight sims were willing to put up with very low frame rates, even 1 frame-per-second would be considered playable for certain types of flights.
Anyway, the tricks used for the 8 bit computers and consoles were nothing more than distilling down the graphical complexity until all they really had to draw was a tilting horizon line and then use a few sprites for everything else.
The one notable pseudo-3d technique I'll point out is the voxel based terrain used by "Comanche: Maximum Overkill". That's well documented.
There are lots of interesting pages about this. Here's a contemporary one that comes to mind: https://www.modeemi.fi/drdoom/3dica/3dica.htm
An easy way to get your pixel color array on screen is SDL2: https://www.libsdl.org/
https://pikuma.com/courses/learn-3d-computer-graphics-progra...
As a pro game dev in my past life, I promise you can get a 3D engine up and running from scratch in relatively few lines of code. Especially something like a wireframe cube that you can rotate.
They weren't the only one though. Sublogic also had Flight Simulator II for those platforms. Which wasn't really combat focused (except for the sopwith camel minigame with the checkerboard and the cardboard mountains - lol). But it was also really impressive on such constrained platforms. Ok, it did about 1 frame per second and only rendered in wireframe on the Atari, but you could tune VOR and ADF radios, set weather etc. It was really impressive for an 8bit machine with 64kbyte.
Sublogic later licensed their product to Microsoft to port it to PC which became Microsoft Flight Simulator. And the rest is history :)
It was a bit weird because on the much more capable Amiga there was a flightsim game that wasn't even able to draw a tilted horizon if the gradient function was turned on. I forget which game it was, I think it might have been F-29 retaliator.
Standard techniques of the time; project the 3D to 2D, cull backwards facing polygons, "painter's algorithm" (draw deepest first, in this case by object rather than by individual polygon).
> I tried to follow a book on writing a ray-tracer from scratch
The hardware of the time would ray-trace at multiple hours per frame. See https://github.com/POV-Ray/povray
There's also various article series in the flipcode archives: https://flipcode.com/archives/articles.shtml
You can also find the source code on archive.org if you don't feel like typing everything.
I was a child so it took me a long time to learn to actually do what the game wanted, and then learn after taking out the targets you got more medals by then bombing or strafing other targets. I don't think I ever got the hang of landing back on the aircraft carrier though.
There would be a section on the gameplay itself and then usually some historical reference about the setting of the game. E.g. if it was a WW1 flight combat simulator, there would be a section on the history of aerial dogfighting and then specs on each plane.
I know that nowadays it's common knowledge that most people don't read the manuals and it's easier to get people into a game with a combination first level /introduction/tutorial. That being said, I feel like we lost something by taking out the manuals with all that rich historical detail.
It really added so much to the game. Many other games came with cool things in the box too, like Wing Commander with the blueprints of each fighter.
I guess part of the reason was that the games themselves weren't all that immersive. There were no cutscenes or long narrative. The tech simply wasn't there yet. The included box items made it more interesting and immersive.
I had a pirated copy. Back then, nobody own legit games in my country. It was hilarious that the copy protection gave you a top down view of an aircraft and made you look up the name in the manual.
Yeah... for me, an aircraft-obsessed teenager who knew all the shapes, this was the same as no copy protection at all :) If anything, it trained me in recognizing the shapes of all aircraft of that era!
PS: I was sad when I learned the F-19 was never a real thing. That said, sometime later MicroProse came up with the F-117, which we know was a real thing.
I used to get around 1h of Internet time (modem) per week. I used this to download stuff that I could use for the rest of the week.
One time I started downloading a game, but a bit too late so I never got to finish the download before my time was up. Of course the game would not work as it was only partially downloaded (IIRC it was a zip file, but not 100% sure). There was some message from Windows telling me that there was something wrong with the exe. But I continued trying to open the game over and over again (maybe fiddled with the properties?) and one day it magically started, ran for a while and then crashed. It was possible to restart it, but it would crash at the same point every time.
It's still a mystery how it was possible, I guess it only had "content" left and the exe itself was fine, but that doesn't really explain why Windows initially refused to start it.
There's actually a small group working on it, and more details here: https://forum.stunts.hu/index.php?board=90.0
Disclosure: I manage the forum where the discussion is happening, I'll need up my SEO if the author could not find it :P
0: https://www.wiki.ultimacodex.com/wiki/Voodoo_Memory_Manager
PS. Hey that's cool you're in Sydney. If you want a drink tomorrow night drop by https://www.meetup.com/turingcircle/events/299581949/ at least a couple of us are going.
if you tried to look at the disk in dos or windows, it would report unformatted.
took a lot of convincing my neighbor's dad that the disk really worked, but only as a boot disk, because windows 3.1 would report it needed to be formatted
Good articles, I agree that there isn't enough technical articles about reverse engineering like this, it's an interesting hobby.
read from bottom up
For people who want to start at the beginning: https://neuviemeporte.github.io/f15-se2/2022/06/05/origins.h...
The most recent article in the sequence is interesting own its own: https://neuviemeporte.github.io/f15-se2/2024/05/05/ghidra.ht....
I did play the later Janes F-15E sim - much more complicated/harder than the Microprose ones were. Not sure it was more fun though, lots more study needed and probably needed proper stick and pedals etc to get much out of it.
There's a name I've not heard in a long time. I loved that game so much, the engine and gameplay was ahead of its time (or felt that way). It was sad to see NovaLogic fall behind in the years that followed.
https://www.goodreads.com/book/show/50489373-sid-meier-s-mem...
What I liked about LHX was that it was pretty versatile with its cameras and modes. You could focus the camera on enemy tanks etc.
It was very bad at actual helicopter combat though. The terrain was all flat and there was no scenery to hide in, no hills to sneak behind, no trees. The only objects were enemy tanks, camps etc. Later another game came out with a weird kind of voxel graphics, Comanche, that fixed all that.
By the time I upgraded to a Pentium (on the weird cpu board) the game was already old news.
Yes, the game you're thinking of is likely "Chuck Yeager's Air Combat," developed by Electronic Arts and released in 1991. It was one of the first flight simulation games to support multiplayer dogfights over a null modem cable. Players could connect two PCs directly via a null modem cable and engage in aerial combat against each other. The game was quite popular for its time and is fondly remembered by many flight simulation enthusiasts.Solid lead though, thanks.
[1] https://news.ycombinator.com/item?id=24099035