Ive been looking at 12587603 disassembly some more and i cant seem to figure out how the axis's are referenced. i can see where the variables for the axis's are pulled from RAM but how the axis's are actually read are still a mystery to me. anyone have any insight on this?
im studying how the main high octane ignition table is read.
INTERPOLATE_TABLE is the 3D lookup routine. A0 is the address of the table, D0 (word) value searched on the X axis, D1 (word) is the value searched on the Y axis. d2 is the size of the of X axis, and the result comes back in D0 as word. So in the above, 19 hex is 25 cells of the table in the X direction which is the only dimension it needs to lookup the value.
If you look at the table, 25 cells in the X direction (400->8000).
The values are scaled before going in to the routine to take into account the axis so the lookup function does not need to know the axis beyond the X size.
So RAM_RPM2 is really RAM_RPM_SCALED and RAM_MAF is RAM_AIR_GPC_SCALED (or something like that). Where GPC=Grams Per Cylinder.
You'll find the scaling code between the ADC read and what writes it to that location in RAM. And all the rest of high and low octane scaling code, just to really keep you on your toes.
So... If it was 1a instead of 19 it would automatically jump to the first cell of the next row? In other words it reads the table as a single row essentially?
Or am I misunderstanding and it jumps 25 cells depending on the y axis lookup.
antus wrote: ↑Mon Jul 01, 2024 6:53 pm
INTERPOLATE_TABLE is the 3D lookup routine. A0 is the address of the table, D0 (word) value searched on the X axis, D1 (word) is the value searched on the Y axis. d2 is the size of the of X axis, and the result comes back in D0 as word. So in the above, 19 hex is 25 cells of the table in the X direction which is the only dimension it needs to lookup the value.
If you look at the table, 25 cells in the X direction (400->8000).
The values are scaled before going in to the routine to take into account the axis so the lookup function does not need to know the axis beyond the X size.
So RAM_RPM2 is really RAM_RPM_SCALED and RAM_MAF is RAM_AIR_GPC_SCALED (or something like that). Where GPC=Grams Per Cylinder.
You'll find the scaling code between the ADC read and what writes it to that location in RAM. And all the rest of high and low octane scaling code, just to really keep you on your toes.
Do you mind elaboration, maybe with another example further down the table?
antus wrote: ↑Mon Jul 01, 2024 6:53 pm
INTERPOLATE_TABLE is the 3D lookup routine. A0 is the address of the table, D0 (word) value searched on the X axis, D1 (word) is the value searched on the Y axis. d2 is the size of the of X axis, and the result comes back in D0 as word. So in the above, 19 hex is 25 cells of the table in the X direction which is the only dimension it needs to lookup the value.
If you look at the table, 25 cells in the X direction (400->8000).
The values are scaled before going in to the routine to take into account the axis so the lookup function does not need to know the axis beyond the X size.
So RAM_RPM2 is really RAM_RPM_SCALED and RAM_MAF is RAM_AIR_GPC_SCALED (or something like that). Where GPC=Grams Per Cylinder.
You'll find the scaling code between the ADC read and what writes it to that location in RAM. And all the rest of high and low octane scaling code, just to really keep you on your toes.
thank you for explaining that! makes a lot more sense now! so looking at this if you wanted to changed the Y axis to manifold pressure instead of grams per cylinder all i would have to do is change what is looked up in RAM instead?
Unless I'm missing a lot (which is likely), looks like forcing speed density is as simple as replacing one RAM address at ROM address 0x7a8e4.
Replace ffffaedc with fffff2bc. Apparently, I don't know.
Thats probably a subject for another thread, but yes if you disconnect the MAF and trigger a DTC and then mask the CEL so you dont get a light, you can get speed density with no code patch. But you loose... I think its traction control? So if your location is correct, you'd need to update the OS Checksum, consider DTCs (assuming you want to remove the MAF), and patch any other part of the OS that disables with the error to restore normal operation. Not too much code but more than one patch.
The SD math writes a grams-per-second value here: 0xFFB0FA
The MAF sensor writes its grams-per-second value here: 0xFFB0F8
PID 0010 is the final MAF value. I haven't looked at the code for a LONG time but I think it just reads from a single RAM address, which is shared by all other code that needs a MAF value, including (I think?) the code that calculates the load (g/cyl) value for the spark table.
If you can find a function that reads from SD-MAF and sensor-MAF addresses, and writes to the final-MAF address, that's the function you'd want to modify to force full-time MAF or full-time SD. Hopefully it won't be too hard to find. But if you can find it, I suspect that it will be straightforward to just force it to copy your chosen input value into the final-MAF address.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
I think I found a crude example of that, but my main concern was the loss of higher RPM tables.
Found 2 spots to replace an address. It would fuck up a lot of things, but still be usable if I'm not missing more. https://www.facebook.com/marc.wolfe.568 ... Jquwwzh6nl
Haven't opened Ghidra since.
