[tvrfan]

How many times a simple typo buggers everything up !!! been there too many times.

jsa - Good suggestion about the single 0xf0 - should have thought of that.....even simpler than my idea. Neat.

[jsa]

The ROM_TO value is at 0x12004.

0x2004 is described as FIXSUM is various Ford Strategy documents.

[jamie from oz]

BE probably is not calculating the checksum because you have 'ChecksumEdn' instead of 'ChecksumEnd' in your definition.

The ROM_TO value is at 0x12004.

You also need to have the 'EEC' parameter in the 'Confg' worksheet set to 'True'.

ohhh i definitely missed that .....
I was using a .xls from the BE database for a template that had the checksum as CHKSUM and thought that may have been the problem and changed it to ROM_TO like others i have looked at.

Code: Select all

Parameter	Value
ChecksumStart0	2000
ChecksumEnd0	FFFF
ChecksumStart1	2000
ChecksumEnd1	DFFF
ChecksumStart8	2000
ChecksumEnd8	FFFF
ChecksumStart9	2000
ChecksumEnd9	FEFF
ChecksumStore	ROM_TO
Target_AFR	14.64
BankCount	4
PCMType	EEC_216K
LTMTB1	0704
LTMTB2	075A

with my typo fixed it calculates 0x12004 (0xE004 in my xls) from 8E 42 to 8F 42 .

Thank you all for your help.

[sailorbob]

0x2004 is described as FIXSUM is various Ford Strategy documents.

Probably because they did not bother updating this in the eec-v documents.

[jamie from oz]

I have a question regarding table function scales.

If for example Rpm payload is at 0x0610 and scaled at x/4 when it goes into the function table scaler 1000 rpm (4000/4=1000) and is row 2 (512/256=2) on the scaler the output from the function should be 2.00 for that column ?

Or is it 512 then scaled to be 2.00?

Jamie.

[jsa]

0x2004 is described as FIXSUM is various Ford Strategy documents.

Probably because they did not bother updating this in the eec-v documents.

What information do you have to indicate it is different to the information in the Ford strategies?

[jsa]

I have a question regarding table function scales.

If for example Rpm payload is at 0x0610 and scaled at x/4 when it goes into the function table scaler 1000 rpm (4000/4=1000) and is row 2 (512/256=2) on the scaler the output from the function should be 2.00 for that column ?

Or is it 512 then scaled to be 2.00?

Jamie.

It's not clear whether you are trying to achieve some objective mathematically or misunderstand how the the table lookup works.

Lets use these inputs from WANA

Code: Select all

857e3: a3,66,4c,3a        ldw   R3a,[R66+4c]     R3a = [108cc];                   # Process Value Row
857e7: a3,66,4e,38        ldw   R38,[R66+4e]     R38 = RPM_Clm;                   # Process Value Column
857eb: ad,0c,3c           ldzbw R3c,c            wR3c = c;                        # Column Quantity
857ee: 45,cc,00,f0,40     ad3w  R40,Rf0,cc       R40 = T.FN1320_VolmtrcEffcyTbl;  # Table Address
857f3: ef,d5,f0           call  848cb            UYTabLU_848cb ();                # Lookup Sub

125da: 20,4e,00,0b        func  20000,  2816                         # Column Scaler R38,R39 = 00,0b

125aa: 7a,00,00,08        func    122,  2048                         # Row Scaler    R3A,R3B = 00,08

Lets step through part of the table lookup sub

Code: Select all

