Links to jcsbanks' Speed Density patches
Okay, here we go.
Eric, I know you already know this, but for anyone else reading: THIS WILL NOT WORK WITH ANY OTHER VERSION OF 96530706!. v7t5 won't work with these instructions. Plain old 96530006 won't work with these instructions. Tephra's 5.10 release won't work with these instructions. Some future version of tephra's mods very likely won't work with these instructions. This is very specifically tied to this particular version of this particular ROM release.
Now that that's out of the way, add the following XML to the end of TephraMOD-96530706-v7t6.xml, just before </rom>:
Next, download this pre-patched 96530706 ROM. It is is a bone-stock version of tephra's 96530706 v7t6 ROM, with the DMA/live-mapping changes described below already made to it. If you don't mind starting from scratch, it's a perfectly fine ROM to use, and you can skip the next section.
Assuming, though, that you already have a ROM you'd like to use (because you've already made a ton of changes to it yourself, perhaps, or you started from another already-patched ROM, like mrfred's speed-density version, or phenem's pre-patched "USDM edition"), let's go through what's been changed to make live-mapping happen.
First, open up both your ROM, and the pre-patched ROM. In your ROM, scroll down to the new section labeled "DMA Logging/Mapping", and make the following changes:
Save your changes (to a new file, just in case you made an error, or just in case my instructions are wrong!), and your ROM will now be roughly equivalent to the downloaded ROM.
At this point, there's one other change I'd suggest: open up the MUT table, and copy the value at MUT41 (1-byte load) to MUT00, so that the Live Map desktop client will log it as part of the first 0x33 requests it automatically grabs (I haven't looked much at the most recent version that jcsbanks released yet, so I don't know if the default MUT table retrieval behavior changed; in the original version, the first 51 (0x33) MUT requests were blindly grabbed).
Okay, now you'll need to make some changes to the PC live-mapping client XML configuration files. First, open up address.xml, and change the two sets of <address> stanzas. The first one should have "a0" as addresshi, and "4d" as addresslo; leave that one alone. The second one should have "a2" as hi, and "cd" as low; change those to "a1" and "8d", respectively.
The next file we need to edit is blockaddress.xml. There are four sections named <blockaddress>; the first of these lists Address3 as 00, Address2 as 03, Address1 as 8b, and Address4 as 00; change those to "00", "03", "7b", and "00", respectively. Leave the rest alone, they're fine.
And, after all that, you're done. This should be considered almost totally untested; my car runs right now with this (and even seems to exhibit signs of working), but if it breaks for you, you get to keep both pieces.
Eric, if you see anything obviously wrong with the above, let me know. I realized while going through this tonight why you were seeing a bunch of 0x3f000 and higher addresses; that's where tephra's code lived in v5.10, but it all moved down into the 0x3e000 range in v7.
If this works out for you, I'll cut-and-paste this over into the 96530006 live-mapping thread where it belongs, instead of continuing to clutter up mrfred's thread with this stuff.
(And now, I'm going to bed; just so noone is waiting on me for anything, I probably won't be able to look at this stuff again until sometime on Monday. Have fun!)
EDIT 7/22/2009: Updated location of "tephra adjustment #2" table.
Eric, I know you already know this, but for anyone else reading: THIS WILL NOT WORK WITH ANY OTHER VERSION OF 96530706!. v7t5 won't work with these instructions. Plain old 96530006 won't work with these instructions. Tephra's 5.10 release won't work with these instructions. Some future version of tephra's mods very likely won't work with these instructions. This is very specifically tied to this particular version of this particular ROM release.
Now that that's out of the way, add the following XML to the end of TephraMOD-96530706-v7t6.xml, just before </rom>:
Code:
<!-- Interrupt vectors --> <table name="DMAC3 DEI3 Interrupt" category="DMA Logging/Mapping" address="138" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x138</data> <data>0x13A</data> </table> </table> <table name="SCI0 RXI0 Interrupt" category="DMA Logging/Mapping" address="324" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x324</data> <data>0x326</data> </table> </table> <table name="SCI0 TEI0 Interrupt" category="DMA Logging/Mapping" address="32c" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x32C</data> <data>0x32E</data> </table> </table> <!-- SCI0 RXI0 interrupt code changes --> <table name="RXI0 code change #1 (cmp/eq #0x37, r0)" category="DMA Logging/Mapping" address="d46e" type="2D" scaling="Hex8"> <table name="Address" type="Static X Axis" elements="3"> <data>D46E</data> <data>D46F</data> <data>D470</data> </table> </table> <table name="RXI0 code change #2 (DMAOPFLAG)" category="DMA Logging/Mapping" address="d6dc" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0xD46C</data> <data>0xD46F</data> </table> </table> <table name="RXI0 code change #3 (nop)" category="DMA Logging/Mapping" address="dc26" type="2D" scaling="Hex8"> <table name="Address" type="Static X Axis" elements="2"> <data>0xDC26</data> <data>0xDC27</data> </table> </table> <table name="RXI0 code change #4 (nop)" category="DMA Logging/Mapping" address="e9e6" type="2D" scaling="Hex8"> <table name="Address" type="Static X Axis" elements="2"> <data>0xE9E6</data> <data>0xE9E7</data> </table> </table> <!-- Change tephra entry-point to dma logging. --> <table name="RXI0 DMA entry-point" category="DMA Logging/Mapping" address="efac" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0xEFAC</data> <data>0xEFAE</data> </table> </table> <!-- DMA code --> <table name="DMA Code" category="DMA Logging/Mapping" address="3ec00" type="3D" scaling="Hex16"> <table name="X" type="Static X Axis" elements="25"/> <table name="Y" type="Static Y Axis" elements="17"/> </table> <!-- tephra adjustments --> <table name="tephra adjustment #1 (1-byte load?)" category="DMA Logging/Mapping" address="3e1e0" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x3E1E0</data> <data>0x3E1E2</data> </table> </table> <table name="tephra adjustment #2 (DEADloc)" category="DMA Logging/Mapping" address="3e638" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x3E638</data> <data>0x3E85A</data> </table> </table> <!-- RAM alt-maps --> <table name="Alternate scaling in RAM" category="DMA Logging/Mapping" address="3e808" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x3E808</data> <data>0x3E80A</data> </table> </table> <table name="Alternate fuel in RAM" category="DMA Logging/Mapping" address="3e810" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x3E810</data> <data>0x3E812</data> </table> </table> <table name="Alternate timing in RAM" category="DMA Logging/Mapping" address="3e81c" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x3E81C</data> <data>0x3E81E</data> </table> </table> <table name="Alternate BWGDC in RAM" category="DMA Logging/Mapping" address="3e828" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x3E828</data> <data>0x3E82A</data> </table> </table> <table name="Alternate BDEL in RAM" category="DMA Logging/Mapping" address="3e830" type="2D" scaling="Hex16"> <table name="Address" type="Static X Axis" elements="2"> <data>0x3E830</data> <data>0x3E832</data> </table> </table>
Assuming, though, that you already have a ROM you'd like to use (because you've already made a ton of changes to it yourself, perhaps, or you started from another already-patched ROM, like mrfred's speed-density version, or phenem's pre-patched "USDM edition"), let's go through what's been changed to make live-mapping happen.
First, open up both your ROM, and the pre-patched ROM. In your ROM, scroll down to the new section labeled "DMA Logging/Mapping", and make the following changes:
- "DMAC3 DEI3 Interrupt" should start out as 0000 9C84. Change it to 0003 ED10. (Remember, when entering hex entries, always type a "0x" in front of the entry. So, in this case, when you click on "9C84", and hit "=" to edit it, type "0xED10" to replace it.)
- "SCI0 RXI0 Interrupt" should be 0000 D5D4. Change it to 0003 EC00.
- "SCI0 TEI0 Interrupt" should be 00009 C84. Change it to 0003 EE30.
- "RXI0 code change #1" should be C8 01 8B. Change it to 88 37 89.
- "RXI0 code change #2" should be FFFF ECCC. Change it to FFFF 8480.
- "RXI0 code change #3" should be 2A 00. Change it to 00 09.
- "RXI0 code change #4" should be 2B A2. Change it to 00 09.
- "RXI0 DMA entry-point" should be 0003 E000. Change it to 0003 EEB0.
- "DMA Code" should be a big table full of "FFFF". Copy the entire table from the ROM you downloaded above, and paste it into the ROM you're editing. (Open the table in the downloaded ROM, click a cell, hit CTRL-A, and hit CTRL-C. Close it, then open the table in your ROM. Click the upper-left corner cell, and hit CTRL-V.)
- "tephra adjustment #1" should be FFFF 8984. Change it to FFFF 898A.
- "tephra adjustment #2" should be FFFF 841E. Change it to FFFF A800.
- "Alternate scaling in RAM" should be 0003 7B40. Change it to FFFF A040.
- "Alternate fuel in RAM" should be 0003 7B42. Change it to FFFF A042.
- "Alternate timing in RAM" should be 0003 7C82. Change it to FFFF A182.
- "Alternate BWGDC in RAM" should be 0003 7E42. Change it to FFFF A342.
- "Alternate BDEL in RAM" should be 0003 7EC2. Change it to FFFF A3C2.
Save your changes (to a new file, just in case you made an error, or just in case my instructions are wrong!), and your ROM will now be roughly equivalent to the downloaded ROM.
At this point, there's one other change I'd suggest: open up the MUT table, and copy the value at MUT41 (1-byte load) to MUT00, so that the Live Map desktop client will log it as part of the first 0x33 requests it automatically grabs (I haven't looked much at the most recent version that jcsbanks released yet, so I don't know if the default MUT table retrieval behavior changed; in the original version, the first 51 (0x33) MUT requests were blindly grabbed).
Okay, now you'll need to make some changes to the PC live-mapping client XML configuration files. First, open up address.xml, and change the two sets of <address> stanzas. The first one should have "a0" as addresshi, and "4d" as addresslo; leave that one alone. The second one should have "a2" as hi, and "cd" as low; change those to "a1" and "8d", respectively.
The next file we need to edit is blockaddress.xml. There are four sections named <blockaddress>; the first of these lists Address3 as 00, Address2 as 03, Address1 as 8b, and Address4 as 00; change those to "00", "03", "7b", and "00", respectively. Leave the rest alone, they're fine.
And, after all that, you're done. This should be considered almost totally untested; my car runs right now with this (and even seems to exhibit signs of working), but if it breaks for you, you get to keep both pieces.
Eric, if you see anything obviously wrong with the above, let me know. I realized while going through this tonight why you were seeing a bunch of 0x3f000 and higher addresses; that's where tephra's code lived in v5.10, but it all moved down into the 0x3e000 range in v7.
If this works out for you, I'll cut-and-paste this over into the 96530006 live-mapping thread where it belongs, instead of continuing to clutter up mrfred's thread with this stuff.
(And now, I'm going to bed; just so noone is waiting on me for anything, I probably won't be able to look at this stuff again until sometime on Monday. Have fun!)
EDIT 7/22/2009: Updated location of "tephra adjustment #2" table.
Last edited by logic; Jul 22, 2009 at 09:43 AM.
You make me laugh, John. 
Obviously, a huge thanks to you for getting this stuff done in the first place. Keep us posted on your adventures with the GT-R and don't forget about us here. We will ensure your awesome ECU mods live on. 
Logic - awesome....thanks for getting this posted up. I'll test soon enough. I'm thinking within a couple weeks I will be switched over to SD. I will also add the instructions about the latest livemap client and setting up an alt MUT table in RAM, if I have not already in the other 96530006 livemap download thread.
Thanks again guys...truly appreciated.
Eric
Obviously, a huge thanks to you for getting this stuff done in the first place. Keep us posted on your adventures with the GT-R and don't forget about us here. We will ensure your awesome ECU mods live on. Logic - awesome....thanks for getting this posted up. I'll test soon enough. I'm thinking within a couple weeks I will be switched over to SD. I will also add the instructions about the latest livemap client and setting up an alt MUT table in RAM, if I have not already in the other 96530006 livemap download thread.
Thanks again guys...truly appreciated.
Eric
John, I officially hate. you. Jealousy is an ugly thing.
I'm with Eric on this one: you wrote all of this stuff, we're just trying to keep it working. This is all thanks to you, and those of us who've used your live mapping client for more than five minutes or know how speed density works understand how cool this all is, and are very appreciative!
Good luck with the GTR, hopefully you'll have some luck with the ECU in that one too! Just be very careful with the launches, I hear those transmissions are a wee bit expensive. You'll have to see if you can get a Consult-III and your ECU into Colby's hands to try and get flashing working. Have fun, and let us know how you like it. 
I'm with Eric on this one: you wrote all of this stuff, we're just trying to keep it working. This is all thanks to you, and those of us who've used your live mapping client for more than five minutes or know how speed density works understand how cool this all is, and are very appreciative!
Good luck with the GTR, hopefully you'll have some luck with the ECU in that one too! Just be very careful with the launches, I hear those transmissions are a wee bit expensive.
You'll have to see if you can get a Consult-III and your ECU into Colby's hands to try and get flashing working. Have fun, and let us know how you like it.
Newbie
Joined: Nov 2006
Posts: 17
Likes: 0
From: Union City, Ca
96530706 Boost control
I have been playing around with the 96530706 tephra speed density rom from this thread.
I've got everything working out good but the boost control.
I understand the gear dependent boost control and what goes along with it but it seems I am missing something. For some reason it keeps adding duty cycle to the solenoid even when the target boost has been surpassed.
I know that all the old boost control maps are now obsolete with the v7tephra map but without those I do not have a boost correction map. Is there something I am missing in my XML? If anybody has time to look over this I would greatly appreciate it.
I've got everything working out good but the boost control.
I understand the gear dependent boost control and what goes along with it but it seems I am missing something. For some reason it keeps adding duty cycle to the solenoid even when the target boost has been surpassed.
I know that all the old boost control maps are now obsolete with the v7tephra map but without those I do not have a boost correction map. Is there something I am missing in my XML? If anybody has time to look over this I would greatly appreciate it.
I haven't tested this yet, but I will put up instructions for 96530706 v7t6 on how to move the SD tuning maps to RAM, so that you can use live mapping to tune your SD instead of flashing repeatedly.
Since I am about to convert to SD, I wanted to get this setup. Of course, this assumes that you already know how to use jcsbanks LiveMap app. If this gets some interest, I may make a new thread showing how to setup everything...the livemap app, your ROM, etc.
Eric
Since I am about to convert to SD, I wanted to get this setup. Of course, this assumes that you already know how to use jcsbanks LiveMap app. If this gets some interest, I may make a new thread showing how to setup everything...the livemap app, your ROM, etc.
Eric
Last edited by l2r99gst; Jul 16, 2009 at 05:25 PM.
I have not tested this, so if you understand this and want to try it out, do so at your own risk. I will test soon enough, but wanted to possibly help a few people out that are interested in live mapping and SD. Also these instructions are building off of the work logic has done to implement the DMA and livemapping code in this ROM. So, I believe at this point, that was untested as well. This is only good for the 96530706 v7t6 ROM that has been patched with mrfred's SD patch.
OK, the basic instructions to move a map to RAM is to:
1. Copy the map header and data to the 'alt maps space'. This is the 0x800 length of ROM space that John copies to RAM. This is where the tephra alt maps live as well as any other maps that we want to tune or run from RAM.
2. Change the pointer to the map from the old ROM address to the new RAM address
Let's run through that process for the two SD tuning tables; the SD MAP VE table and SD RPM VE table. To follow along, use the following XML defs for 96530706 v7t6 only, which has been patched for SD and DMA/Livemapping:
Edit: 7/17-updated the defs for RAM SD maps to move to last line of alt maps space (originally had the wrong address)
OK, once you have put those XML defs into the TephraMOD-96530706-v7t6.xml file, open your ROM. You should see two new tables under the 'Speed Density Tuning' section, as shown here:
1. Copy the data from the right column of your main maps to the RAM maps, so that both MAP VE tables and both RPM VE tables look the same. Here is just and example from my ROM that I will use as the starting values for my MAP VE:
2. Now, open the 'SD MAP VE pointer' and SD RPM VE pointer' maps. This is where we change the pointer in the ROM to read these maps from RAM. In the tables, I have included the stock value, so it's easy to go back if need be. Change the tables as shown below:
3. OK, one last step. Open the 'Alt maps space' table. This is a big table showing the entire space of the ROM that is copied to RAM. Back in step #1 we just copied the data from the two SD tables to this space. If you open it and look at it, based on the XML defs I provided, we added the data to the very last line of this table. We now have to copy the table headers in front of the table. Below is a screenshot of the last 3 rows of my table (since this table is soo big I'm using a partial screenshot). Look at the last line in the screenshot below (by the way the third and second to last lines is where I put my RAM MUT table. So your ROM should have all blocks of FFFF there):
Make the blocks of FFFF in your last line look exactly like mine. If you did step #1 correctly, then your last line should read:
FFFF FFFF FFFF FFFF (8 bins of your data MAP VE data) FFFF FFFF FFFF (9 bins of your RPM VE data)
So change the last line to:
0002 0000 FFFF 886C (8 bins of your data MAP VE data) 0200 FFFF 886C (9 bins of your RPM VE data)
Note: Remember that you have to type 0x first when entering hex data into ECUFlash.
You're just adding in the 0002 0000 FFFF 886C in front of the first map and 0200 FFFF 886c in front of the second map. That change is the table header data.
OK, that should be enough for now. Maybe I can tidy these instructions up and make better defs for easier implementation, etc. But, if you understand this at all, this gives you the basics on how to move maps to RAM to be able to live tune them. The second part of this is using John's livemap app and ECUFlash to live tune.
Eric
OK, the basic instructions to move a map to RAM is to:
1. Copy the map header and data to the 'alt maps space'. This is the 0x800 length of ROM space that John copies to RAM. This is where the tephra alt maps live as well as any other maps that we want to tune or run from RAM.
2. Change the pointer to the map from the old ROM address to the new RAM address
Let's run through that process for the two SD tuning tables; the SD MAP VE table and SD RPM VE table. To follow along, use the following XML defs for 96530706 v7t6 only, which has been patched for SD and DMA/Livemapping:
Edit: 7/17-updated the defs for RAM SD maps to move to last line of alt maps space (originally had the wrong address)
Code:
<table name="RAM SD MAP VE" category="Speed Density Tuning" address="382c8" type="2D" level="1" scaling="MAP VE load"> <table name="MAP" address="32c6" type="Y Axis" elements="8" scaling="MAP 16bit"/> </table> <table name="RAM SD RPM VE" category="Speed Density Tuning" address="382de" type="2D" level="1" scaling="Percent (128)"> <table name="RPM" address="65f6" type="Y Axis" elements="17" scaling="RPM"/> </table> <table name="SD MAP VE pointer - ROM to RAM" category="DMA Logging/Mapping" address="114bc" type="2D" scaling="Hex16"> <table name="ROM pointer-change to RAM loc to enable live mapping" type="Static X Axis" elements="2"> <data>0000</data> <data>32E0</data> </table> </table> <table name="SD RPM VE pointer - ROM to RAM" category="DMA Logging/Mapping" address="7cfc" type="2D" scaling="Hex16"> <table name="ROM pointer-change to RAM loc to enable live mapping" type="Static X Axis" elements="2"> <data>0000</data> <data>3376</data> </table> </table> <table name="Alt maps space" category="DMA Logging/Mapping" address="37b00" type="3D" level="1" scaling="Hex16"> <table name="X" type="Static X Axis" elements="32"/> <table name="Y" type="Static Y Axis" elements="32"> <data>0</data> <data>40</data> <data>80</data> <data>c0</data> <data>100</data> <data>140</data> <data>180</data> <data>1c0</data> <data>200</data> <data>240</data> <data>280</data> <data>2c0</data> <data>300</data> <data>340</data> <data>380</data> <data>3c0</data> <data>400</data> <data>440</data> <data>480</data> <data>4c0</data> <data>500</data> <data>540</data> <data>580</data> <data>5c0</data> <data>600</data> <data>640</data> <data>680</data> <data>6c0</data> <data>700</data> <data>740</data> <data>780</data> <data>7c0</data> </table> </table>
1. Copy the data from the right column of your main maps to the RAM maps, so that both MAP VE tables and both RPM VE tables look the same. Here is just and example from my ROM that I will use as the starting values for my MAP VE:
2. Now, open the 'SD MAP VE pointer' and SD RPM VE pointer' maps. This is where we change the pointer in the ROM to read these maps from RAM. In the tables, I have included the stock value, so it's easy to go back if need be. Change the tables as shown below:
3. OK, one last step. Open the 'Alt maps space' table. This is a big table showing the entire space of the ROM that is copied to RAM. Back in step #1 we just copied the data from the two SD tables to this space. If you open it and look at it, based on the XML defs I provided, we added the data to the very last line of this table. We now have to copy the table headers in front of the table. Below is a screenshot of the last 3 rows of my table (since this table is soo big I'm using a partial screenshot). Look at the last line in the screenshot below (by the way the third and second to last lines is where I put my RAM MUT table. So your ROM should have all blocks of FFFF there):
Make the blocks of FFFF in your last line look exactly like mine. If you did step #1 correctly, then your last line should read:
FFFF FFFF FFFF FFFF (8 bins of your data MAP VE data) FFFF FFFF FFFF (9 bins of your RPM VE data)
So change the last line to:
0002 0000 FFFF 886C (8 bins of your data MAP VE data) 0200 FFFF 886C (9 bins of your RPM VE data)
Note: Remember that you have to type 0x first when entering hex data into ECUFlash.
You're just adding in the 0002 0000 FFFF 886C in front of the first map and 0200 FFFF 886c in front of the second map. That change is the table header data.
OK, that should be enough for now. Maybe I can tidy these instructions up and make better defs for easier implementation, etc. But, if you understand this at all, this gives you the basics on how to move maps to RAM to be able to live tune them. The second part of this is using John's livemap app and ECUFlash to live tune.
Eric
Last edited by l2r99gst; Jul 20, 2009 at 06:43 PM.
logic,
I may need your help tp update the livemap app to add new screens for additional livemap tables. I'm sure I could eventually figure it out, but it's been a while programming in VB.
John already has the tabs for livemapping fuel and timing, but we can add tabs to lievmap whatever tables we add to RAM, like the SD tables, for example.
Of course, you don't need to use the LiveMap app to live map...just makes it easier. You can still do it by choosing the ROM file in the Livemap app, opening ECUFlash, make the change the the RAM map and save, then click Write in the LiveMap app.
Eric
I may need your help tp update the livemap app to add new screens for additional livemap tables. I'm sure I could eventually figure it out, but it's been a while programming in VB.
John already has the tabs for livemapping fuel and timing, but we can add tabs to lievmap whatever tables we add to RAM, like the SD tables, for example.
Of course, you don't need to use the LiveMap app to live map...just makes it easier. You can still do it by choosing the ROM file in the Livemap app, opening ECUFlash, make the change the the RAM map and save, then click Write in the LiveMap app.
Eric
Ugh, John and I are in agreement about GUI programming; the embedded stuff is fine, but me and VB don't really get along very well (I'm a UNIX guy to boot, so I'm a fish out of water doing Windows development). But, usability of the live mapping application is going to have to improve dramatically if we want people to start adopting it, I suppose.
For adding code to support additional tables in the short term, I'd probably suggest just adding a new "Speed Density" tab, and then looking at how John added code behind the "Read RAM Fuel" and "Write RAM Fuel" buttons on the Fuel tab (specifically, the code in the "Buttons" region, under "Buttons for fuel and ignition read/write ECU RAM": Readfuelbutton_Click and Writefuelbutton_Click). The code to actually read and write to the ECU is pretty straightforward, it's just a matter of representation on the screen via a DataGridView.
(Aside: am I the only one disgusted at how slow this stuff feels, especially data grid updates, even on a relative fast machine? Ugh.)
Going a bit further down this road, I think there's a couple of bits of "infrastructure" that the client needs at this point before it starts being a little more "generally useful":
That being said, I'm thinking along the same lines as you in your last paragraph: I wonder if it's worth the trouble of adding all this additional functionality to the live mapping client, when we could essentially punt and use EcuFlash as the editor (which, frankly, is probably going to be much better in the short term than anything we'd come up with)?
But, usability of the live mapping application is going to have to improve dramatically if we want people to start adopting it, I suppose.For adding code to support additional tables in the short term, I'd probably suggest just adding a new "Speed Density" tab, and then looking at how John added code behind the "Read RAM Fuel" and "Write RAM Fuel" buttons on the Fuel tab (specifically, the code in the "Buttons" region, under "Buttons for fuel and ignition read/write ECU RAM": Readfuelbutton_Click and Writefuelbutton_Click). The code to actually read and write to the ECU is pretty straightforward, it's just a matter of representation on the screen via a DataGridView.
(Aside: am I the only one disgusted at how slow this stuff feels, especially data grid updates, even on a relative fast machine? Ugh.)
Going a bit further down this road, I think there's a couple of bits of "infrastructure" that the client needs at this point before it starts being a little more "generally useful":
- Handle arbitrarily-defined 1D, 2D, and 3D tables. Some sort of configuration file (XML?), much like EcuFlash currently has, that correlates in-ROM locations/lengths to RAM addresses. It would be useful to add support for opening and reading files out of EcuFlash's rommetadata directory to make this easier; ie. just grab the install location from HKEY_LOCAL_MACHINE\software\EcuFlash\path, tack on "rommetadata", then re-implement the code Colby uses to search for an appropriate XML for a given ROM ID, write code for handling <include/> directives, and write a rudimentary table parser. (I've already done this in Python for a side project of my own, and it was annoying re-inventing the wheel; I'd have much preferred to put the work into creating reusable components out of the bits of EcuFlash that do that already, but that's hard to do with no source and an intentionally-obfuscated executable). The EcuFlash table data would give you the ROM location and length, and local live-map configuration could correlate tables by name to their RAM location.
- In a related vein, we'll probably need support for multiple ROMs with a single installation, to allow for tuners who work on multiple cars. Maybe ask the user for a path to a ROM image prior to letting you start logging, and pull the ROM ID from that directly (at which point, you know the addresses to read for fuel, ignition, MUT, etc).
- More user-friendliness: reasonable auto-detection of DMA capabilities, with a proper error message for the user. I outlined a possible strategy for detection (and graceful degradation, in the case of a more general client like EvoScan) in the "how the dma code works" thread. In a perfect world, I'd probably suggest adding rudimentary MUT logging code to this, so even if you can't do DMA (and live RAM updates), you can at least log something in a format about as sophisticated as MitsuLogger.
That being said, I'm thinking along the same lines as you in your last paragraph: I wonder if it's worth the trouble of adding all this additional functionality to the live mapping client, when we could essentially punt and use EcuFlash as the editor (which, frankly, is probably going to be much better in the short term than anything we'd come up with)?
That being said, I'm thinking along the same lines as you in your last paragraph: I wonder if it's worth the trouble of adding all this additional functionality to the live mapping client, when we could essentially punt and use EcuFlash as the editor (which, frankly, is probably going to be much better in the short term than anything we'd come up with)?
Other than what you wrote, I didn't see mention about finding the pointer or reference to the ROM location for a certain map. When a map is moved to RAM, you have to find the reference in the ROM from the header of the map and change that pointer to your new RAM address. That may be difficult to automatically do.
Anyway, my trial version of VB that I had expired, but maybe I can build a vmware image and install it there to see if I can make something for at least the SD tables. I doubt it, but I'll have fun trying...as long as I can find the time.
Yeah, this is the part where you have to decide what you want to do with your personal car and what's technically possible, vs. what's possible to support for non-technical folks. Welcome to Tom and Dave's life (@ECMTuning). (Edit: for the record, I don't see an obvious way to determine whether a table has been moved or not, unless you want to add a LOT of complexity to configuration by defining references to the common tables and verifying them against "stock" values.)
I just pulled down VB 2008 Express, which seems to build John's stuff just fine; it's what I used to rebuild the client originally so it'd fit on my tiny little 800x600 screen, and the last copy of his development tree that John posted in the 96530006 thread builds right out of the box with it (you have to copy ZedGraph.dll into the bin\Release directory, though.)
I don't believe it has an expiration date on it, but there's a limit to the size of your project, if memory serves.
(Edit: for the record, I don't see an obvious way to determine whether a table has been moved or not, unless you want to add a LOT of complexity to configuration by defining references to the common tables and verifying them against "stock" values.)
Anyway, my trial version of VB that I had expired, but maybe I can build a vmware image and install it there to see if I can make something for at least the SD tables. I doubt it, but I'll have fun trying...as long as I can find the time.
I don't believe it has an expiration date on it, but there's a limit to the size of your project, if memory serves.
Weird. I thought you just had to register it; you only get 30 days if you don't register it with Microsoft (fire up VB Express, go to Help, click "Register Product", fill in a bunch of fake information) and get an activation key, but otherwise I've been using this same copy for quite a while...