quick question about indexed ops

This is where the BIN Hackers and definition junkies discuss the inner workings of the EEC code and hardware. General tuning questions do not go here. Only technical/hardware-specific/code questions and discussions belong here.

Moderators: cgrey8, EDS50, 2Shaker, Jon 94GT

Post Reply
User avatar
tvrfan
Tuning Addict
Posts: 490
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

quick question about indexed ops

Post by tvrfan » Mon Feb 10, 2020 9:02 pm

Experts help please !

This is from BWAK3N2 - (8065 multibank with 4 banks) I found these when looking for a different bug.

Code: Select all

8ce34: c3,01,98,f2,44     stw   R44,[R0+f298]  
..also...
8cdd8: a3,01,98,f2,34     ldw   R34,[R0+f298]
8cddd: b3,01,a3,f2,46     ldb   R46,[R0+f2a3] 
8cd86: b3,01,96,f2,46     ldb   R46,[R0+f296] 
8cd8b: 9b,01,d6,f0,46     cmpb  R46,[R0+f0d6]  
Question is, what address does this actually resolve to ?
using 8ce34 - if it's a signed offset, which the 80c196 handbook implies it is, does this then negate and overflow to become address [d68] ?

It can't be address [1f298] (i.e. with data bank) as that's ROM, unless it's a specialist chip ??
But addresses don't seem to match anything in the handbook

If it's 0xd68 why the hell isn't the instruction STW R44, [R0+d68] ???
This seems a truly WEIRD way to do it.... or does the overflow trigger something ??

It doesn't look like this is incorrect disassembly (or bank order) as there are no invalid opcodes anywhere in any bank.

