Season's Greetings fellas!
First - thanks to Setzi for the excellent cleanup and modification of the original routine.
I'm a few years late to this party but have used some holiday downtime to do some disassembling whilst learning to code custom ME7 subroutines.
I believe I've found an error in the NLS Ignition-cut-duration counter of this code. http://nefariousmotorsports.com/forum/index.php?topic=607.msg5283#msg5283I am very new to IDApro and C167 ASM in general so I am posting this in all humility and am quite open to the idea that my analysis is incorrect.
See line seg003:0008E870 below -
03:0008E800 ; =============== S U B R O U T I N E =======================================
seg003:0008E800
seg003:0008E800
seg003:0008E800 sub_88E800: ; CODE XREF: sub_88B26E:loc_88B3A6P
seg003:0008E800
seg003:0008E800 arg_E826 = 0E82Ah
seg003:0008E800
seg003:0008E800 jnb word_FD56.8, loc_88E82A
seg003:0008E804 mov r4, 8E40h ; 8E40h
seg003:0008E808 exts #81h, #1 ; 'ü'
seg003:0008E80C mov r9, word_817E00
seg003:0008E810 cmp r4, r9
seg003:0008E812 jmpr cc_NC, loc_88E82A
seg003:0008E814 mov r4, nmot_w
seg003:0008E818 exts #81h, #1 ; 'ü'
seg003:0008E81C mov r9, word_817E02
seg003:0008E820 cmp r4, r9
seg003:0008E822 jmpr cc_ULE, loc_88E82A
seg003:0008E824 movb 8DACh, ZEROS ; 8DACh
seg003:0008E828 jmpr cc_UC, loc_88E888
seg003:0008E82A ; ---------------------------------------------------------------------------
seg003:0008E82A
seg003:0008E82A loc_88E82A: ; CODE XREF: sub_88E800j
seg003:0008E82A ; sub_88E800+12j ...
seg003:0008E82A jnb word_FD56.8, loc_88E880
seg003:0008E82E jb word_FD56.6, loc_88E876
seg003:0008E832 mov r4, nmot_w
seg003:0008E836 exts #81h, #1 ; 'ü'
seg003:0008E83A mov r9, word_817E06
seg003:0008E83E cmp r4, r9
seg003:0008E840 jmpr cc_ULE, loc_88E876
seg003:0008E842 movbz r4, 8B02h ; 8B02h
seg003:0008E846 exts #81h, #1 ; 'ü'
seg003:0008E84A movbz r9, byte_817E08
seg003:0008E84E cmp r4, r9
seg003:0008E850 jmpr cc_ULE, loc_88E876
seg003:0008E852 exts #38h, #1 ; '8'
seg003:0008E856 mov r4, word_384FF0
seg003:0008E85A exts #81h, #1 ; 'ü'
seg003:0008E85E mov r9, word_817E04
seg003:0008E862 cmp r4, r9
seg003:0008E864 jmpr cc_NC, loc_88E888
seg003:0008E866 movb 8DACh, ZEROS
seg003:0008E86A add r4, #1
seg003:0008E86C exts #38h, #1 ; '8'
seg003:0008E870 movb word_384FF0, rl4 ;*********************** I believe this line should be mov word_384FF0, r4 ***********************
seg003:0008E874 jmpr cc_UC, loc_88E888
seg003:0008E876 ; ---------------------------------------------------------------------------
seg003:0008E876
seg003:0008E876 loc_88E876: ; CODE XREF: sub_88E800+2Ej
seg003:0008E876 ; sub_88E800+40j ...
seg003:0008E876 exts #38h, #1 ; '8'
seg003:0008E87A mov word_384FF0, ONES
seg003:0008E87E jmpr cc_UC, loc_88E888
seg003:0008E880 ; ---------------------------------------------------------------------------
seg003:0008E880
seg003:0008E880 loc_88E880: ; CODE XREF: sub_88E800:loc_88E82Aj
seg003:0008E880 exts #38h, #1 ; '8'
seg003:0008E884 mov word_384FF0, ZEROS
seg003:0008E888
seg003:0008E888 loc_88E888: ; CODE XREF: sub_88E800+28j
seg003:0008E888 ; sub_88E800+64j ...
seg003:0008E888 movb rl4, 8AF3h
seg003:0008E88C rets
seg003:0008E88C ; End of function sub_88E800
As the line stands - it moves *byte* r14 value to *word* RAM variable 0x384FF0. At this point r14 = normal ignition closing time (coil dwell time) from tsrldyn as it was in ZUESZ before CALLS to this SUB. I disassembled the earlier iteration of this function (as posted in this thread) and noted that it made use of r14 and an additional RAM location 0x384FF2 as a counter. It seems that with the clean-up and addition of supplemental criteria to v.2 of the function, r14 somehow made its way into the v.2 code (even though its value is neither set nor referenced anywhere in this function save for the original line from ZUESZ before RETS).
So -- long story short - this code does not compare an additive counter (add r4, #1) to ConfigurableIgnitionCutDuration stored at location 0x817E04 (as I believe is the desired behavior) but, rather, compares *byte* r14 (which at this point contains whatever ignition closing time in ZUESZ happens to be) to *word* ConfigurableIgnitionCutDuration.
What does this mean in the real world --? Effectively, I don't know that it means all that much beyond not having too much control over the duration of IgnitionCut. In either case (counting r4++ until we reach ConfigurableIgnitionCutDuration or having an incorrect comparison with r14 serendipitously controlling when ignition is cut) we are oscillating between no ignition and normal ignition. As soon as the comparison is satisfied we return to normal ignition for a moment only to be returned to the NLS function and if the clutch is still depressed and wped > X = ignition is cut again.
If I am correct and there is an error in the coding of the counter - the functioning of the ignition cut during NLS is less than ideal and is bound to be more staccato than necessary, perhaps lending to the onset of knock.
In any event, there is an important realization here. Normal ignition *is* sporadically being attempted in the midst of everything. Many of you have logged Knock Regulation during NLS and the consensus was that it was the result of false identification because how could Knock occur with no ignition. Ignition is certainly occurring (even when this function is performing as designed) sporadically between exiting and entering NLS (otherwise the motor would stop) and it must be that actual Knock (or the approach of Knock) is being detected and that is where the excessive correction factors are coming from.
As has been said previously - the correct method of limiting engine speed during AL/NLS is with ignition retard, not oscillating between normal ignition and no ignition. Regardless, I must say that examination (and enhancement) of this function by the community has been invaluable! So -- many thanks to all of you crazy, brilliant guys
Please chime in anyone if you can confirm or dispute my findings.
Lastly -
I do not think that it is wise to disable Knock Regulation in conjunction with an Ignition Cut model of AL/NLS and while it is acceptable to disable KR with an Ignition Retard model, I am finding that it is not necessary.
Happy New Year!!!