848cc: 5c,3b,3c,3e        ml3b  R3e,R3c,R3b      wR3e = yR3c * R3b;  # wR3E = 0xC * 0x08 
848d0: 74,39,3e           ad2b  R3e,R39          R3e += R39;         # yR3E = 0x60 + 0x0B
848d3: b4,00,3f           adcb  R3f,R0           R3f += CY;          # Add Lo Byte Carry to Hi Byte
848d6: 64,3e,40           ad2w  R40,R3e          R40 += R3e;         # R40 = 0x125D6 + 0x6B
848d9: b2,41,39           ldb   R39,[R40++]      R39 = [R40++];      # R39 = Value @ 0x12641++
848dc: b2,40,3b           ldb   R3b,[R40]        R3b = [R40];        # R3B = Value @ 0x12642
848df: 64,3c,40           ad2w  R40,R3c          R40 += R3c;         # R40 = 0x12654
848e2: b0,38,3d           ldb   R3d,R38          R3d = R38;          # R3D = 0x00
848e5: b0,3a,3f           ldb   R3f,R3a          R3f = R3a;          # R3F = 0x00
848e8: 28,2f              scall 84919            Sub_84919 ();       # Interpolate Pass 1
848ea: b2,40,3b           ldb   R3b,[R40]        R3b = [R40];        # R3B = Value @ 0x12654
848ed: b3,40,ff,39        ldb   R39,[R40+ff]     R39 = [R40-1];      # R39 = Value @ 0x12653
848f1: a0,42,40           ldw   R40,R42          R40 = R42;
848f4: 28,23              scall 84919            Sub_84919 ();       # Interpolate Pass 2
848f6: a0,42,3a           ldw   R3a,R42          R3a = R42;
848f9: a0,40,38           ldw   R38,R40          R38 = R40;
848fc: b0,3f,3d           ldb   R3d,R3f          R3d = R3f;          # R3D = R3F = 0x00
848ff: 28,1c              scall 8491d            Sub_8491d ();       # Interpolate Pass 3

Looking for R3D in the Interpolate sub, R3C high byte used throughout.

Code: Select all

   Sub_84919:
84919: 11,38              clrb  R38              R38 = 0;
8491b: 11,3a              clrb  R3a              R3a = 0;
   Sub_8491d:
8491d: 11,3c              clrb  R3c              R3c = 0;
8491f: 33,de,23           jnb   B3,Rde,84945     if (B3_Rde = 1)  {
84922: 08,01,3c           shrw  R3c,1            R3c >>= 1;            # R3C,R3D 0x00>>1
84925: a0,38,42           ldw   R42,R38          R42 = R38;
84928: fe,4c,3a,3c,38     sml3w R38,R3c,R3a      slR38 = swR3c * R3a;
8492d: a0,42,38           ldw   R38,R42          R38 = R42;
84930: 0a,01,42           asrw  R42,1            swR42 >>= 1;
84933: 64,3a,42           ad2w  R42,R3a          R42 += R3a;
84936: fe,6c,3c,38        sml2w R38,R3c          slR38 *= R3c;
8493a: 68,3a,42           sb2w  R42,R3a          R42 -= R3a;
8493d: 09,01,42           shlw  R42,1            R42 <<= 1;
84940: 09,01,3c           shlw  R3c,1            R3c <<= 1;
84943: 20,13              sjmp  84958            return; }

84945: a0,38,42           ldw   R42,R38          R42 = R38;
84948: 4c,3a,3c,38        ml3w  R38,R3c,R3a      lR38 = wR3c * R3a;
8494c: a0,42,38           ldw   R38,R42          R38 = R42;
8494f: 64,3a,42           ad2w  R42,R3a          R42 += R3a;
84952: 6c,3c,38           ml2w  R38,R3c          lR38 *= R3c;
84955: 68,3a,42           sb2w  R42,R3a          R42 -= R3a;
84958: f0                 ret                    return;

Note how the lookup function has a word input, but the output lo byte, hi byte are used for different purposes.
The high byte is used as the row and column numbers to lookup.
Column 11 of columns 0 to 11 in a 12 column table.
Row 8 of rows 0 to 8 in a 9 row table.

The low byte is passed through to the interpolate sub.

The default decimal value outputs of 2816 and 2048 don't look anything like column or rows numbers.
So how to make it more reasonable looking ...
One could divide the word by 256 using the option diVide in DIR

Code: Select all

fun 125d6 125f1 "Table_Scaler_for_RPM"           :UW :UW V 256

Column numbers now make sense...fine and dandy until some bin comes along with something other than 0x00 for the low byte...

Code: Select all

   Table_Scaler_for_RPM:
125d6: ff,ff,00,0b        func  65535,        11    
125da: 20,4e,00,0b        func  20000,        11    
125de: b0,36,00,08        func  14000,         8    
125e2: 70,17,00,03        func   6000,         3    
125e6: 60,09,00,00        func   2400,         0    
125ea: 00,00,00,00        func      0,         0    
125ee: 00,00,00,00        func      0,         0    

...so lets try and break SAD and share another can o' worms with TVRfan...
Change DIR to this

Code: Select all

fun 125d6 125f1 "Table_Scaler_for_RPM"           :UW :UY :UY

MSG indicates that TVRfan has been tucking into the worms without us...

Code: Select all

