32016: Possible issue with EaPlusRn scaled indexed addressing

[hoglet67]

In Panos 1.4 when running cCheck I noticed an out of range write:

 WARN: [pc=31C6B] Writing outside of RAM @ 10DE97 = 00

Seperately I fixed a disassembly bug that prevented EaPlusRn scaled index addressing instructions being correctly decoded: 4a52f8ac (also caused the disassembler to loose sync) and later found b55c39bb

>> c
Running
Exec breakpoint hit at 31c60
&031C60 [1f00            ] F2 CMPQD   0,R0
>> d 31c60
&031C60 [1f00            ] F2 CMPQD   0,R0
&031C62 [7a06            ] F0 BLE     &031C68 
&031C64 [d705            ] F4 MOVD    R0,TOS
&031C66 [2203            ] F1 CXP      x'3
&031C68 [d7c16c          ] F4 MOVD    -20(FP),R7
&031C6B [5ce0c7bedc      ] F2 MOVQB   0,-292(FP)[R7:B]
&031C70 [e7c5bedc        ] F4 ADDRD   -292(FP),TOS
&031C74 [2204            ] F1 CXP      x'4
&031C76 [c705            ] F4 CMPD    R0,TOS
&031C78 [970604          ] F4 MOVD    R0,4(SB)
&031C7B [dfd000          ] F2 MOVQD   1,0(SB)
&031C7E [e7b50500        ] F4 ADDRD   EXT(x'5)+x'0,TOS
&031C82 [5fb8            ] F2 MOVQD   0,TOS
&031C84 [e7dd8153        ] F4 ADDRD   * + 339,TOS
&031C88 [dfbf            ] F2 MOVQD   -1,TOS
&031C8A [dfbf            ] F2 MOVQD   -1,TOS
>> s
Stepping 1 instructions
Exec breakpoint hit at 31c62
&031C62 [7a06            ] F0 BLE     &031C68 
>> s
Stepping 1 instructions
Exec breakpoint hit at 31c68
&031C68 [d7c16c          ] F4 MOVD    -20(FP),R7
>> s
Stepping 1 instructions
Exec breakpoint hit at 31c6b
&031C6B [5ce0c7bedc      ] F2 MOVQB   0,-292(FP)[R7:B]
>> r
      PC = 00031c6b
      R0 = 00000006
      R1 = 00000006
      R2 = 004003b0
      R3 = 000fde78
      R4 = 000fdfec
      R5 = 000fe002
      R6 = 00000000
      R7 = 00010003
      SB = 00037c08
     SP0 = 000ffdbc
     SP1 = 000fde90
      FP = 000fdfb8
 INTBASE = 000ffe64
     MOD = 03b0
     PSR = *0 *0 *0 *0 I1 P0 S1 U1 N0 Z0 F0 V0 *0 L0 T0 C0 
     CFG = 00000002
>> s
Stepping 1 instructions
>> WARN: [pc=31C6B] Writing outside of RAM @ 10DE97 = 00
&031C70 [e7c5bedc        ] F4 ADDRD   -292(FP),TOS
>> r
      PC = 00031c70
      R0 = 00000006
      R1 = 00000006
      R2 = 004003b0
      R3 = 000fde78
      R4 = 000fdfec
      R5 = 000fe002
      R6 = 00000000
      R7 = 00010003
      SB = 00037c08
     SP0 = 000ffdbc
     SP1 = 000fde90
      FP = 000fdfb8
 INTBASE = 000ffe64
     MOD = 03b0
     PSR = *0 *0 *0 *0 I1 P0 S1 U1 N0 Z0 F0 V0 *0 L0 T0 C0 
     CFG = 00000002
>> s
Stepping 1 instructions
&031C74 [2204            ] F1 CXP      x'4
>> r
      PC = 00031c74
      R0 = 00000006
      R1 = 00000006
      R2 = 004003b0
      R3 = 000fde78
      R4 = 000fdfec
      R5 = 000fe002
      R6 = 00000000
      R7 = 00010003
      SB = 00037c08
     SP0 = 000ffdbc
     SP1 = 000fde8c
      FP = 000fdfb8
 INTBASE = 000ffe64
     MOD = 03b0
     PSR = *0 *0 *0 *0 I1 P0 S1 U1 N0 Z0 F0 V0 *0 L0 T0 C0 
     CFG = 00000002
>> c
Running

The write is to: 10DE97

The 1024KB of RAM ends at 0FFFFF

After fixing the disassembly issues (not present in the above debug session log), the write address seems correct:

FP - 292 + R7

= 0xFDFB8 - 292 + 0x10003

= 0x10DE97

But why is R7 so large ???

Is there an earlier bug, or does this happen on real hardware as well?

[hoglet67]

It seems the stray write happens to RAM TOP + &DE97, and the position changes with memory size.

I've hacked a version of the Matchbox 32016 Co Pro that has 2MB of memory, with an alias at 2MB-4MB.

If the stray write happens, I would expect it to go to &20DE97, which should alias to &DE97.

Booting Pandora to BAS32 does not disturb the value, but allows it to be read

1. Break, BAS32, !&DE97=&AAAAAAAA,

2. Break, BAS32, PRINT ~!&DE97 returns AAAAAAAA

3. Break, Boot Panos, Break, BAS32, PRINT ~!&DE97 returns F8A0974E

4. Break, Boot Panos, run cworld, Break, BAS32, PRINT ~!&DE97 returns F8A0974E

5. Break, Boot Panos, run script containing cworld twice, Break, BAS32, PRINT ~!&DE97 returns F8A09700

In PiTubeDirect, the stray write only happens in case (5).

This appears to be the same on the Matchbox.

This suggests a bug in Panos (or more probably the compiled cworld program) rather than a 32016 emulation bug.

Dave

[hoglet67]

I would like to run this on a real 32K Co Processor, but the memory doesn't alias in the same way, so the stray write is harmless (and leaves no trace)

[ Which, apart from the warning in PiTubeDirect, it's also harmless ]

My 32K Co Pro has 512KB + 128KB = 640KB.

[hoglet67]

I can reproduce this with my original 32016 Co Processor...

By removing one of the RAM 64K Ram chips (the bottom right one), Panos detects just 512KB, but memory location 8DE97 still works.

You can see the bit affected by this memory chip here:

!&8DE97 = &00000000: PRINT !&8DE97: returns 80008000
!&8DE97 = &AAAAAAAA: PRINT !&8DE97: returns AAAAAAAA

Anyway, to reproduce the "bug", do the following

1. Break, BAS32, !&8DE97=&AAAAAAAA,

2. Break, BAS32, PRINT ~!&8DE97 returns AAAAAAAA

3. Break, Boot Panos, Break, BAS32, PRINT ~!&ADE97 returns AAAAAAAA

4. Break, Boot Panos, run cworld, Break, BAS32, PRINT ~!&8DE97 returns AAAAAAAA

5. Break, Boot Panos, run script containing cworld twice, Break, BAS32, PRINT ~!&8DE97 returns AAAAAA00

In case (5) a stray write has occurred, setting &8DE97 to &00.

Closing, as this is not an emulation bug.

Dave