Strange behavior when using blit queue in copper list

[ross]

Originally Posted by Wrangler

@ross: Hi - just tested both of those adfs on a real A500 (OCS) and they both work fine, no glitches.

Thanks!

Bye,
ross

[losso]

Same on ECS Agnus here with ross' versions.

I have started to build a minimal example to reproduce this and tried to rule out other factors one-by-one: the copperlist was unbuffered, waiting until mid-screen before the blit queue, double-checking interrupt handler, check if I introduced a bug into the framework etc. -- so far with no success.

Since I have brought back some other fails-on-hardware bugs to fix from Revision (probably unrelated, though), it might take some time until I can get back to this.

Thanks for all your efforts on pinning this down so far!

[alpine9000]

Originally Posted by losso

Same on ECS Agnus here with ross' versions.

I have started to build a minimal example to reproduce this and tried to rule out other factors one-by-one: the copperlist was unbuffered, waiting until mid-screen before the blit queue, double-checking interrupt handler, check if I introduced a bug into the framework etc. -- so far with no success.

Since I have brought back some other fails-on-hardware bugs to fix from Revision (probably unrelated, though), it might take some time until I can get back to this.

Thanks for all your efforts on pinning this down so far!

I've just fixed some nasty fails on real hardware bugs in a game I'm working on. Maybe we should start a thread to document the pitfalls as we find them to help people avoid our mistakes in the future.

[ross]

Originally Posted by alpine9000

I've just fixed some nasty fails on real hardware bugs in a game I'm working on. Maybe we should start a thread to document the pitfalls as we find them to help people avoid our mistakes in the future.

Take me as interested

[Toni Wilen]

Only if test program exists that confirms it. It must not be some boring theory without proof (seen those too many times..) or "just to be safe, do this"

[alpine9000]

Originally Posted by Toni Wilen

Only if test program exists that confirms it. It must not be some boring theory without proof (seen those too many times..) or "just to be safe, do this"

I'm my case they were just bugs that for whatever reason didnt manifest ever under emulation.

For example I was poking the bitplane pointers in a copper list in a non synchronised way which I'm guessing meant that every now and then on real hardware left them in an invalid state when they were latched?

Timing on real hardware was everything, an unrelated change would change the timing and mask the bug.

In the end I disabled th copper DMA before patching and that seemed to fix it.

[Toni Wilen]

You probably hit the chipset feature where write to DMA pointer register does nothing if next cycle is same DMA channel's data read/write cycle. (Most emulation modes do not emulate this because wrong CPU timing, especially if not 68000, can break situations which work in real hardware)

This is why real world test case is needed. To find and confirm the exact root cause and to test if it is hardware revision specific.

[alpine9000]

Originally Posted by Toni Wilen

You probably hit the chipset feature where write to DMA pointer register does nothing if next cycle is same DMA channel's data read/write cycle. (Most emulation modes do not emulate this because wrong CPU timing, especially if not 68000, can break situations which work in real hardware)

This is why real world test case is needed. To find and confirm the exact root cause and to test if it is hardware revision specific.

I can try and check out an old version of my game that had this bug. Problem is, the bad effect was very intermittent, but I was able to reproduce it on an a500 and a1200.

I had a blitter issue that was 100% reproducible on real hardware and perfect under emulation so I can try and resurrect that if you're interested.

[Toni Wilen]

Originally Posted by alpine9000

I can try and check out an old version of my game that had this bug. Problem is, the bad effect was very intermittent, but I was able to reproduce it on an a500 and a1200.

These are annoying but if it happens in real a500: try to create simple test case (does not need to be really simple but all "useless extra" removed)

I had a blitter issue that was 100% reproducible on real hardware and perfect under emulation so I can try and resurrect that if you're interested.

Yes please, this is the only way to document and emulate these properly. (Unless it is writing to BLTCON0/1 after blitter has been started..)

[alpine9000]

Originally Posted by Toni Wilen

These are annoying but if it happens in real a500: try to create simple test case (does not need to be really simple but all "useless extra" removed)



Yes please, this is the only way to document and emulate these properly. (Unless it is writing to BLTCON0/1 after blitter has been started..)

I emailed you the buggy version of the game.

[Toni Wilen]

Originally Posted by alpine9000

I had a blitter issue that was 100% reproducible on real hardware and perfect under emulation so I can try and resurrect that if you're interested.

Fixed.

Blitter ADAT and BDAT (BDAT in this program) writes in non-DMA mode didn't shift in old value (if shift was non-zero). Old data from last blit corrupted the font writer's mask data. No corruption if old data was zero.

Previous blit used B-channel, next blit had B-channel disabled but it was part of used minterm, BLTBDAT was properly set by CPU write but if shift was non-zero, old data was shifted in to final "B hold" value.

It seems "old" data ("A old" and "B old" in HRM) is automatically cleared only if channel is enabled when writing to BLTSIZE.

