High Density by Darkness crashes

[emoon]

This intro https://files.scene.org/get/parties/1994/saturne94/amiga/in64/darkness-high_density.zip will crash after the "Fractal Roots" part. From what I understand the intro uses some heavy self-modifying code and I think UAE can't run it either (at least as of Aug 2020)

[dirkwhoffmann]

So sad 😞. It was a cool demo (until the Guru came up).

[emoon]

it may generates some "invalid" instructions that may still be run-able on original CPU.

[dirkwhoffmann]

In vAmiga, the crash is caused by an address error exception 🙈:

[2928] (297,217) FC081A  3 BCB--A 6040 07E4 CPU:123 XFILES: Address error exception

[emoon]

I see.

[DannyCork]

so can be closed ?

[dirkwhoffmann]

so can be closed ?

No, the bug is still there. The demo runs just fine on my original A500.

[mras0]

Hi,

Despite not having a Mac to run vAmiga, I've been following your project with interest since I'm making my own emulator (just or fun) and your test suite has been extremely helpful. Thank you for making it available!

I've encountered the same bug, and I think it is very likely caused by incorrect blitter/interrupt timing. Just before switching to the next part, this happens (exact locations depend on configuration, try KS1.3+1MB chip only+2 drives):

Level3 interrupt points to vblank handler:

00069618  48e7 fffe                 MOVEM.L     D0-A6, -(A7)
0006961c  2078 0080                 MOVEA.L     $0080.W, A0
00069620  4e90                      JSR         (A0)
00069622  4df9 00df f000            LEA.L       $00dff000.L, A6
00069628  3d7c 0020 009a            MOVE.W      #$0020, $009a(A6)
0006962e  46fc 2000                 MOVE.W      #$2000, SR
00069632  6100 f080                 BSR.W       $000686b4
; ...

And the following code is executed to start a blitter queue:

0006a64c  2d7c 0000 00c0 0054       MOVE.L      #$000000c0, $0054(A6)    ; A6=$dff000
0006a654  3d7c 002a 0066            MOVE.W      #$002a, $0066(A6)
0006a65a  2d7c 0100 0000 0040       MOVE.L      #$010d00000, $0040(A6)
0006a662  3d7c 0041 0058            MOVE.W      #$0041, $0058(A6)        ; (a) Start blit (1x1 D=0)
0006a668  4239 0006 b22a            CLR.B       $0006b22a.L
0006a66e  21fc 0006 a678 006c       MOVE.L      #$0006a678, $006c.W      ; (b) Set new level 3 interrupt routine
0006a676  4e75                      RTS

0006a678  3d7c 0040 009c            MOVE.W      #$0040, $009c(A6)        ; Acknowledge blitter interrupt
0006a67e  2d7c 0000 4210 0054       MOVE.L      #$00004210, $0054(A6)
0006a686  3d7c 002a 0066            MOVE.W      #$002a, $0066(A6)
0006a68c  2d7c 0100 0000 0040       MOVE.L      #$01000000, $0040(A6)
0006a694  3d7c 0041 0058            MOVE.W      #$0041, $0058(A6)
0006a69a  21fc 0006 a6a4 006c       MOVE.L      #$0006a6a4, $006c.W      ; Next blit
0006a6a2  4e73                      RTE

If the blit started at (a) ends up triggering a level 3 interrupt before the instruction at (b) has begun executing the stack will blow up and D5 (=$00011111) ends up overwriting the value at $0007ac88, which is later added with 6 to form the odd address used in the loop in your screenshot:

0007a0f0  41fa 0b36                 LEA.L       $0b36(PC), A0    ; A0 <- $0007ac28
0007a0f4  2070 1000                 MOVEA.L     $00(A0,D1.W), A0 ; Read from $0007ac28+$60=$0007ac88. A0 <- $00011111 (!!)
0007a0f8  322c 0002                 MOVE.W      $0002(A4), D1
0007a0fc  43fa 05f2                 LEA.L       $05f2(PC), A1    ; A1 <- $0007a6f0
0007a100  7400                      MOVEQ.L     #$00, D2
0007a102  1431 1000                 MOVE.B      $00(A1,D1.W), D2 ; This reads as 3
0007a106  d402                      ADD.B       D2, D2           ; *2=6
0007a108  d1c2                      ADDA.L      D2, A0           ; A0 <- $00011117 (!!)
0007a10a  7e24                      MOVEQ.L     #$24, D7
0007a10c  b258                      CMP.W       (A0)+, D1        ; Boom!
0007a10e  6406                      BCC.B       $0007a116
0007a110  51cf fffa                 DBF.W       D7, $0007a10c

