Problem with blitter fills on fast machines (Maybe bchg?)

[KONEY]

Stuck again with a very annoying problem.

I made a vector object drawn with blitter and then copied with fill mode in another bitmap. Everything is OK but the same code in a fast machine returns different values (always different in a different way) and I'm quite puzzled

This is what happens:



basically corners are not erased properly but this always change, they are never wrong in the "same way".

Being a BCHG instruction responsible for erasing the pixel corner I think the problem is within this piece of code:

move.l a0,a1 ; copia l'indirizzo
cmpi.w #7,d1 ; il numero del bit e` > 7 ?
ble.s NonCorreggi ; se no salta
addq.w #1,a1 ; ..altrimenti punta al prossimo byte
subq.w #8,d1 ; e rendi il numero del bit < 7
NonCorreggi:
not.b d1 ; inverti la numerazione dei bit

bchg d1,(a1) ; inverti il primo pixel della linea

which comes from Randy's course

It seems like in fast machines the results are not consistent, and it's driving me crazy enough to beg for help

full code: https://github.com/KONEY/mechmicrobe...R_FILL_DEBUG.s

[a/b]

I see nothing wrong in that piece of code. subq.w #8,d1 is not needed (you can add/sub 8/16/24/... and it will work the same since only the bottom 3 bits matter when bchanging the memory).
It's probably a combination of that and something else, or something else.

[StingRay]

Code works for me, only thing I see is a read from $dff000 in the blitter wait, which should be fixed but it should not cause the bugs you are experiencing.

[a/b]

Just theoretical, but maybe a cause.. Blitter and cpu are writing to the same byte.
You are modifying the bitmap with cpu while the blitter is running. Since you generally draw a poly-line (end pixel of one is start pixel of next) there's a good chance CPU and blitter will hit the same pixel/byte in wrong order and negate one of the writes.

[KONEY]

Thanks, after spending the afternoon I tried another routine which is more optimized and it hasn't the problem. Seeing the same coordinates return a different thing at every refresh was quite crazy, still very curious to know what was going on!

@stingray that tst.w (a6) is in Photon's miniwrapper and I'm not sure what its role is. What I know is that usually in its place the instruction below ( btst #6,2(a6) ) is repeated, for some bug on older models I think. Maybe Photon's one was the same and there's an error?