RomRaider

Just made some cleanliness changes to the repository!

Points of Interest

- ROM/Logger Definition Request Templates added to the "issues" section. The preferred method of requesting updates can be found in the "Read Me"
- "Read Me" has been updated to include information related to ROM/Logger Definition Requests as well as contributing to the repository! I'd have no issue allowing Non-Z/G ROM's to stay apart of the repository if others wanted to continue providing support for them
- Eventual plans for having "combine_all" merge all the folders into one Nissandefs.xml file. I still want to keep the definitions split up in their separate folders as this makes it extremely easy for me to manage the definitions. Otherwise, it would require opening each ROM's individual definition file to figure out key information such as market and vehicle information.

Basically, just made things much more organized and well put together, rather than having things sprawled around like before.

thankyou for disclosing this!!! i was almost literally going insane trying to figure out why my rom would not load in R.R. PROPERLY, but everywhere else it was fine. SO, then what needs to be done so it will load properly? change the inherit file to CFxxD?

SO, 2 ITEMS tht i do not know how to fix. I have tried but I may be doing it wrong?

1. the air / fuel conversion table is completely incorrect . everytime i try to edit it , it reverts no matter what i do. what is the corrct way to fix? or can i send you the correct table info?

2. The: electronic throttle control - flow potential : table expressions are incorrect for : table 2 (address: 0xe01a ) and high flow table 2( address: oxdfe2).
Need only 3 decimal places like tables 1.
Currently, they hold 4 decimal point values which makes the interpertation for the ecu incorrect.

As always , your doing an amazing work here! thank you for all your help !!!!!

If you're referring to the axis, I've already submitted an issue on RR's github. (Assuming it's non-template related) For now, just use the "set" button on the taskbar to set that table's axis values. However, do be extremely cautious with this table. It's the AFR Sensor Calibration table, so only change it if you're going to be putting new widebands in.



Ooh good catch! I'll push the update soon!

For future reference, feel free to utilize the issue templates for definition corrections! https://github.com/Pytrex/NissanDefinitions/issues

wow thank you for letting me know. i thought it was a/f table as it was read by the ecm. ok well nowt his makes sense, becaue i run an lsu 4.9 for w/b on top of the stock lsu 4.2's. either way its still horribly incorrect,lol BUT , thank you for this information and attention to resolve it!!
edited:
EDIT*I paste the wrong table previous. for some reason it did not copy the final edit which is now posted below:

[Table2D]
0.5 0.75 1.0 1.25 1.5 1.75 2.0 2.25 2.5 2.85 3.0 3.25 3.5 4.0 4.5 5.0
10.0 10.25 10.5 11.0 11.5 12.0 12.5 13.0 14.0 14.700000000000001 15.0 15.5 16.0 17.0 18.0 19.0





but that 14.70 auto populates 8x decimals. that needs changing.please.



this is now resolved!!!!! thank you that was extremely fast!

[/quote]3.feel free to utilize the issue templates for definition corrections! https://github.com/Pytrex/NissanDefinitions/issues[/quote]

perfect, will do for now on when pertaining to the defenition.
I cannot thank you enough, so, once again, thank you!!!

No problem! I suppose it's a tad bit important to have properly defined tables when tuning your vehicle

exactly!, when its someone else's shmmmh j/j

as posted above .. here is the correct table, but need the 14.70 to only be 14.70
EDIT*I paste the wrong table previous. for some reason it did not copy the final edit which is now posted below:

[Table2D]
0.5 0.75 1.0 1.25 1.5 1.75 2.0 2.25 2.5 2.85 3.0 3.25 3.5 4.0 4.5 5.0
10.0 10.25 10.5 11.0 11.5 12.0 12.5 13.0 14.0 14.700000000000001 15.0 15.5 16.0 17.0 18.0 19.0


it auto populates the extra decimal values???? thanks again!!
its starting to take form now and usable ....almost.

MASSIVE UPDATE that's eventually coming to RomRaider! Subcategories have been implemented thanks to @GTO2013! While this isn't in the official release yet, it'll eventually be added. So while I don't have a time frame for when the public defs will switch over to subcategories, just wanted to share that the public defs WILL eventually make the switch! I first have to figure out said subcategories for my own personal defs before sending them to the public defs, as I'm still figuring out how I want things organized haha

Just another cool thing coming in the next RR release

