Avoiding copper strobe/blitter bug

mc6809e · 21 October 2013, 20:26

Can the bug be avoided by "pausing" the blitter by turing off blitter DMA in DMACON before strobing COPJMPx and then turning blitter DMA back on?

Mrs Beanbag · 21 October 2013, 20:49

what bug is this?

mc6809e · 21 October 2013, 21:00

It's a nasty one.

If the copper is WAITing and the blitter is running and the CPU touches COPJMP to strobe the address of a new copper list into the copper's instruction pointer, a blitter channel pointer can be updated instead.

Worst case is when the D channel is altered to point to the new copper list and the list is overwritten by the blit.

phx · 22 October 2013, 12:27

Wow! That's it! Exactly that happened to me a few weeks ago, and I was hunting the bug for many days, until I gave up and made sure the Blitter has finished before loading new Copper pointers.

Parts of my copper list had been overwritten by Blitter data. And I couldn't explain how the blitter could ever write to that region.

Thanks! I didn't know about that bug.

Toni Wilen · 22 October 2013, 12:39

I think it should not happen if blitter DMA is disabled because reason for this bug is same cycle being used by both the copper and blitter when copper wakes up incorrectly from waiting state.

Bug: Copper does weird 3 cycle combination of MOVE and WAIT cycle sequences if COPJMP is written while waiting, http://eab.abime.net/showpost.php?p=...&postcount=122 (I am still not 100% sure this is the exact behavior, there may be some hidden variable)

phx · 22 October 2013, 14:24

I know we have the "Undocumented Amiga hardware stuff" thread. But only some undocumented behaviours, like this one, are really a dangerous bug. It would be great to have a complete list of known hardware bugs of the Amiga chipset somewhere.

mc6809e · 22 October 2013, 16:53

Thanks, Toni. At least the work-around is cheap.

Mrs Beanbag · 23 October 2013, 00:27

Does this happen on all chipsets? Or just OCS/ECS?

Leffmann · 23 October 2013, 00:43

It happens on AGA as well. I thought you would be able to avoid it by stopping Copper DMA, writing the new program pointer, strobing, and then starting Copper DMA again, but no luck.

Lonewolf10 · 24 October 2013, 22:09

Quote:

Originally Posted by phx

I know we have the "Undocumented Amiga hardware stuff" thread. But only some undocumented behaviours, like this one, are really a dangerous bug. It would be great to have a complete list of known hardware bugs of the Amiga chipset somewhere.

I agree

TheDarkCoder · 05 November 2013, 09:37

Quote:

Originally Posted by Toni Wilen

I think it should not happen if blitter DMA is disabled because reason for this bug is same cycle being used by both the copper and blitter when copper wakes up incorrectly from waiting state.

Bug: Copper does weird 3 cycle combination of MOVE and WAIT cycle sequences if COPJMP is written while waiting, http://eab.abime.net/showpost.php?p=...&postcount=122 (I am still not 100% sure this is the exact behavior, there may be some hidden variable)

In general, what happens if one disables blitter DMA while the blitter is active, and after some time re-enables the blitter? Assuming that no BLT register ha been changed, does the blitting restarts and complete as-if DMA has not been stopped?

Toni Wilen · 05 November 2013, 10:07

Quote:

Originally Posted by TheDarkCoder

In general, what happens if one disables blitter DMA while the blitter is active, and after some time re-enables the blitter? Assuming that no BLT register ha been changed, does the blitting restarts and complete as-if DMA has not been stopped?

Yes, blitter only "pauses" when DMA is off.

TheDarkCoder · 06 November 2013, 16:35

Quote:

Originally Posted by Toni Wilen

Yes, blitter only "pauses" when DMA is off.

very nice to know, and also useful, not only to avoid the nasty copper strobe/blitter bug!

Wepl · 14 November 2013, 00:35

I don't see much sense in writing the copjmps with the cpu anyway.
Many old demos/games have some kind of screen distortion because writing copjmp or enabling copper/raster dma somewhere inbetween the frame.
All operations concerning the display should be synchronized. The cpu is usually not.

A proper gfx init is AFAIK:

set cop1lc
wait vertical blank
enable copper/raster dma

