EFIDynoTuning Forum

jsa

If you disagree the tests show R102 as being correct, how are you going to prove what is correct??

jsa

wwhite wrote: ↑2021 Apr 09, 13:02
This is also pseudo code from my head, you get the idea.
Code: Select all
a0, 56, 58    ldw R56, R58    R58 = R56   // EVEN addressing = Bank0, A0=0
Code: Select all
a0, 57, 58    ldw R156, R58    R58 = R156 // ODD addressing = Bank1, A0=1

It is bit position 0 of operand 1 that determines address mode.
The opcode A0 does not equal a different value.

wwhite wrote: ↑2021 Apr 09, 13:02 I am 100% positive SAD is not taking account for ^A0 being odd or even to select the correct bank pair for word direct addressing.
.....

I am 100% certain you did not read the first post.
viewtopic.php?p=936#p936

jsa wrote: ↑2021 Apr 05, 06:53 PYM, TVRFan and I aware that the disassemblers are not handling SFR+100 and R+100 memory offsets in all cases.

wwhite wrote: ↑2021 Apr 09, 13:02
A lot of SAD is cryptic to me, and I have not been able to get the debugger working.
...
Not sure if the above is a ternary operator, or if the programmer is questioning what is going on. There is no code below this comment.
....
What does PSTPD stand for?

All questions for TVRfan in another thread.
You are welcome to start your own thread for any SAD bugs.

wwhite wrote: ↑2021 Apr 09, 16:46
Code: Select all
2344: c7,01,3a,01,3c      stb   R3c,[R0+13a]     Odd_Md_Rg = Odd_Md_Val;
Destination Register R3c in Bank0 will contain the value from Register R3a in Bank1.

No.
This is Store bYte, the opposite order to Load bYte.
Destination Register R13a will contain the value from source register R3c

wwhite wrote: ↑2021 Apr 09, 16:46 So, as you can see, the only Data Banks being used are 0 and 2, with the original 3b3a and 64 word values.

Reg R30, with ODD addressing loads values from Bank1 and Bank3, which have not been initialized.

I really do not see, or understand how your test cases are valid.

No, it is not data banks 0 and 2.
No, R30 does not load values from Bank3.

You have contradicted yourself a few times and have STW back to front.

The test code matches code in OEM bins.
The purpose of the test is to see which versions of 8065 support the memory addressing mode added to 8065 at some point.
The test is valid.

wwhite wrote: ↑2021 Apr 09, 17:16 I think you should initialize all variables in all banks, and log PSW as well, then look at the results.

Please post your test bin and support files, doing as you believe it should work.

wwhite wrote: ↑2021 Apr 13, 13:01
jsa wrote: ↑2021 Apr 09, 03:27 The log files in the linked zip show that VILE supports +100 but P3M does not. Both are 8065's but different steppings. It is not random.
Maybe one uP has memory expansion enabled, and the other does not?

Neither VILE or P3M have memory expansion enabled for the test.

wwhite wrote: ↑2021 Apr 13, 17:08 I notice you are logging the PSW, but only bits 0-7, the logical flag bits.

You should also log the following of PSW:
bits 8,9 = RAM bank select bits (RB0, RB1)
bits 10,11,12,13 = ROM bank select bits (MB0, MB1, MB2, MB3)

Log bit 4 of SFR 'a', that is the memory expansion enable.
Read bit 4 of Ra on each uP.
My guess is that Ra bit 4 will be enabled(1) in VILE, and Ra bit 4 will be disabled(0) in P3M.

Neither VILE or P3M are in memory expansion mode for the test.

wwhite wrote: ↑2021 Apr 09, 11:59
jsa wrote: ↑2021 Apr 09, 07:17 JFA7 / KMAK6 has none of what?
My disassembly of stock JFA7.bin has no references for ^A0 ldw direct address mode with a SF/R+100.

I think you'll find it has hundreds of SF/R+100
Exhibit A;

Code: Select all

