Blitter corruption in WinUAE

[jotd]

careful about

.\@        btst        #6,DMACONR
        bne.b        .\@

on some amigas, you need one more btst (before the loop for instance) or you could miss the busy bit (A1000 bug but also reported by non-A1000 owners)

(winuae doesn't have this problem)

BTW if you enable "blitter nasty", the "no loop" code probably only works from chipmem. From fastmem it just doesn't wait. So use a loop or a blitter interrupt chain.

[Photon]

Exactly, WinUAE doesn't have this problem.

[jotd]

one thing I have noted, though, is that "immediate blitter" allows to get rid of blitter issues (on broken programs) whereas "wait for blitter" doesn't seem to work properly.

I got blitter artifacts with "wait for blitter" which were fixed by "immediate blitter".

Personally I don't care, I only use "immediate blitter" to check that the artifacts are caused by the blitter (so I can fix them...) and not self-modifying code.

[Photon]

The problem with the original question is that it doesn't post the code run when emulation error is experienced. OP must provide code that fails and environment and error message or screenshot of error to have any chance of proceeding. A decade of blits, and post #22 has found a bug? I'd bet $1000000 against that.

Every word of the article quoted is correct and not only works on all Amigas but also works in WinUAE with default options, cycle exact on, and blitter wait on.

(I actually didn't notice he linked to Coppershade before I wrote my previous replies, since that is 'just' an online source.)

[Muzza]

Photon, you seem to have misunderstood the question.

It was about trying to find a bug in my code, not in WinUAE.
And thanks to a few helpful posts I did find it.

Posting source code of 70 C files and 30 ASM files would not have been helpful, hence the cut down pseudo-code version that I posted instead.

[Photon]

Originally Posted by Muzza

I'm getting blitter corruption from my code in WinUAE

Real Amigas seem to run ok.

It's just very unlikely that you should blame anything but your code.

Originally Posted by Muzza

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.

You mean, apart from the HRM and running your code on real Amigas, and all the examples here and everywhere else.

Originally Posted by Muzza

does the order that I set BLTxPTH/BLTCON0 matter too?

Thanks

Yes. Question answered. You're welcome.

Originally Posted by Muzza

Posting source code of 70 C files and 30 ASM files would not have been helpful, hence the cut down pseudo-code version that I posted instead.

100 sources can contain more than 100 incorrect blitwaits from ignoring correct blitwaits on 'websites you never heard of before', and also more than 100 examples of loading blitter registers in the incorrect order.

So this wouldn't have helped the simple question posed, you're correct. As I wrote, we need one piece of code that fails and some kind of description of how it's not functioning as you wish.

[Muzza]

Thanks Photon, I'll be sure to be more experienced before asking beginner questions in future.

For anyone else, the hardware manual appears to say that you must set BLTCON0 before BLTxDAT. But does not clearly say that BLTCON0 must be set before BLTxPTH that I have found.
I am setting BLTCON0 after BLTAPTH/BLTBPTH without problem on real and emulated Amigas, but of course if someone has a definitive answer on this, it would be useful to know.

[Photon]

Well, it was a dumb reply from a not so detailed question. We really need code and expected result and actual result. Even then we might not call into question the docs available and code that works.

Coding is a lesson in humility. You really question your own code first - even when you're experienced. And then when you're really experienced and there can be no error anywhere, you really question your own code before anything. And then when you've found the problem and reduced it to a single instruction that can't possibly fail, you still question your own code before anything. This is the lesson.

Here's the answer I should have written, perhaps.

Blitter corruption (whatever that is, we don't know cos you don't show), is caused by your code because WinUAE can't cause it.

But here's the thing: this might be a false statement, and I don't write those.

Because it IS possible that if you took a correct Blitter init and completely jumbled the order of statements, you could (maybe) provoke WinUAE into failing. It's extremely unlikely, but possible.

Coppershade has only 100% accurate descriptions and only 100% working code, or it's not on Coppershade. This is how tough it is to get published there, and I'm my own author!

So if you accept that WinUAE didn't corrupt your blits, and my blitwait didn't, and you show some code, and wrong result, and expected result, you will get excellent help in this, the best Amiga forum.

[Muzza]

Originally Posted by Photon

Well, it was a dumb reply from a not so detailed question. We really need code and expected result and actual result. Even then we might not call into question the docs available and code that works.

I asked two very specific questions in the post:

Originally Posted by Muzza

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?

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

The answers to these helped me narrow down and discover the bug myself.

You have imagined that I posted something completely different, where I 'blamed' WinUAE and then asked people to find the cause of blitter corruption. I did neither of these things.

[Photon]

Well, even shorter then:

1. When in doubt, check your code.
2. Coppershade, HRM, and WinUAE are correct.
3. Providing code and expected result will give you quick answers here.

The order of operation of the Blitter is provided in the HRM and on Coppershade. Correct code to initialize the Blitter is provided on Coppershade.

If you ask again here, please provide helpful information.

[alpine9000]

I did some unusual (incorrect?) blitter setup write ordering in a game I was working on in maybe 2017. It would work under WinUAE but would glitch on real hardware. I sent Toni the code and he changed WinUAE to “correctly” implement the blitter glitch.

[Toni Wilen]

Originally Posted by jotd

careful about

.\@        btst        #6,DMACONR
        bne.b        .\@

on some amigas, you need one more btst (before the loop for instance) or you could miss the busy bit (A1000 bug but also reported by non-A1000 owners)

(winuae doesn't have this problem)

BTW if you enable "blitter nasty", the "no loop" code probably only works from chipmem. From fastmem it just doesn't wait. So use a loop or a blitter interrupt chain.

I don't think it is possible to "miss" the busy bit because it is set immediately (if not A1000).

But there is another possibility, pre-AGA blitter busy bit goes low even when possible still pipelined D write (if D is enabled and not linedraw) is still pending. AGA fixes this. So bad things can happen if program immediately after wait loop does something that requires last D write being already written to chip RAM.

Anyway, as usual: test case needed that is tested using some basic unexpanded real hardware config. Expanded/fast CPU configurations can have weird hardware issues too... Usually "blitter problem" isn't really blitter problem but some other bad assumption.

did some unusual (incorrect?) blitter setup write ordering in a game I was working on in maybe 2017. It would work under WinUAE but would glitch on real hardware. I sent Toni the code and he changed WinUAE to “correctly” implement the blitter glitch.

This was undocumented behavior with shift register loading order/old contents from previous blit. (also HRM is not totally correct with BLTxDAT vs shift value setup order).

[Photon]

Originally Posted by Toni Wilen

I don't think it is possible to "miss" the busy bit because it is set immediately (if not A1000).

True.

Originally Posted by Toni Wilen

But there is another possibility, pre-AGA blitter busy bit goes low even when possible still pipelined D write (if D is enabled and not linedraw) is still pending. AGA fixes this. So bad things can happen if program immediately after wait loop does something that requires last D write being already written to chip RAM.

Extremely unlikely the case. Even on AGA/060 you would struggle to read a chipmem word before the pipeline clears. OP says Blitter corruption, so not bob collision detection.

Originally Posted by Toni Wilen

undocumented behavior with shift register loading order/old contents from previous blit. (also HRM is not totally correct with BLTxDAT vs shift value setup order).

The article linked in OP should address Blitter load order completely to avoid getting bugs. See also the cheat sheet based on HRM.

Originally Posted by Muzza

blitter corruption 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.

If code is bug free it should run on A500 cycle exact. All of my Blitter code new and 30 years old does.

Originally Posted by Muzza

Occasionally WinUAE outputs 'BLITTER write to DPT ignored!'

Which doesn't mean bugged code won't cause error messages in emu (debugger? not seen it)

Originally Posted by Muzza

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

Yes, order matters, data before shift if data used.

No, your bug is not due to setting BLTxPTH before or after BLTCON0 and 1 if data not used. But we haven't even seen a single blit yet, or even a screenshot of the corruption.

There are many knowledgeable coders here, so that we might spot the bug from blit code or screenshot.

[Muzza]

Photon, you are talking as though this is an open issue. If you read the thread you will see it was all resolved three weeks ago, within two hours of my asking the original questions.

Others were able to help me enough so that I found the problem in my code. This thread worked out great for me. And then you reopened it three weeks later seemingly just to make a few unpleasant digs.

I tried to put you on ignore after it became obvious you had constructed a strawman to argue with, but you're a moderator so I can't. Perhaps instead, you can put me on ignore? That way we don't have to waste any more time on this. This is a hobby project for me and I'd rather keep it as a positive experience - thanks.

[Photon]

That's when you stopped responding, yes...

So you made a sketchy question putting WinUAE/Coppershade/HRM into question, now you come back and got all these responses. I can understand your confusion how we would get all involved. It's about a full understanding, nothing to do with an individual question. Every possible thing - even bugs in hardware, documentation, and emulation - we want to know.

And so thread title even got Toni involved. He can answer for himself.

Now, I am Photon and I am a person. I take special pride in answering questions as asked, and writing only what can be supported by objective testing. So for me personally, your strawman accusation is false - I've tried my very best, it's your post lacking information. Avoid having to play at argumentation by simply providing code and expected result.

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

That version may fix it (on early A1000 hardware only, and doesn't explain any misbehavior in WinUAE at all, cycle exact or not) because it has a move to a custom register likely equal to a tst or btst of same before the wait loop.

Again Coppershade tries to provide only correct information. You didn't get that code from me. If you want a correct blitwait, it's right there on the page you linked in the OP. From your quote, if you had put that in your macro your code would have worked, removing the need for posting the question.