blitter waits and hardware bugs

[Toni Wilen]

Originally Posted by 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.

Only if blit has no idle cycles. It is also (at least in my opinion) too unsafe, depends on officially undocumented feature, and non-future proof. (for example if some reimplementation has wider/separate chip bus for DMA and CPU)

[jotd]

Agreed! I'm not going to perform blitwait like that for the sole reason that if I want a game to be fast, I'll do my best to relocate the code in fastmem instead.

[ross]

It's possible to recognize via code 8361 vs 8370 Agnus (or 8367 vs 8371)?
(in VPOSR there is only a bit for NTSC vs PAL version..)

[Toni Wilen]

Originally Posted by ross

It's possible to recognize via code 8361 vs 8370 Agnus (or 8367 vs 8371)?
(in VPOSR there is only a bit for NTSC vs PAL version..)

Yes. A1000 Agnus variants generate vblank (vblank strobe register access) when vertical position is 1 (instead of correct zero). For example poll INTREQR vblank bit and when it gets set, check vertical position.

[ross]

Originally Posted by Toni Wilen

Yes. A1000 Agnus variants generate vblank (vblank strobe register access) when vertical position is 1 (instead of correct zero). For example poll INTREQR vblank bit and when it gets set, check vertical position.

Thanks

[Tomislav]

AROS WaitBlit()

#include "aros/m68k/asm.h"

	.text
	.balign 4
	.globl	AROS_SLIB_ENTRY(WaitBlit,Graphics,38)

AROS_SLIB_ENTRY(WaitBlit,Graphics,38):
    /* Blitter nasty set? Also simultaneous original DIP Agnus bug workaround. */
    btst #2,0xdff002
    bne.s w1

    /* Already finished? Exit immediately. */
    btst #6,0xdff002
    beq.s w0

    /* Set blitter nasty temporarily. */
    move.w #0x8400,0xdff096
w2: /* Keep CPU out of the chipbus for few cycles. */
    tst.b 0xbfe001
    btst #6,0xdff002
    bne.s w2
    /* Clear blitter nasty. */
    move.w #0x0400,0xdff096

w0: rts

    /* Blitter nasty was already set, normal wait loop. */
w1: btst #6,0xdff002
    beq.s w0
    /* Keep CPU out of the chipbus for few cycles. */
    tst.b 0xbfe001
    bra.s w1

[ross]

Originally Posted by Tomislav

AROS WaitBlit()

I think the AROS code is redundant.

My version is:

    /* Set blitter nasty temporarily and keep CPU out of the chipbus
       (fix first A1000 Agnus bug */

       move.w #0x8400,0xdff096

bw:    btst #6,0xdff002
       bne.s bw
 
   /* Clear blitter nasty and keep CPU out of the chipbus
       (fix second pre-ECS Agnus bug) */

       move.w #0x0400,0xdff096

no idea if the

tst.b 0xbfe001

helps a bit on high spec processors

[jotd]

There are at least 2 games I know that use this incorrect blitwait

bw:    btst #6,0xdff002
       bne.s bw

The games are Crazy Cars III and Highway Hawks.

A confirmed A4000 user told me that after fixing the blitwait code to

    btst #6,0xdff002
bw:    btst #6,0xdff002
       bne.s bw

the graphical errors were gone on Highway Hawks (and no more complains on Crazy Cars III either). So I suppose that there are more machines with this blitter issues than the old Amiga 1000

[Thomas Richter]

Originally Posted by 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.

Many many drawbacks with this flag. Note that the CPU will also no longer be available for interrupts if the blitter nasty flag is on as the autovectors are by default in chip mem. Avoid this flag, it may have unforeseen consequences.

[Toni Wilen]

Originally Posted by Thomas Richter

Many many drawbacks with this flag. Note that the CPU will also no longer be available for interrupts if the blitter nasty flag is on as the autovectors are by default in chip mem. Avoid this flag, it may have unforeseen consequences.

Both have drawbacks.

Blitter only takes all DMA slots if used channel combination uses all cycles (no idle cycles). Most combinations have idle cycles.

