Blitter corruption in WinUAE

[Muzza]

Hi,

I'm getting blitter corruption from my code in WinUAE in certain setups.
I get it when emulating an A1200 with cpu_cycle_exact=true (but not false)
And sometimes emulating an A500 with cpu_cycle_exact=false (but not true!)
Real Amigas seem to run ok.

Occasionally WinUAE outputs 'BLITTER write to DPT ignored!' although this does not always match up with the corruption, so may not be related. Can anyone tell me what this message means?

I've checked and triple checked that I have a Wait Blitter before setting any BLT registers.
This website: http://coppershade.org/articles/AMIG...g_the_Blitter/ claims that the load order for the BLT registers is important, but it is the only source I've seen for this information.

Obviously you need to set BLTSIZE last to start the blit, but does the order that I set BLTxPTH/BLTCON0 matter too?

Thanks

[roondar]

Well, the info that the order matters is also in the HRM, though it's hidden quite well.

Originally Posted by hrm

Warning:

Be sure to load the blitter immediate data registers only after setting the shift count in BLTCON0/BLTCON1 , as loading the data registers first will lead to unpredictable results. For instance, if the last person left BSHIFT to be "4", and I load BDATA with "1" and then change BSHIFT to "2", the resulting BDATA that is used is "1<<4", not 1<<2". The act of loading one of the data registers "draws" the data through the machine and shifts it.

To be fair though, I can't immediately find anything about BLTxPTL/H and BLTCON order mattering.

[ross]

Originally Posted by Muzza

I'm getting blitter corruption from my code in WinUAE in certain setups.

Which version of WinUAE?

[Muzza]

Originally Posted by ross

Which version of WinUAE?

4.4.0 (latest I believe)

[Muzza]

Originally Posted by roondar

Well, the info that the order matters is also in the HRM, though it's hidden quite well.

To be fair though, I can't immediately find anything about BLTxPTL/H and BLTCON order mattering.

Doh, I can never find things in the HRM, thanks for pointing me to it, although it does read as though it applies to BLTxDAT which I'm not currently using.

[roondar]

Originally Posted by Muzza

Doh, I can never find things in the HRM, thanks for pointing me to it, although it does read as though it applies to BLTxDAT which I'm not currently using.

It helps that I actually remembered that it was in there and roughly where

[ross]

Originally Posted by Muzza

4.4.0 (latest I believe)

I asked you because maybe you were using the latest beta.
Is the error always replicable and can you provide an executable?

[roondar]

Originally Posted by ross

I asked you because maybe you were using the latest beta.
Is the error always replicable and can you provide an executable?

Perhaps the Blitter source code might also provide some insights. Haven't had anything similar happen myself, so it would be interesting to see if we can't find a problem/difference from the 'standard'.

[ross]

Originally Posted by roondar

Perhaps the Blitter source code might also provide some insights. Haven't had anything similar happen myself, so it would be interesting to see if we can't find a problem/difference from the 'standard'.

I noticed that very often the problem is not directly related to the code that users post, but to the environment and the exe..

[roondar]

Quite true!
But I still think the Blitter code can be of some small use.

[ross]

Originally Posted by roondar

Quite true!
But I still think the Blitter code can be of some small use.

Well, both then

[Muzza]

Before I look to post exe/code (that may need some cleanup work) I'm just trying a few more things.

I've just discovered something. In some cases I set up the BLT registers and then do multiple blits where only BLTAPTH, BLTDPTH change between each BLTSIZE.
If I also set BLTDMOD per blit (even though it does not change value), then it seems to solve at least one instance of corruption.

Is this a register that gets modified by the system and needs resetting before every blit?

EDIT: actually I think all that is happening is that the extra command just lets the blitter finish its last operation before the next one. It must be a problem with my BLITTER_WAIT

[Muzza]

It was my WAIT_BLITTER macro. At some point in the past I'd changed it from a conventional wait loop to one that enabled blitter nasty.

I can't find exactly where I got it from (it has comments next to it that are definitely not from me, so I must have copied it from somewhere!)
It is similar to the ones posted here http://eab.abime.net/showthread.php?t=94332

Broken version was:

WAIT_BLITTER:    MACRO
        move.w        #$8400,DMACON    ; Enable bit 10 : BLTPRI (BLITTER NASTY) - gives blitter priority over 68k
        tst.w        DMACONR
        tst.w        DMACONR
        move.w        #$0400,DMACON    ; Disable BLTPRI
        ENDM

This version fixes it:

WAIT_BLITTER:    MACRO
        move.w        #$8400,DMACON
.\@        btst        #6,DMACONR
        bne.b        .\@  
        move.w        #$0400,DMACON
        ENDM

[roondar]

So it seems the Blitter Waits in that thread didn't end up working after all. Good to know, even though I've not used them apart from that little test back then.

The second macro you show is very similar (as in, basically identical except for naming conventions) to what I actually use in my own code, it should be fine.

[Muzza]

Related to this, if I have a tight loop of several blits in a row, which of these versions is better?

WAIT_BLITTER:    MACRO
        move.w        #$8400,DMACON    ; Enable BLTPRI
.\@        btst        #6,DMACONR
        bne.b        .\@  
        move.w        #$0400,DMACON    ; Disable BLTPRI
        ENDM

ENABLE_BLITTER_NASTY: MACRO
        move.w        #$8400,DMACON
        ENDM