(as long as you don't have a vbi which eats half of the frame, which would be misuse of an interrupt IMHO)

phx · 14 November 2013, 10:53

You're right! The COPxLC will be automatically reloaded on each VERTB, so there is really no need to use COPJMPx for setting up a new copper list.

I always used COPJMPx, without thinking about that, because I learned it in some stupid tutorial about 25 years ago...

StingRay · 14 November 2013, 12:43

Quote:

Originally Posted by phx

You're right! The COPxLC will be automatically reloaded on each VERTB, so there is really no need to use COPJMPx for setting up a new copper list.

This is only true for Copperlist1 though.

Quote:

Originally Posted by phx

I always used COPJMPx, without thinking about that, because I learned it in some stupid tutorial about 25 years ago...

Nothing wrong with that as long you wait for the vertical blank before doing that.

phx · 14 November 2013, 16:51

Quote:

Originally Posted by StingRay

This is only true for Copperlist1 though.

Hm, yes. Seems I missed something again...

Assuming I will take over the system when it is running an interlaced Workbench screen, then the 2nd copperlist might be active and I would need COPJMP1 to switch to the first one.

Or does a preceding LoadView(NULL) guarantee that the first copperlist is running?

mc6809e · 14 November 2013, 17:48

Quote:

Originally Posted by Wepl

I don't see much sense in writing the copjmps with the cpu anyway.

It's useful when the copper is being used to drive the blitter.

Wepl · 14 November 2013, 22:06

Quote:

Originally Posted by phx

Hm, yes. Seems I missed something again...

Assuming I will take over the system when it is running an interlaced Workbench screen, then the 2nd copperlist might be active and I would need COPJMP1 to switch to the first one.

Or does a preceding LoadView(NULL) guarantee that the first copperlist is running?

What do you mean with second copperlist?
On interlace there is a Short Frame List and a Long Frame List which differer in the bplpts.
I think it's a common false assumption that the reason for the existence of the two copper list pointers is interlace. You can drive interlace without the copper by setting the bpls in the vbi too. On the other side the OS always uses the cop2lc in every display mode.

Wepl · 14 November 2013, 22:15

Quote:

Originally Posted by mc6809e

It's useful when the copper is being used to drive the blitter.

I don't saw an example for that yet. Is it used in some demos maybe?
I wonder what the benefit would be compared to directly write the blitter regs or if the blits are same for each frame to integrate this in the standard coplc.

I saw examples which use blitter interrupts to avoid blitter waits (e.g. Lotus2).

21 October 2013, 20:26	#1
mc6809e Registered User Join Date: Jan 2012 Location: USA Posts: 372	Avoiding copper strobe/blitter bug Can the bug be avoided by "pausing" the blitter by turing off blitter DMA in DMACON before strobing COPJMPx and then turning blitter DMA back on?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Combining copper scrolling with copper background	phx	Coders. Asm / Hardware	16	13 February 2021 12:41
Support for 100Hz/120Hz lightboost strobe	cpharlok	request.UAE Wishlist	89	21 March 2014 20:03
Blitter using the copper...	h0ffman	Coders. Asm / Hardware	9	23 February 2012 08:25
[Found: The Sentinel] creepy music, avoiding eye contact with a statue?	lost_lemming	Looking for a game name ?	2	14 February 2010 00:08
Copper/jit bug workarround	Leandro	support.WinUAE	11	17 September 2002 09:21

21 October 2013, 20:49	#2
Mrs Beanbag Glastonbridge Software Join Date: Jan 2012 Location: Edinburgh/Scotland Posts: 2,243	what bug is this?

21 October 2013, 21:00	#3
mc6809e Registered User Join Date: Jan 2012 Location: USA Posts: 372	It's a nasty one. If the copper is WAITing and the blitter is running and the CPU touches COPJMP to strobe the address of a new copper list into the copper's instruction pointer, a blitter channel pointer can be updated instead. Worst case is when the D channel is altered to point to the new copper list and the list is overwritten by the blit.

22 October 2013, 12:27	#4
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,537	Wow! That's it! Exactly that happened to me a few weeks ago, and I was hunting the bug for many days, until I gave up and made sure the Blitter has finished before loading new Copper pointers. Parts of my copper list had been overwritten by Blitter data. And I couldn't explain how the blitter could ever write to that region. Thanks! I didn't know about that bug.

22 October 2013, 12:39	#5
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,553	I think it should not happen if blitter DMA is disabled because reason for this bug is same cycle being used by both the copper and blitter when copper wakes up incorrectly from waiting state. Bug: Copper does weird 3 cycle combination of MOVE and WAIT cycle sequences if COPJMP is written while waiting, http://eab.abime.net/showpost.php?p=...&postcount=122 (I am still not 100% sure this is the exact behavior, there may be some hidden variable)

22 October 2013, 14:24	#6
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,537	I know we have the "Undocumented Amiga hardware stuff" thread. But only some undocumented behaviours, like this one, are really a dangerous bug. It would be great to have a complete list of known hardware bugs of the Amiga chipset somewhere.

22 October 2013, 16:53	#7
mc6809e Registered User Join Date: Jan 2012 Location: USA Posts: 372	Thanks, Toni. At least the work-around is cheap.

23 October 2013, 00:27	#8
Mrs Beanbag Glastonbridge Software Join Date: Jan 2012 Location: Edinburgh/Scotland Posts: 2,243	Does this happen on all chipsets? Or just OCS/ECS?

23 October 2013, 00:43	#9
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	It happens on AGA as well. I thought you would be able to avoid it by stopping Copper DMA, writing the new program pointer, strobing, and then starting Copper DMA again, but no luck.

14 November 2013, 00:35	#14
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 873	I don't see much sense in writing the copjmps with the cpu anyway. Many old demos/games have some kind of screen distortion because writing copjmp or enabling copper/raster dma somewhere inbetween the frame. All operations concerning the display should be synchronized. The cpu is usually not. A proper gfx init is AFAIK: set cop1lc wait vertical blank enable copper/raster dma (as long as you don't have a vbi which eats half of the frame, which would be misuse of an interrupt IMHO)

14 November 2013, 10:53	#15
phx Natteravn Join Date: Nov 2009 Location: Herford / Germany Posts: 2,537	You're right! The COPxLC will be automatically reloaded on each VERTB, so there is really no need to use COPJMPx for setting up a new copper list. I always used COPJMPx, without thinking about that, because I learned it in some stupid tutorial about 25 years ago...

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)