Re: [hatari-devel] Sokoban VGA (Falcon)

[George Nakos <ggn@xxxxxx>]

Title: Re: [hatari-devel] Sokoban VGA (Falcon)

Hello Douglas,

Tuesday, October 8, 2013, 5:11:35 PM, you wrote:

Interesting that it goes to the trouble / risk of using TAS to restart the blitter, yet the old NOP is still present. Despite trying I was never able to get a blitter restart to fail with the nop removed, and its purpose - if there is one - was never clearly explained by Atari. Perhaps the delay eliminates one unnecessary/bogus spin, or perhaps it is for safety on 16mhz machines, or some board/chip revisions. (?) It is of course always bad to shortcut advice from developer docs... but there are few strict rules in demo land :)

When I was writing Downfall for the Falcon I noticed some really strange things with the blitter. Sometimes the sprites would be changing colours for 1 frame, and it was barely noticeable so I didn't give it much attention. It was while I was debugging another issue that I found the culprit: I had 4 blits (for 4 bitplanes) unrolled, so I'd do something like:

                REPT 4
                move.l  D6,daddr(A6)
                move.w  D5,ycnt(A6)
                move.b  #192,lineno(A6)
                addq.l  #2,D6
                ENDR

....spotted the problem yet? Apparently sometimes daddr(a6) was being written a 2nd time before the blitter had the time to start, so the next plane would be written in the current one! I can only assume that this was the cache kicking in. In the end, placing a nop after the move.b fixed things :).

Also at some points in the code I had to place 2 nops after a call to the blitter, as machines with a CT2 or CT6x would also report some badly drawn graphics (or totally black!). Damnedest thing though, the Falcon's rock stable when playing Downfall in 060 mode for a long time with a ton of calls to the blitter, never mind if nvdi is installed or not...








-- 
Best regards,
 George                            mailto:ggn@xxxxxx