In my emulator adding 4 extra idle cycles to the blitter "fixes" the issue and allows proceeding to the next part. This is obviously not correct, but there is some start delay (http://eab.abime.net/showpost.php?p=579567&postcount=30). (I've already added some delay to interrupts triggering due to #274).

Note the intro works in latest WinUAE beta (4.9.0b34).

[dirkwhoffmann]

Wow, very cool. This bug is around for some time now. I always wanted to start working on it, but I didn’t really know where to begin. I think overall Blitter timing (the number of cycles the Blitter executes) is fine in vAmiga, but there might well be a bug, e.g., in blocking the bus at the right cycles (some cycles during the Blitter ramp up phase might block the bus on a real Amiga, but not in vAmiga. This is just a guess at the moment, but it could well be something like that).

But let’s ask Toni first. Since the bug has been fixed recently in UAE, maybe @tonioni can give us a hint where to look at. His helpful hints saved me tons of time in the past.

[DannyCork]

beautiful teamwork ! 🏩

[mithrendal]

@mras0 do you have the source code of your emulator somewhere online?

[mras0]

@dirkwhoffmann: Yeah, obviously the issue could be caused by many things, but it happens (both in Winuae and my emulator) very early in the frame, so bus contention should be low.

@mithrendal: It is now: https://github.com/mras0/AmiEmu (again, it wasn't/isn't intended for anyone else, so it's not pretty/usable. Also win32 only for now). The hack I mentioned isn't included.

BTW the intro seems to work in WinUAE 4.9.0b1 as well, but not 4.4.0, so it was fixed some time ago.

Trace from 4.9.0b34:

>f 0006a662
Breakpoint added.
>g
Breakpoint 0 triggered.
Cycles: 3032363 Chip, 6064726 CPU. (V=105 H=3 -> V=4 H=100)
  D0 00000006   D1 00000003   D2 00000033   D3 00010DDD
  D4 D32A000F   D5 00011111   D6 0000FFFF   D7 00000008
  A0 0006A64C   A1 00000000   A2 0007A3D8   A3 00DFF0D0
  A4 0007A6B0   A5 00DFF000   A6 00DFF000   A7 0007FFBA
USP  0002BC8C ISP  0007FFBA
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch 3d7c (MOVE) 0041 (OR) Chip latch 00000041
0006a662 3d7c 0041 0058           move.w #$0041,(a6,$0058) == $00dff058
Next PC: 0006a668
>t
Cycles: 8 Chip, 16 CPU. (V=4 H=100 -> V=4 H=108)
  D0 00000006   D1 00000003   D2 00000033   D3 00010DDD
  D4 D32A000F   D5 00011111   D6 0000FFFF   D7 00000008
  A0 0006A64C   A1 00000000   A2 0007A3D8   A3 00DFF0D0
  A4 0007A6B0   A5 00DFF000   A6 00DFF000   A7 0007FFBA
USP  0002BC8C ISP  0007FFBA
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch 4239 (CLR) 0006 (OR) Chip latch 00000006
0006a668 4239 0006 b22a           clr.b $0006b22a [01]
Next PC: 0006a66e
>t
Cycles: 10 Chip, 20 CPU. (V=4 H=108 -> V=4 H=118)
  D0 00000006   D1 00000003   D2 00000033   D3 00010DDD
  D4 D32A000F   D5 00011111   D6 0000FFFF   D7 00000008
  A0 0006A64C   A1 00000000   A2 0007A3D8   A3 00DFF0D0
  A4 0007A6B0   A5 00DFF000   A6 00DFF000   A7 0007FFBA
USP  0002BC8C ISP  0007FFBA
T=00 S=1 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=0 STP=0
Prefetch 21fc (MOVE) 0006 (OR) Chip latch 00000000
0006a66e 21fc 0006 a678 006c      move.l #$0006a678,$006c [00069618]
Next PC: 0006a676
>t
Exception 27, PC=0006A676
Cycles: 34 Chip, 68 CPU. (V=4 H=118 -> V=4 H=152)
  D0 00000006   D1 00000003   D2 00000033   D3 00010DDD
  D4 D32A000F   D5 00011111   D6 0000FFFF   D7 00000008
  A0 0006A64C   A1 00000000   A2 0007A3D8   A3 00DFF0D0
  A4 0007A6B0   A5 00DFF000   A6 00DFF000   A7 0007FFB4
USP  0002BC8C ISP  0007FFB4
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=3 STP=0
Prefetch 3d7c (MOVE) 0040 (OR) Chip latch 00000040
0006a678 3d7c 0040 009c           move.w #$0040,(a6,$009c) == $00dff09c

4.4.0 (where it fails):

Breakpoint 0 triggered.
  D0 00000006   D1 00000003   D2 00000033   D3 00010DDD
  D4 D32A000F   D5 00011111   D6 0000FFFF   D7 00000008
  A0 0006A64C   A1 00000000   A2 0007A3D8   A3 00DFF0D0
  A4 0007A6B0   A5 00DFF000   A6 00DFF000   A7 0007FFBA
USP  0002BC8C ISP  0007FFBA
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch 0041 (OR) 3d7c (MOVE) Chip latch 00000041
0006A662 3d7c 0041 0058           MOVE.W #$0041,(A6,$0058) == $00dff058
Next PC: 0006a668
>t
Cycles: 8 Chip, 16 CPU. (V=4 H=98 -> V=4 H=106)
  D0 00000006   D1 00000003   D2 00000033   D3 00010DDD
  D4 D32A000F   D5 00011111   D6 0000FFFF   D7 00000008
  A0 0006A64C   A1 00000000   A2 0007A3D8   A3 00DFF0D0
  A4 0007A6B0   A5 00DFF000   A6 00DFF000   A7 0007FFBA
USP  0002BC8C ISP  0007FFBA
T=00 S=1 M=0 X=0 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
Prefetch 0006 (OR) 4239 (CLR) Chip latch 00000006
0006A668 4239 0006 b22a           CLR.B $0006b22a [01]
Next PC: 0006a66e
>t
Exception 27, PC=0006A66E
Cycles: 32 Chip, 64 CPU. (V=4 H=106 -> V=4 H=138)
  D0 00000006   D1 00000003   D2 00000033   D3 00010DDD
  D4 D32A000F   D5 00011111   D6 0000FFFF   D7 00000008
  A0 0006A64C   A1 00000000   A2 0007A3D8   A3 00DFF0D0
  A4 0007A6B0   A5 00DFF000   A6 00DFF000   A7 0007FFB4
USP  0002BC8C ISP  0007FFB4
T=00 S=1 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=3 STP=0
Prefetch fffe (ILLEGAL) 48e7 (MVMLE) Chip latch 0000FFFE
00069618 48e7 fffe                MOVEM.L D0-D7/A0-A6,-(A7)
Next PC: 0006961c

Winuae state file just before the relevant part: highdensity2.zip

[tonioni]

Lots of moving parts here.. 4.9b1 working probably was an accident :)

