RomRaider

We all want realtime tuning (and other modifications to the stock ECU). It turns out we're really not as close as I thought/hoped. As it is, there is really no realtime tuning in sight, and I definately don't have the skills to do it. So I thought I'd try to get some things together in hopes that it'll help someone get it done.

Basically, there's a short list of what needs to be done. Doing it is, of course, the hard part.
- Disassemble stock ECU code
- Write new table lookup code pointing to RAM instead of ROM, with fallbacks (in case if reset ECU or whatnot)
- Recompile new code

Now, there have been a few people who have started doing this and their progress is unknown or they may have stopped. A couple ideas have been presented to me. What it comes down to is the only viable option, other than stumbling upon someone (which hasnt happened), is rentacoder.com. We could take donations to pay someone to do it. (I did luck out and find Paul to write the logger but I don't see that happening again)

The issues with that..
- We aren't going to collect enough donations to pay someone even close to fair market value for such a task. If someone were to do it, they'd have to 1) be a nerd up for the challenge and/or 2) have an interest in the result. Please discuss this. We need to have a clear set of requirements and deliverables to provide to the potential developer of this and we'll need to get that ready before asking for donations or posting a request.

- I counted today and we have exactly 100 unique ROMs in the ECU definition file. Adding realtime tuning to a ROM would mean doing the above steps for each of them. We'd at the very least need to compile a list of what revisions can run on what ECU and eliminate duplicates. If we can run a 2005 STi map on all Forresters, the Forrester ROMs aren't necessary (we can copy tables over or whatever). This is what the Honda guys on pgmfi.org do. I took a look at Crome today and it has all four (FOUR!!!) ROMs that Honda guys, using OBD-I ECUs on EVERY Honda made from 1991-2005, need. 100 ECU revisions isn't going to happen. We need to make the list as short as possible.

- We need the compiler. I'd link the thread but I'm too tired right now. $99 -- no big deal. We can get the donations for it in a couple hours.

I'm rambling now and talking about things I have a very limited understanding of. The points I am sure of and adament about have been stated above. Thoughts?

No matter what happens, people need to start Donating if haven't already

First thing we need to get is the source from Colby. I've saved off some sample source of his that deals with 16 bit roms. When we get his c++ source for the 32 bit rom flashing, well be in a good spot. Just a matter of translating his code to Java... which considering some of his hand assembly tuning on the kernels, might complicate things. (I've not thought through all of the above obviously).

ok, notable ecu differences that might require deviation from standard (lets call 05 sti standard)
don't know much about 16bit DBC WRXes, someone else should know the differences.


04 dbw has half sized rom with no immobilizer

05-06 lgt/obxt have different tables and different sized tables (AVCS most notably; however, lgt and obxt can use the same roms interchangably, as I know c0bb does this)

06wrx/fxt/ 07 DBW have air injector pumps

Dont give up hope yet qconcept, we found taulon<sp?> and I dont think we were trying to find him....nor do I know how he found us?

I'll ask around and see If I cant find some die hard programmers who are up to the challenge.

I think the easiest method to implement real-time tuning would be to store the real-time tables in ram exactly as the tables are stored in rom. That is, for 16bit ecus, you'll use the map type definition byte, row/column count, etc. Then you would just need to change the map offset in the rom to point to the specific location in ram. There would be no need to modify the functions that are repeatedly called to interpolate and return the target map value.

The issue with this would be what happens after a reset. Ram is cleared and therefore you lose the real-time data. You would need to add code to copy over the values from the base map to the real-time locations in ram after a reset so that it is never empty.

From here, all you would need was an application that could be integrated into RomRaider to write the real-time changes to ram.

What you are saying could work reasonably well like this -- use a ROM with the alternate address, tune your car, apply the changes to a image that still looks at the original address in ROM and flash that.

That's a pretty big liability though. What if someone forgets? What if they keep using the RAM based tables and get stuck somewhere without a laptop?

It would work for me, I rarely get into my car without my trusty laptop.

Yeah, that would work somewhat. That is, the real-time tuning would be temporary. You flash the temporary real-time enabled ROM. Then you edit your real-time maps in RAM. Do your tuning for a bit and figure out what works best. Transfer these values over to a normal ROM. Flash that ROM replacing the temporary RT rom. If you forgot to flash and left the temporary RT rom on there and the ecu was reset as some point, and assuming that injector scaling was a real-time map, then the car just wouldn't start because the returned value would be, I assume, zero. You could actually setup something like this with a hex editor and the 32bit ecus because the map structure offsets are literal offsets which you could just replace with RAM locations. You could do the same with 16bit ecus as well.

I'd really prefer not to do it that way. I think it would result in a lot of broken cars. Aren't the fuel tables in the 16-bit ECUs inverse? ie, 0 = rich?

0 = no enrichment. Basically 14.7 afr. You could do it this way, you would just need code to rewrite the base to ram after a reset. If you did, there would always be a real-time map there even after a reset, although then there would be basically a copy of your base map.

Right.. so we're back to reverse engineering the ROM..

Alright, in a short conversation with a few people in #asm on efnet, the initial impressions are our best bet would be 1) ask Subaru for the source or 2) write our own from scratch.

It should be easy to find the code that initializes RAM after a reset before the engine starts. It's probably the only code which references or includes the address of the default IAM. You simply hook it to branch to a little subroutine which copies the ROM maps to their proper place within the realtime maps.

I was in Japan a few months ago, I was in Subaru head quarters.... had I known you wanted the source....