Anyone worked with the 16196397 yet?

[RobertISaar]

even if that last slot wouldn't be available, it wouldn't be difficult to either use just the E-side ADX when dialing in the fuel calibration or change the standard ADX to grab a frame from the E-side that has been modified to include the wideband value(preferably the shortest length message to keep log rate up).

sorry about the lack of communication, there's been a hell of a curveball thrown at work... one person getting fired for sexual harassment has thrown most of the shop into chaos, combined with a sudden workforce reduction on the 1st and 3rd shifts, now our shift has to pick up the slack.

[Xnke]

No problem man. The boost patch I just tried does not work at all, so back to the drawing board.

It's basically the patch you sent in the codebase .zip, but I changed the values that were used to send the stuff across the SPI-The values are being updated now, but they're very erratic and I probably got some operators wrong or something. Maybe I switched 2-bar map and emulated 1 bar map? I dunno.

More logs and data soon.

[Xnke]

Ok. So, it doesn't work at all. BUT! Winflash doesn't complain about the PCM giving a wrong response at the end of flashing it, so that's a plus.

Current BIN: NoVats94 F manualpatchtest.bin

Current XDF: P66 V6-modded by jake(1).xdf

Current ADX: E-side only P66V6_1.adx

Current Log: Oopstest.xdl

Patch Data: new boost coderevision2.txt

Take a look through the patch data and see if I did something stupid-I also have the patch entered into the XDF but when I first attempt to patch a virgin BIN, it says patch data indeterminate, so I may have screwed something up there too. I don't know.

[charlay86]

So there's a few issues with the patch:
The JSR instruction target address needs to be corrected.
patch prob 2.jpg
patch prob.jpg
Also that .adx isn't working properly
ADX.png
The attached spreadsheet is based on the raw data from the XDL log file..
oops log.xls

[Xnke]

well, since BA47 is only two bytes, I'll have to make a jump to insert my three byte modification, right?

The JSR target address is a goof I made I think, something related to the offset? instead of jumping to 9458, should I instead jump to 1458? That's where the new spark table code is inserted into the blank space. So at CD5B, I currently have "7E 94 58" but when I subtract the address offset that means CD5B becomes 4D5B. Which also means that location 9458 becomes 1458. Right now 9458 is something to do with main spark table, but 1458 is blank space that I put in some instructions to do the 2bar map stuff. Should I change, at location CD5B, to "7E 14 58" ??

[kur4o]

well, since BA47 is only two bytes, I'll have to make a jump to insert my three byte modification, right?

The JSR target address is a goof I made I think, something related to the offset? instead of jumping to 9458, should I instead jump to 1458? That's where the new spark table code is inserted into the blank space. So at CD5B, I currently have "7E 94 58" but when I subtract the address offset that means CD5B becomes 4D5B. Which also means that location 9458 becomes 1458. Right now 9458 is something to do with main spark table, but 1458 is blank space that I put in some instructions to do the 2bar map stuff. Should I change, at location CD5B, to "7E 14 58" ??

You shouldn`t do that. It will mess the code. Use +$8000 offset only when you add the patch in tunerpro.
At the bin you should keep the relative address location. On e and t side they both start at 8000 relative address.
0-2000 is only used as RAM memory. 2000-8000 is empty memory or memory shared with other processors on the board, since I have seen jumps in that region.

[charlay86]

well, since BA47 is only two bytes, I'll have to make a jump to insert my three byte modification, right?

The JSR target address is a goof I made I think, something related to the offset? instead of jumping to 9458, should I instead jump to 1458? That's where the new spark table code is inserted into the blank space. So at CD5B, I currently have "7E 94 58" but when I subtract the address offset that means CD5B becomes 4D5B. Which also means that location 9458 becomes 1458. Right now 9458 is something to do with main spark table, but 1458 is blank space that I put in some instructions to do the 2bar map stuff. Should I change, at location CD5B, to "7E 14 58" ??

The addresses are all correct, they are absolute, definitely do not subtract 0x8000.
Apologies, there is an extra line of code that is never executed that was confusing me:
ROM:CD5E BD 94 60 jsr loc_945F+1 ; main spark table
you could replace this instruction with NOPs to avoid confusion.
you can do this to avoid having to jump around:
at BA44:
F6 03 69 : ldab byte_369
FD 01 B3 : std byte_1B3
48 : asla (we put acca into byte_1B3, so we add acca to itself. ie multiply by 2)
01 : nop
------
BA4C:
1B : aba (as per before)

[Xnke]

Here's the results of today:

Now, I see no MAP values other than 10.35kpa, and Baro values are stuck at 95kpa, and even looking directly at the E-side values, they never change or are updated. It's like the new code isn't even being executed at all.

I can't get the actual raw values (by putting them into the mode 1 message 0 stream) to give data-which is why I don't think they're actually being executed. That's why I loaded the E-side ADX, I filled in value 49 and 50 from the ALDL message table with the 0369 and 036A values, which should be RawMAP and MAP map exceeds 1BAR, and you'll see the MAP exceeds 1 bar flicker a moment but never does the RAW ECM MAP value change.