RamTune XML Spec Discussion

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 992

Ok, lets get this ball rolling. I figure we can attack the XML spec and ensure that it has the capability of meeting everyones needs. Merch had some good ideas that I hope he expresses here as I don't have the time to read through *all* the old threads. Since we also have a new set of people hacking at this, its important to take this from the start to ensure we are all on the same page.

I've made a rough cut knowing there are issues, given I spent a whole 2 minutes hacking out an instance doc. Maybe someone can hack out an XSD after all the features are laid out.

Only have a few minutes before people get into the office here.

My goals were:

1) Tie the available extensions to a calid and ecuid.
2) Map out known large ram holes.
3) Provide the means to add any number of extensions for a given set of holes. This is where business logic takes over a bit to ensure sanity. One can't presumably add ALL extensions in the future.
4) Like the code use to toggle switches, having the code to patch in can live in the XML spec.

Thoughts please!

EDIT :oops:

Crap, I knew I left something out, of course the patched in code needs to know where to find the tables in RAM. Someone extend the below to incorporate this.

Code:

<ramTune>
   <ram>
      <calid>A8DG300Z</calid>
      <ecuid>4342592006</ecuid>
      <ramHoles>
         <hole startAddress="0x100" endAddress="0x200"/>
         <hole startAddress="0x432" endAddress="0x500"/>
      </ramHoles>
      <romAdditions>
         <addition name="Timing Relocation" romAddress="0x45" memSizeRequired="0x244">
            <description>The enables blah blah blah</description>
            <code>
                 00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A
            </code>
         </addition>
         <addition name="WGDC Relocation" romAddress="0x467" memSizeRequired="0x400">
            <description>The enables blah blah blah</description>
            <code>
                 00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A
            </code>
         </addition>
         <addition name="Primary Fuel Relocation" romAddress="0x10005" memSizeRequired="0x654">
            <description>The enables blah blah blah</description>
            <code>
                 00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A
            </code>
         </addition>
      </romAdditions>
   </ram>
</ramTune>

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 992

I didn't think a lookup table in ram would be a great space saving idea. I added "codeByteRamAddress" to the spec below to describe the byte in the patched in code that would reference the address in RAM where its needed table resides.

Code:

<ramTune>
   <ram>
      <calid>A8DG300Z</calid>
      <ecuid>4342592006</ecuid>
      <ramHoles>
         <hole startAddress="0x100" endAddress="0x200"/>
         <hole startAddress="0x432" endAddress="0x500"/>
      </ramHoles>
      <romAdditions>
         <addition name="Timing Relocation" romAddress="0x45" memSizeRequired="0x244">
            <description>The enables blah blah blah</description>
            <codeByteRamAddress offset="22"/>
            <code>
                 00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A
            </code>
         </addition>
         <addition name="WGDC Relocation" romAddress="0x467" memSizeRequired="0x400">
            <description>The enables blah blah blah</description>
            <codeByteRamAddress offset="42"/>
            <code>
                 00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A
            </code>
         </addition>
         <addition name="Primary Fuel Relocation" romAddress="0x10005" memSizeRequired="0x654">
            <description>The enables blah blah blah</description>
            <codeByteRamAddress offset="66"/>
            <code>
                 00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A 00 00 00 00 00 00 00 00 
                  5A A5 A5 5A 00 00 00 00 00 00 00 00 5A A5 A5 5A 
                  00 00 00 00 00 00 00 00 5A A5 A5 5A 00 00 00 00 
                  00 00 00 00 5A A5 A5 5A
            </code>
         </addition>
      </romAdditions>
   </ram>
</ramTune>

rootusr · **Joined:** Tue Mar 27, 2007 11:16 pm **Posts:** 5

So basically, right now you're 'hard coding' the code to launch the tables AND the tables themselves in XML and then you have to also write code to change lookup tables to RAM. Interesting

In the end I assume the GUI would handle all the ECU code changes and the user would just have to 'create new RAM map' then change the maps they wanted to, and the GUI would generate the correct table lookups into ram for ONLY the tables that were changed?

Sounds awesome

merchgod · **Joined:** Wed Mar 29, 2006 10:38 pm **Posts:** 4225

I think you need to decide exactly how your real-time tuning is going to work before you start planning the xml format. Even with static maps, there's several different ways you can implement it, with a Cobb-like setup being the simplest. The problem with going with a Cobb-like setup is that it is so basic, it is essentially going to appear to be a carbon copy of their work. The RAM hole is generally small enough that the map assortment that they choose is pretty much going to be the optimal setup for tuning, so you'll also end up with pretty much the exact same map assortment as well.