## fun 125d6 125f1 "Table_Scaler_for_RPM"           :UW :UY :UY
 Warning - ExtraData Item(s) Ignored

...SAD didn't break.

Code: Select all

   Table_Scaler_for_RPM:
125d6: ff,ff,00,0b        func  65535,   0,  11
125da: 20,4e,00,0b        func  20000,   0,  11
125de: b0,36,00,08        func  14000,   0,   8
125e2: 70,17,00,03        func   6000,   0,   3
125e6: 60,09,00,00        func   2400,   0,   0
125ea: 00,00,00,00        func      0,   0,   0
125ee: 00,00,00,00        func      0,   0,   0

I've not seen a bin with anything other than the low byte as 0x00, but SAD needs to support the possibility.
Thank you for the question Jamie, ask further if I've not answered yours.

[sailorbob]

What information do you have to indicate it is different to the information in the Ford strategies?

Have a look at a few eec-v calibrations and you'll see that 0x8200A is identical in quite a few whereas 0x12004 is not. For example:

Code: Select all

N9XL1   WANA   0x8200A = 0xC0DE   0x12004 = 0x228E
CMBA0   BTC0   0x8200A = 0xC0DE   0x12004 = 0xCE2D
NVXF3   X2CD   0x8200A = 0xC0DE   0x12004 = 0xD432
CVAF1   EPM2   0x8200A = 0xC0DE   0x12004 = 0x3CA1
OMAE2   EKO2   0x8200A = 0xC0DE   0x12004 = 0x1A9A
PAADA   ETT2   0x8200A = 0xC0DE   0x12004 = 0x8767
KQTH7   6MYE   0x8200A = 0xC0DE   0x12004 = 0x985B

I am not saying ROM_TO is at 0x12004 for all eec-v calibrations but for WANA it looks like it is.

EDIT: corrected PAAD4 to PAADA.

[tvrfan]

To answer the func question in a different way....using rpm table from AA bin. My comments have the output column numbers against rpm calculated. My numbers in decimal, Hex preceded by '0x'.

Code: Select all

   Func_2858:
2858: ff,ff,00,0a         func  65535,  2560
285c: c0,5d,00,0a         func  24000,  2560                                       # 8=4000, 9=5000, 10=6000 & up
2860: 80,3e,00,08         func  16000,  2048                                       # 5=2500, 6=3000, 7=3500
2864: 40,1f,00,04         func   8000,  1024                                       # 2=1300, 3=1600, 4=2000
2868: 00,19,00,03         func   6400,   768                                       # 0=0-700, 1=1000,
286c: f0,0a,00,00         func   2800,     0
2870: 00,00,00,00         func      0,     0

It's standard in all bins for the scaler lookup functions to have the row number in the top byte of their words. If you look at the func and table lookup code subroutines, they both use 'linear interpolate' for the answer. ('interpolate' in a nutshell means that if you put In a value half way between two input values, you will get an answer which is halfway between two output values). So this method is a 'fixed point' calculation.

At 1800 rpm (x4 = 7200 or 0x1c20) =in you will get an answer of 896 (0x380), which is half way between 768 and 1024. So the TABLE lookup gets data from row 3 (and row 4) from its RPM column and knows that the '0x80' is the fractional component (=128, i.e. half of 256). The table interpolate then uses this value to divide the difference between answers in the table cells, to interpolate that part. This method is very efficient (and clever) compared with all that tedious messing about with floating point with lots of s-l-o-w dividing and multiplying.

So think of '1024' above as '4+0' (top byte, bottom byte) to become '4.0' as a fixed point value. Although this is all binary, it's exactly the same maths as we got taught in school, and the 'linear interpolate' is a fast method to get within a few percent of the right answer. In effect the func lookup here returns the equivalent of "3.5" as 3 (top byte) + 128/256 (bottom byte).

I hope that all makes sense...

Who ever designed the lookup code really did "know their arse from their elbow" as we used to say in UK.

Oh yeah, from above a FUNC in SAD has two and only ever two additional items, one for each column....
('linear interpolate' is defined in Wikipedia if you want to learn more)

[tvrfan]

Later addendum to above - not all the funcs have zero lower bytes, typically only scalers (i.e. for tables) have this. For example the AA's ISC (idle speed control) lookup, which is rpm ->ISC valve pulsewidth. This one has different fixed point arithmetic, as per comment.

Code: Select all

