ROM disassembly as raw text file
alright then, using rich's help i have managed to disassemble a ROM.
i now have 55570006 and tephraXmodded 55570106.
and of course i have have my own rom.
time to see if i can put 2+2 together and get 0x4!
i now have 55570006 and tephraXmodded 55570106.
and of course i have have my own rom.
time to see if i can put 2+2 together and get 0x4!
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
You can also download the appropriate "RAX Patch" for that ROM, apply it, disassemble it, and check out the differences.
A good exercise - if you want to put 10 and 10 together and get 100...
Rich
A good exercise - if you want to put 10 and 10 together and get 100...
Rich
alright, i came over from the PSI based boost control thread.
i'm almost done adding direct boost control to 58010005 but i need some help on finding what to look for.
i have made some progress since that post. using rich's C code for quick address conversion i think i found the proper 4 byte ram address for Variable for Boost Control.
it think SHLR->SHLR2 0x5101 -> 0x510 looks to translate over just fine. I just want to know what SHLR means!
all i have left is Boost Error RAM Address. i'm not sure what that is referencing to begin with so i'm not sure.
i have the address but i don't know what to change the byte to.
EX:
<table name="Boost Error RAM Address 0xC5D8 -> 0xC5?? (is 0x808??? for logging)" address="2bef2" category="Direct Boost" type="1D" scaling="Hex16"/>
<table name="Boost Error RAM Address in Load Error Table 0xC5D8 -> 0xC5??" address="6302e" category="Direct Boost" type="1D" scaling="Hex16"/>
thanks!
mo
i'm almost done adding direct boost control to 58010005 but i need some help on finding what to look for.
i have made some progress since that post. using rich's C code for quick address conversion i think i found the proper 4 byte ram address for Variable for Boost Control.
it think SHLR->SHLR2 0x5101 -> 0x510 looks to translate over just fine. I just want to know what SHLR means!
all i have left is Boost Error RAM Address. i'm not sure what that is referencing to begin with so i'm not sure.
i have the address but i don't know what to change the byte to.
EX:
<table name="Boost Error RAM Address 0xC5D8 -> 0xC5?? (is 0x808??? for logging)" address="2bef2" category="Direct Boost" type="1D" scaling="Hex16"/>
<table name="Boost Error RAM Address in Load Error Table 0xC5D8 -> 0xC5??" address="6302e" category="Direct Boost" type="1D" scaling="Hex16"/>
thanks!
mo
Last edited by momostallion; Mar 9, 2012 at 06:31 PM.
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Hi mo.
Going for the easy explanations first...
What Does SHLR Mean?
"SHLR" is presumably an overhang from the days when Evo ECUs were something other than M32R. Was it Hitachi H8? In any case, it means Shift Logical Right. On H8 cpu, a right-shift is represented as "SHLR".
On M32R, a right-shift is "srli", like this:
That shifts the bits in register r1... one step to the right. 
In terms of the PSI-based boost control patch, the tweak here is designed to take us from this...
...to this...
Those addresses are from your 58010005. I thought the example would be easier for you that way.
What is Boost Error?
In 99% of Mitsubishi's code, it leaves an amazing trail of interim values behind it as it works. It often just stores away calculated results and "working" values in safe memory locations, some of which are never referenced again. These have to be diagnostic variables, for ease of development/simulation/debugging. And they are brilliant for us, as we can log stuff at all sorts of points in the code, and find out what it's doing.
Unfortunately, "Boost Error" didn't get the treatment! They just didn't bother. The ECU calculates boost error in registers, puts it in a temp scaling lookup address, does its thing, then forgets it.
To make boost tuning easier, the "Direct Boost" patches include tweaks to the address used for "Boost Error" calc, storage and scaling lookup. It gets shunted off to a RAM address that is free, and is therefore preserved for our logging pleasure.
The new address is simply two bytes lower than the temporary address being used by the stock code. That's valid for all ROMs to date, anyway.
Yours is no different!
The temporary address used for Boost Error (and a billion other operations) is 0x8085d8.
This is ALSO expressed as an offset from the frame pointer, in hex: c5d8
AND as a decimal value: -14888
These are all the same RAM address, just described in different ways. There are even more ways the ECU uses as well, but let's not go there just yet!
So by following past patch successes, we can say that the magic new address for a permanent, loggable Boost Error value should be:
0x8085d6 / c5d6 / -14890
For an easy converter, see my "address_calc" tool - mentioned earlier in this thread.
You'll now want to double-check your ROM to make sure nothing references this new place. Search for "-14890" and "c5 d6". Check any references to make sure it's not being used. Use common sense to distinguish actual code from data, and ignore the data.
And it looks free to me!
So this is the address you're looking for for "Boost Error".
Too easy, eh...
Rich
Going for the easy explanations first...
What Does SHLR Mean?
"SHLR" is presumably an overhang from the days when Evo ECUs were something other than M32R. Was it Hitachi H8? In any case, it means Shift Logical Right. On H8 cpu, a right-shift is represented as "SHLR".
On M32R, a right-shift is "srli", like this:
Code:
RAW HEX ASSEMBLER 51 01 .. .. srli r1,#0x1
In terms of the PSI-based boost control patch, the tweak here is designed to take us from this...
Code:
0x2bec8 a1 bd XX XX lduh r1,@(-XXXXX,fp) # Drop the current "Load" val into r1 0x2becc 51 01 f0 00 srli r1,#0x1 || nop # Right-shift by 1 (ie. divide r1 by 2)
Code:
0x2bec8 a1 bd YY YY lduh r1,@(-YYYYY,fp) # Drop the current "Boost" val into r1 0x2becc 51 02 f0 00 srli r1,#0x2 || nop # Right-shift by 2 (ie. divide r1 by 4)
Those addresses are from your 58010005. I thought the example would be easier for you that way.
What is Boost Error?
In 99% of Mitsubishi's code, it leaves an amazing trail of interim values behind it as it works. It often just stores away calculated results and "working" values in safe memory locations, some of which are never referenced again. These have to be diagnostic variables, for ease of development/simulation/debugging. And they are brilliant for us, as we can log stuff at all sorts of points in the code, and find out what it's doing.
Unfortunately, "Boost Error" didn't get the treatment! They just didn't bother. The ECU calculates boost error in registers, puts it in a temp scaling lookup address, does its thing, then forgets it.
To make boost tuning easier, the "Direct Boost" patches include tweaks to the address used for "Boost Error" calc, storage and scaling lookup. It gets shunted off to a RAM address that is free, and is therefore preserved for our logging pleasure.
The new address is simply two bytes lower than the temporary address being used by the stock code. That's valid for all ROMs to date, anyway.
Yours is no different!
The temporary address used for Boost Error (and a billion other operations) is 0x8085d8.
This is ALSO expressed as an offset from the frame pointer, in hex: c5d8
AND as a decimal value: -14888
These are all the same RAM address, just described in different ways. There are even more ways the ECU uses as well, but let's not go there just yet!
So by following past patch successes, we can say that the magic new address for a permanent, loggable Boost Error value should be:
0x8085d6 / c5d6 / -14890
For an easy converter, see my "address_calc" tool - mentioned earlier in this thread.
You'll now want to double-check your ROM to make sure nothing references this new place. Search for "-14890" and "c5 d6". Check any references to make sure it's not being used. Use common sense to distinguish actual code from data, and ignore the data.
And it looks free to me!
So this is the address you're looking for for "Boost Error".
Too easy, eh...
Rich
^^ wow, thank you! excellent post, it answers every question i had perfectly!
OH... got it! I never considered it was an assembly function, I was being too dense and thinking it was a car parameter of sorts. It makes sense now.
appreciate that. those match exactly with what i found so i'm just happy i'm on the right track. with as much comparison as i've done lately i feel right at home with 55570006 and 52680015 as well.
haha, that's so ridiculous. i spent so much time looking at my rom and 3 others and the only discernible pattern i could find was that it was 2 bytes lower. i even wrote it down and just wrote, WTF? next to it. i thought there was no way that could be correct.
i'm just shaking my head over here. i used your code, saved it as a project called Rich's EZ Address Converter. it made things quite easy. my numbers match, i'm happy.
I really appreciate it sir. i'll got fill in the two missing fields in my xml then i'll test out PSI based boost control. if all looks well, i'll have an update for the community later today.
What Does SHLR Mean?
"SHLR" is presumably an overhang from the days when Evo ECUs were something other than M32R. Was it Hitachi H8? In any case, it means Shift Logical Right. On H8 cpu, a right-shift is represented as "SHLR".
On M32R, a right-shift is "srli", like this:
That shifts the bits in register r1... one step to the right.
"SHLR" is presumably an overhang from the days when Evo ECUs were something other than M32R. Was it Hitachi H8? In any case, it means Shift Logical Right. On H8 cpu, a right-shift is represented as "SHLR".
On M32R, a right-shift is "srli", like this:
Code:
RAW HEX ASSEMBLER 51 01 .. .. srli r1,#0x1
Those addresses are from your 58010005. I thought the example would be easier for you that way.
The new address is simply two bytes lower than the temporary address being used by the stock code. That's valid for all ROMs to date, anyway.
Yours is no different!
Yours is no different!
The temporary address used for Boost Error (and a billion other operations) is 0x8085d8.
This is ALSO expressed as an offset from the frame pointer, in hex: c5d8
AND as a decimal value: -14888
These are all the same RAM address, just described in different ways. There are even more ways the ECU uses as well, but let's not go there just yet!
So by following past patch successes, we can say that the magic new address for a permanent, loggable Boost Error value should be:
0x8085d6 / c5d6 / -14890
For an easy converter, see my "address_calc" tool - mentioned earlier in this thread.
This is ALSO expressed as an offset from the frame pointer, in hex: c5d8
AND as a decimal value: -14888
These are all the same RAM address, just described in different ways. There are even more ways the ECU uses as well, but let's not go there just yet!
So by following past patch successes, we can say that the magic new address for a permanent, loggable Boost Error value should be:
0x8085d6 / c5d6 / -14890
For an easy converter, see my "address_calc" tool - mentioned earlier in this thread.
Too easy, eh...
Rich
Rich
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Note also you can disassemble the post-patched ROM and review the code/data changes. But I bet you've done that...
Rich
But back to the task at hand! I've got objdump updated with the missing M32R definitions, and I'm happy enough with its assembler output.
I've attached my current build. There's also a readme in there, plus a wee shell script to run the tool a bit more easily.
Yeah, I know Linux isn't normally a "provide-a-binary" kind of world. Everyone normally rolls their own. If requested, I can always bundle up the few source mods I made (required to add support for the M32R "bclr", "bset" and "btst" opcodes). You can then stuff around with a full binutils v2.9.1 package download... if that floats your boat.
Rich
I've attached my current build. There's also a readme in there, plus a wee shell script to run the tool a bit more easily.
Yeah, I know Linux isn't normally a "provide-a-binary" kind of world. Everyone normally rolls their own. If requested, I can always bundle up the few source mods I made (required to add support for the M32R "bclr", "bset" and "btst" opcodes). You can then stuff around with a full binutils v2.9.1 package download... if that floats your boat.
Rich
I'll be putting that as well as other things up on github. Would be more than happy to add anyone interested as a contributor. The goal would be to start building a public, annotated version of the assembly. Since it's on github people that aren't contributors can still fork, add tags/comments or patches, and make a pull request
Open source ROM development anyone?
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
I think I grabbed a "too old" version of objdump - hence my "need" to patch up missing instruction definitions!
But apparently late versions of objdump don't do M23R! So there will be an in-between version that is the ideal one... ie. doesn't require any work from you!
Rich
But apparently late versions of objdump don't do M23R! So there will be an in-between version that is the ideal one... ie. doesn't require any work from you!
Rich
I grabbed 2.21.1 and it seems to support M32R just fine when built with the proper options. Latest appears to be 2.22 so maybe that's the one that doesn't support M32R? I didn't notice anything in the release notes about it.
Anyhow, I was able to get what appears to be the proper asm out of it however it is riddled with the same *unknowns* that you had in your first try.
The options I built with are :
--disable-debug
--disable-dependency-tracking
--disable-werror
--enable-interwork
--enable-multilib
--enable-targets=x86_64-elf
--enable-targets=arm-none-eabi
--enable-targets=m32r
If you can even send over a diff/patch that you did on your version I'm sure I can pick through it and figure out how to apply it to this one.
EDIT: Just looked through a bit of the binutils source... did you just hack up the M32R opcodes in opcodes/m32r-opc.h?
EDIT2: I found the BTST opcode in the m32r-opc.h in 2.22. Going to try that version and see if it works out of the box.
Anyhow, I was able to get what appears to be the proper asm out of it however it is riddled with the same *unknowns* that you had in your first try.
The options I built with are :
--disable-debug
--disable-dependency-tracking
--disable-werror
--enable-interwork
--enable-multilib
--enable-targets=x86_64-elf
--enable-targets=arm-none-eabi
--enable-targets=m32r
If you can even send over a diff/patch that you did on your version I'm sure I can pick through it and figure out how to apply it to this one.
EDIT: Just looked through a bit of the binutils source... did you just hack up the M32R opcodes in opcodes/m32r-opc.h?
EDIT2: I found the BTST opcode in the m32r-opc.h in 2.22. Going to try that version and see if it works out of the box.
Last edited by lodifreefly; Mar 12, 2012 at 07:38 PM.
posting again instead of a 3rd edit
Got 2.22 and many of the *unknown*s are gone, however there are still over 4800 of them in there, for example:
84: 59 6f 31 20 *unknown* -> mulwhi r1,r0
Got 2.22 and many of the *unknown*s are gone, however there are still over 4800 of them in there, for example:
84: 59 6f 31 20 *unknown* -> mulwhi r1,r0
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
There is a vast amount of "non-code" in the ROM. Fields... endless fields... of data.
Dissembling all that gubbins will just result in a pile of "unknowns". Not all combinations of bits can be turned into instructions. If the disassembler sees bits in combinations it can't map to an instruction, it just says "unknown".
I didn't try to work out what was data and what was code... I just ran the disassem on the entire file. Like you're doing.
Rich
Dissembling all that gubbins will just result in a pile of "unknowns". Not all combinations of bits can be turned into instructions. If the disassembler sees bits in combinations it can't map to an instruction, it just says "unknown".
I didn't try to work out what was data and what was code... I just ran the disassem on the entire file. Like you're doing.
Rich
Just started my disassembly journey with richardjh's assistance yesterday.
It's a whole new world! You guys might know me as the guy who provided a bunch of defs for the AuDM and Malaysian NA Lancers.
That was easy using a triangulation approach and pattern recognition in a HEX Editor.
Patching though I have to say is more challenging.
Because I too am on a Mac (hackintoshed)
I too couldn't use the Ubuntu made Linux version of objdump provided by richardjh on this thread.
So I was forced to download binutils 2.22 and compile from scratch.
I configured it as specified in the first post and then made it so... .
Then replacing richard's objdump file with my own made his script work perfectly.
All's well and I can disassemble on my "Mac" now.
For the Mac crowd though, do not use the MacPort's version. They didn't configure with m32r, so you won't be able to do any disassembly.
It's a whole new world! You guys might know me as the guy who provided a bunch of defs for the AuDM and Malaysian NA Lancers.
That was easy using a triangulation approach and pattern recognition in a HEX Editor.
Patching though I have to say is more challenging.
Because I too am on a Mac (hackintoshed)
I too couldn't use the Ubuntu made Linux version of objdump provided by richardjh on this thread.
So I was forced to download binutils 2.22 and compile from scratch.
I configured it as specified in the first post and then made it so... .
Then replacing richard's objdump file with my own made his script work perfectly.
All's well and I can disassemble on my "Mac" now.
For the Mac crowd though, do not use the MacPort's version. They didn't configure with m32r, so you won't be able to do any disassembly.
Last edited by ofey; Mar 12, 2012 at 09:04 PM. Reason: add avoid macport
There is a vast amount of "non-code" in the ROM. Fields... endless fields... of data.
Dissembling all that gubbins will just result in a pile of "unknowns". Not all combinations of bits can be turned into instructions. If the disassembler sees bits in combinations it can't map to an instruction, it just says "unknown".
I didn't try to work out what was data and what was code... I just ran the disassem on the entire file. Like you're doing.
Rich
Dissembling all that gubbins will just result in a pile of "unknowns". Not all combinations of bits can be turned into instructions. If the disassembler sees bits in combinations it can't map to an instruction, it just says "unknown".
I didn't try to work out what was data and what was code... I just ran the disassem on the entire file. Like you're doing.
Rich
Also, --disassemble-zeroes helped out with finding some of the table areas otherwise parts of the table were missing and all I was left with was ...