Frankly, going with a Cobb setup is not something I would want to be involved in. Then, it just looks like you are copying Cobb. I would want to at least do them one better.

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 992

merchgod wrote:

I think you need to decide exactly how your real-time tuning is going to work before you start planning the xml format. Even with static maps, there's several different ways you can implement it, with a Cobb-like setup being the simplest. The problem with going with a Cobb-like setup is that it is so basic, it is essentially going to appear to be a carbon copy of their work. The RAM hole is generally small enough that the map assortment that they choose is pretty much going to be the optimal setup for tuning, so you'll also end up with pretty much the exact same map assortment as well.

Frankly, going with a Cobb setup is not something I would want to be involved in. Then, it just looks like you are copying Cobb. I would want to at least do them one better.

Like I said in the first post, I want to use the XML def to define what we're targeting. Its a great medium to express desired features.

Also, I alluded to the fact you had some other good ideas, please post them here or link to a post. The old thread is a tad long.

EDIT: For others chiming in, here is the old thread topic1136.html

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 992

Does this still stand? I like it

Quote:

With the successful test of the new Ramtune code yesterday, I'd figured I'd explain the underlying process a bit better. For simplicity's sake, let's say that we are dealing with a total of 4 possible RamTune tables:

Code:

Map                          Rom Address
Base Timing A                0x29BB2
Ignition Correction A        0x2A11D
Max WG Duty                  0x2B36A
Target Boost                 0x2B46F

The rom address is the table's map definition byte. Normally, in the Subaru code, this offset would be passed to the map interpolation function which will then determine the correct target for that table based on the current axis values (example rpm, load, etc). Instead, we overwrite the loading of the offset with an index value that is unique to that table. For example:

Code:

Map                      Index value
Base Timing A                0
Ignition Correction A        1
Max WG Duty                  2
Target Boost                 3

Then we jump to our custom function to figure out if we are going to use the normal rom offset for a particular table or a RamTune ram offset. This will be determined by what the user has it set to (map switching). There are two look up tables. One is the rom table which is located in the rom (flash area). It contains the normal rom offsets for each table:

Code:

Map                    Index value     Offset (from 0x20000)
Base Timing A                0              0x9BB2
Ignition Correction A        1              0XA11D
Max WG Duty                  2              0XB36A
Target Boost                 3              0XB46F

So, if a rom offset is to be used, we just use the index value to look up the correct offset and return that value. Then, for that particular table, the values are used from the rom.

With RamTune tables, the process is similar. Problem is, not all of the 19 tables (4 in this example) we wish tune with will fit in our memory hole. So, the user would select which combination they want up to a certain point. We have to have some way of indicating that a particular RamTune table is inactive.

So, there is also a ram offset look-up table located in a specific location in ram. It the same as the rom lut except that tables that are deactivated are represented with a null offset. So, let's say the user has Base Timing and Ignition Correction as the only active RamTune maps:

Code:

Map                    Index value     Offset (from 0x20000)
Base Timing A              0              0x037D
Ignition Correction A      1              0X05AF
Max WG Duty                2              0X0
Target Boost               3              0X0

So, we can see that Max WG Duty and Target Boost have offsets of zero. When our custom function comes across a zero offset, it will revert to using the rom lut for that particular table. Notice that the offsets for Base Timing and Ign Correction are different. That is because we are pointing to the RamTune tables in ram instead of the normal tables in rom. The ram lut will be entirely written to and changed by RomRaider. As the user selects different combination of maps, the offsets will need to be changed to reflect this.

merchgod · **Joined:** Wed Mar 29, 2006 10:38 pm **Posts:** 4225

That would be one way to do it and would be applicable to the 16-bit ECU only (the general concept would be the same for the 32-bit ECU with some differences in implementation).

