blitter waits and hardware bugs

[jotd]

Something I'm not sure of even today


Is that a correct way to wait for blitter on all machines?

.wait
    BTST    #6,$DFF002
    BNE.B    .wait

or should we add something like

   tst.b $BFE001

or something first to wait a while before waiting?


Isn't there a bug in some machine chipset (like A4000) that makes the blitwait inefficient in some circumstances ?

[Thomas Richter]

Originally Posted by jotd

Is that a correct way to wait for blitter on all machines?

The correct way is to call WaitBlit() of the graphics library. The problem with the blitter is that it has a couple of issues, depending on the machine, where it does not yet indicate that the blit has started because the CPU is ahead of the blitter, and the latter only updates its state based on the 7Mhz clock of the custom chips. Another issue the blitter has that it may erase the blitter-busy flag too soon while, in fact, the last word is still being blitted.

The graphics.library contains workarounds for such issues, it is thus the recommended way.

[alpine9000]

Originally Posted by Thomas Richter

The correct way is to call WaitBlit() of the graphics library. The problem with the blitter is that it has a couple of issues, depending on the machine, where it does not yet indicate that the blit has started because the CPU is ahead of the blitter, and the latter only updates its state based on the 7Mhz clock of the custom chips. Another issue the blitter has that it may erase the blitter-busy flag too soon while, in fact, the last word is still being blitted.

The graphics.library contains workarounds for such issues, it is thus the recommended way.

It would be nice if you could unlock the details of these workarounds for the many scenarios where the programmer is unable/unwilling to keep the operating system running.

[NorthWay]

Originally Posted by jotd

Is that a correct way to wait for blitter on all machines?

I'm sure Toni has a better explanation, but there is a bug that makes BUSY not flag until the blitter has actually started working. The workaround is thus that after an access to the chip bus you will be guaranteed that it actually has. (Correct?)

I don't know what revision fixed this to flag it as soon as the size register is written.

[roondar]

Originally Posted by jotd

Something I'm not sure of even today

Is that a correct way to wait for blitter on all machines?

.wait
    BTST    #6,$DFF002
    BNE.B    .wait

No, this code can fail on some machines. There are early Agnus chips that have a bug starts their blits one cycle later than normal. On such machines the above will fail. Not that many of these machines exist, so it's not that likely you'll have personally run into this issue. However, they do exist and the Blitwait above will fail on them.

or should we add something like

   tst.b $BFE001

or something first to wait a while before waiting?

Adding any custom chip access is enough to bypass the issue above. Most programs just do a tst.w $DFF002 or similar. Accessing the CIA will also work, but does waste a few cycles

Isn't there a bug in some machine chipset (like A4000) that makes the blitwait inefficient in some circumstances ?

I'm unaware of this, but I'm kind of doubtful. If BlitWaits were more inefficient on A4000's, lot's of games (including AGA ones) would not run well on them and I don't recall any such issues being mentioned. However, I have no evidence either way so it could be true.

Originally Posted by alpine9000

It would be nice if you could unlock the details of these workarounds for the many scenarios where the programmer is unable/unwilling to keep the operating system running.

The OS BlitWait routine for several Kickstart versions has been disassembled ages ago and the core of it works like the idea pointed out here (the loop above + one additional wait). Some versions add a few NOP's to keep the CPU in ROM and out of chipmemory a bigger percentage of time to optimise the waiting, though.

Note that the HRM provides Blitter Waiting code which also works like how it's been described in this thread (below is a copy from the HRM Blitter examples):

waitblit:
        btst.b  #DMAB_BLTDONE-8,DMACONR(a1)
waitblit2:
        btst.b  #DMAB_BLTDONE-8,DMACONR(a1)
        bne     waitblit2
        rts

Edit: the original source for the HRM code segment I copied can be found here http://amigadev.elowar.com/read/ADCD.../node02DE.html

[alpine9000]

I'm guessing that turning on BLITHOG before the "broken" wait loop and turning it off after the wait loop would avoid any issues as that would give you the required custom chip access ?

[roondar]

Originally Posted by alpine9000

I'm guessing that turning on BLITHOG before the "broken" wait loop and turning it off after the wait loop would avoid any issues as that would give you the required custom chip access ?

Yes, this is another common solution. It also has the extra benefit of making the waiting impact the Blitter a lot less, so the Blit will be done faster.

[Toni Wilen]

A1000 blitter sets BUSY when it gets first memory cycle. All (?) blitters clear BUSY when it has internally processed last word, not when last word gets written to memory. (which means at least 2 cycle delay). EDIT: this is almost always harmless (unless you access exact same word with CPU in next cycle) because any blitter register can be written safely during this period, including BLTSIZE. (which needed extra logic in emulation because there was demo that did it..)

