RomRaider

Awesome! I will check this out later today, and probably re write my stuff on it.

My code compiled and everything, but after learning some more C I realize there are much better ways to go about it and the practice can't hurt..

I've also picked up some C#, started writing some console apps, and rewrote the c++ hex comparison console utility I was using to produce .dif files from scratch in C# with a simple forms gui.

Did you see the Cobb announcement about their SD solution for all USDM cars?

Yep, saw that. It's interesting that they feel that a hybrid solution is so useful. MAF blending might be unavoidable but I want to learn more about the issues with pure SD before I start working on MAF blending. But, I kinda like the idea of a small table (like 5x5 or so) that defines a MAF/SD ratio, based on MAP and RPM. You could put 0 in the top-left to have a MAF-based idle, and put 1.0 where you want pure SD, and blend between them wherever you want.

I also like the alpha-N idea for vacuum conditions, because it seems like tip-in would cease to be necessary, so that's another thing I'd like to try.

So many ideas, so little time.

I just tested the SD patch from that last zip file, and it seems to work just fine, so...

viewtopic.php?f=37&t=7818

Just about finished porting the latest to 07STi.

I had to make a couple changes. The 07STi rom A2UJ000J does not use bitmasks on the clutch and fuel cut flags, just a test/comparison with 0 and 1. Essentially a LSb bitmask instead of MSb. I went through and replaced all of the hex values used in bitmasking with a #define RevLimitBitMask ((char)0x??) in ecuhacks.h.

While going through that, I noticed this when the fuel cut is set. Is the extra cast as char pointer just leftover from previous code or is it serving some other purpose?

As NSFW and I suspect, there's going to be a lot of #define tied to different CALIDs to make the code truly portable.

This is the way I read it...

• pFlagsRevLimit is an address (int) of the value you want to retrieve
• (char*)pFlagsRevLimit is a pointer to a char (byte) at address pFlagsRevLimit
• *((char*)pFlagsRevLimit) is the char (byte) value at pFlagsRevLimit

I think it also makes the compiler treat the dereferenced value as a char and forces the & operation to occur on char data types.

The 2nd and 3rd one are definitely correct, but the first one actually depends on how pFlagsRevLimit was defined.

int *pFlagsRevLimit; // you'd be correct
char *pFlagsRevLimit; // you'd be mistaken - this actually makes the 1st and 2nd mean exactly the same thing

...so I think Merp was right, and the (char*) was left over from an earlier revision of the code.

Dschultz and I exchanged a couple of PMs about portability and I'm going to rearrange things a bit to help with that in the next update. Ultimately I'd like to get to a point where there's one header file per ROM, with all of the ROM-specific stuff in it (addresses, mostly) and all you have to do is change one line of code to rebuild for a given ROM. However there are some ROM-specific things that are actually in the project configuration, so it won't be quite that simple, but hopefully it'll be close.

The difference in rev limiter bits vs. bytes could be accomodated by something like this:

#define pClutchSwitchByte ((char*) 0x12345)
#define ClutchSwitchBitMask 1

if (*pClutchSwitchByte & ClutchSwitchBitMask)

Plus I want to do dynamic fuel injector scaling for Z0rr0's ethanol sensor. I might do that first actually since it will take less work than rearranging everything.

So I can learn more about this strange language called C. I ran the two senarios through the pre-process seperately.
The define is as such:
#define pFlagsRevLimit ((char*) 0xFFFF5A40)

The cpp output for "*((char*)pFlagsRevLimit) &= 0x7F;" is:

If I change the code line to "*pFlagsRevLimit &= 0x7F;" I get this:

In both cases the code compiles to be:

In the end the same result is achieved, a byte is loaded ANDed with 0x7F and written back to the RAM location.

Finished the port and flashed on the tester's car. Everything is working so far (need to build VE table to test the rest).

In addition to the changed bitmasking code I've added CEL flashing code (in C) with FBKC flashing & IAM recall. Also added a blending mode (3d rpm X map table) to the speed density code. Will be posting this project soon.. contemplating releasing it as is or waiting to add programming mode and/or spark cut.

For the CAL ID, I changed A2UJ000J to A2UJ0SDJ.. thoughts?

Personally, I would prefer if you posted it as is - but then again I'm biased

In the cobb software, they use a table with value 0,1,2. 0=maf, 1=sd, 2=maf/sd blend. When using blend there are three thresholds. One is rpm, one is map, one is tps. After the thresholds are met it will switch from maf to sd. Kinda like the utec is setup.

There are two undefined smoothing factors for load in the gr sti roms. They use one of them for sd and recommend to not use a smoothing factor with sd. So it is set to 1= no smoothing. Stock is set for .127 iirc for maf. That gives a stronger smoothing factor. Map sensor voltage must be way more stable than maf volts.

They use a true ve table for there sd. Its set up nicely and looks easy to tune. The realtime tuning will be great with sd. They did a really nice job. It was worth the wait.

I don't think it really matters. I haven't seen any consistent pattern to the numbering scheme.

I was hoping to have some flex-fuel stuff to share by now, and re-arrangement of the code for easier portability, but everything has taken a back seat to my day job. It's coming though. I have the code written (some time ago, actually) for fuel injector scaling via TGV input, with a bit of the portability work, I just need time to give it proper testing.

I'm still having issues when trying to add more than 3 "patch" items in my metadata. I've verified that it isn't specific to any code, just the amount of items in the metadata. Rompatch returns a 'patch is null' error, but sniffing the patch shows that it looks legit.

Any ideas? I've consolidated all code into a single ROMHole section, but I need to run two more hooks that require patches.

Can you post a ROM and a patch file? I'll need to watch RomPatch in a debugger to see what's going on. You can PM them to me if you'd rather.