Links to jcsbanks' Speed Density patches
Jun 26, 2009, 11:09 AM
#153
All the ROMs in the first post are "patched". There are two ways to make use of these ROMs. One is to copy all your tables over to the "patched" ROM. The other way is to copy the patch over to your existing ROM. Either way is ok, but I think its far easier to copy the SD patch to an existing ROM and recommend that approach unless you are looking to run a new tephra ROM that you haven't used before. In this latter case, I have created "SD prepatched" tephra ROMs. I will be adding "SD prepatched" v5 and v7 ROMs little by little.
Jun 26, 2009, 12:19 PM
#154
oh so the "patch" is just changing all the values in the SD specific tables. Gotcha, that is what i did last time and found it to be way easier. You also run less risk of forgetting to copy a table that you changed in the distant past.
Thanks and great work as always. I cant wait for the boost control in V7 mixed with SD
Thanks and great work as always. I cant wait for the boost control in V7 mixed with SD
Jul 8, 2009, 03:37 PM
#156
mrfred - when patching v7t6 with your v7t5 96530706 SD patch I'm getting funking data in the SD MAP Sensor VE and Calibration tables. I assume this is ok since I'm not opening your patched v7t5 ROM so I have to copy your data into these tables to effectively active the SD patch?
Just wanted to confirm this with you before I start copying and pasting. Thanks.
Just wanted to confirm this with you before I start copying and pasting. Thanks.
Jul 8, 2009, 03:55 PM
#157
Opening v7t5 and v7t6 is a little tricky...they both are listed as 96530706, so the correct xml may not be inherited and some of the tephra addresses are different. So, to be safe, it's better to install ECUFlash in a separate directory (or copy the .exe and dlls) to work with both v7t5 and v7t6 (open v7t5 in one instance pointing to a directory with only the v7t5 xml and use the other ECUFlash instance to open v7t6 with only the v7t6 xml...both directories need the base 96530006 xml and the evobase xml).
I know it sounds a bit confusing, but this is only for people that have downloaded and used both v7t5 and v7t6.
But, to answer your question, your method is correct. Open a patched ROM and unpatched ROM and then copy the patched table data over to the unpatched ROM.
I know it sounds a bit confusing, but this is only for people that have downloaded and used both v7t5 and v7t6.
But, to answer your question, your method is correct. Open a patched ROM and unpatched ROM and then copy the patched table data over to the unpatched ROM.
Last edited by l2r99gst; Jul 8, 2009 at 05:11 PM.
Jul 8, 2009, 06:39 PM
#158
Actually, after I went through the trouble of copying stuff around, I realized there's an easier way to go from t5 to t6: change the ID on the old ROM and in the old XML to something else, like 96530716 or something, and do it all with one installation of EcuFlash. 
Jul 10, 2009, 12:54 PM
#160
Okay, it's still randomly rebooting on me during comm initialization (MUT logging still works fine, and everything else looks peachy; I'm still impressed at how low-impact this addition is). Here's what I've changed in 96530706 to add John's DMA code, for anyone else who might want to peek at this as well:
Interrupt handlers: jcsbanks, l2r99gst, mrfred, tephra, or anyone else who feels like taking a peek at this, can you see anything obvious that I've missed? I'm particularly curious about the changes to those two locations in tephra's code; I haven't dug into what's happening there enough to know why he changed that.
Interrupt handlers:
- 0x138: DMAC3 DEI3 vector changed from 0x9c84 to 0xed10.
- 0x324: SCI0 RXI0 vector changed from 0xd5d4 to 0x3ec000 (location of John's new code).
- 0xd46e: Changed "tst #1, r0" (c8 01 8b) to "cmp/eq #0x37, r0" (88 37 89).
- 0xd6dc: Changed 0xffffeccc reference to 0xffff8480 (DMAOPFLAG).
- 0xdc26: Changed "mov.b r0, @r10" (2a 00) to "nop" (00 09).
- 0xe9e6: Changed "mov.l r10, @r11"(2b a2) to "nop" (00 09).
- 0xefac: Changed 0x3e000 (tephra's entry point) to 0x3eeb0 (John's entry point).
- Copy John's chunk of code at 3ec00 through 3ef5f. I've actually gone to the trouble of re-assembling this now, and the assembled version matches what I ended up with through hex editing. Go figure. If you don't re-assemble his source, you need to make the following changes:
- 0x3ef18: Changed 0xffffa800 to 0xffff841e (tephra's DEAD address).
- 0x3ef30: Changed 0x3f000 to 0x3e000 (tephra's entry point).
- 0x3ef34: Changed 0x38b00 to 0x37b00 (new start of alt-map location).
- 0x3e1d4: Changed 0xffff8984 reference to 0xffff898a (this is a WTF for me, but it was changed in John's version of 96530006).
- 0x3e640: Changed 0xffff841c reference to 0xffffa800 (another WTF, same thing).
- 0x3e7d4: Changed 0x37b40 to 0xffffa040 (alt injector scaling). This isn't strictly necessary, since I don't think the client actually supports scaling adjustments right now, does it? (Anyone want to write a feedback-driven injector latency and scaling tuning tool using this?
) - 0x3e7dc: Changed 0x37b42 to 0xffffa042 (alt high-octane fuel).
- 0x3e7e8: Changed 0x37c82 to 0xffffa182 (alt high-octane timing).
- 0x3e7f4: Changed 0x37e42 to 0xffffa342 (alt BWGDC).
- 0x3e7fc: Changed 0x37ec2 to 0xffffa3c2 (alt BDEL).
- MUT0 (or something similar) should probably be changed to 1-byte load.
- In the client, address.xml needs to be changed so that the high-octane timing map is at a182, rather than a2cd.
- In the client, blockaddress.xml needs to be changed so that the "ROM address" is at 0x37b0, not 0x038b0.
jcsbanks, l2r99gst, mrfred, tephra, or anyone else who feels like taking a peek at this, can you see anything obvious that I've missed? I'm particularly curious about the changes to those two locations in tephra's code; I haven't dug into what's happening there enough to know why he changed that.I'm going to go through this and see if I see anything that sticks out right away. I will summarize in the post below to make it easier to read/separate from this post.
Eric
Last edited by l2r99gst; Jul 10, 2009 at 01:39 PM.
Jul 10, 2009, 12:59 PM
#161
A quick correction that I see to what you have:
should be 0x03ED10
I don't see mention of this change:
Serial port TEI, address 0x32c: changed from 0x9C84 to 0x3EE30
John has this listed as 'Dead loc JB'. For 'Dead loc Tephra', he has at address 0x3f5d6 and the value was changed from 0x841c to 0xA800.
Also, there is the following...I think you have some of this implemented above (with the different addresses), but just mentioned to be sure:
@0x3f1aa - 'Tephra 1 byte load source': changed from 0x8984 to 0x898a
@0x3f64c - 'Tephra map vectors': I think this is a table that lists the ROM locations for the maps that are in alt maps and the corresponding RAM locations for setting the alt maps in RAM.
Eric
Interrupt handlers:[list][*]0x138: DMAC3 DEI3 vector changed from 0x9c84 to 0xed10.
I don't see mention of this change:
Serial port TEI, address 0x32c: changed from 0x9C84 to 0x3EE30
0x3ef18: Changed 0xffffa800 to 0xffff841e (tephra's DEAD address).
Also, there is the following...I think you have some of this implemented above (with the different addresses), but just mentioned to be sure:
@0x3f1aa - 'Tephra 1 byte load source': changed from 0x8984 to 0x898a
@0x3f64c - 'Tephra map vectors': I think this is a table that lists the ROM locations for the maps that are in alt maps and the corresponding RAM locations for setting the alt maps in RAM.
Eric
Last edited by l2r99gst; Jul 10, 2009 at 04:49 PM.
Jul 10, 2009, 02:08 PM
#162
Oh, dammit, nice catch on that typo. That would explain why it's rebooting as soon as DMA kicks in, wouldn't it? 
Looks like I missed the SCI0 TEI0 interrupt too, fantastic. Between the two of those, that would probably explain why logging keeps failing.
As for the DEAD stuff, I think I see what's going on here. He's changing the DEAD address from 841c to 3800, and changing tephra's code (one of the WTF notes in my original post) to match.
One note: the addresses you're throwing around look like the addresses John used for the IX ROM, no? There shouldn't be any new code in 0x3f000 or higher...
tephra, if you're reading this: have you ever posted the assembly source for your work anywhere? (Or is it even something you're willing to share?) I'm half-tempted to start up a section of the wiki just for source code, or possibly just set up a subversion repository to keep it (at least as a backup for the original authors; in John's case, for example, there's noone left to continue development since he has his eyes set on a new, more dignified platform).
Looks like I missed the SCI0 TEI0 interrupt too, fantastic. Between the two of those, that would probably explain why logging keeps failing.As for the DEAD stuff, I think I see what's going on here. He's changing the DEAD address from 841c to 3800, and changing tephra's code (one of the WTF notes in my original post) to match.
One note: the addresses you're throwing around look like the addresses John used for the IX ROM, no? There shouldn't be any new code in 0x3f000 or higher...
tephra, if you're reading this: have you ever posted the assembly source for your work anywhere? (Or is it even something you're willing to share?) I'm half-tempted to start up a section of the wiki just for source code, or possibly just set up a subversion repository to keep it (at least as a backup for the original authors; in John's case, for example, there's noone left to continue development since he has his eyes set on a new, more dignified platform
).
Jul 10, 2009, 03:51 PM
#163
Originally Posted by logic
One note: the addresses you're throwing around look like the addresses John used for the IX ROM, no? There shouldn't be any new code in 0x3f000 or higher...
Eric
Jul 10, 2009, 04:03 PM
#164
Hot damn, that was the problem. I added the missing TEI interrupt vector and fixed the typo on the DMA vector (and did a bit of rethinking on the DEAD stuff), and now DMA logging seems to work (with v7t6). I haven't tested RAM writes yet, but if the rest is functioning, I'd be very surprised if writing failed.
I'm really short on time, so I can't make a more useful post right now; give me until later tonight, and I should be able to post some instructions that are a little easier to follow than the mess I posted above. By the way, there's at least two or three significant changes in what I originally posted when you move from t5 to t6.
(I would love to see tephra include this in his patches; it's not that invasive, but it does depend on the location of a few things in his code, so every time he makes a release, this is going to need to be updated to match...)
I'm really short on time, so I can't make a more useful post right now; give me until later tonight, and I should be able to post some instructions that are a little easier to follow than the mess I posted above. By the way, there's at least two or three significant changes in what I originally posted when you move from t5 to t6.
(I would love to see tephra include this in his patches; it's not that invasive, but it does depend on the location of a few things in his code, so every time he makes a release, this is going to need to be updated to match...)