Originally Posted by Thomas Richter

The correct way is to call WaitBlit()

I think you should already know that even when this is correct answer, it is also useless answer in this forum.

[jotd]

There are early Agnus chips that have a bug starts their blits one cycle later than normal. On such machines the above will fail. Not that many of these machines exist, so it's not that likely you'll have personally run into this issue. However, they do exist and the Blitwait above will fail on them.

So possibly it could happen with A500+ACA accelerator right? A500 alone could leave that bug unnoticed, but accelerating it with a buggy Agnus could trigger issues I guess.

I think you should already know that even when this is correct answer, it is also useless answer in this forum.

Yeah, I wanted to answer exactly that. Slightly condescending and all like RTFM... but in my case (I'm fixing an OS-compliant game) that could actually be an option. But I'd prefer a routine that I can paste in any context, even with OS down.

Maybe Toni you could add a special "agnus bug" option to be able to reproduce those bugs. I already love your "chipset hack" to find broken audio replays, it helped a lot. Maybe adding another bit in chipset hack could be enough.

[roondar]

Originally Posted by Toni Wilen

All (?) blitters clear BUSY when it has internally processed last word, not when last word gets written to memory. (which means at least 2 cycle delay)

Interesting. That makes me wonder: are there situations in which this causes issues? For instance, suppose I start setting Blitter registers immediately after BUSY is cleared, can this go wrong? Or is the fact that the Blitter has internally processed the last word already enough to prevent issues in this case.

I suppose it's possible an issue could arise if the CPU tries to read the very last word blit directly after BUSY is cleared. On fast machines this should then give the CPU the old pre-blit answer rather than the new. Not sure this is really going to cause many issues, but it's certainly interesting!

Originally Posted by jotd

So possibly it could happen with A500+ACA accelerator right? A500 alone could leave that bug unnoticed, but accelerating it with a buggy Agnus could trigger issues I guess.

This should really only affect the A1000. But, it's always wise to have the extra access just in case

[jotd]

So maybe waiting BEFORE writing to blitter registers is more dangerous than waiting just after having written to BLTSIZE (even if the first solution is less wasteful because the CPU can work in the meantime, specially when the blit is interleaved)

I rarely could insert blitwaits before blitter operations in games I fixed. It almost never worked... But it's also more difficult because if another routine changes a bitter register (not BLTSIZE) before you wait, you're toast.

[roondar]

Originally Posted by jotd

So maybe waiting BEFORE writing to blitter registers is more dangerous than waiting just after having written to BLTSIZE (even if the first solution is less wasteful because the CPU can work in the meantime, specially when the blit is interleaved)

It would seem to me that it's still safe considering what Toni wrote. Edit: it's also what I've always done without any known issues.

However, I'll defer judgement of this to Toni - he knows a heck of a lot more than me, that's for sure.

[jotd]

I fixed the incorrect blitter errors and it seems to have done it for a A4000/040 user...

http://mantis.whdload.de/view.php?id=4440

so thanks. And it seems that some A4000 machines have an issue like this too...

[ross]

There is this interesting old thread: http://eab.abime.net/showthread.php?t=31758
I would like to understand why the addition of waits with CIA access improves the situation on fast machines..
The maximum I had at the time was a 030/50 so the fewer wasted waits I did the better it was

[jotd]

it's probably not wasted if you have to wait most of the time anyway.

[ross]

Originally Posted by jotd

it's probably not wasted if you have to wait most of the time anyway.

Well, I'm against code waste

[roondar]

My guess is that using the CIA to wait is simply a good way to wait a specified number of cycles. Why this affects faster machines more is an interesting question though, it doesn't feel like it should - most of these machines access chip memory slower than the A1200 does.

[Toni Wilen]

I guess one unknown when the question was asked (which is now known) feature was blitter idle cycles being usable by the CPU but if blitter nasty is off and CPU steals cycle from blitter (by reading DMACONR) and it was going to be blitter idle cycle: blitter loses the cycle. Without cycle steal both blitter and CPU would have "used" it.

[ross]

Originally Posted by Toni Wilen

I guess one unknown when the question was asked (which is now known) feature was blitter idle cycles being usable by the CPU but if blitter nasty is off and CPU steals cycle from blitter (by reading DMACONR) and it was going to be blitter idle cycle: blitter loses the cycle. Without cycle steal both blitter and CPU would have "used" it.

So that's one more reason to use blitter nasty before the wait. But when I have blitter operations that don't use all available cycles? What is the best technique for the wait?

[jotd]

well if the code is running in chipmem and if you enable blitter nasty I guess you don't even have to loopwait. Enable it, wait just enough so the blitter understands that it can steal all cpu and disable it again.