Chrome V3, need a place to organize my thoughts

[Monochrome]

[quote=""Jeff V.""]You're over complicating this. Making matters worse, you keep flipping between mass and volume like they're interchangeable. They're not.

The sensor measures the volume of air drawn through it over a given period, applies the temperature and baro corrections to determine the mass of air in that volumetric measurement, and then uses the 3D lookup table to determine how much fuel to inject to achieve the desired AFR for the engine's current speed.

"Load" is air mass drawn through the sensor per unit of time.[/quote]

Ah yep. I need to be saying volume not mass. I’ll go back and edit that.

But....

Do we have two different ROMs disassembled? The fuel table look up is just another correction factor to the equation which comes later. I’ll get into that when I get into the rest of the intake tables.

All I’m focusing on is Load. I just posted the code for how Load is calculated....

What am I missing?

[mjannusch]

[quote=""Monochrome""]You just have your 2G spyder correct?[/quote]
That's correct. Now it has a 1G CAS with a 24-tooth trigger disc.

[Monochrome]

[quote=""mjannusch""]That's correct. Now it has a 1G CAS with a 24-tooth trigger disc.[/quote]

Damn. I need a couple people with 91/92 cars and a flash ECU to replicate this test.

[aaronatstate]

[quote=""Monochrome""]I just had someone run a test for me using a timing light and having the code fix the timing to 5 degrees. Would like at least one or two more people to verify this.

You just have your 2G spyder correct?[/quote]

At idle RPMs the timing is off by less than a degree, so I doubt you’d see it with a timing light. At 700 RPM it’s 0.35 degrees off. At 7000 RPM it’s off by 3.5 degrees, based on the sensor latency. The math works out to be 0.0005xRPM=Timing difference. With a 1g sensor it advances the timing more.

The latencies are 0.05 milliseconds for 1g, and 0.130 milliseconds for 2g. It may not be in the code but built into the hardware of the ECU. The signals are definitely coming in at different rates between the sensors.

So it may not be entirely BS

I have a 92 with a flash ECU from Adam.

[Monochrome]

[quote=""aaronatstate""]At idle RPMs the timing is off by less than a degree, so I doubt you’d see it with a timing light. At 700 RPM it’s 0.35 degrees off. At 7000 RPM it’s off by 3.5 degrees, based on the sensor latency. The math works out to be 0.0005xRPM=Timing difference. With a 1g sensor it advances the timing more.

The latencies are 0.05 milliseconds for 1g, and 0.130 milliseconds for 2g. It may not be in the code but built into the hardware of the ECU. The signals are definitely coming in at different rates between the sensors.

So it may not be entirely BS

I have a 92 with a flash ECU from Adam.[/quote]

Yeah but who has actually tested this? How did they test it?

Hint: I think I know why the timing variates but if I’m right it’s not because of sensor lag. Again I need a couple more people with timing lights and 91/92 cars with a flash ECU to do a test

[aaronatstate]

[quote=""Monochrome""]Yeah but who has actually tested this? How did they test it?

Hint: I think I know why the timing variates but if I’m right it’s not because of sensor lag. Again I need a couple more people with timing lights and 91/92 cars with a flash ECU to do a test[/quote]

Why don’t you explain it first? :d ontknow:

My point is you aren’t going to be able to discern a .35 degree difference on the scale on the lower timing cover. Especially when the scale is 5 degree increments. Sorry, there is no one that will see that difference.

AEMs software has a setting for sensor latency. They must think it’s important enough

Like I said it could be in the hardware of the ECU.

[ChargerX3]

What else could the lag be then?

[Monochrome]

[quote=""aaronatstate""]Why don’t you explain it first? :d ontknow:

My point is you aren’t going to be able to discern a .35 degree difference on the scale on th elbowed timing cover. Especially when the scale is 5 degree increments. Sorry, there is no one that will see that difference.

AEMs software has a setting for sensor latency. They must think it’s important enough

Like I said it could be in the hardware of the ECU.[/quote]

Actually... You can.