Blitter start after BLTSIZE write (1 cycle + 2 blitter idle cycles)
Blitter cycle when interrupt generated/busy cleared (too long explanation, I think it was included in my detailed internal blitter operation post on eab, posted on early 2021 I think)
Paula detecting the interrupt. (4 CCKs! This is strange delay)
CPU detecting the interrupt. (IPL needs to be stable for single CPU cycle and then another cycle before it is latched internally. And finally internal detection depends on instruction, it generally happens when CPU does internal IRC to IR copy. I have partial cpu tester support done but I'll probably delay it until much later, too boring..)

 - 64 CPU-RW     0058 0006A666
 - 66 CPU-RW     4239 0006A668
 - 68 CPU-WW     0041 00DFF058
 - 6A CPU-RW B   0006 0006A66A
 - 6B          B
-1 0006a668 4239 0006 b22a           clr.b $0006b22a [00]
 - 6C CPU-RW Bb  B22A 0006A66C
 - 6D          B
 - 6E CPU-RW     21FC 0006A66E
 - 6F BLT-D 00 D   0000 000000C0
 - 70 CPU-RB     0001 0006B22A
 - 72 CPU-RW     0006 0006A670
 - 74 CPU-WB     0000 0006B22A
-1 0006a66e 21fc 0006 a678 006c      move.l #$0006a678,$006c [0006a678]
 - 76 CPU-RW     A678 0006A672
 - 78 CPU-RW     006C 0006A674
 - 7A CPU-RW     4E75 0006A676
 - 7C CPU-WW     0006 0000006C
 - 7E CPU-WW     A678 0000006E
 - 80 CPU-RW     3D7C 0006A678
 - 82          I
 - 85 CPU-WW     A676 0007FFB8

Cycle $6C "b" is where blitter interupt is generated initially. CLR.B $xxx.L (prefetch, prefetch, read, [IPL detect] prefetch, write) which happens just early enough (4 CCKS + 2 CPU cycles) to not detect the blitter interrupt -> following MOVE.L gets executed before interrupt.

This is not the only one with similar stupid interrupt handling.

Hope this helped :)

[dirkwhoffmann]

Hope this helped :)

Perfect, thanks a lot!!! With the detailed information above, it should be easy to fix.

[dirkwhoffmann]

Finally, this issue is fixed 😎. Thanks to all who have contributed. Great team work.

Summary: The error was caused by two independent bugs in vAmiga:

• The Blitter interrupt was triggered one DMA cycle too early (Tests Blitter/bltint/bltint2 to bltint6 fail #549).
• The IPL polling cycle in the CLR instruction was wrong (Test Blitter/bltint/bltint1 fails #548).