0229d: a0,03,4c           ldw   R4c,R102         R4c = R102;

wwhite wrote: ↑2021 Apr 09, 11:59
jsa wrote: ↑2021 Apr 09, 07:17 KRAF5 has hundreds of what?
Hundreds of ^A0 ldw direct address mode with hundreds of SF/R+100 & SF/R+200.

No, not +200.

jsa

wwhite wrote: ↑2021 Apr 09, 03:44 Back to R13a, R3a+100, should be R3a^100 meaning "^13a denotes register address location '^3a in RAM bank #1'

Ford are quite happy to refer to the registers as 0020 to 03ff.
R13A is a valid description, I'll continue to describe it in that manner.
Feel free to call them whatever you like.

wwhite wrote: ↑2021 Apr 09, 03:55 Catch code JFA7 has none, this is my bench EEC
KRAF5_LFQ1 has hundreds.

Have a couple of SD48, and one SD47

JFA7 / KMAK6 has none of what?
Can you run both test bins on it and post the logs?

KRAF5 has hundreds of what?
Can you run both test bins on it and post the logs?

SD47 and SD48, assuming they are 8061's, are not expected to support SF/R+100.

jsa

Agreed arguing theoretical semantics is fruitless.

A lot 8065 decompiled OEM binaries have multiple instances of sf/rxx+100 and R2xx+100.

The log files in the linked zip show that VILE supports +100 but P3M does not. Both are 8065's but different steppings. It is not random.

8061's are not expected to support +100.

I'm running this on 8061.

Which catchcode did you run it on?
Have you got an 8065 to try it on?

jsa

0x3a+0x100=0x13a

It's an address inside the uP. It's a register. R13A.

A bank prefix operation is not used to access it.

If you use other address modes to access it, it will be coded 3a,01 in the binary, no bank prefix operation.

Look in the test bins for examples where a different address mode accesses the address R13a without a bank prefix opcode.

jsa

A supporting uP decodes a double/word op odd address 3b as 3a+100.

jsa

Now you are on too it.

Does not matter what the Ford and other literature says, emulators do or disassemblers find. It only matters what the silicon does.

On some 8065 stepping processors, your concern from above, 3b is actually word 13a.

The whole point of the test is to discover what certain hardware versions do.

jsa

Set the Scalar STACK_SFR to 8061 and write the update to the QH.
That will change the Stack SFR from 0x20 to 0x10.
Reboot the EEC, the stack address will be loaded to 0x10.

The OEM stack address does not have to be followed. The stack can be put elsewhere.

Look at the definition spreadsheet. It tells you what is written where for the 8061 and 8065 options.
Look at that address in the LST.
R20 becomes R10 when when STACK_SFR is changed to 8061 then written.
Reboot to take effect.
Both have the stack below 0x200.

Code: Select all

2201: a1,00,02,20         ldw   R20,200          STACK_8065 = 200;

What catchcode is your BIN?

jsa

Both disassemblers will need updates as a result of some test bin results.

viewtopic.php?f=40&t=132

jsa

PYM, TVRFan and I aware that the disassemblers are not handling SFR+100 and R+100 memory offsets in all cases.

I have written test bins to dis/prove conjecture around the SF/R+100 memory offset.
The files can be found at;
https://github.com/OpenEEC-Project/EEC- ... -Test-Bins

They are well worth a look.

We'd be interested in your results if you decide to run them on your own hardware.

Edit: Fix link

EFIDynoTuning Forum

Search found 274 matches

Re: SFR+100 and R+100 8065 memory access

Re: SFR+100 and R+100 8065 memory access

Re: SFR+100 and R+100 8065 memory access

Re: SFR+100 and R+100 8065 memory access

Re: SFR+100 and R+100 8065 memory access

Re: SFR+100 and R+100 8065 memory access

Re: SFR+100 and R+100 8065 memory access

Re: SFR+100 and R+100 8065 memory access

...is under construction

SFR+100 and R+100 8065 memory access