DISABLE_BLITTER_NASTY: MACRO
        move.w        #$0400,DMACON    ; Disable BLTPRI
        ENDM

WAIT_BLITTER2:    MACRO
.\@        btst        #6,DMACONR
        bne.b        .\@  
         ENDM


; version 1
WAIT_BLITTER
Set common BLT registers

loop:
   read one word from RAM

    set BLTAPTH,BLTDPTH,BLTSIZE
   if not done:
       WAIT_BLITTER
        goto loop




; version 2
ENABLE_BLITTER_NASTY
WAIT_BLITTER2
Set common BLT registers

 loop:
   read one word from RAM

    set BLTAPTH,BLTDPTH,BLTSIZE
   if not done:
       WAIT_BLITTER2
         goto loop


 DISABLE_BLITTER_NASTY

Version 2 is modified so it only turns blitter nasty on and off once. Will the blitter still steal DMA cycles from the CPU if it has no work to do?

[ross]

This is interesting, because real amiga did not give problems.
You should try the code with the new blitter emulation engine in WinUAE 4.5 (when fully completed).
Anyway yes, that code was for testing only and not to be used in a real environment!

[roondar]

Originally Posted by Muzza

Related to this, if I have a tight loop of several blits in a row, which of these versions is better?

Version 2 is modified so it only turns blitter nasty on and off once. Will the blitter still steal DMA cycles from the CPU if it has no work to do?

Version one will do ever so slightly better. This is because the code that determines whether to wait or not can run while the Blitter is running and CPU+Blitter interleaving is overall faster than CPU or Blitter having bus exclusively in turns. The reason that CPU+Blitter is faster is that the CPU has idle cycles in which it doesn't access the bus at all, during which the Blitter can do useful work.
(Note, this is obviously only true if the CPU has something useful to do. If it's waiting on the Blitter or waiting on anything else, it's not being usefull )

A small tip here is that most Blitter routines work best if they are ordered like this:

 Loop:

   <do stuff/grab variables from RAM>
    WAITBLITTER
    <setup blitter and start blitting>

   go to Loop

The reason is the same, you want the CPU to do as much useful work as possible while the Blitter is running because this is more efficient than the CPU working while there is nothing else on the bus.

[Toni Wilen]

What was the actual code? (Blitter setup before the wait) That kind of "wait" should work if blitter steals all cpu cycles but it isn't really good idea because non-cycle accurate emulation or reimplemention/etc that targets performance (like having enough bandwidth to allow both CPU and chipset run at the same time) would not work very well..

Anyway, that message means blitter pointer register was CPU written immediately before blitter used same pointer for DMA read/write. Write goes nowhere in this situation. All DMA pointer registers have same limitation.

[Muzza]

Originally Posted by Toni Wilen

What was the actual code? (Blitter setup before the wait) That kind of "wait" should work if blitter steals all cpu cycles but it isn't really good idea because non-cycle accurate emulation or reimplemention/etc that targets performance (like having enough bandwidth to allow both CPU and chipset run at the same time) would not work very well..

I've tried to extract the relevant code here.
Looking at it simplified like this (the real code is a lot longer) I think perhaps I'm making a performance mistake. There may be zero to eight blits happening in this pseudo code. I set certain non-changing blitter registers in advance to avoid setting them up to 8 times later on, but of course that means I have to put my WAIT_BLITTER earlier than I would have to otherwise.
Possibly it is better to just set BLTCON0/1, BLTAF/LWM, BLTAMOD & BLTDMOD every time and not do the first WAIT_BLITTER so early.

; one time setup of some blitter registers
; in advance of several blits to come

WAIT_BLITTER
move.l            #$09f00000,BLTCON0 ; A->D
move.l            #$ffffffff,BLTAFWM
move.w            #0,BLTAMOD

.loop2:

... work ...

WAIT_BLITTER
move.w          #CONSTANT,BLTDMOD

.loop1:
... calc new a4 ...
move.l         a4,BLTAPTH
move.l         a0,BLTDPTH
move.w       #CONSTANT,BLTSIZE

if not done1 then: increment a0, WAIT_BLITTER, bra .loop1

if not done2 then: bra .loop2

Originally Posted by Toni Wilen

Anyway, that message means blitter pointer register was CPU written immediately before blitter used same pointer for DMA read/write. Write goes nowhere in this situation. All DMA pointer registers have same limitation.

If I understand correctly, surely the only way that could be happening is if WAIT_BLITTER was not doing its job correctly?

[Photon]

Originally Posted by Muzza

Hi,

I'm getting blitter corruption from my code in WinUAE in certain setups.
I get it when emulating an A1200 with cpu_cycle_exact=true (but not false)
And sometimes emulating an A500 with cpu_cycle_exact=false (but not true!)
Real Amigas seem to run ok.

Occasionally WinUAE outputs 'BLITTER write to DPT ignored!' although this does not always match up with the corruption, so may not be related. Can anyone tell me what this message means?

I've checked and triple checked that I have a Wait Blitter before setting any BLT registers.
This website: http://coppershade.org/articles/AMIG...g_the_Blitter/ claims that the load order for the BLT registers is important, but it is the only source I've seen for this information.

Obviously you need to set BLTSIZE last to start the blit, but does the order that I set BLTxPTH/BLTCON0 matter too?

Thanks

Yes. A decade in, I would blame code, not WinUAE.

And looking quickly, it seems that actually waiting for the Blitter fixes the problem. Am I wrong?