#####################################################
### Pulsewidth adjustment for ISC Valve - used as multiplier in code
# appears to be +/- 25rpm resolution , 50 rpm deadband
# Scaled /65536 (2621 = 0.04, 1835 = 0.028, 52 = 0.008 )
##########################################################
   Func_29fc:
29fc: ff,7f,c3,f5         func   32767,  -2621
2a00: f0,0a,c3,f5         func    2800,  -2621
2a04: d0,07,d5,f8         func    2000,  -1835
2a08: c8,00,cc,ff         func     200,    -52
2a0c: 64,00,00,00         func     100,      0
2a10: 9c,ff,00,00         func    -100,      0
2a14: 38,ff,34,00         func    -200,     52
2a18: 30,f8,3d,0a         func   -2000,   2621
2a1c: 00,80,3d,0a         func  -32768,   2621
2a20: 00,80,3d,0a         func  -32768,   2621

[jamie from oz]

That all makes sense but takes me a couple reads to make sense in my mind .

Yes i get the interpopulation calcs .

My other question is the output from the function when i put it into BE as Payload do you need to put a equation in or just X as its been scaled through the function?

example (1800rpm in and 896 for Rpm_out ) so no scaling required for table payload input for BE.

Code: Select all

84fe3: db,03              jc    84fe8            if (R3c < RPM)  {
84fe5: 91,02,7b           orb   R7b,2            B1_R7b = 1; } }
84fe8: ef,51,f5           call  8453c            UUWFuncLU_8453c (
84feb: 76,05                    #arg 1              Table_Scaler_for_RPM,
84fed: 10,06                    #arg 2              RPM );
84fef: c3,66,4e,40        stw   R40,[R66+4e]     RPM_out = R40;
84ff3: f0                 ret                    return;

84ff4: 90,01              ???   

Code: Select all

   Sub_86ee2:
86ee2: 36,ed,01           jnb   B6,Red,86ee6     if (B6_Red = 1)  {
86ee5: f0                 ret                    return; }

86ee6: a3,66,4e,38        ldw   R38,[R66+4e]     R38 = RPM_out;
86eea: 08,01,38           shrw  R38,1            R38 >>= 1;
86eed: 89,00,03,38        cmpw  R38,300          
86ef1: d1,04              jleu  86ef7            if (R38 > 300)  {
86ef3: a1,00,03,38        ldw   R38,300          R38 = 300; }
86ef7: a3,66,50,3a        ldw   R3a,[R66+50]     R3a = [108d0];
86efb: 89,00,04,3a        cmpw  R3a,400          
86eff: d1,04              jleu  86f05            if (R3a > 400)  {
86f01: a1,00,04,3a        ldw   R3a,400          R3a = 400; }
86f05: a3,66,4e,38        ldw   R38,[R66+4e]     R38 = RPM_out;
86f09: a3,66,50,3a        ldw   R3a,[R66+50]     R3a = [108d0];
86f0d: ad,0a,3c           ldzbw R3c,a            wR3c = a;
86f10: 45,de,12,f4,40     ad3w  R40,Rf4,12de     R40 = Table_147d8;
86f15: ef,b3,d9           call  848cb            UYTabLU_848cb ();
86f18: c7,72,de,43        stb   R43,[R72+de]     [1115e] = R43;

[jsa]

Have a look at a few eec-v calibrations and you'll see that 0x8200A is identical in quite a few whereas 0x12004 is not. For example:

Code: Select all

N9XL1   WANA   0x8200A = 0xC0DE   0x12004 = 0x228E
CMBA0   BTC0   0x8200A = 0xC0DE   0x12004 = 0xCE2D
NVXF3   X2CD   0x8200A = 0xC0DE   0x12004 = 0xD432
CVAF1   EPM2   0x8200A = 0xC0DE   0x12004 = 0x3CA1
OMAE2   EKO2   0x8200A = 0xC0DE   0x12004 = 0x1A9A
PAAD4   ETT2   0x8200A = 0xC0DE   0x12004 = 0x8767
KQTH7   6MYE   0x8200A = 0xC0DE   0x12004 = 0x985B

I am not saying ROM_TO is at 0x12004 for all eec-v calibrations but for WANA it looks like it is.

Thanks.
Another interpretation is 0x8200A is ROM_TO and 0x12004 is FIXSUM?

[jsa]

My other question is the output from the function when i put it into BE as Payload do you need to put a equation in or just X as its been scaled through the function?

example (1800rpm in and 896 for Rpm_out ) so no scaling required for table payload input for BE.

Code: Select all

84fe3: db,03              jc    84fe8            if (R3c < RPM)  {
84fe5: 91,02,7b           orb   R7b,2            B1_R7b = 1; } }
84fe8: ef,51,f5           call  8453c            UUWFuncLU_8453c (
84feb: 76,05                    #arg 1              Table_Scaler_for_RPM,
84fed: 10,06                    #arg 2              RPM );
84fef: c3,66,4e,40        stw   R40,[R66+4e]     RPM_out = R40;
84ff3: f0                 ret                    return;

84ff4: 90,01              ???   

I've added the column breaks to the function.
I've used x/4 for RPM and x/256 for column.

Code: Select all

   Table_Scaler_for_RPM:
125d6: ff,ff,00,0b        func      16383.75 ,        11    
125da: 20,4e,00,0b        func       5000    ,        11    
                                     4500    ,        10
                                     4000    ,         9
125de: b0,36,00,08        func       3500    ,         8
                                     3100    ,         7
                                     2700    ,         6
                                     2300    ,         5    
                                     1900    ,         4
125e2: 70,17,00,03        func       1500    ,         3    
                                     1200    ,         2
                                      900    ,         1
125e6: 60,09,00,00        func        600    ,         0    
125ea: 00,00,00,00        func          0    ,         0    
125ee: 00,00,00,00        func          0    ,         0    

Splitting the gaps, you can see for 600-1500 a column is 300rpm steps, 1500-3500 is 400rpm steps and 3500 to 5000 is 500rpm steps.

I don't know that BE will accept nested IF logic as part of a 3 step equation to give some sort loose RPM value.

Your SYM, RPM_out, is really RPM~Column. Use x/256 for the column number relevant to the Table.

Using TVRfan's AA example on the WANA function as you have requested...
896/256 = 3.5
Column 3 is 1500
Step is 400
1500+400*0.5 = 1700

1800-1500 = 300
300/400 = 0.75
3+0.75 = 3.75
3.75*256 = 960 = 0x3C0

It does not work in WANA because AA is 1600+400/2 = 1800.

[sailorbob]

Another interpretation is 0x8200A is ROM_TO and 0x12004 is FIXSUM?

I would disagree with that. What are the chances of dozens of calibrations having that same ROM_TO value? Also, I think 0xC0DE is a little bit of humour from the software engineers in using the word 'code' in that memory location

[jsa]

I would disagree with that. What are the chances of dozens of calibrations having that same ROM_TO value? Also, I think 0xC0DE is a little bit of humour from the software engineers in using the word 'code' in that memory location

Well it complies with the strategy document address statements as far as 2004 and 200A goes, but then those documents are silent on which bank, so why not both in bank 1?

Yeah, it is amusing that they stuck that in a pile of different strategies.

Mays as well have a Scalar and Checksum store called Phil

[tvrfan]

I've never used BE or similar, as it turned out. I do keep up with the disassembly part as it's interesting to me.
I can say that scalers and scaled values are used all over the place in all the bins, and most are fixed point values.
This is all to minimise the calcs and make them faster. It's a common technique in low level programming.

I don't know anything about BE (jsa can help you here).

If BE supports "X *<value>" or "X / <value>" that should work for a lot of stuff, as <value> will be a power of 2. (e.g. 2,4,8,16,32,64 -> 65536). There are some that appear to be " <fixed> / X " and similar, where 65536 represents something real (like for example "65536 = 1 atmosphere"). There are signed calcs too (i.e. +32768 to -32768).

If you are not an IT geek, I get that this all takes some getting your head around and understanding the 'tricks' used, especially if maths isn't one of your best subjects. (I don't mean that in any nasty way at all, just being realistic)

