Strange behavior when using blit queue in copper list
1 Attachment(s)
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:
Not tried out yet:
|
Hi losso,
surely you have to wait for someone with another Amiga 500 to ensure that it is not an issue of your. Quote:
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:
In the modulo-first case, the instructions are now: Code:
000306a0: 0001 0000 ; Wait for , ignore horizontal 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.
|
Quote:
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.) Code:
000105bc: 0201 fffe ; Wait for vpos >= 0x02 and hpos >= 0x00 Code:
000105bc: 0201 fffe ; Wait for vpos >= 0x02 and hpos >= 0x00 |
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 |
1 Attachment(s)
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) |
Quote:
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 |
Quote:
|
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 :)
|
2 Attachment(s)
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.
|
All times are GMT +2. The time now is 04:19. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.