ROM disassembly as raw text file
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Okay itzwolf, here are your PSI Based Boost Control tweaks for ROM 56890009 / 56890010...
First, some scalings you'll need (temporarily)...
...and the defs themselves...
Put these in your 56890009.xml. A good place is immediately above the "Load Boost" section.
The "0xAAAA -> 0xBBBB" are code/address patches. Make sure that the "AAAA" part matches the original data you see prior to changing anything! If it doesn't, stop right there. Assuming it matches, apply the patch by changing that data to 0xBBBB. You need the "0x" prefix.
I'm sure you know the drill... just spelling it out!
Then revise your table data to align with "Direct PSI" style boost control. I'm sure you've got thread references for all of that.
Note that all five of the "table" definitions point to the same data locations as the traditional load-based versions. This patch doesn't add a second set of maps... it just allows you to re-task the existing data (or scale) to be interpreted in a psi style, not load.
Please take maximum care testing this out! Verify all of the following via logging:
For my posted changes to ROM 56890009/56890010, you are the beta tester for the above changes. Remember that...!
Let me know how it goes, and if you have a better time with boost targets this way. I know I found it a lot easier than load-based!
Golden: if you're reading this, how about we hold off on applying these xml updates to your site until we have verification it's all good. It's probably the smart way to play it...
Rich
First, some scalings you'll need (temporarily)...
Code:
<scaling name="psia8" units="psia" toexpr="x*0.19347" frexpr="x/0.19347" format="%.1f" min="0" max="49.5" inc="0.1" storagetype="uint8" endian="big"/> <scaling name="BoostErrorPsi" units="psi" toexpr="(x-128)*0.19347/4" frexpr="(x*4/0.19347)+128" format="%.1f" min="-6.1" max="6.1" inc="0.1" storagetype="uint16" endian="big"/> <scaling name="psia16" units="psia" toexpr="x*0.19347" frexpr="x/0.19347" format="%.1f" min="0" max="49.5" inc="0.1" storagetype="uint16" endian="big"/>
Code:
<table name="Atmospheric Boost" category="Direct Boost" address="53488" type="1D" scaling="psia16"/>
<table name="Boost Target #1A (High Gear Range)" category="Direct Boost" address="58ef1" type="3D" swapxy="true" scaling="psia8">
<table name="Throttle" address="63020" type="X Axis" elements="9" scaling="Throttle_Main - Stored Minimum Throttle %"/>
<table name="RPM" address="62f9e" type="Y Axis" elements="18" scaling="RPM"/>
</table>
<table name="Boost Target #1B (High Gear Range)" category="Direct Boost" address="58f9b" type="3D" swapxy="true" scaling="psia8">
<table name="Throttle" address="63020" type="X Axis" elements="9" scaling="Throttle_Main - Stored Minimum Throttle %"/>
<table name="RPM" address="62f9e" type="Y Axis" elements="18" scaling="RPM"/>
</table>
<table name="Boost Target #2 (Low Gear Range)" category="Direct Boost" address="57465" type="3D" swapxy="true" scaling="psia8">
<table name="Throttle" address="63020" type="X Axis" elements="9" scaling="Throttle_Main - Stored Minimum Throttle %"/>
<table name="RPM" address="62f9e" type="Y Axis" elements="18" scaling="RPM"/>
</table>
<table name="Target Boost Error Correction" category="Direct Boost" address="58d84" type="2D" scaling="DynamicBoost">
<table name="Boost Error" address="62fc8" type="Y Axis" elements="17" scaling="BoostErrorPsi"/>
</table>
<table name="Variable for Boost Control 0xC7BA -> 0xC75E" category="Direct Boost" address="2bc8e" type="1D" scaling="Hex16"/>
<table name="SHLR->SHLR2 0x5101 -> 0x5102" category="Direct Boost" address="2bc90" type="1D" scaling="Hex16"/>
<table name="Boost Error RAM Address 0xC5D0 -> 0xC5CE (is 0x8085ce for logging)" category="Direct Boost" address="2bcb6" type="1D" scaling="Hex16"/>
<table name="Boost Error RAM Address in Load Error Table 0xC5D0 -> 0xC5CE" category="Direct Boost" address="62fc4" type="1D" scaling="Hex16"/>
Put these in your 56890009.xml. A good place is immediately above the "Load Boost" section.
The "0xAAAA -> 0xBBBB" are code/address patches. Make sure that the "AAAA" part matches the original data you see prior to changing anything! If it doesn't, stop right there. Assuming it matches, apply the patch by changing that data to 0xBBBB. You need the "0x" prefix.
I'm sure you know the drill... just spelling it out!
Then revise your table data to align with "Direct PSI" style boost control. I'm sure you've got thread references for all of that.
Note that all five of the "table" definitions point to the same data locations as the traditional load-based versions. This patch doesn't add a second set of maps... it just allows you to re-task the existing data (or scale) to be interpreted in a psi style, not load.
Please take maximum care testing this out! Verify all of the following via logging:
- Your logged Boost should already be at address 0x80875e on your ROM. That's what the patch change will switch to instead of load. So it better be "Boost"!
- You should be able to log Boost Target PSI at address 0x808ba4 (2-byte logging). The scaling is "x*0.19347".
- You should be able to log Boost Error PSI at address 0x8085ce (2-byte logging). IIRC, it'll scrape along the floor at "minus six point something" until you actually get near target boost. The scaling is "(x-128)/4*0.19347".
- Make sure your logged WGDC % is behaving sensibly.
For my posted changes to ROM 56890009/56890010, you are the beta tester for the above changes. Remember that...!
Let me know how it goes, and if you have a better time with boost targets this way. I know I found it a lot easier than load-based!
Golden: if you're reading this, how about we hold off on applying these xml updates to your site until we have verification it's all good. It's probably the smart way to play it...
Rich
Everything is looking good when looking at my ROM as far as the hex variables and such. Can't wait to test this later!
Would the equations need to be "(x*0.19347)-14.5" for Boost Target PSI and "(x-128)/(4*0.19347)-14.5" for Boost Error PSI or does that not matter here because of the Atmospheric Boost offset?
I am at work so I have no way of checking so just tossing it out there to see...
Please take maximum care testing this out! Verify all of the following via logging:
- Your logged Boost should already be at address 0x80875e on your ROM. That's what the patch change will switch to instead of load. So it better be "Boost"!
- You should be able to log Boost Target PSI at address 0x808ba4 (2-byte logging). The scaling is "x*0.19347".
- You should be able to log Boost Error PSI at address 0x8085ce (2-byte logging). IIRC, it'll scrape along the floor at "minus six point something" until you actually get near target boost. The scaling is "(x-128)/4*0.19347".
- Make sure your logged WGDC % is behaving sensibly.
I am at work so I have no way of checking so just tossing it out there to see...
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Logged Boost Error PSI is an indication of actual boost vs. target boost. No need for an atmo adjustment. Is it's the "how wrong am I?" variable.
Logged Boost Target is straight off the map lookup. So it's whatever is in your map, pure and simple. If your "Atmospheric Boost" offset matches your real world atmo, you're good. In fact, you can log this very same variable in load-based mode - it gives you the load target (with the right scaling in place).
Rich
Logged Boost Target is straight off the map lookup. So it's whatever is in your map, pure and simple. If your "Atmospheric Boost" offset matches your real world atmo, you're good. In fact, you can log this very same variable in load-based mode - it gives you the load target (with the right scaling in place).
Rich
Last edited by richardjh; Aug 26, 2011 at 04:53 PM. Reason: Clarity
Okay itzwolf, here are your PSI Based Boost Control tweaks for ROM 56890009 / 56890010...
First, some scalings you'll need (temporarily)...
...and the defs themselves...
Put these in your 56890009.xml. A good place is immediately above the "Load Boost" section.
The "0xAAAA -> 0xBBBB" are code/address patches. Make sure that the "AAAA" part matches the original data you see prior to changing anything! If it doesn't, stop right there. Assuming it matches, apply the patch by changing that data to 0xBBBB. You need the "0x" prefix.
I'm sure you know the drill... just spelling it out!
Then revise your table data to align with "Direct PSI" style boost control. I'm sure you've got thread references for all of that.
Note that all five of the "table" definitions point to the same data locations as the traditional load-based versions. This patch doesn't add a second set of maps... it just allows you to re-task the existing data (or scale) to be interpreted in a psi style, not load.
Please take maximum care testing this out! Verify all of the following via logging:
For my posted changes to ROM 56890009/56890010, you are the beta tester for the above changes. Remember that...!
Let me know how it goes, and if you have a better time with boost targets this way. I know I found it a lot easier than load-based!
Golden: if you're reading this, how about we hold off on applying these xml updates to your site until we have verification it's all good. It's probably the smart way to play it...
Rich
First, some scalings you'll need (temporarily)...
Code:
<scaling name="psia8" units="psia" toexpr="x*0.19347" frexpr="x/0.19347" format="%.1f" min="0" max="49.5" inc="0.1" storagetype="uint8" endian="big"/> <scaling name="BoostErrorPsi" units="psi" toexpr="(x-128)*0.19347/4" frexpr="(x*4/0.19347)+128" format="%.1f" min="-6.1" max="6.1" inc="0.1" storagetype="uint16" endian="big"/> <scaling name="psia16" units="psia" toexpr="x*0.19347" frexpr="x/0.19347" format="%.1f" min="0" max="49.5" inc="0.1" storagetype="uint16" endian="big"/>
Code:
<table name="Atmospheric Boost" category="Direct Boost" address="53488" type="1D" scaling="psia16"/>
<table name="Boost Target #1A (High Gear Range)" category="Direct Boost" address="58ef1" type="3D" swapxy="true" scaling="psia8">
<table name="Throttle" address="63020" type="X Axis" elements="9" scaling="Throttle_Main - Stored Minimum Throttle %"/>
<table name="RPM" address="62f9e" type="Y Axis" elements="18" scaling="RPM"/>
</table>
<table name="Boost Target #1B (High Gear Range)" category="Direct Boost" address="58f9b" type="3D" swapxy="true" scaling="psia8">
<table name="Throttle" address="63020" type="X Axis" elements="9" scaling="Throttle_Main - Stored Minimum Throttle %"/>
<table name="RPM" address="62f9e" type="Y Axis" elements="18" scaling="RPM"/>
</table>
<table name="Boost Target #2 (Low Gear Range)" category="Direct Boost" address="57465" type="3D" swapxy="true" scaling="psia8">
<table name="Throttle" address="63020" type="X Axis" elements="9" scaling="Throttle_Main - Stored Minimum Throttle %"/>
<table name="RPM" address="62f9e" type="Y Axis" elements="18" scaling="RPM"/>
</table>
<table name="Target Boost Error Correction" category="Direct Boost" address="58d84" type="2D" scaling="DynamicBoost">
<table name="Boost Error" address="62fc8" type="Y Axis" elements="17" scaling="BoostErrorPsi"/>
</table>
<table name="Variable for Boost Control 0xC7BA -> 0xC75E" category="Direct Boost" address="2bc8e" type="1D" scaling="Hex16"/>
<table name="SHLR->SHLR2 0x5101 -> 0x5102" category="Direct Boost" address="2bc90" type="1D" scaling="Hex16"/>
<table name="Boost Error RAM Address 0xC5D0 -> 0xC5CE (is 0x8085ce for logging)" category="Direct Boost" address="2bcb6" type="1D" scaling="Hex16"/>
<table name="Boost Error RAM Address in Load Error Table 0xC5D0 -> 0xC5CE" category="Direct Boost" address="62fc4" type="1D" scaling="Hex16"/>
Put these in your 56890009.xml. A good place is immediately above the "Load Boost" section.
The "0xAAAA -> 0xBBBB" are code/address patches. Make sure that the "AAAA" part matches the original data you see prior to changing anything! If it doesn't, stop right there. Assuming it matches, apply the patch by changing that data to 0xBBBB. You need the "0x" prefix.
I'm sure you know the drill... just spelling it out!
Then revise your table data to align with "Direct PSI" style boost control. I'm sure you've got thread references for all of that.
Note that all five of the "table" definitions point to the same data locations as the traditional load-based versions. This patch doesn't add a second set of maps... it just allows you to re-task the existing data (or scale) to be interpreted in a psi style, not load.
Please take maximum care testing this out! Verify all of the following via logging:
- Your logged Boost should already be at address 0x80875e on your ROM. That's what the patch change will switch to instead of load. So it better be "Boost"!
- You should be able to log Boost Target PSI at address 0x808ba4 (2-byte logging). The scaling is "x*0.19347".
- You should be able to log Boost Error PSI at address 0x8085ce (2-byte logging). IIRC, it'll scrape along the floor at "minus six point something" until you actually get near target boost. The scaling is "(x-128)/4*0.19347".
- Make sure your logged WGDC % is behaving sensibly.
For my posted changes to ROM 56890009/56890010, you are the beta tester for the above changes. Remember that...!
Let me know how it goes, and if you have a better time with boost targets this way. I know I found it a lot easier than load-based!
Golden: if you're reading this, how about we hold off on applying these xml updates to your site until we have verification it's all good. It's probably the smart way to play it...
Rich
I come bearing great news that the Direct Boost is 100% functional and I was able to dead on nail the boost I wanted every time. I tried setting the WGDC% to low and excessively high with great results with the error control.
Thanks again for finding the addresses for me and ultimately the community!
Golden,
When you get a chance these are a green light to add to your XML database.
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
Well, at least everything matches! 
While I'm still in the area, here are the definitions for the factory ROM Over-Boost Timing Retard mechanism...
Load Based Boost Control:
Direct PSI Based Boost Control:
The OBTR table is normally zero-filled. If you wish, you can populate it with timing retard values. If boost boes over your target, timing is pulled by the specified amount.
Here's an example of some values thrown into the table ("direct boost" mode)...
Note: If you intend to leave the timing retard values all zero, you don't need to patch the mechanism for direct boost mode - just ignore it completely. It's been there, ignored, all along... and it hasn't got upset yet!
No idea if anyone will find use for this. In theory, a properly set up spark map makes this a pointless mechanism!
Rich
While I'm still in the area, here are the definitions for the factory ROM Over-Boost Timing Retard mechanism...
Load Based Boost Control:
Code:
<table name="OBTR (Over-Boost Timing Retard) Load" category="Load Boost" address="58d20" type="2D" swapxy="true" scaling="Timing">
<table name="Load Error" address="62ff0" type="Y Axis" elements="9" scaling="LoadError"/>
</table>
Direct PSI Based Boost Control:
Code:
<table name="OBTR (Over-Boost Timing Retard)" category="Direct Boost" address="58d20" type="2D" swapxy="true" scaling="Timing">
<table name="Boost Error" address="62ff0" type="Y Axis" elements="9" scaling="BoostErrorPsi"/>
</table>
<table name="OBTR Variable for Boost Control 0xC7BA -> 0xC75E" category="Direct Boost" address="21c9a" type="1D" scaling="Hex16"/>
<table name="OBTR SHLR->SHLR2 0x5201 -> 0x5202" category="Direct Boost" address="21c9c" type="1D" scaling="Hex16"/>
<table name="OBTR Boost Error RAM Address 0xC5D0 -> 0xC5CE" category="Direct Boost" address="21cb2" type="1D" scaling="Hex16"/>
<table name="OBTR Boost Error RAM Address in Load Error Table 0xC5D0 -> 0xC5CE" category="Direct Boost" address="62fec" type="1D" scaling="Hex16"/>
The OBTR table is normally zero-filled. If you wish, you can populate it with timing retard values. If boost boes over your target, timing is pulled by the specified amount.
Here's an example of some values thrown into the table ("direct boost" mode)...
Note: If you intend to leave the timing retard values all zero, you don't need to patch the mechanism for direct boost mode - just ignore it completely. It's been there, ignored, all along... and it hasn't got upset yet!
No idea if anyone will find use for this. In theory, a properly set up spark map makes this a pointless mechanism!
Rich
Thread Starter
Evolved Member
Joined: Oct 2010
Posts: 2,447
Likes: 14
From: Australia
My side project this weekend was to implement a simple IAT Adjusted BWGDC system in my ROM. All done now, and working nicely! 
This should allow me to permanently sort out the mild boost overshoot issue that appeared in winter (yep, I tuned my boost in summer). I had reduced the entire BWGDC map by a few percent to compensate - now I won't need to mess about raising it again.
I know tweaking that table for summer vs. winter isn't a big deal... but I shouldn't have to, should I? hehe. Now it'll be done for me by this table.
Here's a log graph from my initial test drive. Ambient temp was around 15C. IAT started out at 36C, as the car had been driven earlier. This quickly dropped as I drove.
The blue line is the raw BWGDC... as read from the Reactive Solenoid Base WGDC map. The purple line shadowing it is the actual WGDC used... including the IAT-based offset from the new table.
To begin with, the logged BWGDC IAT Adjust offset was positive. This made the final WGDC higher than the map-read value.
Then, as measured intake air temp dropped, the offset reduced. Around 26C, the WGDC was left alone.
Finally, as IAT kept dropping, the offset went very slightly negative. At that point, the final WGDC was a hair lower than the map-read value.
Cool.
Please note: I'm not sure if my WGDC offsets are sane - I used the finger-in-the-wind method to populate the new table. :P
It should be enough to get me in the ballpark, though. I guess I'll find out how close the "hot" offsets are come summer!
For anyone fooling with disassembly, I'd be happy to throw up the innards of this, as a kind of "anatomy of a patch". If someone would find that interesting, shout - I'd be happy to.
This one is actually a good example of a ROM patch - it's dead easy to follow, has no twisty/tricky bits, but has just enough meat on its bones to be worth going over. You'll just have to ignore the snoring from up the back - that'll be tephra & company...
Cheers!
Rich
This should allow me to permanently sort out the mild boost overshoot issue that appeared in winter (yep, I tuned my boost in summer). I had reduced the entire BWGDC map by a few percent to compensate - now I won't need to mess about raising it again.
I know tweaking that table for summer vs. winter isn't a big deal... but I shouldn't have to, should I? hehe. Now it'll be done for me by this table.
Here's a log graph from my initial test drive. Ambient temp was around 15C. IAT started out at 36C, as the car had been driven earlier. This quickly dropped as I drove.
The blue line is the raw BWGDC... as read from the Reactive Solenoid Base WGDC map. The purple line shadowing it is the actual WGDC used... including the IAT-based offset from the new table.
To begin with, the logged BWGDC IAT Adjust offset was positive. This made the final WGDC higher than the map-read value.
Then, as measured intake air temp dropped, the offset reduced. Around 26C, the WGDC was left alone.
Finally, as IAT kept dropping, the offset went very slightly negative. At that point, the final WGDC was a hair lower than the map-read value.
Cool.
Please note: I'm not sure if my WGDC offsets are sane - I used the finger-in-the-wind method to populate the new table. :P
It should be enough to get me in the ballpark, though. I guess I'll find out how close the "hot" offsets are come summer!
For anyone fooling with disassembly, I'd be happy to throw up the innards of this, as a kind of "anatomy of a patch". If someone would find that interesting, shout - I'd be happy to.
This one is actually a good example of a ROM patch - it's dead easy to follow, has no twisty/tricky bits, but has just enough meat on its bones to be worth going over. You'll just have to ignore the snoring from up the back - that'll be tephra & company...
Cheers!
Rich