Reference (SAE, Kick 1.3, OCS chipset, Immediate Blitter):

vAmiga 馃檲:

vAmiga and SAE behave similar until blit 91. This blit is started with a different value in BLTDPT:

Blitter was falsely accused. Discrepancy is due to some code in Kickstart. If SAE and vAmiga are run with df0: only, all Blitter checksums are equal.
Next suspect: Copper. There is Copper DMA going on just a few pixels ahead of the graphics glitch:

The copper, I have read that someone has written that the real nightmare of the Amiga emulation is only the copper...
the real nightmare of the Amiga emulation is only the copper...
Actually, there are multiple nightmares out there 馃槵
I just figured out what happens before the graphics glitch occurs:
[648] (148,112) 051DBA BCBSDA 4020 07C0 [03BB58] Copper: COPPC: 3BB58 move(BPLCON0, $4200) (16896)
[648] (148,114) 051DBA BCBSDA 4020 07C0 Denise: pokeBPLCON0(4200)
[648] (148,114) 051DBA BCBSDA 4020 07C0 Denise: pokeBPLCON0(3200,4200)
The intro switches from 3 actives bitplanes to 4.
I still have no idea where these bad pixels come from. I only found out the following: If you watch this intro for a long time, the balls turn into flying bananas. Which means that the programmer must have been pretty drugged.

Besides, here is the relevant part of the Copper list for reference (not for the bananas, for the bug):

I can definitely confirm that it's not the on-the-fly modification of BPLCON0. I've written more tests and vAmiga handles them correctly. All of them.
Amiga 500 鉂わ笍:

vAmiga 馃槑:

SAE 馃檲:

Therefore we can rule out BPLCON0 as a suspect. It must be the BPLxPT registers then. Let's arrest them.
It's not the BPLxPT registers. I verified the DMA data in line 0x94 manually and all data words match. The only remaining possibilities are:
TODO: Rule out 2 by dumping the iBuffer (index buffer) in line 0x94. If it contains a repeating pattern, it must be 1. Add a function dumpIBuffer() to the debug functions.
Brilliant bug hunt strategy. You are the hunter.
Here is what happens:
[1199] (127,209) 051DBA BCBSDA 4020 07C0 Agnus: denise->bpldat[PLANE4] = FF80 (from 3A1DE)
[1199] (148,121) 051DBA BCBSDA 4020 07C0 Agnus: denise->bpldat[PLANE4] = 0 (from 3A510)
In line 127, BPL4DAT is set to $FF80. When we reach line 148, the number of active bitplanes is 3, so the value in BPL4DAT does not matter. When the intro switches to 4 bitplanes in line 148, BPL4DAT is transferred into the shift register and drawn. This causes the graphics glitch. In the rest of the line, BPL4DAT is loaded with 0 which is the correct value to draw the scene right.
Unfortunately, there is no direct indication of what is going wrong. It just explains why we see what we see.
Crosscheck and run international karate on the A500 MMSE. Maybe it also shows the glitch?
Maybe it also shows the glitch?
OMG. It's really there 馃槼.

Bottom line: The intro has a bug that gets compensated by a bug in xAE. This was the least thing I expected 馃き.
Despite the fact that I wasted two days of my life hunting a phantom, this is good news. It shows that vAmiga is clearly improving 馃槑.
You should change the label from bug to feature. I believe in vAmiga. The rebel. The new source of trust. 馃憣馃槀
I think this can be closed then 馃槄.
Most helpful comment
OMG. It's really there 馃槼.
Bottom line: The intro has a bug that gets compensated by a bug in xAE. This was the least thing I expected 馃き.
Despite the fact that I wasted two days of my life hunting a phantom, this is good news. It shows that vAmiga is clearly improving 馃槑.