When combined with idle cycles, if CPU steals blitter's idle cycle (because nasty was not enabled), blitter loses the cycle. With nasty on, both blitter and CPU would have "used" the cycle. This can make noticeably performance difference (which is very important in demos).

And finally, as was recently noticed, A1000 Agnus is broken and in some situations copper blit wait fails to work correctly if nasty is not on.

Please stop looking through system friendly/OS colored classes all the time

[Toni Wilen]

Originally Posted by jotd

A confirmed A4000 user told me that after fixing the blitwait code to

I think this is more likely caused by CPU starting the DMACONR read before BLTSIZE write started. Was BLTSIZE immediately before DMACONR read and was it 68060?

[Toni Wilen]

(I still don't understand all the details yet, so "official" undocumented thread post needs to wait)

Almost solved mystery of Copper WAIT with blitter wait enabled sometimes not working and requiring two WAITs. (or even more if A1000)

It only happens if blitter nasty is not enabled. (Prove me wrong if possible!)

Background:

- It seems blitter is "inhibited" when CPU is allowed to steal blitter cycle (Gary /BLISS signal active and Agnus accepting it).
- CPU allowed to steal cycle from blitter logic is very simple. Gary enables /BLISS if CPU request chipset bus access and it has waited for at least 3 cycles. It does not need to be blitter cycle. Blitter does not even need to active.

When CPU writes to BLTSIZE, /BLISS is guaranteed not to be active (because CPU wrote to BLTSIZE which is in chipset bus) and blitter starts normally.

When Copper writes to BLTSIZE, /BLISS might be active at the same time (if CPU has already waited for few cycles due to bitplane or copper DMA). In this case BLTSIZE write still succeeds and blitter starts but it seems busy bit logic is inhibited (these is some latch that needs clocking?) and busy isn't set until inhibited status gets cleared. Unfortunately this can't be tested with CPU because CPU access would clear the "inhibited" state immediately.

Result is that in this situation following copper WAIT with blitter wait enabled might see cleared busy bit.

It is even worse with A1000 because busy bit gets set when blitter gets first DMA slot. This combined with "inhibited" status can mean blitter busy might not be set even if there are 2xWAITs.

[jotd]

I think this is more likely caused by CPU starting the DMACONR read before BLTSIZE write started. Was BLTSIZE immediately before DMACONR read and was it 68060?

it's reportedly 68040. And in both cases, blitwait is not right after BLTSIZE write

[Toni Wilen]

Originally Posted by jotd

it's reportedly 68040. And in both cases, blitwait is not right after BLTSIZE write

Hmm... I still can't believe it is DMACONR related but some weird 68040 board "feature". Do you have the previous slave that has the problem? I'd like to take a closer look.

[Wepl]

Many years ago I had problems with the initial decryption routine in Arkanoid. It uses the blitter with all channels and max bltsize. With nasty enabled I had reports that on some machines the machine locked up and required reset.
Maybe also a hardware problem but I try to avoid nasty where possible.

[jotd]

Toni I'll zone some installed Highway Hawks game with the old version. Maybe a cracked version would run from floppy on a A4000 but maybe not.

[Thomas Richter]

If the problem is with a 68040: Is this configured correctly? The custom chip memory area must, absolutely must be set to cache inhibit serialized. The 68040 has a "push queue" in which it stores outgoing memory calls, and it may delay the execution of this writes until the bus is idle. That is, after a blitter-write instruction, the blitter may not yet have seen this write because it is waiting in the push-queue of the 68040 to be executed. You can place a NOP after the write to ensure that the write is going out.

[jotd]

it's running under whdload. I hope that whdload does the proper initialization of the custom chips cache. I think that there would be more problems than blits if this area was misconfigured.

[hooverphonique]

Originally Posted by jotd

it's running under whdload. I hope that whdload does the proper initialization of the custom chips cache. I think that there would be more problems than blits if this area was misconfigured.

It's the job of the cpu library to set this up, not whdload, but depending on which library is used, maybe it isn't?

[jotd]

whdload takes over the system, including MMU. For instance, each attempt to write in a location that whdload hasn't declared as accessible results in an access fault (example: writing on DEF080 which "works" to set copperlist but it's not the official DFF080 address)