If I had the time to do an RT tuning myself, this is how I would proceed:
1. Plan on creating a standalone RAM flashing and ROM patching utility
2. Get read/writes to RAM via SSM nailed down. I would only support the OpenPort 2.0 - not only can you guarantee the user is using the same hardware (and not some $10 chinese cable with crappy drivers), the OP 2.0 will be a much more reliable means of doing read/writes and will actually be easier to code for. Read the Drewtech PassThru J2534 API pdf.
3. Plan on a dynamic RT tuning setup but only for one table at a time. This will simplify things greatly while still building the foundation for future multiple table assortments. That is, you don't have to deal with map assortment profiles, calculating RAM offsets for multiple tables, etc. in the beginning. Here's how it would work:
A. User patches ROM with RT code and flashes it to their ECU. The RT code is generic and not specific to any tables.
B. User opens utility and chooses a ROM file to start with (same rom id that is flashed to the ECU) and chooses a table they wish to RT tune. Utility connects to ECU, verifies rom id (via ecu id) is the same and then copies the table's ROM data to RAM and updates the RAM lut (ROM offset and corresponding RAM offset). It then verifies the write and if A-ok, activates the RAM tuning for that table.
C. User uses their own ROM editor to make changes and then saves. In the utility, they choose to write to RAM. Utility reads rom file again for the current table and copies new data to RAM. Changes will be fast - the name of the file will be locked in the utility, so the process would be, make changes to table in RomRaider (or whatever), SAVE, in utility -> hit update, rinse-repeat.
D. When the user is done with the table, they already have a ROM file with the changes saves for that table. They just need to flash that to the ECU with Ecuflash. They can then move on to the next table.
4. ROM patching would include the ability to check for existing code before patching (via checkum) and would also have a default set of factory values that cover every change in every patch per rom id.

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 992

merchgod wrote:

That would be one way to do it and would be applicable to the 16-bit ECU only (the general concept would be the same for the 32-bit ECU with some differences in implementation).

If I had the time to do an RT tuning myself, this is how I would proceed:
1. Plan on creating a standalone RAM flashing and ROM patching utility
2. Get read/writes to RAM via SSM nailed down. I would only support the OpenPort 2.0 - not only can you guarantee the user is using the same hardware (and not some $10 chinese cable with crappy drivers), the OP 2.0 will be a much more reliable means of doing read/writes and will actually be easier to code for. Read the Drewtech PassThru J2534 API pdf.
3. Plan on a dynamic RT tuning setup but only for one table at a time. This will simplify things greatly while still building the foundation for future multiple table assortments. That is, you don't have to deal with map assortment profiles, calculating RAM offsets for multiple tables, etc. in the beginning. Here's how it would work:
A. User patches ROM with RT code and flashes it to their ECU. The RT code is generic and not specific to any tables.
B. User opens utility and chooses a ROM file to start with (same rom id that is flashed to the ECU) and chooses a table they wish to RT tune. Utility connects to ECU, verifies rom id (via ecu id) is the same and then copies the table's ROM data to RAM and updates the RAM lut (ROM offset and corresponding RAM offset). It then verifies the write and if A-ok, activates the RAM tuning for that table.
C. User uses their own ROM editor to make changes and then saves. In the utility, they choose to write to RAM. Utility reads rom file again for the current table and copies new data to RAM. Changes will be fast - the name of the file will be locked in the utility, so the process would be, make changes to table in RomRaider (or whatever), SAVE, in utility -> hit update, rinse-repeat.
D. When the user is done with the table, they already have a ROM file with the changes saves for that table. They just need to flash that to the ECU with Ecuflash. They can then move on to the next table.
4. ROM patching would include the ability to check for existing code before patching (via checkum) and would also have a default set of factory values that cover every change in every patch per rom id.

My copied ROM & RAM LUT method you supplied could work for 32 ROMs with changes? Is the logic about the same between the 16bit and 32bit? I'd only offer up work on 32bit ROMs.

1) Planned.

2) Crap, $170. Ohhh well. Suppose this can be my bday present. Maybe I'll add it to one of the wedding registries. Good point.

3) Yes, like my desire to just play with WGDC initially. Since I have a MBC in line with the BCS, I can test without overboost fear. Yes, lots of user interaction details.

4) Like UTEC maps we could sum all the bytes or something similar for a cheap checksum before pushing to ROM, then do a pull and verify. If the same, update the RAM LUT.

There is lots to plan. I like the dual LUT version. If this is possible with the 32Bit ROMs, I'll proceed with pulling your XML def proposals from the other thread, to here.

All I want this thread to be is XML related. Other details will follow in future threads. My hope is that if I get hit by a car, then someone can take the XML agreed on and move onto the next step.

merchgod · **Joined:** Wed Mar 29, 2006 10:38 pm **Posts:** 4225

