ROM disassembly as raw text file
Evolving Member
Joined: Jan 2009
Posts: 150
Likes: 0
From: Singapore
Various defs for 53050009...
As usual, please apply with all due care. Test and log.
I'll send these to Golden...
Rich
Code:
<table name="Reactive Solenoid Max WGDC vs CTS" category="Turbo" address="5a228" type="2D" scaling="WGDuty">
<table name="Coolant Temp" address="5d32a" type="Y Axis" elements="8" scaling="Temp"/>
</table>
<table name="OBTR (Over-Boost Timing Retard)" category="Direct Boost" address="58c74" type="2D" swapxy="true" scaling="Timing">
<table name="Boost Error" address="6261e" type="Y Axis" elements="9" scaling="BoostErrorPsi"/>
</table>
<table name="OBTR Variable for Boost Control 0xC76C -> 0xC712" category="Direct Boost" address="21cc6" type="1D" scaling="Hex16"/>
<table name="OBTR SHLR->SHLR2 0x5201 -> 0x5202" category="Direct Boost" address="21cc8" type="1D" scaling="Hex16"/>
<table name="OBTR Boost Error RAM Address 0xC588 -> 0xC586" category="Direct Boost" address="21cde" type="1D" scaling="Hex16"/>
<table name="OBTR Boost Error RAM Address in Load Error Table 0xC588 -> 0xC586" category="Direct Boost" address="6261a" type="1D" scaling="Hex16"/>
<table name="OBTR (Over-Boost Timing Retard) Load" category="Load Boost" address="58c74" type="2D" swapxy="true" scaling="Timing">
<table name="Load Error" address="6261e" type="Y Axis" elements="9" scaling="LoadError"/>
</table>
As usual, please apply with all due care. Test and log.
I'll send these to Golden...
Rich
Evolving Member
Joined: Feb 2009
Posts: 340
Likes: 2
From: Australia
Rich (or anyone else!) - do you have the 3 OMNI 4bar switches for the 53050009 by any chance? i copied the code for the ADM GSR as a place holder in my xml but of course the addresses are wrong.
And I'll be testing the OBTR stuff soon.
Great work sir
And I'll be testing the OBTR stuff soon.
Great work sir
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Hi Beeble.
Omni 4Bar tweaks for 53050009? Give this a whirl...
Golden's site has been updated.
Enjoy... once you get your car back, anyway.
Rich
Omni 4Bar tweaks for 53050009? Give this a whirl...
Code:
<table name="Omni4bar #1 0x03B6 -> 0x02FF" address="17aba" category="Omni 4 Bar Boost" type="1D" scaling="Hex16" /> <table name="Omni4bar #2 0x0ED8 -> 0x0BFC" address="17aea" category="Omni 4 Bar Boost" type="1D" scaling="Hex16" /> <table name="Omni4bar #3 0x0ED8 -> 0x0BFC" address="17afe" category="Omni 4 Bar Boost" type="1D" scaling="Hex16" />
Enjoy... once you get your car back, anyway.
Rich
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Just gimme a working ROM+address+patch combination, and I'll see if I can suss out the equivalent on your ROM...
Edit: Found it - updated goldenevo.com with the new patch address for 53040010.
Rich
Edit: Found it - updated goldenevo.com with the new patch address for 53040010.
Rich
Last edited by richardjh; Sep 11, 2011 at 12:41 AM.
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
I want some control over my mixtures during spool-up... something that can add fuel over and above the base High Octane Fuel Map.
While there is an "Accel Enrichment" system theoretically available, it is apparently disabled on the Ralliart ROM - zero-filled table, required bitflag not set, etc. I still have high hopes of bringing it to life, but it's currently a bit beyond me!
So instead, I've written my own system. I call it Rich Spool, named after me. :P
Rich Spool is a lot more closely related to actual spoolage than the badly named "Lean Spool", that's for sure. It works off a new 3D table like this...
There is also some new code that tracks "delta load", with a view to applying a proportion of the "Rich Spool Compensation Table"... depending on how fast load is increasing.
Now, if the value from the 3D map is "100%", it doesn't matter what load is doing - at that rpm/load point, the AFR map lookup result won't be changed by this new mechanism.
Here's that table, in pretty 3D graph mode:
The an island in the middle of this map targets the specific spool-up areas where I want to add a wee bit of extra fuel (remember - there is no "Accel Enrichment" occurring on the stock RA ROM).
The result is this:
The yellow/orange line, AFRMAP_RS_Comp, is the "Rich Spool" compensated version of the original High Octane Fuel Map lookup value (AFRMAP_Orig_Map). Note the slight enrichment during spool-up.
So I'm now able to affect spool-up fuelling at specific rpm/load points, set whatever adjustment I want, and have it applied in proportion to "delta load".
Of course, a really smart person would have sussed out how to bring the existing "Accel Enrichment" system back to life. I will keep tracing all that stuff, honest. But until then I'm pretty happy with my Plan B!
Rich
While there is an "Accel Enrichment" system theoretically available, it is apparently disabled on the Ralliart ROM - zero-filled table, required bitflag not set, etc. I still have high hopes of bringing it to life, but it's currently a bit beyond me!
So instead, I've written my own system. I call it Rich Spool, named after me. :P
Rich Spool is a lot more closely related to actual spoolage than the badly named "Lean Spool", that's for sure. It works off a new 3D table like this...
There is also some new code that tracks "delta load", with a view to applying a proportion of the "Rich Spool Compensation Table"... depending on how fast load is increasing.
Now, if the value from the 3D map is "100%", it doesn't matter what load is doing - at that rpm/load point, the AFR map lookup result won't be changed by this new mechanism.
Here's that table, in pretty 3D graph mode:
The an island in the middle of this map targets the specific spool-up areas where I want to add a wee bit of extra fuel (remember - there is no "Accel Enrichment" occurring on the stock RA ROM).
The result is this:
The yellow/orange line, AFRMAP_RS_Comp, is the "Rich Spool" compensated version of the original High Octane Fuel Map lookup value (AFRMAP_Orig_Map). Note the slight enrichment during spool-up.
So I'm now able to affect spool-up fuelling at specific rpm/load points, set whatever adjustment I want, and have it applied in proportion to "delta load".
Of course, a really smart person would have sussed out how to bring the existing "Accel Enrichment" system back to life. I will keep tracing all that stuff, honest. But until then I'm pretty happy with my Plan B!
Rich
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
They don't seem to be in any definitions yet.
I've got something different I'm looking at right now, but once that's done I'll start to put together all the X/RA stuff - using the very detailed descriptions that are available for I-IX.
I really do want to get the inbuilt stuff working - happy to consign my patch to the dustbin of history. But right now I like the outcome of this a lot...
Rich
I've got something different I'm looking at right now, but once that's done I'll start to put together all the X/RA stuff - using the very detailed descriptions that are available for I-IX.
I really do want to get the inbuilt stuff working - happy to consign my patch to the dustbin of history. But right now I like the outcome of this a lot...
Rich
I found the Accel Enrichment tables for Rich the other night. They didn't do anything for him. The Evo does have values in the table. I have not tested to see if it works on the Evo roms.
If you'd like to test, I can send you a def.
If you'd like to test, I can send you a def.
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Next little side-project...
Baro Compensated Direct PSI-Based Boost Control
Note: I live in a really, really flat country, so this is about as useful to me as mammary glands on a bull. But it might be useful to people with locales reaching higher than "the pub up the hill"...
Direct PSI-Based Boost Control has always just loaded an "Atmospheric Boost" constant. This was scaled as "psi/0.19347", so "14.5 psi" is a byte value of 75.
The plan here was simply to replace the instruction that loads "Atmospheric Boost" with a call to a function that uses the BARO variable... which is scaled so that "14.5 psi" is a byte value of 200.
To convert from one to the other, just multiply by three, and divide by eight.
Throw in a sanity check that limits the max possible PSI value to something sensible (say, 14.7 psi for anyone blasting through a deep undersea tunnel!), and that's about it.
Here's the function that does the job... a whopping 10 lines of code...
Returning a function result in register r4 isn't "The Done Thing" as far as this ROM code is generally concerned, but I'm exercising poetic license... it makes it much easier to patch the call TO this function if we can impact only r4.
Here's the ORIGINAL ROM code, before patched call... red bit will be replaced...
And patched...
There is a second place to apply a patch - in the "OverBoost Timing Retard" processing. Same style as above.
And that's it!
The patch function logs the rescaled, returned "Atmospheric Boost" value into 0x8050a0. I've taken the RA for a spin, and this logged value is pegged at 14.51 psi. Tested in anger, the Boost-Target based error correction worked perfectly - nailed my 21.7 psi target, with the logged "Boost Error psi" variable confirming correct operation.
Now, if only I had a huge mountain somewhere nearby, I could actually test it at significantly different altitudes!
Rich
Baro Compensated Direct PSI-Based Boost Control
Note: I live in a really, really flat country, so this is about as useful to me as mammary glands on a bull. But it might be useful to people with locales reaching higher than "the pub up the hill"...
Direct PSI-Based Boost Control has always just loaded an "Atmospheric Boost" constant. This was scaled as "psi/0.19347", so "14.5 psi" is a byte value of 75.
The plan here was simply to replace the instruction that loads "Atmospheric Boost" with a call to a function that uses the BARO variable... which is scaled so that "14.5 psi" is a byte value of 200.
To convert from one to the other, just multiply by three, and divide by eight.
Throw in a sanity check that limits the max possible PSI value to something sensible (say, 14.7 psi for anyone blasting through a deep undersea tunnel!), and that's about it.
Here's the function that does the job... a whopping 10 lines of code...
Code:
tag- SUBR: subr_return_atmos_pressure_in_r4
tag- :
tag- : Outputs
tag- : r4 = "Atmospheric Boost" in "psia16" scale (x*0.19347)
tag- :
tag- : Note: Preserve all other registers.
tag- :
tag- : Vars used:
tag- : 0x8050a0 (-28512) - Atmospheric Boost from Baro
tag- :
0xfb680: st lr,@-sp -> st r1,@-sp tag- : Push lr, r1
0xfb684: st r2,@-sp || nop tag- : Push r2
0xfb688: lduh r1,@(-5848,fp) tag- : Load r1 from 0x80a928 (Baro)
0xfb68c: ldi r2,#3 -> mul r1,r2 tag- : r1 *= 3 We multiply raw Baro by three...
0xfb690: srli r1,#0x3 || nop tag- : r1 >>= 3 ...then divide by eight, to get correct scale.
0xfb694: ldi r4,#75 -> cmpu r4,r1 tag- : r4 = 76 (upper limit). If r4 < r1...
0xfb698: bc 0xfb69c -> mv r4,r1 tag- : ...Jump to 0xfb69c (returning r4 as max), else r4 = r1.
0xfb69c: sth r4,@(-28512,fp) tag- : Store r4 (Atmospheric Boost) into 0x8050a0 for debug logging
0xfb6a0: ld r2,@sp+ -> ld r1,@sp+ tag- : Pop r2, r1
0xfb6a4: ld lr,@sp+ -> jmp lr tag- : Pop lr , Retn----------------------------------------
Returning a function result in register r4 isn't "The Done Thing" as far as this ROM code is generally concerned, but I'm exercising poetic license... it makes it much easier to patch the call TO this function if we can impact only r4.
Here's the ORIGINAL ROM code, before patched call... red bit will be replaced...
Code:
0x9f51c: lduh r2,@(-13478,fp) tag- : Load r2 with Boost Target map lookup result 0x9f520: ld24 r4,#0x53484 tag- Tabl: r4 points at "Atmospheric Boost", formerly "boost_control_load_offset" 0x9f524: lduh r3,@r4 -> add r2,r3 tag- : Load r3 from @r4, then r2 += r3
And patched...
Code:
0x9f51c: lduh r2,@(-13478,fp) tag- : Load r2 with Boost Target map lookup result 0x9f520: bl 0xfb680 tag- Call: subr_return_atmos_pressure_in_r4 0x9f524: add r2,r4 || nop tag- : r2 += r4
And that's it!
The patch function logs the rescaled, returned "Atmospheric Boost" value into 0x8050a0. I've taken the RA for a spin, and this logged value is pegged at 14.51 psi. Tested in anger, the Boost-Target based error correction worked perfectly - nailed my 21.7 psi target, with the logged "Boost Error psi" variable confirming correct operation.
Now, if only I had a huge mountain somewhere nearby, I could actually test it at significantly different altitudes!
Rich
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
David, one thing you can do for me is to check the memory areas and variable addresses you're using for V2... and likely to use for V-whatever... and feed that info through to me. I'll make an effort to keep free and clear.
Chances are, I've already stuffed that up with "RAX Patch v1", but it's early days. Let's at least try to coordinate future Aussie ROM hacking exploits from now on.
Just point at where you don't (or do) want me to be, and I'll take note.
Rich
Chances are, I've already stuffed that up with "RAX Patch v1", but it's early days. Let's at least try to coordinate future Aussie ROM hacking exploits from now on.
Just point at where you don't (or do) want me to be, and I'll take note.
Rich
sure thing.
at the moment for V2 I am using:
0x805000 -> 0x805100
0x80C000 -> 0x80D000
I would love to move the second one into RAM_BACKUP, but I dont think there is a contiguous 4k block free...
at the moment for V2 I am using:
0x805000 -> 0x805100
0x80C000 -> 0x80D000
I would love to move the second one into RAM_BACKUP, but I dont think there is a contiguous 4k block free...
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Okay, so from now on I'll use RAM 0x805100-0x8051ff for my vars.
How about your ROM addressing, ie. code and data? It's probably easier for you to point me at an area you're not using. I can then use that area, and stay out of your way.
Maybe just email me, at your convenience! That'll avoid turning this thread into a memory management document!
Rich
How about your ROM addressing, ie. code and data? It's probably easier for you to point me at an area you're not using. I can then use that area, and stay out of your way.
Maybe just email me, at your convenience! That'll avoid turning this thread into a memory management document!
Rich
Sure. I get some tip in accel leaning out between 1700 and up to 3000. From roughly 1700 - 2400 is the worst. Anything higher it hits positive pressure areas so fast that i don't really see the issue. The other thread with the 2000-3000 thread I do have effects of (though not nearly as bad which also makes me think its an accel issue at least in my case) but since I've been playing with my car more and added a Primo intake I've been working all over the lower areas and such while scaling my MAF carefully I noticed I get high 16's and even 17's along with a good hesitation sometimes for a second then the car just takes off.
I am pretty positive its not MAF scaling. From idle and up to about 2.5 volts cruising my LTFT's are now sitting +/- 0.95 on average. Sometimes they venture off but again that's when I believe the accel portion is kicking in drawing it off. Once I maintain the throttle they drift right back to nearly +/- 0.95 ever single time.
This also gets me into thinking about something. My MAF scaling needed more than the standard 1.49 multiplier people are suggesting. I even started exactly from mrfred's provided scaling from 3dman1's Evo and down low areas are not even close. I live literally at about 15-25 feet above sea level in Florida. I wonder if a slight scaling change to my injectors would have been a better idea to start with since both idle and cruise LTFT were in the positives. My bone stock car always stayed around +2 to +8 LTFT during the hot summer months so I could only imagine what winter would have done.
Also at one point using the MAF scaling excel spreadsheets I ended up maxing the MAF variables all the way out at 65535 or something i don't have the exact figure off hand. I did finally see a big change in AFR's then though but they were low 10's on a stock turbo. I'd think it would have been so bad it wouldn't have even pulled through the rpms.
Where I sit now is a multiplier of 1.50 from about 3 volts till 5 volts. This has my AFR's about .5/.6 leaner than the stock air box which I feel is probably about right with the Primo intake. My car shows 3.9x to 4.0x volts through a pull hitting 28psi and failing to about 18psi @ redline for reference. Below 3 volts was a starting of 1.52 and then some MAF spreadsheet calculations, some by hand adjustments, and smoothing by hand to meet in between and look sane.