[tvrfan]

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,

[jsa]

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

[tvrfan]

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 ??

[sailorbob]

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.

[tvrfan]

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.

[sailorbob]

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.

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.

[tvrfan]

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.

[sailorbob]

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.

[ollopa]

According to the EEC-IV software manual both are signed:

3-2.3.7 SHORT INDEXED ADDRESS MODE

The short indexed address mode enables an instruction to access any "A" operand byte or word loca
tion within -128 to +127 bytes of a 16-bit base address. The base address is specified by software
and is stored as a word variable on-board the microprocessor IC chip. The word variable must be
address-aligned at its iocation.

Software specifies the location of the word variable as an 8-bit address in the 1st byte (the R^
component) of the address mode two-byte format (see Figure 3-3). The 2nd byte contains the
software specified offset value within the numerical range of -128 to +127. This offset value is
sign-extended before being added with the word variable to produce the effective address of the "A"
operand memory location.
The offset value is positive when its binary MSB is "0", and negative when it is "1". Since this
value is a signed number, it enables addressing on either side of the base address. Short indexed
addressing is specified at the assembly source level by any operand base address or base-address
label enclosed by parenthesis and prefixed with the offset value, e.g., ADCB COOL(TEMP),SCALE or
ADCB '^64('^2A),'^B6 where COOL(TEMP) and '^64('^2A) are "A" operand designators.

3-2.3.8 LONG INDEXED ADDRESS MODE

The long indexed and short indexed address modes are basically the same except the long indexed
address mode enables software to access any "A" operand location within -32,768 to +32,767
bytes (offset value) of the base address. The long indexed address mode format (see Figure 3-3)
is three bytes long where the 1 st byte is R^ (an 8-bit address specifying the storage iocation of the
base address), the 2nd byte contains the high byte of the offset value, and the 3rd byte contains the
low byte of the offset value. The MSB of the offset value high byte contains the sign of the index value
(positive index vaiue, MSB == 0; negative index value, MSB = 1). Long indexed addressing is
specified at the assembly source level in the same manner as the short indexed address mode, e.g.,
ADCB HOT(TEMP),SCALEor ADCB '^2710('^2A),'^B6 where HOT(TEMP) and '^2710('^2A) are "A"
operand designators.

stw.jpg

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.

I interpret this differently. Sign extension is only necessary when expanding the width of a negative number and since in both cases the width of the addition is 16 bits, it makes perfect sense that no sign extension is necessary for the long index calculation (and perfect sense that it is required for short index calculation). I don't see this as evidence one way or the other for the format of the long index operand (2's complement vs signed magnitude).

My personal bias here is that if the engineers used 2's complement for the short indexing then they're likely to have used it again for the long indexing.

[sailorbob]

Numerous disassemblies prove that long indexed offsets are unsigned. The code simply wouldn't work otherwise.

This extract also has the low byte and the high byte order the wrong way around

3-2.3.8 LONG INDEXED ADDRESS MODE

...... The long indexed address mode format (see Figure 3-3) is three bytes long where the 1 st byte is R^ (an 8-bit address specifying the storage location of the base address), the 2nd byte contains the high byte of the offset value, and the 3rd byte contains the low byte of the offset value.

[tvrfan]

I can only say that disassembly works perfectly (as far as I can tell) with byte = signed, long = unsigned. So I agree with Bob.

However, I think it's true that nearly all of the long indexes you see are based on R0, so in a 16 bit field, it would actually make no difference.
If you feed a signed negative 16 bit value to a memory controller which sees a 16 bit address, it sees it as an unsigned. That makes sense to me.

But if the contents of the register are negative already, the manual does imply a 'wrap around' result = ie. for [R34 + 0xffff] where R34 = 0xf0 the result would be address 0xEF, or Register Ref. Whether this is true I have no idea, and I don't think I've ever seen a 'wrapped' long index (Yet...).
Most of them are [R0+x] to get absolute address [x].

So practically speaking the above rule *works* . Even if it may not technically be true.... a bit like advanced science (Quantum Mechanics anyone?)

When I originally asked this question, I did not realise that some 8065 bins had RAM high up in bank 1, and I wondered if there was a quirk with R0 or something. After all there *is* an extra mode for late 8065, i.e. those odd word addresses, so it was possible.

Yeah that description IS wrong , but the diagram is right ...

<added a little later > Actually of course any 16 bit calculation can wrap either way, for a plus or a subtract (i.e. through 0xffff or through 0x0) - so if the memory controller then sees a simple 16 bit address, then it doesn't matter if it's signed or unsigned, it makes no difference ?? I reckon.

[tvrfan]

and there is this gem in A9L, which shows a word wraparound.......... but again signed/unsigned makes no difference, I reckon.
it is really weird to do it this way though - I still wonder if it's correct..............why not stb, R42, [R0+9b] or a straight stb R42, R9B ???

Code: Select all

# Diagnostic Proc Table D
   Sub_7319:
7319: 71,df,d9            an2b  Rd9,df           Vvsfl1 = 0;                       # clr RD9 bit 5 VVS flag1?
731c: 28,07               scall 7325             Sub_7325 ();
731e: 71,ef,46            an2b  R46,ef           Scvnt = 0;                        # LSO output line 4 OFF (Speed Control Vent)
7321: 71,fe,46            an2b  R46,fe           Scvac = 0;                        # LSO output line 0 OFF (Speed Control Vacuum)
7324: f0                  ret                    return;

   Sub_7325:
7325: b1,ff,42            ldb   R42,ff           R42 = ff;
7328: c7,73,1b,ff,42      stb   R42,[R72+ff1b]   Vsc_count = R42;                  # Vsc Count? R9B = R42 why such a strange instruction?
732d: f0                  ret                    return;