EDIT: Only B channel "remembers" old value. "A old" is always cleared.

[Photon]

There are multiple separate issues here. But I could address some questions about loading the Blitter registers correctly.

1. Blitwait must be before every blit. Only if you need to rely on the result of the blit for the CPU, or if you plan to disable Blitter DMA, should you wait after the blit. Examples: bob collision detection (BZERO) or joint rendering into the same buffer (BLTDPTx) by the blitter and the CPU.

2. To support early A1000 Blitter chips, the documentation says to read twice before the CPU can rely on the value. Copper blits need only to perform one blit wait and nothing else. Blitter interrupts are triggered by BBUSY and so need no wait.

3. Register load order: There are only 4 important registers: BLTCONx, BLTxDAT, BLTAxWM, and BLTSIZE. This is the normal load order, all other registers can be set in any order after this. BLTSIZE starts the blit and obviously should be last.

BLTxDAT will be shifted immediately upon the write to the corresponding BLTCONx, do this instead if that's what you desire.

BLTADAT must be set before BLTAxWM for BLTADAT to be masked.

[Toni Wilen]

Originally Posted by Photon

BLTxDAT will be shifted immediately upon the write to the corresponding BLTCONx, do this instead if that's what you desire.

BLTADAT must be set before BLTAxWM for BLTADAT to be masked.

No. HRM is wrong, it is probably (too) simplified explanation.

BLTADAT does not shift immediately or mask immediately. Only BDAT does immediate shifting. It most likely does not work like BDAT because mask is dynamic, first and last word mask is different than middle words and shifting is done after masking.

[Photon]

Hm, sorry for muddling matters by replying in the Undocumented Hardware Features thread at about the same time.

I just took the general meaning of the problems and replies in this thread and wanted to minimize confusion. These are just the simplest rules I've found that lets a coder write or debug a blit routine and be sure that it's correct. (There's a short article on Coppershade, but it's not as simplified.)

[Toni Wilen]

Yeah but this thread is not beginner stuff so everything should be 100% accurate

[Photon]

I have to disagree. I'm addressing intent, and you're addressing hardware implementation/emulation accuracy. Two sides of the same coin, yet worlds apart. Ends of a spectrum.

The chips stay the same and do what you tell them, so it's about 100000 times more likely (rough estimate) that the coders are writing code that doesn't express their intent.

HRM is certainly accurate and complete enough to allow a relatively experienced hardware programmer (whether new to Amiga or not) to code a Copper list that blits, and a font writer is beginner stuff and the code worked and you fixed the emulation.

I have to wag my finger and say "tsk, tsk!" at that you say you don't like "better do this just to be safe", but then suggest changing the order of register writes for no good reason and haven't protested against "try this" things such as waiting an extra line, double blit waits in Copper lists, etc. (Which I'm quick to do now! )

I normally refuse to help if no code is posted, but I still wanted to help.

Now I used my rules and they ruled out the blits, and on the HRM page I linked it says that the blitter WAIT is a normal WAIT with an AND condition provided by bit 15. HPOS below $07 as you know is on the previous line and will fail >= comparisons on the raster.

$0001,$0000 is not a correct WAIT instruction, and $0007,$7ffe is a correct Copper Blit WAIT.

[ross]

Originally Posted by Photon

$0001,$0000 is not a correct WAIT instruction, and $0007,$7ffe is a correct Copper Blit WAIT.

Well, technically $0001,$0000 is a valid WAIT instruction that.. do not wait beam position but blitter
Actually $0001,$8000 can be used to make delay of exactly 6CCK in copper list (like $01fe,$0000 for 4CCK).
Call them if you want CNOP6 and CNOP4.

[Toni Wilen]

Originally Posted by Photon

I have to disagree. I'm addressing intent, and you're addressing hardware implementation/emulation accuracy. Two sides of the same coin, yet worlds apart. Ends of a spectrum.

Perhaps..

I always want everyone (not just me) to also know exactly WHY something happens when I do this and that instead of blindly following some guides or HRM and possibly even refusing to attempt something crazy which hopefully does something unexpected, then it is time to try to find out why.

Demo coders are supposed to make crazy things

[Photon]

So now they can do crazy things with a correct blit wait that doesn't waste a scanline per blit.

[dissident]

Originally Posted by Photon

2. To support early A1000 Blitter chips, the documentation says to read twice before the CPU can rely on the value. Copper blits need only to perform one blit wait and nothing else. Blitter interrupts are triggered by BBUSY and so need no wait.

Are you really sure this only applies to the CPU? What happens, if we've got a lores display with 5 or 6 planes or a hires display with 3 or 4 planes and additionally all sprite channels are used? It would not make sense, if the blitter on the A1000 would always catch the first memory cycle, because bitplane DMA has always priority over the copper and the blitter in that order. The copper also needs in these cases two $0001,$0000 waitblits to be sure that the blitter is finished.

@Toni: Could you confirm this behaviour for these cases on the A1000?