RomRaider

This would be a big hit in the TB48 community and I could likely gather a bounty of around USD$1000 for such a feature if anyone with the capability is interested?

It would be for VC264, VC269 and VD70A ROMs.

I'm not sure if you could do a full on cut, but you could have it heavily retard ignition timing pretty easily I believe. Why do you want to alter the rev limiter logic? It's always best to avoid hitting it at all. But I'm pretty sure it's as easy as just replacing the fuel cut portion of the code with setting vFADV (final ignition timing) to whatever value you want.

I don’t mean an ignition retard but a spark cut. Ideally just replace whatever code that cuts fuel to cut spark instead.

People like it for the different sound. Some people hit rev limiter all the time. Lots of TB48 owners have switched to standalone ECUs for this alone.

Given how our ECU's don't have any form of ignition cut (AFAIK), it might not even be possible. Uprev does all their 2 step/launch control through ignition retard (even -10 degrees works at holding the revs, so -20 or -30 would work "well" for your application). I'm sure there's SOME way to do so by some form of manipulation, but it wouldn't be pretty. Maybe setting the ignition delay RAM value to 65535 or 255?

So ignition cut is potentially really easy it seems. You might just need to set vTDWLL (RAM) "Energizing Angle" to 0. This is normally done at the end of all the ignition timing calculations. So what you could do is have it jmp at the end of the dwell function. Then have it check if it has exceeded your "fuel" cut threshold. If it has, set it to 0, if not, just have the normal calculation go through. Then just rts after finishing the stack nonsense. That's how Uprev does it with their simplified timing and such. Except instead of modifying vTDWLL, they're just modifying the vFADV "Final Ignition Timing" RAM parameter instead of dwell. But assuming an energizing angle of 0 = no spark, then this should work. On HPTuner's forums, someone was able to initiate spark cut just by adjusting the Dwell RPM Table. This appears like it would work the same for Nissan's, but the table uses a fixed axis. So you would be forced to use 6400 RPM as the spark cut point.

Edit; Nevermind, I just missed an obvious JSR at the end of the fADV function haha So there’s a separate parameter that you’d actually want to set to 0, but maybe dwell being 0 could have the same effect?

Setting dwell to 0 is very common with Hard Cut patches.
Its what Honda's do, and its also what VWs do, and IIRC Mitsubishis do the same as well.

Interesting. It makes sense though. Since dwell is how long the coil will be firing for. So if it's 0, then it won't fire at all. Thanks for confirming this! I personally have no interest in spark cut, but knowing how it operates is always good to know!

I guess we wouldn't get a customisable cut threshold and restore threshold that way but it'd be interesting to try.

What do you mean? You’d still be able to run it off the fuel cut thresholds if setup properly. Below cut RPM, normal ignition functionality. Above cut RPM, dwell = 0. Then when it drops below the restore point, normal ignition functionality.

You could also just base it off the Fuel Cut Flag since that would presumably change to 1 when fuel cut is being applied. But you’d need to find one that only trips during rev limiter fuel cut haha But there are tons of ways to go about it where you have thresholds. It wouldn’t make sense to not be able to control the thresholds imo.

But apart from the dwell table, there’s no way to go about it without custom coding. Which honestly isn’t even too difficult to do. Ghidras fully capable surprisingly enough.

I don't do coding. Gave up a long time ago haha. Yeah I'm just talking about the dwell table.

If it was a custom coded thing, how would using the fuel cut flag work for ignition cut when they would want fuel to continue as normal (ignition cut only)?

I haven’t actually checked if there is a fuel cut flag specific to the rev limiter. But if there is, you could just switch the RAM address it writes to and call that RAM address when checking for conditions. So then fuel cut wouldn’t occur and you would be able to minimize the amount of code required.

So with the dwell table, it uses a fixed axis like I’ve mentioned. But I’m positive that it could be converted to have an actual axis. I haven’t looked at table coding, but the JSR’s seem to mainly only care about size. So 8bit vs 16bit and such. So you could theoretically just change the JSR to go to one that has an axis defined and then use your own axis from wherever you want. Then you could precisely line up spark cut with your original fuel cut limiter.

Edit;

I think the easiest method would be utilizing the Dwell Table for sure. You’d have to add a custom axis for it, but it would require the LEAST amount of coding possible. I’m sure it’s as simple as swapping the JSR and adding an axis to the dwell code.