[cgrey8]

I have a real world task related to disassembly and the good-ole GUFB/A9L. I want to locate DESMAF so I can add it to the def file.

The intention is not just to add it to the list of available payload items. I also want to add/convert the various idle functions that result in the value of DESMAF to kg/hr so people can choose to view those functions in kg/hr instead of lb/min. This way, people can compare those values with the actual kg/hr MAF values datalogged and have a better idea of what they are setting these values to. I don't need DESMAF to do that. But I just thought having DESMAF would "help" people in understanding idle tuning on the GUFx platforms.

So that being said, the disassembly of A9L that I have doesn't have DESMAF listed. And it doesn't have the functions that set DESMAF declared by name either. So I find myself swimming in the code to find out how to locate DESMAF in the RAM.

So given that, there's a specific end-game. Here are the things required to know to get it added to a def:

• Address of DESMAF
• Length (1 or 2 bytes)
• Sign/unsign
• Conversion to lb/min (the easier conversion)
• Conversion to kg/hr (easier after lb/min is found)

How does a real-world effort like this begin?

[cgrey8]

Staring at the code further just making stabs in the dark, I looked for any other variables that have interaction with DESMAF, as defined in the GUFB doc. I found that PSPPM and ACPPM both are defined and have interaction with DESMAF (around 5ab1 & 5ab9).

The operations on R20 suggest the value in R20 is a word (2-bytes).

So I believe I've narrowed DESMAF to, at least in that area of code, be located in R20. What I'm not seeing, for sure, is if that's where it lives or if R20 is loaded and stored with DESMAF...yet. But doing some searching through the disassmbly for how R20 is used, it doesn't appear other areas of the code are doing things with R20 that are DESMAF related. So I'm convincing myself that R20 is not always the value of DESMAF. So I start searching upwards from 5a1b all interactions with R20 and I find where it is set equal to R38 (5a7a). Reading the comments in the disassembly, R38 is the output of an interpolation done at 5a77. But I'm not seeing anywhere that is storing R20 directly to a RAM address. I do see it being stored into other Registers. I didn't run down each of them to see if they were, then being stored anywhere.

My kneejerk reaction is that DESMAF is a value that gets calculated when needed, used, then discarded. Thus it isn't going to be easy to datalog it. I could always just add it to the payload list and watch it and see if, at runtime, if the datalogged value looks stable and lucid for a value I'd expect for DESMAF or if it's some random value that's either not changing or is non-sensical.

But while looking through the code, I saw something I just completely don't understand.

Code: Select all

5cb5: a0,20,3e        ldw   R3e,R20          FLAGS_3e = R20;
5cb8: d6,02           jge   5cbc             if (FLAGS_3e < R20) {
5cba: 01,3e           clrw  R3e              FLAGS_3e = 0;  }

I searched for any other code jumping directly to 5cb8, but didn't find anything. So I'm failing to understand why the code sets R3e equal to R20, then compares to see if R3e > 0. When would this ever be the case unless 5cb8 was being jumped to without 5cb5 being executed sometimes? My initial arrogant assumption is this is stupid code. But I know that assembly can be tricky and so there's probably some clever trick going on here that makes this a teachable moment. So I'm asking the question even though it is a tangent from the real task of the thread. If the explanation is more than a simple you-dummy-and-here's-why-explanation, I'll break it out into its own thread.

[decipha]

your on the right track r20 does hold DESMAF

5cb8 is a 0 clip on the ISC, it might help to know that 3e is holding the ISC Airmass, 20 is holding DESMAF

btw, thats the tail end of the DESMAF calc, r20 is being saved to ram right there... hint hint

[tvrfan]

<snip>
But while looking through the code, I saw something I just completely don't understand.

Code: Select all

5cb5: a0,20,3e        ldw   R3e,R20          FLAGS_3e = R20;
5cb8: d6,02           jge   5cbc             if (FLAGS_3e < R20) {
5cba: 01,3e           clrw  R3e              FLAGS_3e = 0;  }

<snip>

Cgrey - I can't see how to help here without sounding like an overbearing school teacher.....please forgive me up front, and read the LOGIC of what I'm going to say ! Thanks.
- - - - -
This pseudo source code attached to the code is *WRONG*. Don't just assume it's right. I ask the two questions in order

1. What does LDW actually *DO* ??
2. What do jumps such as JGE actually *DO* ??

As I'm feeling kind, I'll give you the answers.