Finally got around to working on this again, v0.0.1 is up! You can check the release notes to see what's new. I definitely recommend messing around with it a bit before utilizing it for tuning, as everything is in different places now. I'd also recommend starting with a fresh ROM just for safety. If you only want the final NissanDefinitions.xml file rather than downloading the entire repository, you can now do so from here -> https://github.com/Pytrex/NissanDefinit ... tag/Latest

If you only download the xml, then all you need to do is tell RR where it's located! Doesn't need to be unzipped (as of 12/5/21) or anything.

I missed this. So RR 0.8 has per-column, row and cell conversions now?

I can't find anything about how to do it in the XML files but I'll check yours for reference.

Hmmm I think I'll make up a full RR def for the TB48DE and trial doing all of my tuning in RomRaider rather than *blocked word*. It'd save using two separate pieces of software for editing and checksum correction for a start. Anything left that's missing in RR, I'll just submit feature requests.

Rather than having specific cell scalings, I utilize masking. Works really well, as it allows for seamless operation! If you were to alter the knock window in any way, you would immediately need to alter any per cell scalings. But with masking, there's never a need.

Just thought I'd post an update here for anyone whose curious. I've taken most of the past nine months off due to Uni. However, there are only a few more weeks left until Summer break. So once Summer break hits, I'll be up and rolling per usual

With that said, here's some of what I'm going to try implementing with the public repo:

Automated definition generation via 1:1 values with similar ROMs + offsets
It'll find a known map between two similar ROMs then locate various other parameters based off the known offset between the two maps. This is just a potential addition, as I still need to see how closely related two ROMs need to be in order to share the same offsets.

Automated A2L modifications and ROM def modifications
Instead of using NotePad++ regex to mass modify files, I'm going to attempt to utilize scripts to help avoid unwanted outcomes.

Sub-DTC List Support + Ordered Master DTC List
Thanks to RR's new update, supmasks can now be manually organized! Meaning, the Master DTC list will be ordered numerically. On top of this, this allows for sub-DTC lists similar to the previously defined ones.

Metric Scaling Reprioritization
Unfortunately, the metric bug has hit me and I've now seem just how amazing the metric system is with calculations and such. So while the scaling default will still be based on your personal selection of standard (imperial) or metric, I'll ensure that the metric scaling gets added for all parameters. So both standard and metric will be fully supported. Currently, standard is the primary scaling system, with not all parameters having a metric counterpart defined at the moment. This is a guaranteed change that will be one of the first ones to come. This will apply to both the Logger and the Editor.

Logger Support Additions
Currently, the public logger isn't functional and only supports a few ROMs. While unlikely, I am going to look and see if there's any way to automate defining RAM parameters. I have a few ideas of how to go about this currently, but I'll have to wait till later to investigate further. But if logger definitions could be automated, it would seriously enhance the tuning experience like no other. So it's definitely a personal priority. On top of this, last December I analyzed $AC functionality and was able to figure out how to log more than 12 addresses! So instead of being limited to 12 addresses, we're now able to log up to 61 total addresses! This is MASSIVE! The one thing is that this hasn't been implemented into RR logger yet, so it's not exactly usable atm. But in my personal testing, everything is fully functional as expected. So it's just a matter of getting this added to RR logger before we're able to take advantage of it I'll include the link for anyone who wants to see the original post -> viewtopic.php?f=65&t=18620&start=31

New Focus on Userlevel
While userlevel has been around for a while, I've neglected using it beyond for organization purposes before subcategories were implemented. However, I'm planning on utilizing them for their intended purpose, to ensure that people are aware of what parameters they should be modifying based off their experience level. I feel like implementing userlevel again will allow more inexperienced users to get a better grasp of what they should and should not be messing with.

Map Descriptions
As many of you have seen, the current map descriptions are VERY lacking in detail. Many of which are just the ZB060 descriptions. So one of the things I want to do is go through and add meaningful descriptions to all parameters, while saving any excessive details for the wiki.

So as you can see from a few of my plans, I'm set on improving the public repo quite a bit. My personal CF48D repo is at a fantastic place, so I'd rather focus on helping the community as a whole and prioritize the public repo for this Summer. With that being said, I'd highly recommend utilizing the "issues" section on the repo so that I'm aware of any potential issues that are occurring! I do ask that you focus on using it primarily for issues or enhancement ideas rather than definition requests, as I feel like automation is going to be my primary focus when it comes to ROM definitions.

