
@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.