I remember being told once that TESA was actually written in C. Based on the popularity at the time, sure. That's believable enough. But now that I've done enough research and deconstruction to know better, I'm %90 certain that TESA was written in assembly. Why? Because not a single C decompiler will produce C pseudocode from the binary. I actually thought maybe something was getting lost in translation. The cleanest decomp came in the form of Boomerang. I was expecting to get the same kind of converted C pseudocode that I got from IDA. Instead, I wound up with a C-looking pile of assembly language. It's always assembly language.
So, I said "fuck it" to the C decompiler space and I went hunting for a DOS disassembly tool. I figure the lack of support for 16-bit instructions would probably make it hard for any modern PC to correctly disassemble. With modern software removed from the equation, there's really only one available option that I could think of. A badass obscure DOS program called SOURCER.
If you've ever gone hunting for a tool to disassemble DOS EXE files, then you've probably been pointed to the same few tools without ever having much luck. Use IDA or Ghidra or something. With those, you can spend hundreds of hours looking through butchered 16-bit assembly and it'll never be accurate enough to be reassembled. Not because those programs are bad, but because our modern CPUs don't have 16-bit instructions. That makes the output much less accurate and unbuildable. That's where SOURCER comes in.
SOURCER has to run in dos, so to use it in the modern age we have to run it in DOSBox. But DOSBox classic is complete shit in that it's insanely accurate to only one kind of machine. So I wanted to use DOSBox X but there's still another big problem with that. DOSBox X has partial-speed processors. We want to have the speed of a Pentium60, but the weirdos who developed this fork think those only ran at 31545 cycles. That's so far off that it's actually idiotic.
Think about it for a second. Think about the DOSBox X cycle rates. Why the fuck would a 486 EVER have a higher cycle rate than a Pentium? Oh yeah! It WOULDN'T. That's really fucking stupid. There isn't any single circumstance where this would ever be true. The Pentium60 was the first superscalar processor that could handle two instructions at once. It ran at an effective speed of 100 million instructions per second. The i486 ran at 11 million instructions per second at maximum. But for some reason, the loonies who develop DOSBox X think the 486 should have a faster cycle rate than a chip with a physical 10x performance difference. Insanity. This lie is so well accepted that Bing AI actually used DOSBox X as a reference when I asked what the Pentium 60 cycle rate was. But the math doesn't math. The numbers don't line up. The cycle rate for a Pentium 60 should be 5,900,00 to 6,100,000.
REMEMBER: The DOSBox Cycle Rate isn't measured in mHz (despite the DBX devs putting mHz in the dropdown.) The DOSBox Cycle rate is measured in MIPS. Don't believe me? Well, the official DOSBox wiki dives pretty deep into how the CPU emulation works, and DBX doesn't actually change that to my knowledge. Honestly, I think all DBX actually does is add a bunch of menu options to change the config that already existed. I can't really find any concrete proof that setting the cpu or memory in any particular way makes any real difference. So all I can assume is that DBX is a load of bullshit designed to *look* like an expanded version of DOSBox. Golf claps, because the UI is different enough to be deceiving.
So there really is only one option for me. I just need to fork DOSBox myself and do it right. At least the dev who invented DOSBox understood the 386 enough to emulate it. Even the Pentium_slow option isn't a bad representation of a P60, despite not allowing for any expanded conventional memory. Really, that's the killer here. I don't just want the speed of a P60 because I can do that in regular DOSBox. But something I can't do in regular DOSBox is give that P60 the correct amount of memory that it needs to operate. It feeds on the requirements of the 386 emulation, and that pretty much kills its usability. You can use it for a game like TESA and it'll run perfectly, but that's because TESA actually runs slow when it runs too fast, and it runs too fast on a full-speed pentium. Since it's impossible to operate the p60 variant at full speed, TESA runs under the conditions that it asks for.
(Wait, why am I doing this again? My performance fix was perfect. it works. The game runs at a solid 27fps and I super-optimized the TSR loading chain. Adding Causeway is just a redundancy, and trying to make it run faster is physically impossible. Well, the speed isn't really the factor that's pushing me. I want to fix the extreme memory bugs. I want to fix the hella limited color palette. I want to fix the entire Summerset Isle because it's unplayably broken.)
All of that said, I did use SOURCER with default DOSBox to make sure that it actually worked. It definitely works, and there are a good selection of target assemblers to change the syntax for the disassembly. The problem is that TESA is a 286 game ported to Pentium so the 386 cpu instruction set isn't exactly identical. It's good, it looks complete. But I don't want to spend the time cleaning it up for reassembly just to discover that the order in which instructions happen changes or something. I would rather do that after I've disassembled it in the most possibly accurate environment.