Lack of blitter waits on A500

[Codetapper]

I'm curious if some of the more techy coders can answer this one! On many A500 games, the coders simply did not put any blitter wait operations in. This was apparently because the CPU was so slow in comparison to the blitter that they weren't needed. Some games had incredibly small bits of code between each blit. eg. Menace source:

        move.w  d2,bltdmod(a6)
        move.w  #$09f0,bltcon0(a6)    ;use D = A for the blit
        move.l  (a0)+,bltdpt(a6)      ;and do all three planes.
        move.w  d3,bltsize(a6)
        move.l  (a0)+,bltdpt(a6)
        move.w  d3,bltsize(a6)
        move.l  (a0)+,bltdpt(a6)
        move.w  d3,bltsize(a6)
        bra     restoreloop

Even if the blit is something tiny like a perfectly aligned 16x16 pixel image, that would be 4 cycles for a D=A blit x 16 pixels high = 64 cycles.

I find it quite incredible that in the time the blitter is working, the CPU can't execute 2 lousy instructions before it's finished? If the CPU is slightly faster, the blitter will be copying to a different location and corrupt the screen.

Can anyone explain exactly how these timings work? What size blit could be performed on an A500 without any waits? And if you lookup the 68k instruction counts, it seems that the blitter should not beat the CPU at all, particularly when the game is altering blitter registers while the blitter should be operating!

[StingRay]

Most probably the game sets "blitter nasty" before performing the small blits.

[Codetapper]

I just checked and indeed it's doing:

        move.w  #$87e0,dmacon(a6)

So blitter nasty is set for the entire game (not enabled and disabled as required!) and I guess that's why no blitter waits.

I would still think that would cause problems for certain times (during a vertical blank etc) where there isn't much DMA happening, or does that bit being set effectively kill the 68000 CPU completely? (But not 68020+)

[Toni Wilen]

Blitter stops the CPU (steals all cycles) if nasty is set and blitter's enabled channel combination don't have any idle cycles.

For example D and A enabled: uses all cycles, but on the other hand D only clear uses only every other cycle, CPU won't stop. Line mode also uses only every other cycle. check HRM for cycle diagrams.

"Unfortunately" CPU won't stop immediately, there is 2 cycle delay between write to BLTSIZE and before blitter starts and first D write cycle is always idle (except linemode) and finally CPU prefetch has already fetched next word: there are total 4 "free" memory cycles available before CPU stops. (If anyone is interested in details)

68020+ can still stop because custom chipset register accesses are also blocked (shares same chip ram bus) but CPU can be fast enough to execute following blitter register write during above "blitter startup delay" time. Above code probably isn't 68020 compatible if a0 points to 32-bit ram. (need only single memory access)

68040+ is most likely always fast enough.