The problem with the 32-bit ECU with the dynamic on-the-fly RT tuning is that you are not dealing with a single 16-bit offset to define the RAM table location like the 16-bit ECU, but rather upwards of around 30 bytes for the RAM lut. So, really, it would depend on what the size of the RAM hole is as that would add up pretty quick. Probably better to store the RAM lut in the ROM and then you would only be dealing with a 32-bit offset per table in RAM. The disadvantage would be that the user would have to flash with Ecuflash to change the map assortment. Note that I haven't written any RT code for the 32-bit ECU and haven't messed with it much in that regards - just thought about how I would generally go about it if I were to. You still have a ton of work to do before you are even close to the testing stage on your own car (plus the fact that no RT code has even been developed).

I would set up a virtual ECU, so that you can test your application along the way. When you get to a point where you can begin testing, then perhaps by then, someone will step up to work on the RT code and be willing to be patch bitch for all the different rom revisions. So, really, some parts of the app will depend on how they decide to implement the RT code and what type of RT tuning it is based on.

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 992

merchgod wrote:

The problem with the 32-bit ECU with the dynamic on-the-fly RT tuning is that you are not dealing with a single 16-bit offset to define the RAM table location like the 16-bit ECU, but rather upwards of around 30 bytes for the RAM lut. So, really, it would depend on what the size of the RAM hole is as that would add up pretty quick. Probably better to store the RAM lut in the ROM and then you would only be dealing with a 32-bit offset per table in RAM. The disadvantage would be that the user would have to flash with Ecuflash to change the map assortment. Note that I haven't written any RT code for the 32-bit ECU and haven't messed with it much in that regards - just thought about how I would generally go about it if I were to. You still have a ton of work to do before you are even close to the testing stage on your own car (plus the fact that no RT code has even been developed).

I would set up a virtual ECU, so that you can test your application along the way. When you get to a point where you can begin testing, then perhaps by then, someone will step up to work on the RT code and be willing to be patch bitch for all the different rom revisions. So, really, some parts of the app will depend on how they decide to implement the RT code and what type of RT tuning it is based on.

So we have the case that the 16bit roms lack the ROM space to host a couple LUTs, while the 32Bit ROMs possibly lack the RAM space to host the 2nd LUT.

This could impact the ramtune XML Defs.

I would prefer to have 1 solution across the board as far as LUT locations are concerned. I'd like the initial take to be as simple as possible. How about the defs get defined with the case of 1 LUT in ROM, one in RAM no matter the ROM (16/32). Surely we can get at least one entry in a 32 Bit ROM LUT to play with. If its found memory hole size in 32Bit ROMs is truly limiting either we later then move the 2nd LUT to the ROM, or set a strict limit on the number of LUT entries in RAM.

This is somewhat of an iterative approach zeroing in on the best solution. Also, how far along was the older RamTune application in terms of the ram dump feature? Can it pull 32bit RAM dumps? If so we could take a peak at available space and make a (edit: best effort) final decision on LUT locations.

merchgod · **Joined:** Wed Mar 29, 2006 10:38 pm **Posts:** 4225

Tgui wrote:

So we have the case that the 16bit roms lack the ROM space to host a couple LUTs, while the 32Bit ROMs possibly lack the RAM space to host the 2nd LUT.

This could impact the ramtune XML Defs.

I would prefer to have 1 solution across the board as far as LUT locations are concerned. I'd like the initial take to be as simple as possible. How about the defs get defined with the case of 1 LUT in ROM, one in RAM no matter the ROM (16/32). Surely we can get at least one entry in a 32 Bit ROM LUT to play with. If its found memory hole size in 32Bit ROMs is truly limiting either we later then move the 2nd LUT to the ROM, or set a strict limit on the number of LUT entries in RAM.

This is somewhat of an iterative approach zeroing in on the best solution. Also, how far along was the older RamTune application in terms of the ram dump feature? Can it pull 32bit RAM dumps? If so we could take a peak at available space and make a (edit: best effort) final decision on LUT locations.

Let me explain, at least the way I would probably do it, how the RT code works when it comes to dynamic RT tables and I think you'll better understand:

We insert hooks in the ROM code where the ECU is passing the table offset to the 2d/3d map target functions. Our custom function detemines whether we are running RT RAM tables or not. If not, it simply returns the ROM offset passed to our custom function back to the map target function and nothing has changed. If were are, then it checks the current table offset against our RAM lut to see if it is one of the RT tables. If it's not, it, also returns the ROM offset to the map target function and nothing has changed. If it is, then we return the map offset for RT table which follows each corresponding ROM offset in the RAM lut and would contain the map info pointing to our RT RAM tables.