So about a month ago I finally finished disassembling the MUT commands in the code. I had to go across 6 different ROMs to figure out what each command did (our ROM doesn't have all of them populated) but one of the commands is D9.

Code: Select all

RAM:0000F644 ?? ??       MUT_Actuator_Flag0:.space 2             ! DATA XREF: FP_CrankRotate_Test+6r
RAM:0000F644                                                     ! PurgeSystem+24r ...
RAM:0000F644                                                     ! Bit 00 = MUT D9 - Fix Timing to 5 Deg
RAM:0000F644                                                     ! Bit 01 = MUT D8 - Fuel Pump
RAM:0000F644                                                     ! Bit 02 = MUT D7 - Purge Solenoid
RAM:0000F644                                                     ! Bit 03 = MUT D6 - FPR Solenoid
RAM:0000F644                                                     ! Bit 04 = MUT D5 - EGR
RAM:0000F644                                                     ! Bit 05 = MUT F2 - VICS
RAM:0000F644                                                     ! Bit 06 = MUT D3 - BCS Solenoid
RAM:0000F644                                                     ! Bit 07 = MUT D3 - Fuel Pump resistor
RAM:0000F644                                                     ! Bit 08 = MUT D2 - Active Exhaust
RAM:0000F644                                                     ! Bit 09 = MUT D1 - Open
RAM:0000F644                                                     ! Bit 10 = MUT CF - Open
RAM:0000F644                                                     ! Bit 11 = MUT CE - High (Both) Radiator Fans
RAM:0000F644                                                     ! Bit 12 = MUT CD - Low Rad fan
RAM:0000F644                                                     ! Bit 13 = MUT CC - O2 heaters
RAM:0000F644                                                     ! Bit 14 = MUT CB - Open
RAM:0000F644                                                     ! Bit 15 = MUT CA - MIVEC
RAM:0000F646 ?? ??       MUT_Actuator_Flag1:.space 2             ! DATA XREF: PurgeSystem+2Ar
RAM:0000F646                                                     ! PurgeMUTCmd+17r ...
RAM:0000F646                                                     ! Bit 0 = MUT C9 - Alternator
RAM:0000F646                                                     ! Bit 1 = MUT C8
RAM:0000F646                                                     ! Bit 2 = MUT C7
RAM:0000F646                                                     ! Bit 3 = MUT C6 - Purge Solenoid
RAM:0000F646                                                     ! Bit 4 = MUT C5 - Vent Solenoid
RAM:0000F646                                                     ! Bit 5 = MUT C4
RAM:0000F646                                                     ! Bit 6 = MUT C3 - SAS Mode

MUT command D9 forces the ECU to skip all it's timing modifiers and fixes the timing to 5 degrees without going into SAS mode which also disables closed loop and the ISC.

Using this command and a timing light, I had a local guy shine it at the crank and rev the motor. He claimed it never moved... Obviously the timing belt cover could be distorted or the crank pulley itself could be nicked or improperly made aftermarket.... but if there was a latency, you'd see this lag with the light with the ignition timing fixed.

There are several timing modifiers beyond the timing table in the code for idle, sudden TPS movement, acceleration, deceleration, etc... I really really wonder if anyone has actually tested this properly or just shined a light and assumed there was a sensor latency when actually it could just be one of these timing modifiers in the code.

This is why I need a few more people to test this.

[Monochrome]

On the topic of MUT Commands, I also need someone with a 98/99 SL to verify that VICS command because I don't trust the source who told me it was F2 based on the pattern you see in the bits...

[mjannusch]

[quote=""Monochrome""]but if there was a latency, you'd see this lag with the light with the ignition timing fixed.[/quote]
That seems like a pretty big assumption. Have you disassembled the routine that sets it to 5 degrees? I’d think all that would do is feed 5 degrees of advance into the ignition timing routines instead of pulling from the map, If that’s the case, then you would not see the timing drift at high RPM.

[Monochrome]

[quote=""mjannusch""]That seems like a pretty big assumption. Have you disassembled the routine that sets it to 5 degrees? I’d think all that would do is feed 5 degrees of advance into the ignition timing routines instead of pulling from the map, If that’s the case, then you would not see the timing drift at high RPM.[/quote]

Yes I have. I can post the code if you’d like.

And

That’s exactly what it does. Skips the timing table completely and feeds 5 degrees to the coil output pin.

Why would sensor latency show if it was using the map but not show when being fed a constant from the code? Isn’t this latency supposed to be a lag from crank trigger signals itself? Which would mean we would see this latency get worse and worse with the timing light as the motor was reved?

[aaronatstate]

How do you trigger the MUT commands?

If I can get a timing light this weekend I’ll try it out.

[Monochrome]

[quote=""aaronatstate""]How do you trigger the MUT commands?

If I can get a timing light this weekend I’ll try it out.[/quote]

Use the Custom Request box in the lower right corner of the window in EVOScan.

[mjannusch]

[quote=""Monochrome""]Yes I have. I can post the code if you’d like.

And

That’s exactly what it does. Skips the timing table completely and feeds 5 degrees to the coil output pin.

Why would sensor latency show if it was using the map but not show when being fed a constant from the code? Isn’t this latency supposed to be a lag from crank trigger signals itself? Which would mean we would see this latency get worse and worse with the timing light as the motor was reved?[/quote]
Can you post the code, please? Not sure what's going on, but it could be possible that any sensor latency is compensated for in hardware with some type of predictive latching IC. Or we got it wrong and the latency values in the AEM are actually compensating for how the AEM reads the hall-effect or optical sensor waveform since it might be using a more generic detection strategy than the stock ECU, which likely uses a dedicated IC to read the transition states and trigger an interrupt.

[Hans_GZP]

I'd say the best way to test that theory is to get a stock 91-92 vr4 and plug in a 93 vr4 ecu into it and run the base ignition timing test. If it's hardware, you would see the difference then.

[DCIV]

I have a 92 with a cas.


Coop

[Monochrome]

[quote=""mjannusch""]Can you post the code, please? [/quote]

Hold onto your hats.

It starts here when you enter in custom request MUT D9

Code: Select all

seg001:1F9DB             loc_1F9DB:                              ! CODE XREF: MUT_CMD_Process+B8j
seg001:1F9DB EE 06 05 00+                cmp:g.w #0xD9:16, @(6:8,fp) ! '+' ! Fix Timing to 5 Deg BTDC
seg001:1F9E0 26 14                       bne     loc_1F9F6:8     ! Branch if Not Equal (Z = 0)
seg001:1F9E2 1D F0 A4 16                 tst.w   @T40_MUT_CMD:16 ! Compare with 0
seg001:1F9E6 36 01 0F                    bne     loc_1FAF8:16    ! Branch if Not Equal (Z = 0)
seg001:1F9E9 1D F6 44 C0                 bset.w  #0:16, @MUT_Actuator_Flag0:16 ! Test bit and set

Bit 0 of this flag is switched on. It then gets referenced again here:

Code: Select all

seg002:21164 1D F6 44 F0                 btst.w  #0:16, @MUT_Actuator_Flag0:16 ! Fix Timing to 5 Deg
seg002:21168 27 04                       beq     loc_2116E:8     ! Branch if Equal (Z = 1)
seg002:2116A AA CC                       bset.w  #12, r2         ! Test bit and set

It then sets bit 12 of this flag (F21C)

Code: Select all

1D F2 1C 92                 mov:g.w r2, @TableSetSelect:16 ! Move data

I named this flag TableSetSelect has this flag is used a lot to reference different sets of tables in the code (like Park/Neutral switch). Anyway that's a side track.

Following this bit. Here it then activates another flag...

Code: Select all

seg002:2598E             DiagnosticModeTest: ! far               ! CODE XREF: FixedTimingDiagModeP
seg002:2598E 1D F2 1C FC                 btst.w  #12:16, @TableSetSelect:16 ! Fix timing to 5 deg
seg002:25992 27 0B                       beq     loc_2599F:8     ! Branch if Equal (Z = 1)
seg002:25994 1D F2 1C FB                 btst.w  #11:16, @TableSetSelect:16 ! SAS mode
seg002:25998 26 05                       bne     loc_2599F:8     ! Branch if Not Equal (Z = 0)
seg002:2599A 58 00 01                    mov:i.w #1:16, r0       ! Move data
seg002:2599D 20 02                       bra     loc_259A1:8     ! Branch Always
seg002:2599F             ! ---------------------------------------------------------------------------
seg002:2599F
seg002:2599F             loc_2599F:                              ! CODE XREF: DiagnosticModeTest+4j
seg002:2599F                                                     ! DiagnosticModeTest+Aj
seg002:2599F A8 13                       clr.w   r0              ! Make zero
seg002:259A1
seg002:259A1             loc_259A1:                              ! CODE XREF: DiagnosticModeTest+Fj
seg002:259A1 11 19                       prts                    ! Return from subroutine (different page)

Which then switches another flag bit....

Code: Select all

seg002:2597A             FixedTimingDiagMode: ! far              ! CODE XREF: Timing+8P
seg002:2597A 03 02 59 8E                 pjsr    DiagnosticModeTest:24 ! Branch to subroutine (specified page)
seg002:2597E A8 16                       tst.w   r0              ! Compare with 0
seg002:25980 27 06                       beq     loc_25988:8     ! Branch if Equal (Z = 1)
seg002:25982 1D F4 6A C7                 bset.w  #7:16, @IgnTimingFlags:16 ! Test bit and set
seg002:25986 20 04                       bra     loc_2598C:8     ! Branch Always
seg002:25988             ! ---------------------------------------------------------------------------
seg002:25988
seg002:25988             loc_25988:                              ! CODE XREF: FixedTimingDiagMode+6j
seg002:25988 1D F4 6A D7                 bclr.w  #7:16, @IgnTimingFlags:16 ! Test bit and clear
seg002:2598C
seg002:2598C             loc_2598C:                              ! CODE XREF: FixedTimingDiagMode+Cj
seg002:2598C 11 19                       prts 

Which is finally reference here:

Code: Select all

seg002:25FE8 1D F4 6A F7                 btst.w  #7:16, @IgnTimingFlags:16 ! Test bit
seg002:25FEC 26 0A                       bne     loc_25FF8:8     ! Branch if Not Equal (Z = 0)
seg002:25FEE 1D F3 36 80                 mov:g.w @EngineRotationConditions:16, r0 ! Move data
seg002:25FF2 0C 00 11 50                 and.w   #0x11:16, r0    ! 10001  Bits 0 and 4
seg002:25FF2                                                     !
seg002:25FF2                                                     ! Bit 0 = Engine Running RPMs > 438
seg002:25FF2                                                     ! Bit 4 = Engine Running (starter and isc tests complete)
seg002:25FF6 27 07                       beq     loc_25FFF:8     ! Branch if Equal (Z = 1)
seg002:25FF8
seg002:25FF8             loc_25FF8:                              ! CODE XREF: IgnTimingCalc+ACj
seg002:25FF8 1D 09 FE 83                 mov:g.w @InitialSparkAdv:16, r3 ! Move data
seg002:25FFC 04 14 2B                    adds.b  #0x14:8, r3     ! Addition
seg002:25FFF
seg002:25FFF             loc_25FFF:                              ! CODE XREF: IgnTimingCalc+B6j
seg002:25FFF BF 06 46                    mov:g.w #0x46, @-sp ! 'F' ! Move data
seg002:26002 BF 06 0A                    mov:g.w #0xA, @-sp      ! Move data
seg002:26005 BF 93                       mov:g.w r3, @-sp        ! Move data
seg002:26007 03 01 44 4C                 pjsr    Chk_value_Hi_Lo:24 ! Branch to subroutine (specified page)
seg002:2600B 04 06 2F                    adds.b  #6:8, sp        ! Addition
seg002:2600E 1D F4 70 90                 mov:g.w r0, @IgnTimingFinal:16 ! Move data
seg002:26012 02 2C                       ldm     @sp+, (r2,r3,r5) ! Pop data from the stack to one or more registers
seg002:26014 0F                          unlk    fp              ! Deallocate stack frame
seg002:26015 11 19                       prts                  

9FE (what I call InitialSparkAdv) is 0x0005 aka 5 degrees which is just fed to F470 which is the ignition coil drive output address for that pin.

[quote=""mjannusch""]Not sure what's going on, but it could be possible that any sensor latency is compensated for in hardware with some type of predictive latching IC. Or we got it wrong and the latency values in the AEM are actually compensating for how the AEM reads the hall-effect or optical sensor waveform since it might be using a more generic detection strategy than the stock ECU, which likely uses a dedicated IC to read the transition states and trigger an interrupt.[/quote]

To throw a monkey in the mix (don't shoot me), there is actually a value at A10 which i call Timing Circuit Activation Delay time. Maybe Jeff could double check for me but this value is 0x000F which translates to only 60 uSec (.00006 Seconds or .06 mSec). 0x000F = 15 * 4 = 60

https://www.stealth316.com/2-cas_conversion.htm

As determined from the AEM standalone engine management calibrations, the latency for the 1991-1992 sensors is 50 microseconds (us), or 0.050 millisecond (ms). The 1993 sensors have a 130 us latency (0.130 ms). What this means is that if you install the 1991-1992 optical pickup sensor and use a 1993+ ECU there will be more ignition timing advance than the ECU wants

IF this value in the ROM was for this sensor latency then it's only about half what the AEM calibration calls for unless I got my scaling wrong for this value.

Edit: Found this in the 1G DSM Code

Code: Select all

8878   ECDF                         ;--------------------------------------------------------------------
8879   ECDF                         ; At this point, we will check the CAS signal to make sure it stays
8880   ECDF                         ; set until 56us after the start of the interrupt. I guess this might
8881   ECDF                         ; be to filter eventual glitches in the CAS signal
8882   ECDF                         ;--------------------------------------------------------------------
8883   ECDF DC 7E                   ldd     temp20                  ;                                   
8884   ECE1 C3 00 0E                addd    #$000e                  ; d = StartInterruptTime + $0e (56us)                              
8885   ECE4 8F 16 01 01 L1663       brclr   port5, #$01, L1664      ; Branch as long as CAS bit is clear (CAS signal is set)
8886   ECE8 3B                      rti                             ; CAS bit was set, Bail of interrupt
8887   ECE9 1D 29       L1664       cmpd1   t3_clock1               ; Compare current time to time stored when we started the interrupt processing                                 
8888   ECEB 2A F7                   bpl     L1663                   ; Loop if t3_clock1 < (temp20 + $0e (56us)), i.e. if its been less than 56us since interrupt was called

Looks like 1G DSMs with the photo sensor also have the (almost) same timing control delay (56 uSec instead of 60).

[Monochrome]

[quote=""DCIV""]I have a 92 with a cas.


Coop[/quote]

Grab your timing light, hook it up to the #1 spark plug.

Hook up your laptop to your car, open EVOScan, start your motor and connect. In the custom request box type D9 or C3 (doesn't really matter) and hit enter. This will fix the ignition timing to 5 deg.

Shoot the light at your crank. The light will flicker every time the plug fires which will be when the notch on your crank pulley lines up with the #5 on your lower timing belt cover. Have someone rev the motor to redline.

Report back if the light changes from 5 degrees.

[DCIV]

[quote=""Monochrome""]Grab your timing light, hook it up to the #1 spark plug.

Hook up your laptop to your car, open EVOScan, start your motor and connect. In the custom request box type D9 or C3 (doesn't really matter) and hit enter. This will fix the ignition timing to 5 deg.

Shoot the light at your crank. The light will flicker every time the plug fires which will be when the notch on your crank pulley lines up with the #5 on your lower timing belt cover. Have someone rev the motor to redline.

Report back if the light changes from 5 degrees.[/quote]

This sounds like fun actually. I know the timing stuff, I’ve done that a lot. The custom requested box might be interesting but I will let you know what happens.

Coop

[Monochrome]

Just stopped by to update what's going on with Chrome V3. I'm still not finished but here's a glimpse of what's taking so long.

The goal with V3 is I want to release every single 1D, 2D and 3D table in the ROM. Used, disabled, not used... All-of-them.

The ROM is 196570 bytes in size.

All the 1D tables start at byte 800 and end at byte 155C in the ROM. This means 3420 1D tables alone (all these tables are then repeated on another Page but that's a side track). Again, many are disabled or not used but thanks to disassembling many other H8 Mitsubishi ROMs, I've been able to figure out what most of the unused ones are for.

2D and 3D tables are grouped together and start at 1800 and go to 13BB1. I've lost track of exactly how many there are but there's hundreds of them.

To give a perspective of how large of a challenge this is, these are the tables from Chrome V2 pertaining to just idle. Just about all the tables beyond these I disabled or were disabled in the ROM stock to keep it simple.



Only 15 tables.... Very easy right? Well yes except that's not even close to the whole story of all that goes into idle. Especially since Chrome V2 lost ATX and aftermarket throttle body compatibility.

Here's the rest of the story:



If this was a story, those would just be the chapters. Here's the tables in just chapter 1!



Here's what I can fit into one single screen shot:



Just for idle there are 336 1D tables and 52 2D tables. So... 388 tables total just for idle.... Again, some are disabled or not used.

It took me a month straight (figure about 32-40 hours per week) just to dissect each and every one these. Adam (Jesters) was a HUGE help in poking around at pins on a bench ECU to find out what flags they trigger. We were on the phone for at least 2-3 hours at a time more than a few times to figure a lot of these flags out.

As you can see, this is no easy task.

Where I'm at now is finishing up the disassembly of the tables (about 65% done) and cross referencing them with other Mitsubishi ROMs because I want to bring in features from those ROMs into ours. For example I want to bring in the Code that operates the VICS motors from the DOHC NA cars so they can use the TT ROM in their NA cars. I did this with features such as Lean Spool in Chrome V2. That actually came from an EVO 6 ROM.

I also have several of my own mods that I want to code and also revise a couple of the mods I had in Chrome V2 (such as the Active Exhaust and Custom switched outputs)