So I'm doing a bit of tracing through the 96530006 periphery stuff, and bumped into a question that I'm hoping mrfred, acamus, or someone else can shed some light on. First, some background for those who don't know, or haven't bothered looking at this stuff:

What we call the "periphery" values are actually a set of 6 tables, with 8 word-width entries each, starting at F9A in all ROMs. At FFFF8A04 (in 96530006; other ROMs will differ), a periphery offset is stored which says which of the eight values to look up. sub_DC6, sub_DD2, and sub_DE0 perform those lookups (for byte-, word-, and long-width tables, respectively); passing in r4 as the starting address, the looked-up value is returned in r0. These lookup routines, and sub_DE0 in particular, are used a fair bit elsewhere for doing table lookups; you might be familiar with their use in locating the fuel tables, for example.

At boot, the ROM periphery values (subject to the periphery offset) are copied into RAM; in 96530006, F9A through FEA are copied into FFFF89F6 through FFFF8A00 (D0, D1, D2, D3, D4, and a final address that isn't listed in the MUT region, but it's all consecutive in RAM anyway). There's some mangling that's done to a few of the values, though (and these appear to be universal; 8859, at the very least, supports them):

• if 0x101C is set to 0, both FCA and FDA are set to zero before copying to RAM.
• if 0x101D is set to 0, FCA bit 1 is set to zero before copying to RAM.
• if 0x101E is set to 0, FCA bit 2 is set to zero before copying to RAM.
• if 0x101F is set to 0, FCA bit 4 is set to zero before copying to RAM.
• if 0x1020 is set to 0, FCA bit 5 is set to zero before copying to RAM.
• if 0x1021 is set to 0, FCA bit 6 is set to zero before copying to RAM.
• if 0x1022 is set to 0, FCA bit 7 is set to zero before copying to RAM.
• if 0x1023 is set to 0, FCA bit 8 is set to zero before copying to RAM.
• if 0x1024 is set to 0, FCA bits 9 and 10 are set to zero before copying to RAM.
• if 0x1025 is set to 0, FCA bits 13 and 14 are set to zero before copying to RAM.

Note that, by default, all of the above are set to 1, meaning none of the bit-zeroing happens out of the box. The routine that does this (the copying to RAM, as well as the bit-twiddling) starts at FA6C (in 96530006); the periphery-related stuff is at FAB8.

(Small aside #1: I REALLY don't get the point of these tests; if you can change the 0x101C-0x1025 values in the ROM...er...why wouldn't you just change the periphery bits directly? "Ours is not to question why...")

(Small aside #2: It seems like F9A, which is undocumented in the wiki right now, is mostly used for "system-ish" stuff; at least a couple of bits appear to be immobilizer-related, for example.)

Anyway, what got me started looking at this was FEA; I wanted to see what code was involved with bit 14. This is where I feel a little silly: while I see a ton of references to the other peripheries, where the heck is FEA (or FFFF8A00) referenced? I can't find any obvious code that makes use of it (either directly, or as some offset of MUT_D0), other than the initial copy to RAM, and one check at 3C72E (and that only tests bit 4, and all branches appear to blow r0 away after the bit test).

mrfred, you spent a lot of time digging through this stuff at one point; would you be able to point me at something in 8859 to reference against (I know 9653 isn't your primary interest, I'm happy to do the translation legwork myself)? I feel like I'm missing something incredibly obvious here, because someone obviously found a few of the FEA periphery bits that we've labeled.

 

In your quest to decipher the periphery bits, Can you confirm/deny any additional goings on with Periphery FAA bit 11? I ask because I have a hunch that something is being triggered here that causes cold idle issues.

An OBD II code that that has me wondering is which periphery covers P0505?

Thanks for your hard work....I wish I could code like you guys do. I am just a tester/tuner.

Paul

 

FCA bit 6 is front O2 error code (P0134).
When you disable 0x101C (some code about the front O2) you don't want to pop up the O2 errorcode. I belive it's an automated mechanism to disable the error code for some functions.

When changing the fca you disable the error testing routine. If you disable 0x1021 you disable the whole function and the error test routine.

Thats what i belive. Never spent much time thinking about this.

 

I think the point of the Periphery Offset and and the eight item tables, is you could have multiple versions in one ROM. Like versions for different regions with different emissions requirements and maps for higher/lower quality gas.

The 101C-1025 is a debug master disabler that will turn off FCA bits no matter which offset/version is selected. Possibly for debugging the OBD tests on a multi-version ROM.

All the ROMs I have looked at so far have the eight item tables all identical, so all this is a guess. But thats why I always though they did it like that.

 

I have deciphered some of them already a while ago.
Some of them go further down e.g.
1030 Enable_Closed_Loop
103D Enable_EGR_Solenoid

 

Yeah, the periphery offset itself makes good sense to me, and exploiting it for map switching makes a lot of sense too. You know, I hadn't thought about that; probably makes it a little easier for them as a debugging tool.

Still, I can't find any reference at all to FEA other than that one bit4 test. I have to be missing something obvious, or there's a chunk of code I haven't disassembled somewhere.

More strange details: F40 is the default periphery offset value. If F42 is non-zero, however, the periphery offset is read from F50 plus an offset stored in FFFF8A02 (a second offset; address is specific to 96530006).

Also, I lied; this routine gets called from the main loop too, so the periphery values are constantly being copied to RAM to overwrite whatever is there. Weird.

acamus: yeah, I was leaving the stuff futher down out just because they're part of different routines. There's a huge block of enable/disable functionality words around 0x1000+ that appear to be used all over the place.

 

There is no ref of FEA in MT I4, but there are couple of references in AT V6, so either they have something to do with V6 or with autotransmission.
Do not worry, it has nothing to do with you overlooking something :P

Let me check AT I4, so we are sure what part it affects.

EDIT:
It has definitely something to do with V6.

 

In the 8859, FEA bit14 is used to disable/enable the P0069 "MAP vs baro" test. I believe that this test is present in only the Evo 9 ROMs (and probably the Evo 10 ROM as well).

 

Ahhh, there we go. I had a minor screwup in my 8859 IDA disassembly (don't ask), so references to FFFF6BBC and a bunch of other RAM addresses weren't being generated properly.

Yeah, I don't see any of that in 9653; FEA manipulation seems to be limited to bit 4 on that ROM.

 

About 6 bits are used in the 8859 to disable/enable some OBD tests. I started listing them this morning, but then figured you had seen them all in the 9653. Seems not though. Perhaps the tests these bits control are not present in 9653. Would make some sense as there is much more spare ROM space in the ROM.

 

Wait, are you saying the 96530006 ROM has provisions for AT V6 and/or MT V6 vehicles? From an evo ECU?

 

No, some FEA bits are for 6-cylinder stuff. The periphery bits, some routines, etc., are universal for all mitsu ecus. They reuse a lot of code, because its quicker then starting from scratch.

 

I think I actually heard my hopes shatter when I read this.

Thanks for the quick response though.

 

In looking at FEA for the 9417 series they all have bits 9 - 15 set = 1. Could these be related to the idle issues we get when switch from these roms to the new v7?

I resolved my issue (almost) with varous other periphery settings. What I am hunting for now is the cause of the 2K rpm rev at cold start up that goes away once the car is warm.

 

nvm