The other issue to note I spotted is that Euro and Aussie bins seem to be calibrated as metric values (e.g. degree C) but US are imperial (A9L is in degrees F). Not sure if this changed in multibanks.

From jsa's example above, and my AA example, you can see that those scaler funcs actually represent a curve on a graph (just like the pictures of ignition advance in the days of dizzy springs). So the distance between the points/rows can change a lot.

[jsa]

I've never used BE or similar, as it turned out.

Were you just hex editing your AA tunes?

If BE supports "X *<value>" or "X / <value>" signed calcs too (i.e. +32768 to -32768).
.
.
The other issue to note I spotted is that Euro and Aussie bins seem to be calibrated as metric values (e.g. degree C) but US are imperial (A9L is in degrees F).

Most simple equations

Make of that what you will, but it does support /x, x/, x*, *x, brackets, add and subtract. So (X*2-32)/1.8 will do temperature conversion from F° to C°. Of course the C° to F° can be done with a revised equation.

[jamie from oz]

Thanks this info is great to help me and probably others out.

Yes I get the X/4 and X/256 for scaling so it makes BE legible to the tuner.

[Your SYM, RPM_out, is really RPM~Column. Use x/256 for the column number relevant to the Table.]

Thanks I was only using RPM_out as it's shorter than RPM_column.
(RPM_col) might save my finger haha.

