Notices

ROM disassembly as raw text file

Thread Tools
 
Search this Thread
 
Old Aug 1, 2011, 05:49 PM
  #31  
Evolved Member
Thread Starter
 
richardjh's Avatar
 
Join Date: Oct 2010
Location: Australia
Posts: 2,447
Received 14 Likes on 13 Posts
Done.

Rich
Old Aug 2, 2011, 07:29 AM
  #32  
EvoM Community Team
iTrader: (15)
 
fostytou's Avatar
 
Join Date: Sep 2006
Location: Aurora, IL
Posts: 3,143
Received 7 Likes on 7 Posts
Originally Posted by richardjh
I've now tried out the Over-Boost Timing Retard mechanisim. Seems to work!


My test settings (in "Direct psi-based" boost control mode)...


Is that actually functioning as a load based correction still or is that axes / scaling just mislabeled?
Old Aug 2, 2011, 09:07 AM
  #33  
Evolved Member
Thread Starter
 
richardjh's Avatar
 
Join Date: Oct 2010
Location: Australia
Posts: 2,447
Received 14 Likes on 13 Posts
It was mislabelled in that pic - supposed to read "Boost Error (psi)". I'd already caught that before sending it off to Golden.

Rich
Old Aug 2, 2011, 10:27 PM
  #34  
Evolved Member
Thread Starter
 
richardjh's Avatar
 
Join Date: Oct 2010
Location: Australia
Posts: 2,447
Received 14 Likes on 13 Posts
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





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
Old Aug 3, 2011, 08:08 AM
  #35  
Evolved Member
iTrader: (1)
 
Golden's Avatar
 
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]$
Old Aug 3, 2011, 02:59 PM
  #36  
Evolved Member
iTrader: (1)
 
Golden's Avatar
 
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.
Old Aug 3, 2011, 03:03 PM
  #37  
EvoM Guru
iTrader: (8)
 
RazorLab's Avatar
 
Join Date: Aug 2003
Location: Mid-Hudson, NY
Posts: 14,071
Received 1,056 Likes on 764 Posts
Originally Posted by Golden
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)
These are to switch to PSI-Target, why are they related to OBTR?
Old Aug 3, 2011, 07:19 PM
  #38  
Evolved Member
Thread Starter
 
richardjh's Avatar
 
Join Date: Oct 2010
Location: Australia
Posts: 2,447
Received 14 Likes on 13 Posts
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
Old Aug 3, 2011, 08:03 PM
  #39  
Evolving Member
 
RS200Z's Avatar
 
Join Date: Jan 2009
Location: Singapore
Posts: 150
Received 0 Likes on 0 Posts
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.
Old Aug 9, 2011, 08:08 AM
  #40  
Evolved Member
Thread Starter
 
richardjh's Avatar
 
Join Date: Oct 2010
Location: Australia
Posts: 2,447
Received 14 Likes on 13 Posts
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...
  • 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.
And that's on top of a ROM that already has...
  • GST v2.6 Base Map stuff.
  • Over-Boost Timing Retard.
  • Direct PSI-based boost control.
Awesome!


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
Attached Thumbnails ROM disassembly as raw text file-2011.08.09_altmap_test.png  
Old Aug 9, 2011, 09:05 AM
  #41  
Evolving Member
iTrader: (2)
 
vegittoss15's Avatar
 
Join Date: Feb 2011
Location: Hamilton, NJ
Posts: 289
Likes: 0
Received 0 Likes on 0 Posts
I just gotta say, as a developer, this is extremely cool stuff
Old Aug 10, 2011, 01:42 AM
  #42  
Evolved Member
Thread Starter
 
richardjh's Avatar
 
Join Date: Oct 2010
Location: Australia
Posts: 2,447
Received 14 Likes on 13 Posts
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!...

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
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
Old Aug 10, 2011, 01:56 AM
  #43  
EvoM Guru
iTrader: (6)
 
tephra's Avatar
 
Join Date: Feb 2007
Location: Melbourne, Australia
Posts: 9,486
Received 66 Likes on 42 Posts
Mode23
Old Aug 10, 2011, 02:06 AM
  #44  
Evolved Member
Thread Starter
 
richardjh's Avatar
 
Join Date: Oct 2010
Location: Australia
Posts: 2,447
Received 14 Likes on 13 Posts
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
Old Aug 11, 2011, 07:10 AM
  #45  
Evolving Member
iTrader: (2)
 
vegittoss15's Avatar
 
Join Date: Feb 2011
Location: Hamilton, NJ
Posts: 289
Likes: 0
Received 0 Likes on 0 Posts
Pardon the noob for asking, but what exactly is mode23?


Quick Reply: ROM disassembly as raw text file



All times are GMT -7. The time now is 04:52 AM.