(NB. for disassembly I've assumed RAM/KAM exists in a virtual bank 0 - 0x1fff, with the CPU registers, and not therefore in bank 1.
This is so addresses below 0x2000 don't ever appear with any bank prefix number.
It's not really clear to me if addresses below 0x2000 get mapped to a bank at all )

But then just to mess up that logic, there is this opcode within A9L, which implies the long offset is NOT signed

Code: Select all

84b2: a3,01,00,0d,14      ldw   R14,[R0+d00]     R14 = [d00];                      # Console status
84b7: 99,2a,15            cmpb  R15,2a           
84ba: d7,2c               jne   84e8             if (R15 != 2a) goto 84e8;         # console present?
84bc: 3c,24,1b            jb    B4,R24,84da      if (Console_flag = 0)  {
84bf: 38,0a,18            jb    B0,Ra,84da       if (HSO_OVF = 0)  {
84c2: 47,01,0e,20,06,80   ad3w  R80,R6,[R0+200e] HSO_time = IO_Timer + [200e];     # add 5D to current IOTime
84c8: d7,02               jne   84cc             if (HSO_time = 0)  {
84ca: 07,80               incw  R80              HSO_time++; }                     # increment past zero
84cc: c3,01,1a,c1,80      stw   R80,[R0+c11a]    [c11a] = HSO_time;                # to console location ?   <<<<<<<<<<<<<<
84d1: a0,80,0e            ldw   Re,R80           HSI_Time = HSO_time;
84d4: b1,0f,0d            ldb   Rd,f             HSO_Cmd = f;                      # request interrupt (in 5D IOtimes)
84d7: ef,2c,4b            call  d006             d006(); } }                       # Console call
84da: a3,01,80,0c,14      ldw   R14,[R0+c80]     R14 = [c80];                      # flags for data pointers
is that stw at 84cc storing a time to 0x3ee6 or c11a ??
the Ford handbook specifically mentions c11a as a time field for cal console................which implies that a long index is UNSIGNED


Any suggestions ??

Thanks,
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 705
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: quick question about indexed ops

Post by jsa » Mon Feb 10, 2020 11:00 pm

IIRC, 01 is odd so long indexed.
8F298 is my guess without looking up the handbook.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 490
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: quick question about indexed ops

Post by tvrfan » Mon Feb 10, 2020 11:53 pm

Having dug around for info and thought about it...

It looks like it may be that -

Short index is SIGNED (A9L for proof)
Long index is SIGNED ?? (Guess)

Zero index (short and long) is UNSIGNED.
This would explain why it has a separate section in the 8096 manual, when it's really just using R0. And it makes sense to me.

Any comments on that idea ??
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

sailorbob
BIN Hacker
Posts: 1682
Joined: Tue Jul 12, 2005 6:10 am

Re: quick question about indexed ops

Post by sailorbob » Tue Feb 11, 2020 3:40 am

If the 2nd byte of the instruction is even then it is short indexed, if the 2nd byte is odd then it is long indexed. I can only recall seeing the zero register being used with long indexing and it's an unsigned index.

User avatar
tvrfan
Tuning Addict
Posts: 490
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: quick question about indexed ops

Post by tvrfan » Tue Feb 11, 2020 4:39 am

sailorbob wrote:
Tue Feb 11, 2020 3:40 am
If the 2nd byte of the instruction is even then it is short indexed, if the 2nd byte is odd then it is long indexed. I can only recall seeing the zero register being used with long indexing and it's an unsigned index.
Thanks Bob. But you do see long indexes with non-zero register here and there as well. Here's a snip from xdt2 bin

Code: Select all

166fe: 38,4a,61           jb    B0,R4a,16762
16701: ac,66,52           ldzbw R52,R66
16704: b3,53,28,5d,4c     ldb   R4c,[R52+5d28]
16709: c7,49,8b,00,4c     stb   R4c,[R48+8b]
1670e: af,52,6a,4e        ldzbw R4e,[R52+6a]
16712: 73,53,22,5d,4e     an2b  R4e,[R52+5d22] 
16717: c3,49,82,00,4e     stw   R4e,[R48+82]
1671c: b3,49,8a,00,4a     ldb   R4a,[R48+8a]
16721: 3b,4a,f8           jb    B3,R4a,1671c
16724: b3,49,8b,00,4c     ldb   R4c,[R48+8b]
16729: 93,53,2e,5d,4c     orb   R4c,[R52+5d2e]
1672e: c7,49,8b,00,4c     stb   R4c,[R48+8b]
16733: 3b,c2,1a           jb    B3,Rc2,16750
16736: a3,49,82,00,50     ldw   R50,[R48+82]
1673b: 3a,4a,05           jb    B2,R4a,16743
1673e: 88,4e,50           cmpw  R50,R4e          
16741: df,06              je    16749
16743: 95,04,c2           xorb  Rc2,4 
16746: 3a,c2,bb           jb    B2,Rc2,16704
16749: c7,52,70,51        stb   R51,[R52+70]
1674d: 71,fb,c2           an2b  Rc2,fb
16750: 17,52              incb  R52 
And I agree that from what I've seen the evidence is very strong that non-zero short indexes are signed (A9L in several places) , and that zero long indexes are unsigned.

Currently I have short indexed ops as signed offset, long ops as unsigned offset in disassembler.
and I found this in xdt2 as a confirm.

Code: Select all

8fb75: 10,08              bank  8
8fb77: 6f,37,fe,fa,38     ml2w  R38,[R36+fafe] 
8fb7c: 0d,01,38           shldw R38,1
8fb7f: d3,03              jnc   8fb84 

8fafe: 82,06              word    682

8fb00: d9,0a,04,0d,46,10,00,00,d9,0a,d9,0a,d9,0a ??? 
   
    Sub_8fb0e:
8fb0e: a1,40,0f,36        ldw   R36,f40  
so I guess that's the confirm. Long indexes are UNSIGNED.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

sailorbob
BIN Hacker
Posts: 1682
Joined: Tue Jul 12, 2005 6:10 am

Re: quick question about indexed ops

Post by sailorbob » Tue Feb 11, 2020 6:14 am

Yes, I am aware that long indexing is used for other registers as well as the zero register. As your initial post was about the addresses when using the zero register I was responding to that specific issue.

tvrfan wrote:
Mon Feb 10, 2020 9:02 pm
It can't be address [1f298] (i.e. with data bank) as that's ROM, unless it's a specialist chip ??
The upper 8k in bank 1 of 4 bank eec-v's is usually RAM resulting in the ROM being 48k (0xC000) in size in this bank. 4 bank binaries are typically only 216k in length because of this.

User avatar
tvrfan
Tuning Addict
Posts: 490
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: quick question about indexed ops

Post by tvrfan » Tue Feb 11, 2020 1:43 pm

Bob,

Yep, No worries. I was checking that perhaps a non-zero register with long index might possibly be signed, but that xdt2 example shows it's not.
All good.

Thanks for that piece of info about the RAM, it explains what's going on in the code, I thought RAM/KAM was always below 0x2000.

I now see that the Ford handbook map on page H3 shows that only addresses 0-0x3ff (i.e. internal registers) are without a (data/code) bank, which means that the 'standard' RAM/chip areas below 0x2000 have a bank number as well. Didn't spot that before. So typical RAM and special chips are actually in bank 1 from looking at the code in most multibank bins.

So that means my current SAD coding is technically wrong and needs to show a bank number for all addresses above 0x3ff and not > 0x1fff.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

sailorbob
BIN Hacker
Posts: 1682
Joined: Tue Jul 12, 2005 6:10 am

Re: quick question about indexed ops

Post by sailorbob » Wed Feb 12, 2020 3:24 am

Short indexed offsets are signed. Long indexed offsets are unsigned.

The final paragraph in section 2.2.1 of the Intel 'Using the 8096' document is wrong when it says long indexed offsets are added as a 2's complement value to the register value to form the address. This is confirmed by section 3.2.6 of the 1985 Intel 'Microcontroller Handbook' which states 'no sign extension is necessary for' long indexed offsets.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest