CPU/copper sync

[goldmomo]

While playing around with my Amiga 500 I noticed something that is different with WinUAE (A500 Setup / OCS Cycle-exact).
It's probably just hypothetical, but I'll ask :-)

When I write to $dff180 with 68k (multiple move) and Copper in parallel (no Bitplane DMA active), WinUAE show me following DMA-Slot allocation:

--> cut

 [30  48]  [31  49]  [32  50]  [33  51]  [34  52]  [35  53]  [36  54]  [37  55]
 COP  180    CPU-WW  COP  08C    CPU-RW  COP  180    CPU-WW  COP  08C    CPU-RW
     FFFF      0D00      0180      3285      0000      0C00      0180      3286
 000202CE  00DFF180  000202D0  00CAB53C  000202D2  00DFF180  000202D4  00CAB53E
 4C927600  4C927800  4C927A00  4C927C00  4C927E00  4C928000  4C928200  4C928400

 [38  56]  [39  57]  [3A  58]  [3B  59]  [3C  60]  [3D  61]  [3E  62]  [3F  63]
 COP  180    CPU-WW  COP  08C    CPU-RW  COP  180    CPU-WW  COP  08C    CPU-RW
 0   FFFF      0B00      0180      3287      0000      0A00      0180      3288
 000202D6  00DFF180  000202D8  00CAB540  000202DA  00DFF180  000202DC  00CAB542
 4C928600  4C928800  4C928A00  4C928C00  4C928E00  4C929000  4C929200  4C929400

 [40  64]  [41  65]  [42  66]  [43  67]  [44  68]  [45  69]  [46  70]  [47  71]
 COP  180    CPU-WW  COP  08C    CPU-RW  COP  180    CPU-WW  COP  08C    CPU-RW
     FFFF      0900      0180      3281  (   0000      0100      0180      3282
 000202DE  00DFF180  000202E0  00CAB544  000202E2  00DFF180  000202E4  00CAB546
 4C929600  4C929800  4C929A00  4C929C00  4C929E00  4C92A000  4C92A200  4C92A400

 [48  72]  [49  73]  [4A  74]  [4B  75]  [4C  76]  [4D  77]  [4E  78]  [4F  79]
 COP  180    CPU-WW  COP  08C    CPU-RW  COP  180    CPU-WW  COP  08C    CPU-RW
     FFFF      0F00      0180      3283      0000      0E00      0180      3284
 000202E6  00DFF180  000202E8  00CAB548  000202EA  00DFF180  000202EC  00CAB54A
 4C92A600  4C92A800  4C92AA00  4C92AC00  4C92AE00  4C92B000  4C92B200  4C92B400

<-- cut

So two color clocks behind each other $dff180 is written (Copper / CPU) then Copper has to load and CPU to fetch and so on.
I expect one color00 write (1 color cycles = 2 lowres pixel) and after that the next color00 write with 2 (Copper/CPU) loads/fetches), so 3 color cycles (6 lowres pixel).

On my amiga 500 I can see this behavior but not in the emulation (WinuAE -> 4:4 lowres pixel ratio but not 2:6 although the dma slot allocation is shown correctly).

Not that it's still up to my Indivision ECS.

Thanks and regards

[Toni Wilen]

Moved from beta thread. Not going to analyze this until 4.9.1 is out

[Toni Wilen]

Your code checks mouse button, perhaps it has something to do with CIA E-clock. Does it work differently it you don't "sync" the code to E-clock? (read right mouse button for example)

68000 document says "This signal is generated by an internal ring counter that may come up in any state. (At power-on, it is impossible to guarantee phase relationship of E to CLK.)". Of course it is still possible it always starts in same phase and documented behavior only happens with early revisions or something.

[goldmomo]

Hello Toni,

I removed CIAA read access (also moved code to CHIP and sync per frame, do left joystick to exit).

Copper will write 2000 times $180,$ffff,$180,$0000 (start at $3c3b).
CPU will drive $f00,$0f0 -> $dff180 starting V=$20 32*101 times.

If they both try to write $180 together , I can see on my A500, 2 Lowres Pixel CPU (red), 6 Copper (black) , 2 CPU (green), 6 Copper (white) or vice versa (like DMA slot usage correctly shown in WinUAE).

In WinUAE only change every 4 lowres pixel.

Yesterday I turned my Altera - DE1 into a Minimig, the behavior was different there, will try again later (wife allocated my time slot for today).

(WinUAE A500 config, HW A500 with Indivision ECS).

Best regards

[Toni Wilen]

https://download.abime.net/winuae/files/b/winuae.7z has some preliminary updates that appears to fix this.

Note that this file can and will change randomly, randomly breaking and fixing things... especially before official betas start (it won't start soon)

[goldmomo]

Works for me, thank you very much.
I hope the effort has added value for other programs/games.

[Toni Wilen]

I already know it does fix something else..

But more importantly, during testing chipset/cpu timing, possibly previously unknown nasty chipset bug was found (affects all chipsets). In a very specific condition bitplane and sprite DMA can conflict, causing "DMA" write to wrong custom register. ($100 to $10E range depending on other conditions)

More details later, still debugging exact behavior and conditions.