Let's say we have Target Boost and Initial WGDC as our two RT tables. The RAM lut (written by the user app), might look like this (32-bit ECU):
{0x00095A30, 0x000F0000, 0x000959F8, 0x000F0020}
0x00095A30 = normal map info ROM offset for Target Boost
0x000959F8 = normal map info ROM offset for Initial WGDC
0x000F0000 = RT map info ROM offset for Target Boost (map info points to our Target Boost RAM table)
0x000F0020 = RT map info ROM offset for Initial WGDC (map info points to our Initial WGDC RAM table)

So, if 0x000959F8 is passed to our custom function, the ROM code will iterate through our RAM lut (if RAM table mode is active) looking at every other 32-bit offset. If it finds a match, it will return the offset immediately following the match (in this case 0x000F0020) and normal ECU operation will continue. The ECU will then use the map info for initial WGDC at 0x000F0020 which will contain offsets pointing to our RT RAM tables. This is an example if the map info for RT tables is stored in the ROM. You could also store it in RAM and therefore the user app could change it at any time without a flash. The problem is, that this would take up too much of our RAM hole and probably would not be worth it as it would reduce your total map assortment by quite a bit.

Another way to implement this would be to change the ROM offset to indicate a position in our RAM lut and change the first byte of the ROM offset to any non-zero value (which would never be the case normally) to indicate that it is a RT specific table.

Jon [in CT] · **Posted:** Wed Oct 15, 2008 5:59 pm

merchgod wrote:

This is an example if the map info for RT tables is stored in the ROM. You could also store it in RAM and therefore the user app could change it at any time without a flash. The problem is, that this would take up too much of our RAM hole and probably would not be worth it as it would reduce your total map assortment by quite a bit.

Another way to implement this would be to change the ROM offset to indicate a position in our RAM lut and change the first byte of the ROM offset to any non-zero value (which would never be the case normally) to indicate that it is a RT specific table.

What if the RAM LUT, stored in RAM, contained the offset to the RAM table, but relative to the start of the RAM LUT? Then one should be able to get away with using 16-bit offsets, reducing the RAM LUT size requirement by half. But this wouldn't work if one is trying to use more than one RAM hole and they are more than 64K apart.

merchgod · **Joined:** Wed Mar 29, 2006 10:38 pm **Posts:** 4225

Jon [in CT] wrote:

What if the RAM LUT, stored in RAM, contained the offset to the RAM table, but relative to the start of the RAM LUT? Then one should be able to get away with using 16-bit offsets, reducing the RAM LUT size requirement by half. But this wouldn't work if one is trying to use more than one RAM hole and they are more than 64K apart.

The RAM lut needs to have the ROM offset and the RT RAM offset. In the case of the 16-bit ECU, you could change the ROM map offset to an index position relative to the RAM lut (with the MSB byte = 0xFF to indicate a RT table), but then you would have no way to switch to ROM tables if necessary (post-reset or say if on-the-fly map switching were possibility or if an error occured). The 32-bit ECU complicates matter as the map offset points to the map info (up to 30 bytes of data) and if your table assortment is dynamic, then that map info, as far as the RT offsets in RAM, also has to be dynamic. That can be placed in RAM, but that might be 250-300 bytes for 10 tables and probably not be worth it. The map info could be placed in ROM, but you would still need two 32-bit offsets per table in the RAM lut.

wrxsti-l · **Posted:** Wed Oct 15, 2008 6:27 pm

merchgod wrote:

1. Plan on creating a standalone RAM flashing and ROM patching utility

Why does this need to be stand alone? Why couldn't the ROM patching and RAM flashing be built into RomRaider?

GUI-wise, it could be an extra couple buttons before "overlay Log" that only show up when the "User Level" has been set to "Advanced" or higher.

As for the code to implement it, I have no idea, but assume that it would take no longer including it in RomRaider then creating it as a stand-alone utility.

Tgui · **Joined:** Tue Jul 11, 2006 9:25 pm **Posts:** 992

wrxsti-l wrote:

merchgod wrote:

1. Plan on creating a standalone RAM flashing and ROM patching utility

Why does this need to be stand alone? Why couldn't the ROM patching and RAM flashing be built into RomRaider?

GUI-wise, it could be an extra couple buttons before "overlay Log" that only show up when the "User Level" has been set to "Advanced" or higher.

As for the code to implement it, I have no idea, but assume that it would take no longer including it in RomRaider then creating it as a stand-alone utility.

So other applications can leverage the work being done here.

RomRaider

RamTune XML Spec Discussion

Who is online