@snajper, post #2
@snajper, post #5
@peceha, post #6
WbToScreen 0 ShowScreen 0 WBStartup BitMap 0,800,600,2 LoadBitMap 0,"ram:tescior.iff" For x.w=0 To 9 GetaShape cnt,x*16,0,16,16 Next x wFlags.l=$2|$4|$8|$400 Window 0,0,16,190,190,wFlags,"test",0,0 cnt.w=0 For y.w=0 To 7 For x.w=0 To 9 WBlit cnt,8+x*16,8+y*16 cnt+1 If cnt>9 Then cnt=0 Next x Next y Repeat ev.l=WaitEvent If ev=$200 End EndIf Forever
@*y, post #10
WbToScreen 0 ShowScreen 0 WBStartup BitMap 0,800,600,2 LoadBitMap 0,"ram:tescior.iff" For x.w=0 To 9 GetaShape x,x*16,0,16,16 Next x wFlags.l=$2|$4|$8|$400 Window 0,0,16,190,190,wFlags,"test",0,0 cnt.w=0 For y.w=0 To 7 For x.w=0 To 9 WBlit cnt,8+x*16,8+y*16 cnt+1 If cnt>9 Then cnt=0 Next x Next y Repeat ev.l=WaitEvent If ev=$200 End EndIf Forever
@peceha, post #11
@teh_KaiN, post #12
WbToScreen 0 ShowScreen 0 WBStartup BitMap 0,320,256,2 LoadBitMap 0,"ram:tescior.iff" wFlags.l=$2|$4|$8|$400 Window 0,0,16,190,50,wFlags,"test",0,0 GetaShape 0,0,0,16,16 WBlit 0,0,0 Repeat ev.l=WaitEvent If ev=$200 Then End Forever
@peceha, post #17
@juen, post #18
@peceha, post #21
@*y, post #22
I think original reason was 68030 cache related bug/feature: long aligned writes always get cached if write allocate cache mode is enabled, even if write goes to hardware level (CI pin active) cache-inhibited memory. Only MMU level cache inhibit works properly in this situation.
CPU wrote something to chip ram, and because it was long and aligned write, it also got stored in data cache. Then blitter modified same memory. Finally CPU was used to read from address that was previously written to: data came from cache, not from memory that blitter modified.
EDIT: This happens very rarely because cache is so tiny.