RomRaider Logo

RomRaider

Open Source ECU Tools
 FAQ •  Register •  Login 

RomRaider

Documentation

Community

Developers

It is currently Sat Feb 21, 2026 10:00 pm

All times are UTC




Post new topic Reply to topic  [ 61 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Fri Mar 07, 2014 4:43 pm 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
If you're using a 2-byte, there could be an issue with types. Try stepping through it with the debugger in HEW. Build and download the compiled image, then go to the code, right click -> Set PC here. Switch to assembly view and set the registers to appropriate values and watch it run.

Regarding the pedal vs plate choice, it really depends what you're trying to accomplish. If the goal is to perform some function that is dependent upon engine metrics (ALS), throttle plate would be preferable as the relationship between pedal/plate is often tuned differently or to driver preference. If you're just looking for an input from the driver (ala launch control) pedal position is the way to go (it is on my TODO to switch the LC code over to this).

What I was really getting at though was the use of a new ramvariable to store this value. These should be reserved for modified output values or intermediate logging values. Basically, only things that don't exist in existing RAM. Values that are only referenced should be referenced directly, especially when latency is a concern.

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Sat Mar 08, 2014 7:04 pm 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
Merp wrote:
If you're using a 2-byte, there could be an issue with types. Try stepping through it with the debugger in HEW. Build and download the compiled image, then go to the code, right click -> Set PC here. Switch to assembly view and set the registers to appropriate values and watch it run.

Regarding the pedal vs plate choice, it really depends what you're trying to accomplish. If the goal is to perform some function that is dependent upon engine metrics (ALS), throttle plate would be preferable as the relationship between pedal/plate is often tuned differently or to driver preference. If you're just looking for an input from the driver (ala launch control) pedal position is the way to go (it is on my TODO to switch the LC code over to this).

What I was really getting at though was the use of a new ramvariable to store this value. These should be reserved for modified output values or intermediate logging values. Basically, only things that don't exist in existing RAM. Values that are only referenced should be referenced directly, especially when latency is a concern.


I tried stepping through with HEW. It said the WGDC parameters were unavailable. I did see it change up the other parameters as it stepped.

I understand your ramvariable concern now. I should definitely switch it over.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Mon Aug 18, 2014 8:09 pm 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
Been spending a little time playing with this stuff again.

Figured out the reason PGTB never worked. Haven't figured out the cause, but hTableTargetBoost after the hack continued to point to the OEM table. So I edited the HEX in romraider to point at the ram address of the PGTB output as it should. Haven't tested it yet but I see no reason why it shouldn't fix it. Also made switches for turning timing and POLF hacks on/off in my Rom to start testing that too.

Also I believe I figured out two previous problems. If I upload a new build without flashing back to an OEM build first the car won't run. This is what I believe kept my shiftlight from working and scared me off that for a while.

The other issue was when the accelerator pedal was giving me the opposite effect when setting up for the ALS crap. This was my idiocy. I had it defined as an unsigned char instead of a float.

I will hopefully get some cool new stuff out soon.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Fri Aug 22, 2014 1:36 am 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
Excellent, great work! I look forward to some pull requests :)

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Tue Aug 26, 2014 3:11 am 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
PGTB works now. Haven't found the actual cause but the fix worked.

trying to build the shiftlight hack in HEW and it its giving an error writing the defs. What is required for the defs to properly work?

Edit: fixed that problem to be confronted with another.



Have a basic shift light built and have started the table hooks for a target idle hack.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Wed Sep 03, 2014 5:09 am 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
Shiftlight is ready for roadtesting.
Building/Checking my idle speed hook in hew to have a basic operation test of switching idle maps on the fly. Getting excited.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Thu Sep 04, 2014 9:17 am 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
Found the glitch causing target boost and other tables to not be hooked correctly.

The names for the hooks in metadata.c must be unique. If they are the same as another the hook is ignored. Once I fixed metadata I FINALLY have tTargetBoost hooking as it should.

Ran through all of my code in hew and IDA. Confident that I'll have a wOrking shiftlight and driving mode hack. (normal mode, performance mode, antilag mode switchable by user specific input)


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Thu Sep 04, 2014 1:17 pm 
Offline
Moderator

Joined: Thu May 20, 2010 8:01 am
Posts: 3117
Location: Johannesburg, South Africa
^ now that sounds like some extra code I'd love to compile...

_________________
He who dies with the most gadgets wins.

Please do not PM me - use the email option.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Thu Sep 04, 2014 4:42 pm 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
It definitely isn't ready for prime time.
I know merp prefers the cruise light be implemented but I don't have the time to find that yet.
Also only the mode switching, target idle speed and user input is ready to test. There's a lot more work to do but this was the hardest part.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Sun Sep 14, 2014 3:54 am 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
User input works for mode switching but I need to alter it a bit. Had to rewrite it to get the desired functionality but lost a portion that needs to be put back in.

Need to look into idle tables more in depth. They are causing a logical error when running. The logic is force bypassing the tables and going to an initialized entry.

Shiftlight is dependent on a modeswitch variable that needs correction.

50% done with the preliminary base hack.
Then it's adding functionality to the different modes and ALS.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Sun Sep 14, 2014 6:41 pm 
Offline
Experienced
User avatar

Joined: Thu Jul 23, 2009 5:46 pm
Posts: 863
Excellent :)

Please take some time and get your progress on git/github. The more eyes reviewing the code the better, and the sooner the easier rebasing will be (although I don't mind doing the initial rebase for you!)

_________________
Please do not send me support questions via PM, use the forum instead!


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Tue Sep 16, 2014 1:25 am 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
Merp wrote:
Excellent :)

