RomRaider

Is that really the strategy for realtime table implementation, to "conditionally look in ram for table data?"

I agree now that my "hooking" idea is too cumbersome and is totally unnecessary. The far simpler solution is to guarantee there are always realtime tables present when needed, even after an ECU reset. Then you can change all the instructions which reference these tables to simply use the RAM (realtime) version, without any extra conditional processing.

You just need to hook a new routine into some code that always executes before any of the tables that have realtime versions are referenced. The new routine checks whether the realtime tables exist. If not, they are created at the proper locations in RAM using the ROM versions. I can't imagine such a routine being much more than a couple dozen instructions.

Also, again, an area of RAM that looks clean and available for use as realtime tables might not look so clean after a bunch of trouble codes and their associated freeze frame data have been stored. Is anything being done by RAMWRITE or whatever which prevents the ECU from using the realtime map storage area for other purposes?

That is where I was going... for instance, if throttle % is 100 when the ignition is turned on, switch maps. Or something like that.

http://e-www.motorola.com/webapp/sps/li ... cu_lib.jsp

Search around for HC16... if you're looking for what I think you are.

here is some info i found:

http://www.bipom.com/6816dev.shtm

http://www.nohau.com/emul16_300pc.html

http://www.imagecraft.com/software/mdevtools.html#v6tools

version 6 of this software supports HC16($99) at the bottom of the page

http://www.steroidmicros.com/software/software.aspx?ID=ICC-V6

http://www.mininova.org

I think it'd be a good idea to use legitimate software since we're distributing this stuff.. If this will help get the job done, I don't think we'll have trouble getting the donations for it. ev8siv3 has been very busy tuning and said he probably doesn't have the time to do this any time soon. Anyone else think they could handle it?

For those who haven't seen, the Honda guys at pgmfi.org (and to a lesser extent the OBD-1 DSM guys) are lightyears ahead of us. They've got Crome to the point where you can add javascript snippets to extend the functionality of the ECU with just a few clicks. I think they're using a lot less ECU revisions to do this so they don't have to duplicate their work as much, which is a big reason we should be trying to minimize as well. Someone who understands disassembly could probably learn a lot from them, but unfortunately that's not me.

I've taken a look at their forums but there isn't a lot of tech, as far as disassembly, discussed that I could tell.

Here's a short list of most recent rom revisions. I think it's a waste of time to work on any other USDM Impreza roms.

http://wiki.RomRaider.org/index.php?tit ... _Revisions

So what software is currently being used to dissasemble the stock rom(s)? I have programmed some motorola 68k series back in the day and would like to take a look at the stock rom.

From what I've seen, everyone is using IDA 5+

Ouch, that software is expensive!

Indeed. The lack of a student or less feature-rich (and cheaper) version is keeping me from acquiring the software also.

*cough*torrent*cough*

LOL think it's already been suggest in a pm ... .

This is the link to the free HC16 program from Cosmic Software!!

http://www.cosmic-software.com/eval_kit ... m_eval.exe