[tvrfan]

Shortened story of AA bin.... I never did actually tune it. That was my plan, but it didn't happen. Originally my idea was to buy a Cologne engine (2.8L V6) with Bosch 'K' injection for a swap into a kit car. (In UK at the time. There were carb, Bosch 'K', and EEC-IV versions around.) I went to see one advertised and it turned out to be an EEC-IV one, so I bought it anyway. I got interested in how the system software worked, and at the time there was the EECSUCKA. I built one and got a dump of the AA box. I started writing a disassembler. After that, life happened. Company went bust. Job changes, several house moves, emigrate to New Zealand, etc. etc. and I sold the kit with the engine in it. But I kept up with SAD as it became, as an interesting personal IT project.

[jsa]

Thanks for the background TVRfan. To think that random series of events brings us SAD, thank you for your continued efforts.

Jamie, yeah typing, typing and more typing, it the worst part of disassembly.
I use Clm and Row and the - to mean scaler and a hint to the value having some introduced error.
My function and table names get quite long.
Something like;
T.Fn1234_RPM/Ld>°Adv
Get too carried away and then the comments column gets pushed sideways.

Say that table is at address 6789
Once named is DIR, SAD will use the name in place of the address in the code columns. \s6789 can be used in CMT to save typing the long name in comments.

Unfortunately the \s16789 is not working for multibanks due to some issue. I think TVRfan has a fix in the next SAD release, so no harm in using \s in CMT as they will appear in LST once fixed.

[tvrfan]

Oh, yes I forgot, in later bins there are also TABLES which are scalers for further table lookups. This makes last table lookup a result of FOUR inputs (or a 4D table in other words). I'm not entirely sure, but I think all the scaler values are x*256 to give whole number in top byte and fraction part in lower byte. I haven't seen an 8D calc yet... (maybe? ....)

e.g.
part 1 Param1 - function lookup (scaler) + Param2 - function lookup(scaler) -> 2D table A lookup (i.e. row + column).
part 2 Param3 - function lookup (scaler) + Param4 - function lookup(scaler) -> 2D table B lookup.
part 3 Table A result (scaler) + Table B result (scaler) -> Table C, final table lookup.

This made me go "huh?" too the first time I saw it, but it's perfectly valid, and neat too.

[ismailkho]

I used your bin with SAD 4.0.6, the latest stable version available on the SAD GIT website. It appears to have captured a substantial amount of data, all located in bank 1. The bank directives have the first two values as file offsets, allowing users to specify the desired order if SAD gets the bank number wrong. Typically, these values are left as comments.

Upon initial inspection, the listing seems to be in good shape. Bank 9 is empty, code is stored in banks 0 and 8, and data is in bank 1. This layout is common, and the interrupt handlers are aligned, indicating that the order is likely correct. The value 8200a is a checksum "correction" value, which causes the checksum subroutine to return zero. I believe the checksum subroutine is located at 04511. It appears that there is only one grand checksum value, as the banks are added together.

The value 8200c probably represents the end of the ROM. It is used by the cal console (or other Ford plugin tools) to determine where it can map a virtual memory block. The value 8200e is usually 5d and is related to these tools as well, although I cannot recall the exact details. It is likely related to the I/O timer.

I hope this information is helpful!

[tvrfan]

I assume the last post by ismailkho is an error somewhere, as it's a copy of my previous post further up...

[jsa]

Yep, bait for the link in the signature.
A number of similar copy posts have been made.

Hit the exclamation icon to report it for removal.

[tvrfan]

Duh !! I was being dumb, I didn't even check the html link....
Thanks

[jamie from oz]

Thought it was unusual posting and ignored it.

[jsa]

I'm smart enough not to click on scammer links.

3 copy cat posts at about the same time, flagged them all for deletion.