thunderchero wrote: ↑Tue Sep 05, 2023 6:13 pm
instruction 5CD521F matches but I can't find matching code in mpr565.dll
lol, at first I missed the middle 5 and wondered why that routine is written to .bss section, but no, the address is 7 letters.
Other than trek.exe, dll files like mpr565 are getting relocated on load. With it by the relocation table all code references are getting mapped to new location. If doing a hex value search, only search for the code instructions, not for the data references or jump addresses.
5CD521F matches loc_1001521F this case.
When paused, you can find the loaded dlls in segments view and in debugger modules view.
When you right click a dll in the moduls view, you can instruct IDA to analyse the loaded module code. Alternatively type 'c' on some hex code that you identify as code.
When you debug trek.exe with unmodified working palettes, you can pause it before combat, load the mpr565.dll module, search the code location of interest, set a breakpoint, and then continue to see when it is getting called and follow instructions to figure the call stack.
There is also a debugger option for tracing the call stack, but that never worked out for me, specially when analysing errors.
E.g. set a breapoint to the return instruction of said routine, then step by instruction or 'run until execution returns from the current function' to see what it has been called by.
For convenience, I usually enable the "Debugger commands" toolbar you can find in View->Toolbars tab.
That way you will find, that in normal execution it is called by:
mpr565_10015610, which is called by
mpr565_1000999C, ...
mpr565_10002E43
mpr565_100156E5
mpr565_10001522
mpr565_1001A271
mpr565_10015EAD (engMessage)
mpr97_1000290F (MPRMessage case 2)
trek_53AE8B (MPRMessage_context_buffer)
trek_53AE0E (call_MPRMessage_context_buffer)
trek_511758 (cc_MPRMessage_context_buffer)
trek_402484 (c_call_Time_render_object)
-> which finally is a method that tells about what it's actally doing here that fails.
From the read it looks like it is aquiring some MPR buffer context to swap the render buffer.
trek_4740CD (Tactical_Combat_Commands_AI_Automatic)
then it starts to loop and render, at least 1-2 seconds
followed by same call sequence one more time
from there you can proceed to investigate code execution by setting some additional breakpoints
or you can search Falcon code, whether you find something of interest regarding the MPRMessage context buffer