1. LDW loads the value into the register. NOTHING ELSE.
2. JGE uses the current PSW to see if it needs to jump.

THE PSW WAS SET BY THE PREVIOUS AD2W INSTRUCTION !!
so the jump is actually checking whether the result of THIS previous bit OVERFLOWS as a signed addition.

Code: Select all

5cac: 64,1c,20          ad2w  R20,R1c        R20 += R1c;
5caf: 64,38,20          ad2w  R20,R38        R20 += R38;
5cb2: 64,3c,20          ad2w  R20,R3c        R20 += R3c;

This is a great example of why mpaton and I were trying to get you all to read and understand more .... (yeah, I'm lecturing...... I'll stop now)

[cgrey8]

your on the right track r20 does hold DESMAF

5cb8 is a 0 clip on the ISC, it might help to know that 3e is holding the ISC Airmass, 20 is holding DESMAF

btw, thats the tail end of the DESMAF calc, r20 is being saved to ram right there... hint hint

I'm looking and I'm not seeing an opcode I associate with a store-word...yet. It must be after some jump somewhere and I'm just missing it. I'm not done looking.

...This pseudo source code attached to the code is *WRONG*. Don't just assume it's right...

Knowing that helps. I guess I wrongfully trusted whoever wrote all the pseudo-code in this particular assembly dump to have done it right since they did other things right.

...I ask the two questions in order

1. What does LDW actually *DO* ??
2. What do jumps such as JGE actually *DO* ??

As I'm feeling kind, I'll give you the answers.

1. LDW loads the value into the register. NOTHING ELSE.
2. JGE uses the current PSW to see if it needs to jump.

THE PSW WAS SET BY THE PREVIOUS AD2W INSTRUCTION !!
so the jump is actually checking whether the result of THIS previous bit OVERFLOWS as a signed addition...

That's the missing piece of the puzzle I knew I wasn't getting. I just didn't know what I was missing...but something about what I was seeing had to be amiss. That and being led astray by the wrong pseudo code. It also helped that I finally found where the flags in the PSW were explained. I read before posting this that jge checked if N=0 or 1. But I didn't know what N was. And I never could find in that document (8096 doc) where it was explained. I'm sure it's in there, I just didn't find it. I eventually found it in an 8xC196 Instruction doc (pg A-4 or 443 in the pdf).

But back to my original question. Had I not had an assembly file with "some" of the variables identified with proper PIDs, how would I ever have come across R20? For instance, lets say all I had was the output of SAD to go from?

[cgrey8]

...btw, thats the tail end of the DESMAF calc, r20 is being saved to ram right there... hint hint

In my assembly I see:

Code: Select all

5cbf: c3,72,d8,20     stw   R20,[R72+d8]     ARCHFG = R20;

I'm assuming this is probably it and I, again, was led astray by the pseudo-code in my wrongfully commented disassembly.

Now I just need to find out what's loaded in R72 so I can add d8 to it, and get the address of DESMAF.

At first I did a search of just R72, but it appears R72 is the base-pointer for some structure in memory because there are LOTS of references to offsets of R72. So I decided to search instead for R72, (i.e. include the comma in the search) and I only found 3 places in the code where those existed, and all were loading 0x180 into R72.

So 0x0180 + 0x00d8 = 0x0258

That sound about right for DESMAF?

Also I noticed that before R20 was saved, it was multiplied by 2 (i.e. shifted left one). I don't know how, but somehow that seems like a hint to what the conversion to lb/min should be.

So I take another tactic. I go to the GUFB def file and look for other things that datalog in lb/min units and that are also 2 bytes. And I find ISC stuff along with ACCEL and EFTRFF. The ISC stuff is closely related to DESMAF so I'm going to assume the conversion is closer to ISC calcs. However that shift mentioned above suggests that maybe, just maybe, DESMAF, as stored in RAM, isn't the same conversion. I'm making an assumption that DESMAF is unsigned. But the ISC stuff is signed (as per the def). So that might have something to do with what I'm seeing. And my shoot-from-the-hip guess of what a good conversion for DESMAF is X/8192. BTW, this whole paragraph is a stream-of-consciousness, not to be taken as any kind of fact. I just want the people helping to know what I'm thinking so they can correct me where my thinking is wrong.

[tvrfan]

Following on....

I don't know if that pseudo code came from SAD or not, I discovered this bug in SAD a while ago - what should happen is that the pseudo code generator should look for the last opcode which sets the PSW, and it wasn't, it was just doing last instruction. So be aware !!

