Possible bug in Copper timing / emulation

Hi
While playing with Copper loops and jumps, i think i discovered a bug in the Copper emulation.

If you setup a Copper loop to keep spamming the Color 00 register 55 times every scanline. it gives a somewhat funny result (see attached screenshot)

there is 2 things i notice.
1. The pattern is not the same all the way down
2. On the right side of the screen, there is a "step" where the colorshift takes up more than 8 pixels. (i think about 10 pixels)

i would expect this code to repeat the same pattern all the way down the screen, but instead it changes about half way down the screen to another pattern. If i add more color shifts to the copperlist, it will also change to a straight pattern about half the way down the screen.

i have testet with different WinUAE versions, and the result is the same.
I have not testet this on real hardware, as i don't have it setup right now.

attached is:
WinUAE Copper bug.png : Picture of the screen i see
WinUAE CopperBug-Small.s: Sourcecode to reproduce the issue
WinUAE-CopperBug.lha: Exe file to show the issue
Amiga 1200.uae: The UAE configuration used.

I dont know if this is a bug, or expected behavior, but it makes very little sence to me.

/Labodilsen

[Toni Wilen]

It is 100% correct

Right side: single cycle at the very end of scanline is never available for the copper, free or not free. (reason unknown)

Change of pattern: I think (didn't really check anything) it is either WAIT or COPJMP (both have extra cycles that don't need to be free) that fit perfectly with unavailable cycle making following scanline 1 cycle "faster".

EyeQLazer by Scoopex uses same trick (note that at least screenshot in pouet.net is from old emulator version that didn't work correctly)

Hi Toni
Thanks for the fast answer.

So what you are saying (just to recap for my own understanding)

because of that single cycle that is not available at the end of every scanline. Then at some point the WAIT og COPJMP instruction will hit that Single cycle, and change the behavior of the code?

Nice.. ofcourse it's easy to work around, so i will fix my code, instead of complaining about non existing bugs.

[Toni Wilen]

I checked using DMA debugger.

It is COPJMP condition's extra cycle that does not need to be free. If it happens during "not available for copper" cycle, COPJMP executes 1 copper cycle (2 color clocks) faster (vs any normal copper MOVE that needs to wait). This makes the difference.

Originally Posted by Toni Wilen

Right side: single cycle at the very end of scanline is never available for the copper, free or not free. (reason unknown)

Is this for PAL only, or also for NTSC?..
i ask because, if i set WinUAE to NTSC, the code bugs out with a nice flicker..

and then i remembered this text from the hardware reference manual:

All lines are not the same length in NTSC. Every other line is a long line (228 color clocks, 0$E3), with the others being 227 color clocks long. In PAL, they are all 227 long. The display sees all these lines as 227 1/2 color clocks long, while the copper sees alternating long & short lines.

So the "not available" cycle might be to trick the copper to see 227 1/2 lines on every line? (just a though)

Sorry to bring this up again, but i'm still seeing some unexpected behavior.

I've setup a copper list with the below lines repeated down the screen (not using COPJMP this time). this gives a stable 7 color change, but a line $7F the pattern change. and then at line $FF it restores it self again.

 
dc.w	$003b,$80fe
dc.w $0180,$000f,$0180,$00ff,$0180,$00f0,$0180,$0ff0,$0180,$0f00,$0180,$0f0f,$0180,$0fff
dc.w	$0180,$0000
dc.w	$00e1,$80fe

the code waits for horizontal $3b, change the color some 8 times, and then wait for Horizontal $E1. and then repeat.

[Toni Wilen]

Always include executable binary. I don't compile (too boring) and it is easiest to see what the copper list does with copper and dma debuggers in WinUAE.

Hi Toni
Not a problem, i've attached the exe to the original post about this second issue.

[Toni Wilen]

Originally Posted by LaBodilsen

Sorry to bring this up again, but i'm still seeing some unexpected behavior.

Real A1200 shows exactly same pattern. (I haven't checked any details)

Case closed then.. sorry for the "non-bug" report.

[Toni Wilen]

Every part of chipset has odd undocumented features

btw, there is one more unexpected Copper behavior: if COPJMP sequence's second cycle would use cycle immediately after first refresh cycle in scanline, copper skips it and jumps directly to 3rd cycle of COPJMP sequence (Skipped cycle is idle cycle that normally needs free dma cycle. Copper still functions normally when skipped). This makes COPJMP sequence 1 copper cycle faster than normally!

Interesting, wonder how to take advantage of this little nugget, and create something "impossible"

btw: i just love how you can't keep this information to yourself, i've seen several threads where you tell things like this, and it seem like you kinda enjoy giving this information, and its quite enjoyable to read really. so thank you for all the great work on WinUAE and forums.