Strange behavior when using blit queue in copper list
 

Hi everyone,

I ran into a strange problem with my copper list blit queue. In WinUAE and on my Amiga 1200, everything runs as expected (objects get drawn, offscreen buffer gets cleared). However, on my Amiga 500, the effect soon begins to deteriorate, as can be seen here (24 sec into the video):

https://www.youtube.com/watch?v=sfI79iWxRhA

The only difference between the two versions is that the "fixed" one does two blitter-waits instead of one (i.e. $00010000 in the copper list). Boy, that took some time to isolate…

Regarding strange copper+blitter behavior, I only came across the COPJMP2-bug, but I'm not using any copper jumps.

I behaves as if the copper wait is unstable -- right after the WAIT instruction, new blitter register values get set early, and the current blit overwrites unwanted memory areas etc.

Is it good practice to use two consecutive blitter waits when you use a copper list for your blit queue? Or is my Amiga 500 (512KB trapdoor, Gotek) showing signs of subtle hardware failure? All other demos I tested while debugging this ran fine, but that may be coincidence.

Executables attached; I'd be interested if this happens on other machines as well.


Edit: Of course there might still be something stupid going on which just happens to look better with this workaround. I will try to provide a bare-minimum example instead of a binary blob, but not before Revision :). What I've tested so far:

• accidentally accessing blitter registers on the main thread (found none)
• using BLTPRI (no difference)
• removing an unnecessary COPJMP I was using (triggered by the copper; no difference)
• blitter register order (setting CONx and masks before PTH, no difference)
• disabling debug features (keyboard control and serial output, no difference)
• making sure the blit queue is completely written before the copper reaches it ($dff180-banging suggests it is)
• doing just 1 blit, i.e. 1 object without clearing (that worked and led to the 2-WAIT workaround)
• using copper NOPs around the copper WAIT In the copper (no difference)

Not tried out yet:

• spurious interrupts (I'm using a copper interrupt, $dff180-banging at least does not look like it's called more than once a frame)
• using a static blit queue (only indirectly by having the same objects without movement; started to glitch, too)

Hi losso,
surely you have to wait for someone with another Amiga 500 to ensure that it is not an issue of your.

I was going to suggest to try: CNOP BWAIT ($01fe $CAFE $0001 $0000)
but you have already done that :)

What is the result with an always satisfied WAIT then BWAIT
(like $0001 $fffe $0001 $0000)
or a 'merged' video/blitter wait (like a single $0001 $7ffE)?

Bye!
ross

Does it work (or at least problem happens less regularly) if you modify some less "dangerous" blitter registers than BLTCON0/1 after copper blitter wait? (for example do BLTxMOD updates first)

Because blitter finished state gets set before final D write is done (which is still pipelined inside blitter), it may be possible that next copper move(s) (depending on number of bitplanes) happens before D write is done. I think I couldn't duplicate this reliably so I didn't bother to do logic analyzer tests to confirm it 100%.

OCS or ECS Agnus?

bpls
 

Thanks for the ideas. My results are:

• WAIT+BWAIT: glitches
• merged WAIT/BWAIT: glitches
• setting modulos first: glitches

In the modulo-first case, the instructions are now:

SysInfo reports ECS AGNUS - 1Meg

Edit: Running in 4 bitplanes, by the way

Hi Toni, so a simple delay suffice?
losso inserted a CNOP (4 cycles) and do not work..
If a 6 cycles delay is enough then $0001 $fffe $0001 $000 should work...

Bye,
ross

[EDIT: too late :)]

mmh... thinking better, if like Toni said blitter finished state gets set before final D write then a wait need to be after,
so BWAIT+WAIT ($0001 $0000 $0001 $fffe)..

Can You test?

Bye,
ross

Doing two blitter waits might be necessary ; see comments about Agnus bugs in doc of graphics.library/WaitBlit.

Hi meynaf, i can remember bad, but what you are referring is not an old Agnus revision (A1000 OCS) bug?

Bye,
ross

Interesting... it seems $00010000 $0001fffe as suggested by ross does the trick, too.

This works fine (posting full copperlist just in case):

(EDIT: Just noticed there is only 1 blob in here, I captured the wrong state in WinUAE. However, on the machine it works with all balls activated.)