R72 - In A9l near the beginning, it sets up its 'base' registers in a subroutine (Rf0 - Rfe) and it also sets some RAM/KAM ptrs too, for every background loop ...

Code: Select all

2162: a1,80,01,72       ldw   R72,180
2166: a1,7e,02,74       ldw   R74,27e
216a: a1,7a,03,76       ldw   R76,37a

so that value you refer to will probably be a stored or 'learned' parameter.

In the description of the PSW in 8096/196 (and in the Ford eec book) there is a description of what those flags are....

this cut and pasted, so layout is all messed up, but here my best edit attempt.....

[and my note - As I remember a 'signed overflow' as with that A9L example above, one can't assume the V flag is set, but the 'N' flag will be set, so you check a greater or equals. Example

0x6000 + 0x6000 = 0xc000 this is a signed overflow as result goes negative. In decimal 24576+24576 = -49151 (I think that's right....) ]


Table A-2. Processor Status Word (PSW) Flags

Mnemonic Description
C The carry flag is set to indicate an arithmetic carry from the MSB of the ALU or the state of
the last bit shifted out of an operand. If a subtraction operation generates a borrow, the
carry flag is cleared.

C , Value of Bits Shifted Off
0 < 1⁄2 LSB
1 ≥ 1⁄2 LSB

Normally, the result is rounded up if the carry flag is set. The sticky bit flag allows a finer
resolution in the rounding decision.

C ST Value of Bits Shifted Off
0 0 = 0
0 1 > 0 and < 1⁄2 LSB
1 0 = 1⁄2 LSB
1 1 > 1⁄2 LSB and < 1 LSB

N The negative flag is set to indicate that an operation generated a negative result. It is
correct even if an overflow occurs. For all shift operations and the NORML instruction, the
flag is set or cleared to equal the most-significant bit of the result, even if the shift count is
zero.

ST The sticky bit flag is set to indicate that, during a right shift, a “1” has been shifted into the
carry flag and then shifted out. This bit is undefined after a multiply operation. The sticky
bit flag can be used with the carry flag to allow finer resolution in rounding decisions. See
the description of the carry (C) flag for details.

V The overflow flag is set to indicate that the result of an operation is too large to be
represented correctly in the available space.

For shift operations, the flag is set if the most-significant bit of the operand changes during
the shift.
For divide operations, the quotient is stored in the low-order half of the destination
operand and the remainder is stored in the high-order half. The overflow flag is set if the
quotient is outside the range for the low-order half of the destination operand. (Chapter 3,
“Programming ConsiderAtions,” defines the operands and possible values for each.)
Instruction Quotient Stored in:

V Flag Set if Quotient is:
DIVB Short-Integer DIV Integer
< –128 (81H) or > +127 (7FH)
< –32768 (8001H) or > +32767 (7FFFH)
DIVUB Byte > 255 (0FFH)
DIVU Word > 65535 (0FFFFH)

VT The overflow-trap flag is set when the overflow flag is set, but it is cleared only by the
CLRVT, JVT, and JNVT instructions. This allows testing for a possible overflow at the end
of a sequence of related arithmetic operations, which is generally more efficient than
testing the overflow flag after each operation.

Z The zero flag is set to indicate that the result of an operation was zero. For add-with-carry
and subtract-with-borrow operations, the flag is never set, but it is cleared if the result is
other than zero. Therefore, the zero flag indicates the correct zero or non-zero result for
multiple-precision calculations.

[cgrey8]

...I don't know if that pseudo code came from SAD or not, I discovered this bug in SAD a while ago - what should happen is that the pseudo code generator should look for the last opcode which sets the PSW, and it wasn't, it was just doing last instruction. So be aware !!...

I don't know where I got this disassembly file. If I had to guess, I'd say I got it from sailorbob, but I don't know that for sure. I've had it for quite a while.

...R72 - In A9l near the beginning, it sets up its 'base' registers in a subroutine (Rf0 - Rfe) and it also sets some RAM/KAM ptrs too, for every background loop ...

Code: Select all

2162: a1,80,01,72       ldw   R72,180
2166: a1,7e,02,74       ldw   R74,27e
216a: a1,7a,03,76       ldw   R76,37a

so that value you refer to will probably be a stored or 'learned' parameter.

That code looks familiar to what I was looking at. However I couldn't tell if that was a confirmation that my math, above, for DESMAF is correct.

I've got it and the other ISC functions that have lb/min values duplicated with a kg/hr version. And I have to say, I wish I'd done this to the def years ago. The values, in kg/hr units, are a LOT more meaningful.


As for the rest of your comments, that's the same info I found in the 8xC196 doc. It's amazing how "complex" each instruction can be. You have to keep up with more than the main players of the opcode, but also on each of these flags too.

Any feedback on conversion?

[tvrfan]

Sorry, did I lose the plot there ? Conversion ?

[cgrey8]

Conversion from raw bits to a lucid value in lb/min or kg/hr so it can be added to the def and displayed in human-meaningful form.

For the past 2 days, I've been running with it at X/8192. And that gives me pseudo-lucid values. However I haven't yet associated value changes in DESMAF with anything the EEC is actually doing yet. I'm assuming it is being calculated then "used" in some way. I just need to spend more time looking at the GUFB doc file to wrap my head around it. But surprisingly, the DESMAF values changes quite frequently. It's not a relatively stable value like DSDRPM. Some of that may be an indication that I still have work to do in my ISC multiplier functions?

BTW, Clint got back to me and said the latest version of BE has the ability to do conversion of common units for me without me having to ADD alternate view PIDs (a lb/min view and kg/hr view). The catch is it requires a change to the def file which will likely break backwards compatibility with older versions of BE. My 5.49.1 version is where he was attempting to add this feature, but it wasn't working. It was tolerant of my def file changes, but was not displaying the alternate views despite my selecting to view kg/hr instead of lb/min in the user settings. I had to update to the latest BE version...which has ALWAYS been a pain for me. But right now, I have the 3 GUFx defs updated so that users can select between:

• DegF or DegC
• PSI or inHg (in WC not supported)
• lb/min or kg/hr

There's a lot of loose ends such as getting some confidence in my DESMAF conversion. And I'd like to update the conversion formula for the MAF curve so it can be viewed in lb/min or kg/hr too.

Unfortunately, Clint doesn't have support for oddball units like lb/minx1000, lb/min/intake, lb/intake, etc.

[tvrfan]

Ahhh. I thought that's what you meant, but wasn't sure.

Personally, I've not been delving much into the 'calibration' or 'conversion' aspects, I've been more trying to get code out correctly.
I can see some values from various functions, but I honestly can't help much, I haven't a clue how something like a hot wire or flap converts into Kg/Hr flow.
So I really can't help there, probably some of the more hands-on tuners can help ??

BUT - I think it is a very good idea to try binary scale dividers as you have - chances are high that it would be done this way.
Why ? it's relatively easy to code, and a coder can get fast divides with shifts, and use those for lookups. I would certainly do that if I was coding that kind of thing.

The only thing I can think of is whether value would be signed or unsigned (effectively max is either 32767 or 65535) and it can be either depending how it's handled in the code.

As far as I know (so far, anyway) only the timing algorithm uses 24 bit time values.

[cgrey8]

Can either of you confirm that the offset I calculated is correct for DESMAF? Looking at the datalogged values I'm getting for the offset I do have, the values just aren't coming out to be values I can explain. I've looked through the GUFB doc and wrapped my head around DESMAF as much as I can. And from what I can tell, DESMAF should be fairly stable given my tune...particularly once the engine is warmed up. But what I'm datalogging is NOT what I would call stable.

The GUFB doc says, DESMAF is passed into FN800 (ISC Xfer function) to calculate the ISC PW. And I am not seeing ISCDTY move in conjunction with what I'm datalogging for DESMAF.

And to add confusion, 0x0258 is already called ARCHFG in the GUFx defs...which ironically is what the comment in the A9L assembly code is calling R20.

So, I'm skeptical that maybe I'm not pointed at what I think I'm pointed at. I'm thinking DESMAF is somewhere else.

That thought sent me looking further at the assembly. What about R16 in this same area of code? It also has ACPPM and PSPPM added to it. And it appears to be located at 0x025E. The comments call this value PEAK_LOAD, but nowhere, according to the GUFB doc, should PEAK_LOAD, in any way, be related to ACPPM or PSPPM. R16 also does not experience any shifting prior to being stored in RAM, so I'm going to guess that if R16 is DESMAF, it gets the same conversion that ACPPM and PSPPM get, which is X/4096.

Thoughts?

[sailorbob]

So 0x0180 + 0x00d8 = 0x0258

That sound about right for DESMAF?

No, you need to consider the addressing mode being used.

The GUFB doc says, DESMAF is passed into FN800 (ISC Xfer function) to calculate the ISC PW.

It does not say this.

[cgrey8]

The GUFB doc says, DESMAF is passed into FN800 (ISC Xfer function) to calculate the ISC PW.

It does not say this.

That was my lame interpretation. Here's what it actually says:

- DESMAF = The desired airflow necessary to operate at a specified idle condition. This register is fed with the base calibrated airflow requirements in the desired RPM calculation routine each pass through the background. It is later modified in the ISC duty cycle output routine to account for the C/L ISC corrections (IPSIBR & ISCKAM) and any dashpot component (DASPOT). DESMAF is then used in calculating the input to the ISC transfer function (FN800).

So it may not be passed in directly.

[cgrey8]

Well I tried DESMAF as 0x025E and that didn't seem to give me lucid values either.

If the values are to be believed, the conversion is off by at least a factor of x10...closer to x13.

In "boiled-down" terms, the DESMAF calculation is as follows:
DESMAF = FN875N/D * FN1861 + ACPPM (if present) + PSPPM (if present) + HWPPM (if present) + DASPOT + IPSIBR + ISCKAM

Under stable warmed-up idle conditions with my tune:
FN875N should output ~22kg/hr
FN1861 should output 1.000
ACPPM = 0 (No AC)
PSPPM = 0 (No PS Pressure sensor present)
HWPPM = 0 (No Defroster)
At idle sitting still, DASPOT should be = 0
IPSIBR ~0.1 (gotten from datalog)
ISCKAM2 ~0.44 (gotten from datalog)

So, I'm expecting to datalog a value very near 22-23kg/hr. However I'm getting a value closer to 290 while sitting still at idle.

BTW, I read deeper into the GUFB doc,
DEBYMA = DESMAF - ITHBMA (Throttlebody Mass Air Flow)

DEBYMA is passed into FN800 to come up with an ISC PW.

What am I missing?

[sailorbob]

Not sure how you came up with 0x025E. As said before, you need to consider the addressing mode being used to determine the address.

[cgrey8]

Code: Select all

5aea: 30,3e,05        jnb   B0,R3e,5af2      if (ISF_ACON) {
5aed: 67,f5,86,00,16  ad2w  R16,[Rf4+86]     R16 += ACPPM;  }
5af2: 30,3f,15        jnb   B0,R3f,5b0a      if (!ISF_PSON) goto 5b0a;
5af5: 3a,ec,15        jb    B2,Rec,5b0d      if (PSFLAG) goto 5b0d;
5af8: 67,f5,8a,00,16  ad2w  R16,[Rf4+8a]     R16 += PSPPM;
5afd: 91,04,ec        orb   Rec,4            PSFLAG = 1; 
5b00: c3,72,e0,00     stw   0,[R72+e0]       PERLOAD = 0;
5b04: c7,72,ea,00     stb   0,[R72+ea]       INJ_PIP_CNT1 = 0;
5b08: 20,03           sjmp  5b0d             goto 5b0d;

5b0a: 71,fb,ec        an2b  Rec,fb           PSFLAG = 0; 
5b0d: 31,e6,0a        jnb   B1,Re6,5b1a      if (HWFLAG) {
5b10: 30,e6,07        jnb   B0,Re6,5b1a      if (HWFLGL) {
5b13: 3e,26,04        jb    B6,R26,5b1a      if (!DNDSUP) {
5b16: 67,f6,0c,20     ad2w  R20,[Rf6+c]      R20 += [93b4];  }  }  }
5b1a: c7,72,eb,3e     stb   R3e,[R72+eb]     INJ_PIP_CNT2 = FLAGS_3e;
5b1e: c3,72,de,16     stw   R16,[R72+de]     PEAK_LOAD = R16;

This is the area of code that hinted that maybe R16 contained DESMAF since the values I was getting for R20 didn't give me what I was expecting to see. R72+de appears in multiple places loading and storing but that didn't seem unusual given even the GUFB doc describes DESMAF being builtup in "phases"...not all at once. R72 contains 0x0180. So I added 0xde to 0x0180 to come up with the 0x025E.

At what point did I go wrong?

[sailorbob]

You weren't getting the values you were expecting because you were looking at the wrong address. Look at the code, not the comments. I'll say it one more time - you need to consider the addressing mode being used to determine the address.

0x5B1E isn't saving PEAK_LOAD either.

[cgrey8]

Am I on the right track with R16? If so, this is what I'm focused on.

Code: Select all

5b1e: c3,72,de,16     stw   R16,[R72+de]

And yes, I learned earlier on in this thread that the comments in this assembly are not to be trusted.

But given this line, my interpretation of this line is it takes the value in R16 and stores it in the memory location pointed to by R72 plus 0xde. What addressing mode am I missing? Being 0xde is above 0x7F, should I be subtracting or something? When you say I need to look at the addressing mode, I hear that, but I'm just not getting what I'm supposed to from that comment. So I'm trying to explain what it is I think it is doing in hopes someone can point to where my logic went off the rails.

[decipha]

you went completely off the rails

see post 17 up ^^ and theres your answer

[cgrey8]

I'm reading the section of the instructions that talks about Short indexed addressing. And what I'm doing with the values seems consistent with the directions I'm reading. So I'm going to need someone to break it down as to what exactly I'm doing wrong, because I'm just not getting it. And reading through the tech docs isn't producing the "Ah-Ha! moment" that I think people are expecting it should.

[sailorbob]

http://eectuning.org/forums/viewtopic.php?f=8&t=21748

[cgrey8]

That example was one where there were 4 operands because it was long indexed. My example only has 3 operands and the register R16 and R72 are both even. So that tells me it is short indexed. The only other thing I can think I was doing wrong is adding 0x0180 to 0xd8 since 0xd8 is above 0x7f (i.e. it can be negative). However even as I've mentioned this as a possibility, nobody has suggested that I might be on the right track with that way of thinking. So I abandoned it. That's the only thing I can figure I've been doing wrong.

So should it be:
0x0180 - 0x28 = 0x0158
???

[decipha]

correct! You got it!

but guesstimating isnt good you got the right address but you might want to dig deeper to see how its correct

[cgrey8]

That wasn't way off the rails. A reminder that the index is signed would've put me on the right track again.

R20 math is 0x0180+0xd8 or 0x0180-0x28 = 0x0158
R16 math is 0x0180+0xde or 0x0180-0x2e = 0x015e

I'm still not sure which of these two is DESMAF but I'm still leaning more towards DESMAF being R16.

Looking through the GUFB doc at other things that interact with ACPPM and PSPPM in similar ways to DESMAF, I found FAM. But I haven't found a differential between them that I can look at the code and determine the difference between them.

[sailorbob]

Indexed addressing is not always signed and I pointed you to the other thread because it discusses addressing modes. Also, the addressing mode of opcode 0xC3 is not dependant on whether the first operand is an odd or even value.

You didn't mention the constant being signed until after I mentioned the addressing mode three times and referred you the the other thread so no one had chance to comment on whether you were "on the right track" before you "abandoned it".

[cgrey8]

Last night I started on a simple C# calculator to add unsigned words in hex to a signed byte. With it, I can literally put in 180 and de and it will calculate the answer, taking into account that the de is signed...and both in hex terms.

I'll add another tab to it to add an unsigned word to a signed word in the case of long addressing.

And I'm assuming Zero-Addressing is where the index offset is unsigned? Or is it still signed, it just rolls over to get to the other 32768 values?

Even if nobody but me uses it, it'll be a good teaching tool for myself.

[sailorbob]

See the other thread about indexed addressing, or the Intel docs referred to in various threads in this forum.

[cgrey8]

This APPEARS to work right. Can others confirm? If it does work, I'll break this out into its own thread. Otherwise, I'll let it languish into this thread.

setup.zip

It requires .NET v4.5.2.
.NET 4.5.2 installer download site


If you don't have this version of .NET or you don't want it installed on your machine, then don't bother downloading the installer.

Since I'm the developer, I couldn't really "install" it and see how it works. I tried to install it in my WinXP Virtual Machine, but .NET 4.5.2 doesn't support WinXP. So I couldn't get a good "user experience" of installing this. So it may not work.

Anyway, back to the thread topic, I never got any feedback as to whether DESMAF is in R20 or R16.

BTW, thanks for the responses I have gotten. This stuff is frustrating and maddening to me so I get rather irate when I can't figure it out...particularly when there's some aspect I know I don't know/remember, but should and I just can't figure it out. I can RTFM, but if I don't know what I'm looking for, it makes it difficult to answer many of these questions for myself. Highest respects to those that did have the patience to figure this stuff out.

[decipha]

see 10 or/and 27 post above ^^