RomRaider

Hey guys, I'm working on a way to disable FBKC during fuel cut launch control and FFS while retaining FBKC during pulls.

I was looking through the FBKC code, and found a spot to hook the RPM threshold subroutine for FBKC enable/disable. I figure this way will ensure it is disabled as the ecu will simply think its out of RPM range, so there is no chance of the bit being reset before FBKC is checked/applied.

I'm considering the following logic:

hook subroutine (change jump location from the comparison subroutine in the rpm check subroutine to high rom free space)
finish subroutine operation (determine if rpm is in range, set checkbit accordingly)
IF (rpm in range){
check clutchswitch
IF(clutch in){
set RPM disable checkbit}}
return

I haven't gone through all the KC logic yet, but I'm wondering if there are any unforeseen consequences to doing it this way? Perhaps it would be better to leave the KC stuff alone, and set the actual FBKC value to zero in the LC/FFS subroutine? If i'm reading correctly, FBKC is held after passing the rpm thresholds, but then again, it isn't occurring until LC/FFS is active (clutch in).

I lean toward setting the FBKC value to zero, just because it seems like the approach that's least likely to have unforeseen consequences.

Will you need extra logic to disable FLKC and IAM adjustments as well? I haven't messed with LC or FFS but I've heard that it can pull timing long enough to slow down quarter-mile runs, so I assume that meant FLKC and/or IAM.

The only problem with zeroing the value I can see, is if the order of operations is off and it goes: FBKC sub sets -1, Total timing set with -1 applied, zero FBKC, repeat. In which case, it would just limit the FBKC to -1 during lc/ffs.

As far as FLKC or IAM, I have yet to experience either, although I've never done more than a few LC tests in a row. FFS is another story, I've done it plenty of times with noticeable FBKC, but no other corrections.

If FLKC is a problem, I can move the hook to whichever subroutine is executed last, and set both checkbits if the clutch is in.

I have a car to test this on..

07 STi

Which rom? I'll look at it after I get it working on my car.

I should have a patch made this week and have some IDA screenshots so someone can check my work.

I have to check...

I'll let you know tonight

Just took a better look at the order of operations, and the rev limit subroutine is executed before and fairly close to the FBKC range check and retard setting. So, it looks like inserting the code into the FFS code won't work, and would result in either no change or spiking FBKC.

Here's what I have so far. It needs a double/triple check before compiling and making a difference file to patch. I also need to check out the implications/consequences of a low-rpm fbkc disable, ie, what else looks at checkbit 1.



mov.l @r2,r2 should be mov.b

-Added operations to keep proper return address to avoid an infinite loop
-Changed mov.l @r2,r2 to mov.b @r2,r2
-Moved around a couple things for pipeline optimization
-Added addresses

It has an even number of operations, so is it correct to assume I don't need an align byte provided fbkc_clutch_check is located at a 4n address?

Any advice on optimization? I gave the sh2e manual pipeline section a light read, and all I got from it was that it's slower to use the same register in back to back operations if you can avoid it.

Here's a patched rom in IDA



Updated without the double negative r4 before the jump.

You have motivated me to learn more SHx assembly. Stay tuned for questions.

Can you tell me if I have this right?

Currently the instruction at 3B180 loads the address of a subroutine (sub_249C) from 3B24C. You're going to put the address of your own code (sub_F1064) into 3B24C.

In your subroutine, you load the old subroutine into r2, save a return address, jump to the old subroutine.
So now the factory code has run just as before, but the next instructions are yours.
Compare 1 (literal) and r0
If the 1 bit was not set, jump to F107A (with a nop first) which just loads the return address and returns.
Otherwise load an address into R2 (FFFF69F1), load the value from that address into r0. Is this the clutch switch?
Move r0's 0x80 bit to r0's 0x01 bit.
Load the return address, and return.
The stock code that comes next will treat r0's 0x01 bit as the FBKC enable flag.

Assuming I got that right, two things worry me:

1) the value at FFFF69F1 (again, I'm guessing this is the clutch switch) may have other bits in it, which will confuse the stock code that runs after your hook. I'm guessing you can watch that address, in the logger, have you tried that?

2) r0 may have had other bits set in it, which other code might care about (you mentioned FLKC, is that enabled by another bit in r0?), and those will be overwritten by the value at FFFF69F1.

Both of those seem fairly low risk but I like the idea of preserving the initial value of r0 and only modifying the FBKC enable bit, just to prevent surprises.

For the most part, you've got it.

When the comparison of #1 and r0 runs, it checks the whole word. ie: does r0 = 0000 0001

The master checkbyte (I have it named KC checkbit enable) stores other bits pertaining to FBKC, such as load enable/disable.

However, in this subroutine, that checkbyte is bitmasked to extract only the RPM enable bit, which is moved to r4 for further evaluation. (tst #2,r0;movt r4; add #-1,r4; neg r4,r4)

So, r0 is later set by sub 294C to either h'00 or h'01, so no issues with other bits being set.

0xFFFF69F1 does contain a few switches.

MSB: Clutch switch
Bit 6: Stop light switch
Bit 5: Set/Coast switch
Bit 4: Resume/Accel switch
Bit 3: Brake switch
Bit 2: ??
Bit 1: Accelerator switch
LSB: ??

These are listed in the 'switches' section of the logger defs.

The way the TST operation works, the other switches are bitmasked, and ignored.

The register used to store the address 0xFFFF69F1 (r2) is not used after this bit of code is executed, it is later overwritten in another subroutine. Although I should double check this.

I was reading some old threads about LC/FFS, and I found a few reports of FLKC and IAM changes. So I may look for a way to disable all KC whenever the rev limit fuel cut is active, possibly with a slight delay afterwards.

Very interesting. Is there an how to explaining how to patch a given ROM to enable LC and FFS or I have to buy the TinyWREX patch?

Well, for most roms, it isn't so much 'enabling' as it is adding the code and functionality. It is a very simple patch as far as logic is concerned, but it requires that you learn SH2e assembly language, use of IDA Pro, hex editing, and risking a bricked ecu. If you have a background in computer science it should be a pretty straightforward learning process.

Also, I believe there is a piece of code floating around, WolfPlayer may have posted it on nasioc open source forums, that has most of the logic, and only requires you to fill in the details.

speaking generally, i would not do this.

i have been using lc/ffs for many many years with a utec and it definitely does NOT disable knock control while active.

have you considered the fact that the engine is actually knocking?