While this one glitches/crashes (using normal wait, but taking care to set modulos first):

Can you duplicate it with "static" copper list? (Stop all movement calculations etc), it would make this much easier to check with logic analyzer.

Hmm.. Or perhaps A1000 Agnus busy bit fix didn't fix copper blit waits. Does anything change if you add one dummy copper move after BLTSIZE write but before the wait?

So it is just a problem of delay cycles.
Now you should understand if some blitter registers can be touched immediately after (a work for Toni ;)).

[EDIT]
@Toni: no demo use this technique?
I vaguely remember something of Spaceballs that performed a blitter rendering with a queue of precalculated instruction

:great

I tested the dummy-move-after-bltsize variant. I also removed the object movement. Unfortunately with a bob configuration that does not trigger the glitching in both versions.

However, I noticed something else: I left the keyboard controls in, and when you press "B" and "N" you change one ball's size, which does trigger the glitching.

Here, the two versions do behave differently:

static.exe: glitches hard, crashes
dummy.exe: glitches when switching sizes, then "stabilizes"

This can bee seen here: https://www.youtube.com/watch?v=5vk1PVVqyLg (when pressing "B" and "N", and "R" at the end to activate movement)

This smells hardware-ish to me, but I'm more confused than before.

(AFK now for today)

one last edit: also worth mentioning for the flickering in this: I'm using triple buffering

Before I bother to examine it: it needs to be narrowed down to either:
a) all blits cause the problem, all the time.
b) there is only single blit/wait/write to blit registers that usually/always causes the problem.

Without this it gets too random, especially if it requires copper list change to trigger it and only one (or few) blits trigger it. All the unknown variables must be removed first.

Possible debugging options:

Write to background color before BLTSIZE write, then reset it immediately after WAIT. Assuming all blits are not too short, it should be easy to see if the problem is BLTSIZE+WAIT combination always/sometimes thinking that blit hasn't yet been started.

To prevent crashes (less annoying to debug), add extra WAIT after the color change.

Then reduce variables until only the problem remains :)

(It is guaranteed I'll test this someday if no one else does it)

Ok, finally remembered!
Was 'Mobile Destination Unknown' from The Gathering '93.
The demo stream precalculated frames (blitter fill-lists..) from disk, but actually use the CPU [to drive the blitter].
So not a good reference, sorry :rolleyes

Bye,
ross

There are two bugs, actually. One is apparently old A1000 bug indeed, but the other is for "all revisions thru ECS".

It does not appear to be that easy to duplicate.

WAIT some visible position
COLOR0=0f0
BLTSIZE=value
Copper blitter wait
COLOR0=000

Waits normally. (ECS Agnus). Number of planes also does not seem to have any effect (except blit speed changing).

Why not try something different? We have to get a precise syncronization and mantain blitter control..
We have BPLCON0==$4200 so we can wait $xxE1 even on V-line==$FF without losing Copper control.

So with $7fe1,$00fe we trigger blitter action if, and only if, we are at this precise position ($E0)at end of every line
(yes, you can possibly loss an entire line but with triple buffer I don't think is a problem, even better for CPU chip access..)
Then with DMA cycles explained:
$DE ($E0-2) 3rd copper WAIT cycle, awakening if h>=$E0 and blitter finished, practically only if H==$E0 ($E1-2 (odd) and $E2-2 ($E0==lost) is not awakening positions possible)
$DF (free cycle for blitter! -> final D write, blitter nasty required) (if DDFSTOP<$D8 as in our case)
$E0 lost
$E1 copper delayed cycle, MOVE 1st word fetch (address)
$E2 refresh/strobe
$00 ..next line.. MOVE 2st word fetch (data)
$01 refresh
..and so on..

Make sense?

I want to solve this copper blitter wait problem first :)

Ok, made a version of "balls" with $7fe1,$00fe mod.
(attached bootable ADF).

No problem whatsoever in WinUAE (OCS, ECS, AGA, cycle exact).
Someone can test in real A500/+?

@Toni: if it's working (or minor glitch) then you can clarify many things about this copper wait bug :)

[EDIT: added blitter_nasty version]

Bye,
ross

@ross: Hi - just tested both of those adfs on a real A500 (OCS) and they both work fine, no glitches.