Please take some time and get your progress on git/github. The more eyes reviewing the code the better, and the sooner the easier rebasing will be (although I don't mind doing the initial rebase for you!)


I would love to but I've got some Internet issues at the moment. I also never could get github to do what I wanted. I would definitely love your help with that.
When I get the Internet problem sorted I could post up what I've got.

As far as progress I've got some awesome things!
The performance mode works off the clutch defogger and cruise resume being pressed. I am going to change the clutch part I believe and maybe make it dependent on idle or zero vehicle speed. But it works as is.

The mode numbers 0 1 or 2 flash the cel when changed. Number of flashes is the new mode. This also already works perfectly it's very cool to see.

I am planning on hooking the mapswitch default to be linked to the drive mode. (if def ALShacks) should be working next build and will eventually need to be worked into its own input selection.

Shiftlight I am suspending for now. It's boring and has a pointer issue I'm too green to figure out.

I also want to implement a function to kill injectors until a button combo is pressed or maybe add in another drive mode if enabled that requires a mode change prior to ignition. Probably will add a mode 3 and tie in the default mode as an enabler making the 3 drive modes match up with mapswitch values.

And last function I'd like to work on is a ECM reset button combo but I don't know the logic for it. I saw the basic idea of it somewhere online but can't find it.

Other things: I was quite stupid and finally realized that the tunes I was using didn't have the rear 02 and AIR deletes causing what I thought was an issue with the target idle hack. Fixed the types for the idle values and now that they match I can work that back in.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Tue Sep 16, 2014 4:04 am 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
Added 4th mode for a valet or a future killswitch.
Cycles from a chosen default through mode 3(ALS or perf level 2 is ALS isn't desired)

Target idle hack works!
In ALS mode my idle jumps to 2000rpm as a tester level.

Mapswitch isn't working yet. It's showing map 0 so I need to look into what I changed last year to get it working.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Thu Sep 18, 2014 6:28 pm 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
Drivemode now updates mapswitch. I'm cleaning up the code and moving it to its own file. Then I can start to get it on github for a pull or for your eyes.

I'm getting requested torque hooked for performance mode so it should be equivalent to sidrive for those of us without.

Edit:
Code mostly cleaned up. Need to double check it's all still working.
Still need to add a case for an official mapswitch input.

Requested torque has been added, need to doublecheck the output to make sure it matches the oem output then uncomment the metadata portion.

Then I'll probably give it a break for a bit and make sure timing hacks and fuel hacks are 100% before continuing any further development. I also need to map out the idle rolling code and any other idle forms and get it inline with the newest build of merp mod and a recent 32bitbase.


Top
 Profile  
 
 Post subject: Re: Merpmod pgwg,pgtb tables
PostPosted: Wed Sep 24, 2014 6:06 am 
Offline
Experienced

Joined: Thu Jan 09, 2014 10:17 pm
Posts: 394
Got ALS.c and ALSTables.c up on Git.
You can get the majority of what I've done through those two.

Theres a decent chunk of coding strewn about other files but I haven't had the time to fit them into a current version of the merpmod. Still running off some old files. A lot of work to do to get it making sense. It is getting so much easier now that I'm getting comfortable with all the coding and files.


As of now working 4 Modes:

0 - Valet with KillSwitch
1 - Normal
2 - Performance
3 - High Performance (Future ALS)

ModeSwitch Lights CEL. Flash count matches Mode number.
Can Cycle up through modes back to a user defined default.
Can Cycle down through modes all the way to 0. Does NOT cycle back to top.

Cycle up = Press Clutch, defogger ON, and Cruise Resume.
Cycle Down = Press Clutch, Defogger ON, and Cruise Set.
Valet Mode = Cycle Down to zero mode OR... Press Clutch, Defogger ON, Cruise Set, Press Brake.... Release and press brake again = KillSwitch.

To turnoff Killswitch = Cycle up a mode.

Mode stays constant after car is turned off.

Current tables working
Merpmod Mapswitch:
OL Fueling per Mapswitch.
Timing per Mapswitch.
Target Boost per Gear, per mapswitch.
WGDC per Gear, per mapswitch.
Target Idle (only 0 MPH for now) per Mode. (Target Idle A and B tables from OEM are used FOR NOW. Plan on implementing new table(s) probably)
Requested Torque per Mode. (OEM req torque table A is used for Normal Mode)

Also there's a Shiftlight I built into CELFlash. It pulls the current DriveMode and gear to decide RPM to flash. This way it can flash at a Valet to be one more reminder to keep it slow, it can tell you when optimal upshifts are for mileage on normal mode and can act as an actual shift light in the performance modes. It still works off the CEL flash and I have no intention of furthering it. So it is what it is as far as I'm concerned.

Only untested feature is Killswitch. This is ready for me to build and test though. Only thing I'm worried about is the switch check for two bits on the same byte. Don't know how that'll respond. May have to do some Shift Logical Left/Right coding. We'll see I suppose.

Killswitch is a "soft" kill. It is done by a 0 RPM Target Idle and 0 Requested Torque. Basically you can't keep it idling and there's no using the gas to keep it from stalling out. I planned on in the future using the Injector hack to kill them, I'd also like to keep the car from even attempting to turn over if possible. And I may actually keep this as a "soft" kill switch. I like the idea of it not being abrupt. Gives the driver time to think it over. Plus it will confuse the would-be others. It also flashes to tell the driver of the Killswitch activation.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 61 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Style based on FI Subsilver by phpBBservice.nl