English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 08 February 2021, 22:55   #1
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 26
Blitter corruption in WinUAE

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
Muzza is offline  
Old 08 February 2021, 23:02   #2
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,756
Well, the info that the order matters is also in the HRM, though it's hidden quite well.
Quote:
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.
roondar is offline  
Old 08 February 2021, 23:14   #3
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,213
Quote:
Originally Posted by Muzza View Post
I'm getting blitter corruption from my code in WinUAE in certain setups.
Which version of WinUAE?
ross is offline  
Old 08 February 2021, 23:16   #4
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 26
Quote:
Originally Posted by ross View Post
Which version of WinUAE?

4.4.0 (latest I believe)
Muzza is offline  
Old 08 February 2021, 23:19   #5
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 26
Quote:
Originally Posted by roondar View Post
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.
Muzza is offline  
Old 08 February 2021, 23:21   #6
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,756
Quote:
Originally Posted by Muzza View Post
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
roondar is offline  
Old 08 February 2021, 23:22   #7
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,213
Quote:
Originally Posted by Muzza View Post
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?
ross is offline  
Old 08 February 2021, 23:24   #8
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,756
Quote:
Originally Posted by ross View Post
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'.
roondar is offline  
Old 08 February 2021, 23:32   #9
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,213
Quote:
Originally Posted by roondar View Post
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..
ross is offline  
Old 08 February 2021, 23:33   #10
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,756
Quite true!
But I still think the Blitter code can be of some small use.
roondar is offline  
Old 08 February 2021, 23:35   #11
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,213
Quote:
Originally Posted by roondar View Post
Quite true!
But I still think the Blitter code can be of some small use.
Well, both then
ross is offline  
Old 09 February 2021, 00:02   #12
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 26
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

Last edited by Muzza; 09 February 2021 at 00:08.
Muzza is offline  
Old 09 February 2021, 00:37   #13
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 26
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:
Code:
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:
Code:
WAIT_BLITTER:    MACRO
        move.w        #$8400,DMACON
.\@        btst        #6,DMACONR
        bne.b        .\@  
        move.w        #$0400,DMACON
        ENDM
Muzza is offline  
Old 09 February 2021, 00:46   #14
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,756
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.
roondar is offline  
Old 09 February 2021, 01:00   #15
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 26
Related to this, if I have a tight loop of several blits in a row, which of these versions is better?

Code:
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?
Muzza is offline  
Old 09 February 2021, 01:00   #16
ross
Defendit numerus

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 50
Posts: 3,213
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!
ross is offline  
Old 09 February 2021, 10:29   #17
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 2,756
Quote:
Originally Posted by Muzza View Post
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:
Code:
 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.
roondar is offline  
Old 09 February 2021, 16:50   #18
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 46
Posts: 24,699
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.
Toni Wilen is offline  
Old 09 February 2021, 22:13   #19
Muzza
Registered User

 
Join Date: Sep 2019
Location: Sydney
Posts: 26
Quote:
Originally Posted by Toni Wilen View Post
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.

Code:
; 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
Quote:
Originally Posted by Toni Wilen View Post
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?
Muzza is offline  
Old 26 February 2021, 21:26   #20
Photon
Moderator

Photon's Avatar
 
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 4,953
Quote:
Originally Posted by Muzza View Post
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?

Last edited by Photon; 26 February 2021 at 21:32.
Photon is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Winuae monitor 1920x1080 with immediate blitter White support.WinUAE 4 22 January 2020 13:06
demo bug with Winuae 4.2.1 - scroller corruption SaphirJD support.WinUAE 13 02 July 2019 18:00
TVPaint corruption under WinUAE ral-clan support.WinUAE 25 07 August 2017 17:16
Jaguar XJ220 GFX Corruption in winuae SexyWayne support.Games 5 02 January 2005 12:43
WinUAE graphic corruption? Critter support.WinUAE 13 08 February 2004 14:13

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 04:01.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, vBulletin Solutions Inc.
Page generated in 0.09539 seconds with 13 queries