Hi,
over the years I have added quite a few features into RomRaider that I needed for personal projects, that most of you who write definitions probably dont know about. Since writing documentation is about 5% as fun as writing code, most of this is not documented.
Opening other definitions formats Usually RomRaider only takes definitions in its .xml format. I have added support for other file formats (these are called ConversionLayers in code). RR can then export the converted definition in its standard .xml format if you go to the tab file/Export <filename>. You can then further edit the definition if you want.
1. XDFs
It is possible to open XDFs directly with RR. I have tested this on various XDFs I could find (mostly BMW). A thing to note here is that XDFs dont have an identification component like RR does, so if you add an XDF to the definition manager it will always be chosen if not other file is picked first. What makes more sense is to pick the binary first, RR will then ask you to pick a definition. You then choose your XDF. If it loads successfully you can export it as RR definition and add the identification tags yourself.
2. BMW NCS Expert Coding Files (.CXX)
This is very BMW specific: BMW supports recoding modules via NCS Expert. It contains the addresses NCS Expert sends to the interface, this SHOULD correlate to the data layout in the EEPROM, but it does not have to. I have used this technique to create a RR definition for E36 clusters. These files only contain the raw data and no identification component, there is no conversion to the physical value included. So to make this a proper definition you will need to put in some manual labour.
3. VDF/JDF JET Tuner (US PCMs)
As of writing this, this feature is not yet included in a public release (
https://github.com/RomRaider/RomRaider/pull/215). I added this for my personal LS3 project, which runs an E38 GM PCM. JetTuner offers a free demo version, which comes with .JDF definition files. You can open binaries with this tool, but not save them as binary after editing. I added support for this format in RR, so RR can now tune a lot of US PCMs. You can also buy more .VDF definition files for various other cars. For E38 PCM I added the checksum algorithm aswell, you need to add this manually after you save the definition as a RR .xml (see below).
ChecksumsChecksums that I added (more are implemented in src/main/java/com/romraider/maps/checksum)
1. BYTEXOR: Simple XOR checksum, used in some BMW modules
2. COPY: Simply checks if the data at one memory range matches another range. Copies it over if it doesnt match.
3. E38PCM: Algorithm for E38 GM PCM (no parameters)
4. MOTRONICSINGLE: Motronic 1-Byte Checksum (PR:
https://github.com/RomRaider/RomRaider/pull/156. ported from
https://github.com/matiss/motronic-checksum)
5. MOTRONICDOUBLE: Motronic 2-Byte Checksum
To add a checksum you just need to add it to the definition as follows:
Code:
<checksum end="0x61" start="0x0" type="BYTEXOR" xorloc="0x61" />
The end parameters is exclusive, except for the COPY checksum.
It is also possible to write your own checksum in java and ship it with the definition, see
https://github.com/RomRaider/RomRaider/pull/156.
Various other features in definitions1. Added <author> and <version> tag in the <romID> component, will be shown in the header after the definition is loaded
2. Property skipCells="n" for 3D tables: Allows you to skip n amount of cells after each column.
3. Support for 1D tables: In old RR versions 1D tables could only be used as axis. You can now use them standalone as one or more scalar values.
4. Presets for 1D and 2D tables. I added this for the NCS Expert support. It works the same way as switches, just that you can see the data. 3D Tables are currently not supported. Example:
Code:
<table category="Tacho | Speedometer" endian="little" mask="FF" name="TACHO_SKALA_ENDWERT | SPEEDOMETER MAXIMUM VALUE" sizex="1" sizey="1" storageaddress="0x4" storagetype="uint8" type="1D">
<description>Add additional description here</description>
<state data="6D" name="220_km/h_ece | 220 kilometers per hour | (europe)" />
<state data="81" name="260_km/h_ece | 260 kilometers per hour | (europe)" />
5. Masking: You can add a property mask="20" (defined in hex), which will mask out certain bits. This is dependent on the storagetype, for uint16 you would write it as "FF20" for example. In retrospect I should have added the 0x-Prefix here...
6. Loading definitions remotely: This definition will automatically pull the latest version off ba114s MS41 Github and fallback to the file locally (will need to be in the same folder) if no connection is available:
Code:
<?xml version="1.0" encoding="utf-8"?>
<xi:include href="https://raw.githubusercontent.com/ba114/Siemens-MS41/main/MS41%20ECU%20Definitions.xml" xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:fallback>
<xi:include href="MS41 ECU Definitions.xml"></xi:include>
</xi:fallback>
</xi:include>
This uses x-include, which you can also use to split your definition into multiple files. You could for example put fuel and ignition tables into seperate files and include them in the main file.
7. Skipping the physical-to-raw tag: If you are using integer storagetypes (so no floats), you can skip the to_byte tag. RR will find the nearest match for the value you entered at runtime. This will be a slower then supplying the to_byte tag however. I added this for XDFs support, since XDFs dont supply the inverted formula.
8. dataLayout tag: You can add a tag dataLayout="bosch_subtract" (currently the only supported) for axis layouts that cannot be defined with a normal definition. In this case this implements the bosch subtract axis style (see
viewtopic.php?t=16613), but if you work on an ECU with a fancy axis layout more variants can be added here.
This should have been most of it. I also heavily refactored the code at some point, which gained large performance and memory improvements. Thats why recent RR versions can handle much larger definitions and also load much faster then for example 0.5.9.
Cheers,
Robin