I hope everyone has been doing well and I'm excited to work on improving the tuning experience for the community this Summer!

That's definitely the way forward; manual def creation is such a waste of time. Well, maybe not a waste, but extremely inefficient. One way I was considering to accomplish this is from a "high level" with the benefit of IDA / ghidra to compare the code structure and match xrefs to data. I ran out of time testing diaphora with IDA and never got to playing with ghidra's diff capabilities.
Matching code patterns would give better confidence (especially for scalar constants, sometimes impossible to uniquely identify without looking at code), and allow finding slightly-different parameters.

Otherwise, looking for 1:1 copies will of course work to a certain extent. You could go one step further and compare "Hamming distances" - this might catch a lot of maps with only minor modifications, and fairly easy to code. The ROMs are small enough that it's realistic to do lots of bruteforce searches. And when it gets too slow, adding parallel processing is usually worth the effort (takes just a few hours to learn and use OpenMP on trivial code).


I agree, worth looking at, but those offsets will need to be flexible. As I recall the general order was usually pretty similar between ROMs, but almost always some minor relative differences.


Automation is the way forward, I'm sure I don't need to convince you ! I'm not sure what you mean by modifying the A2L, but if you're going to be parsing A2L, definitely look for an already-made A2L parser. Maybe https://github.com/mrom1/a2lparser or some others ?


This could also be gained as a side-effect of parsing the A2L or the def's XML(if the RAM parameters are also ending up in there ?)

Work smart, not hard - that's what I was aiming for with nisrom & findrefs; doing the same tedious task over and over is unacceptable : ))

Agreed! The first few times you manually define ROMs it's not too bad, but it gets repetitive real quick. And since you're literally just looking for patterns and comparing, why do it yourself when you could program something to do it for you and be much faster as well?



I'll definitely have to look into all that! Thanks for giving me somewhere to start


This is all hypothetical currently, as I still need to compare various ROMs to get a better understanding of how they all differ. Because at the very least, transmission and engine differences will be incompatible. That then leaves what else causes two otherwise identical ROMs to differ.

The main thing I can think of would be trim level, or more precisely, whether cruise control/TCS/VDC would be equipped. But I'm not 100% certain on whether those differences would result in altered data structure or if they'd just be zeroed out values. I know for a fact that different engines and transmissions have different code structures. So let's say that's the ONLY thing that deviates the code. With that, it would still end up requiring me to manually define at least one ROM variant in order to reference it.

But honestly, this is basically just a very basic fallback plan in case I can't get anything fancy working. So this is only here to give me at least SOME automation, I'd much rather be able to plug any given ROM into a program and have it spit out a definition file haha And with most of the maps having very similar values (yet not identical), I feel like it wouldn't be the most challenging to define maps and axes that way.


In this case, I just mean my A2L definition template. Currently, I use NotePad++'s ability to use RegEx to search and modify multiple files contents. But the issue is, this just feels very barbaric and it relies on some inconsistent RegEx searches. So I want to set something up to make it much easier to make changes to ROM definitions without having to worry about breaking everything. Because as I find new things to implement, I don't want to have to manually edit each individual definition file. For example, switching to a single DTC table for all ROMs took a bit of messing with RegEx to get it to work the way I wanted, same for the knock window stuff which even needed to keep the axis data as well! So we'll see how I want to go about it all later.

But for the A2L parser, that's actually really handy! It'll definitely be useful for quickly parsing any new A2L's that pop up! I just wish I had the idea to use one of them before manually defining just about every single parameter from the ZB060 A2L. Yea, I literally have hand defined probably 99% of the ZB060 A2L parameters that are found in both ROMs. To be fair, I did at least just copy and paste a template map then modify the necessary attributes! So it's not like I hand typed every single line over and over again haha


I agree with you there! Why do something over and over again when the computer could do it for you? After working with MATLAB this year, I'm completely set on automation. Not saying I'm going to use MATLAB to do this, but I currently have it opening a binary ROM file and manually adding the storageaddress next to the ROM values. So while it's not going to be the right coding language for the job, I'm the most comfortable with it at this point in time. So it'll at least help me test ideas faster than having to learn a new coding language haha Albeit, I'm not exactly sure on it's limitations for this sort of thing. So I guess we'll just have to mess around and find out