ROM disassembly as raw text file
#34
Evolved Member
Thread Starter
For reference, here's some bad C code for a quick address conversion tool.
This is a quick-and-dirty converter that handles three address styles...
1. Hex, absolute: eg. "808590"
2. Decimal-negative, relative to 0x80c000: eg. "-14960"
3. Hex, 4 bytes, relative to 0x7fc000: eg. "c590"
It runs kinda sorta like this...
Relative address (q to quit):809ba8
Address 0x809ba8 is (-9304,fp), Table Reference dba8
Relative address (q to quit):dba8
Table Reference dba8 is (-9304,fp), address 0x809ba8
Relative address (q to quit):-9304
(-9304,fp) is address 0x809ba8, Table Reference dba8
Yes, I know it's full of 0xBADC0DE fail. Sue me.
Rich
This is a quick-and-dirty converter that handles three address styles...
1. Hex, absolute: eg. "808590"
2. Decimal-negative, relative to 0x80c000: eg. "-14960"
3. Hex, 4 bytes, relative to 0x7fc000: eg. "c590"
It runs kinda sorta like this...
Relative address (q to quit):809ba8
Address 0x809ba8 is (-9304,fp), Table Reference dba8
Relative address (q to quit):dba8
Table Reference dba8 is (-9304,fp), address 0x809ba8
Relative address (q to quit):-9304
(-9304,fp) is address 0x809ba8, Table Reference dba8
Code:
#include <stdio.h> #include <string.h> int main( int argc, char **argv ) { long int fp_val = 0x80c000; char input_buf[ 999 + 1 ]; int done = 0; /* If a different base is ever required... * * printf( "Enter fp value for this ROM (eg. 80c000)\n"); * * scanf( "%lx", &fp_val ); */ printf( "\nfp = 0x%.6lx\n", fp_val ); do { printf( "\nRelative address (q to quit):" ); scanf( "%s", input_buf ); if ( 'q' == input_buf[0] ) { done = 1; } else if ( '-' == input_buf[0] ) { long int decval; sscanf( input_buf, "%ld", &decval ); printf( "(%s,fp) is address 0x%.6lx, Table Reference %lx\n", input_buf, fp_val + decval, 0x10000 + decval ); } else if ( 4 == strlen( input_buf ) ) { long int hexval; sscanf( input_buf, "%lx", &hexval ); printf( "Table Reference %s is (%ld,fp), address 0x%.6lx\n", input_buf, hexval - 0x10000, fp_val - 0x10000 + hexval ); } else if ( 6 == strlen( input_buf ) ) { long int addval; sscanf( input_buf, "%lx", &addval ); printf( "Address 0x%s is (%ld,fp), Table Reference %lx\n", input_buf, addval - fp_val, addval - fp_val + 0x10000 ); } else { printf("???\n"); } } while (!done); return 0; }
Yes, I know it's full of 0xBADC0DE fail. Sue me.
Rich
#35
Evolved Member
iTrader: (1)
Join Date: Nov 2009
Location: Omaha, NE
Posts: 1,456
Likes: 0
Received 0 Likes
on
0 Posts
I built. I ran. I like.
Code:
[michaelgo@papmdbbldp02 address]$ make address g++ address.cpp -o address [michaelgo@papmdbbldp02 address]$ ./address fp = 0x80c000 Relative address (q to quit):809ba8 Address 0x809ba8 is (-9304,fp), Table Reference dba8 Relative address (q to quit):dba8 Table Reference dba8 is (-9304,fp), address 0x809ba8 Relative address (q to quit):-9304 (-9304,fp) is address 0x809ba8, Table Reference dba8 Relative address (q to quit):q [michaelgo@papmdbbldp02 address]$
#36
Evolved Member
iTrader: (1)
Join Date: Nov 2009
Location: Omaha, NE
Posts: 1,456
Likes: 0
Received 0 Likes
on
0 Posts
I put Richard's new tables up on my site.
Roms updated so far:
53610010
5557000x (for me)
5559000x (for Bryan)
Tables added:
IAT to switch Load from Baro+Temp to Baro
Reactive Solenoid Max WGDC vs CTS
OBTR (Over-Boost Timing Retard) Load
OBTR (Over-Boost Timing Retard)
OBTR Variable for Boost Control 0xC78A -> 0xC72E (+ other values)
OBTR SHLR->SHLR2 0x5201 -> 0x5202
OBTR Boost Error RAM Address 0xC5A4 -> 0xC5A2 (+ other values)
OBTR Boost Error RAM Address in Load Error Table 0xC5A4 -> 0xC5A2 (+ other values)
And the Direct Boost tables for 53610010
All thanks goes to Richard. I just added the tables to my site and found the addresses for my rom by copying his work.
Roms updated so far:
53610010
5557000x (for me)
5559000x (for Bryan)
Tables added:
IAT to switch Load from Baro+Temp to Baro
Reactive Solenoid Max WGDC vs CTS
OBTR (Over-Boost Timing Retard) Load
OBTR (Over-Boost Timing Retard)
OBTR Variable for Boost Control 0xC78A -> 0xC72E (+ other values)
OBTR SHLR->SHLR2 0x5201 -> 0x5202
OBTR Boost Error RAM Address 0xC5A4 -> 0xC5A2 (+ other values)
OBTR Boost Error RAM Address in Load Error Table 0xC5A4 -> 0xC5A2 (+ other values)
And the Direct Boost tables for 53610010
All thanks goes to Richard. I just added the tables to my site and found the addresses for my rom by copying his work.
#38
Evolved Member
Thread Starter
The "Over-Boost Timing Retard" table knows you're over-boosting via the boost error calculation. That's what needs patching...
Traditional ROM boost error correction processing works from Boost Target Engine Load vs. actual load.
If you've switched over to direct psi-based error correction, all that stuff is no longer load-based. But those original patches didn't cover the "Over-Boost Timing Retard" subroutine. Its calculations were all screwy... but it didn't matter as long as the over-boost timing retard table values were zeroes.
If you want to use this mechanism with direct psi-based error correction, you need the equivalent patches applied to the OBRR subroutine, scaling, etc. The OBTR table magically changes to PSI-error instead of Load-error, and the calcs should fall into line.
Rich
Traditional ROM boost error correction processing works from Boost Target Engine Load vs. actual load.
If you've switched over to direct psi-based error correction, all that stuff is no longer load-based. But those original patches didn't cover the "Over-Boost Timing Retard" subroutine. Its calculations were all screwy... but it didn't matter as long as the over-boost timing retard table values were zeroes.
If you want to use this mechanism with direct psi-based error correction, you need the equivalent patches applied to the OBRR subroutine, scaling, etc. The OBTR table magically changes to PSI-error instead of Load-error, and the calcs should fall into line.
Rich
#39
Evolving Member
Just wanna say, amazing work you have done there Richard! Please keep up your research so we have better knowledge on how our ECU works and in turn can better tune it.
#40
Evolved Member
Thread Starter
Right, my latest ROM rattling exercise... TephraXMOD for me!
Instead of going and pestering the man, I've got off my butt and applied the TephraXMODv1 patches to my AUDM '09 Ralliart ROM (53610010). This was all in the name of science - a good learning experience for me.
Before going any further... no, I'm not doing this for anyone else's ROM. No. Just... no. Go ask Tephra.
It was a pain - especially without IDA Pro's supposed wonderfulness. But I've got a better idea of things now, having waded through relative jump addressing, different RAM variable addresses, table header patches, code patches, etc. And of course figuring out what did what, and why.
But now that it's done, I'm a happy guy, as I have...
There are still changes pending - I'm not quite finished with the XMOD port yet:
So far, only the Fuel Map vectors have been redirected to the AltMap addresses. I'm going to test each Alt-Map individually, one at a time - I hate changing lots of stuff in one go. The boost control tables are next.
Alt-Map "Ground ADC" switching mode is currently unusable - its patches go beyond what I want/need. That's the beauty of implementing it at the code level - I can pick and choose!
Here's a log of my Main/Alt map test... this shows raw AFRMAP values. The AltMap spool-up area is moderately leaner than the main map...
Changing maps while driving - love that CruiseControl button.
Rich
Instead of going and pestering the man, I've got off my butt and applied the TephraXMODv1 patches to my AUDM '09 Ralliart ROM (53610010). This was all in the name of science - a good learning experience for me.
Before going any further... no, I'm not doing this for anyone else's ROM. No. Just... no. Go ask Tephra.
It was a pain - especially without IDA Pro's supposed wonderfulness. But I've got a better idea of things now, having waded through relative jump addressing, different RAM variable addresses, table header patches, code patches, etc. And of course figuring out what did what, and why.
But now that it's done, I'm a happy guy, as I have...
- KnockCEL - flashy engine light thing. Tested out with stupidly low trigger criteria, and it works a treat.
- AltMap - switched via holding down the CruiseControl button. It's cool the way it toggles the CRUISE light periodically in "Alt" mode - a Ralliart special, I presume, as there is no ICS light on the dash.
- GST v2.6 Base Map stuff.
- Over-Boost Timing Retard.
- Direct PSI-based boost control.
There are still changes pending - I'm not quite finished with the XMOD port yet:
So far, only the Fuel Map vectors have been redirected to the AltMap addresses. I'm going to test each Alt-Map individually, one at a time - I hate changing lots of stuff in one go. The boost control tables are next.
Alt-Map "Ground ADC" switching mode is currently unusable - its patches go beyond what I want/need. That's the beauty of implementing it at the code level - I can pick and choose!
Here's a log of my Main/Alt map test... this shows raw AFRMAP values. The AltMap spool-up area is moderately leaner than the main map...
Changing maps while driving - love that CruiseControl button.
Rich
#42
Evolved Member
Thread Starter
Yeah, it's exciting stuff to be getting into.
However, I don't profess to understand everything in the TephraXMOD patch yet. No-siree. Like, I have absolutely no clue what the patch below is actually meant to do in the great scheme of things!...
What is this area, anyway? Value #5 is replaced with #35 in the check, but to what end? On that ROM (55590107), the value comes from 0x808810... seems to be MUT D4, in the "command" range. But... wha..? *
* Right here, my brain goes into traction-control mode, and throttles off for self-protection.
If anyone can tell me what this #5 -> #35 patch area is all about, I'd really like to know! Porting code from A to B without understanding it is monkey-with-keyboard stuff.
Rich
However, I don't profess to understand everything in the TephraXMOD patch yet. No-siree. Like, I have absolutely no clue what the patch below is actually meant to do in the great scheme of things!...
Code:
0x8ad18: a0 9d c8 10 ldub r0,@(-14320,fp) (...this is 0x808810) 0x8ad1c: 02 f0 7c 58 btst #0x2,r0 -> bc 0x8ae7c 0x8ad20: 7f 53 f0 00 bra 0x8ae6c || nop 0x8ad24: 80 c0 00 ff and3 r0,r0,#0xff 0x8ad28: 61 00 62 01 ldi r1,#0 -> ldi r2,#1 0x8ad2c: b0 01 00 54 beq r0,r1,0x8ae7c 0x8ad30: b0 02 00 38 beq r0,r2,0x8ae10 0x8ad34: 63 02 64 03 ldi r3,#2 -> ldi r4,#3 0x8ad38: b0 03 00 38 beq r0,r3,0x8ae18 0x8ad3c: b0 04 00 39 beq r0,r4,0x8ae20 0x8ad40: 65 04 66 23 ldi r5,#4 -> ldi r6,#35 0x8ad44: b0 05 00 39 beq r0,r5,0x8ae28 0x8ad48: b0 06 00 5d beq r0,r6,0x8aebc 0x8ad4c: 67 06 61 07 ldi r7,#6 -> ldi r1,#7 0x8ad50: b0 07 00 38 beq r0,r7,0x8ae30 0x8ad54: b0 01 00 3c beq r0,r1,0x8ae44 0x8ad58: 61 08 62 09 ldi r1,#8 -> ldi r2,#9 0x8ad5c: b0 01 00 48 beq r0,r1,0x8ae7c 0x8ad60: b0 02 00 3e beq r0,r2,0x8ae58
* Right here, my brain goes into traction-control mode, and throttles off for self-protection.
If anyone can tell me what this #5 -> #35 patch area is all about, I'd really like to know! Porting code from A to B without understanding it is monkey-with-keyboard stuff.
Rich
#44
Evolved Member
Thread Starter
Ah, bingo - those magic mode23 hex bytes I saw way back when in EcuFlash... now I'm seeing them as they really are. And I didn't even recognise them!
Funny.
Rich
Funny.
Rich