@domb84 Can you confirm you have a work serial port? This is 95% needed for everything that happens after. Mac84 has a excellent breakdown on adding the serial port (
https://docs.google.com/document/d/1htmhRHyY_kEjoiTgSInV0PeXvzyXTMaXDYJ_3Ai4A4A/edit?tab=t.0 ). On the Reels serial port you will get out output as debug statements:
No stock firmware I see this:
Info->sieCropHini = 762 Info->sieCropVini = 492 !!!!!!!!!!!!
That looks interesting, when I zoom-in these values go up (these are the coordinates for the top left corner.) So I use a good hexeditor, like HxD (free) or 010 Editor (way better as it has MIPS disassembler), and search on "sieCropHini" . At address 0xdbe478 in the firmware I find this string:
Info->sieCropHini = %d Info->sieCropVini = %d !!!!!!!!!!!!
So this is passed at a formatted output like printf() or sprintf(), with input values of x and y.
So we need to find where is referenced in 0xdbe390 in the code.
The compiler used for these old processors seems to always use the register 'a0' for the first parameter in a called function. So a call like printf(a0, a1, a2 ...), the string address (0xdbe390) is likely loaded into a0. MIPS is a old 32-bit CPU, so it can only load 16-bit into a register with a single instruction. So 0x00db is loaded separately to 0xe390.
BTW: I knew nothing about MIPS, I had to learn all of this while hacking. This is ghridra was a bit helpful, as a learning tool to explain MIPS to me, but also I used a lot of ChatGPT.
The compiler could load 0x00db like
lui $a0, 0x00db <- Load upper immediate
but in this case it did this
lui $a0, 0x00dc <- Load upper immediate
This seems weird, the default compiler behavior to use the add function for the second part.
addiu $a0, 0xe390 <- As 0xe000 has the top bit set (0x8000) is treated a negative (e.g. -0x1c70)
It is all weird, but logical. The add opcode is always
<addr> <command>
90 e3 84 24
So when I search on 90 e3 84 24 (little endian format), I found where the resolution is set up with the scanner.
So the opcodes for the highlighted bytes are:
lui $a0, 0x80dc - Load upper immediate
move $a2,$s2 - ignore for now as it is not $a0
sw $a2, 8($a0) - ignore for now as it is not $a0
jal - this is the call to printf() or similar
addiu $a0, $a0, -0x1c70 - Adding e390 to 0x80db0000, is the same as added -0x1c70 to 0x80dc0000.
More MIPS weirdness, the instruction following branch (jal) is executed before the call to 0x80160.
So search on the bottom 16-bits for the thing you want to find, then make sure the top 16-bit are setup correctly. Then you found the code area, to have ghidra look at. You can test by removing the print call. Replace 5800020c (jal 0x80160) with 00000000, a No Op. The code with run without the print.
I use the call to 0x80160 to add my own print-outs to learn more of the scanner behavior.
