Sprite corruption with OCS Agnus, ECS Denise, Kickstart 3.1

[mark_k]

While playing around with various settings, I noticed that with OCS Agnus, ECS Denise and Kickstart 3.1 the mouse pointer sprite is corrupted (lots of garbage below it). And if you move the pointer down near the bottom of the screen, it vanishes and reappears near the top. There's also a line of garbage below the bottom row of the Workbench screen. That happens with WinUAE 2.8.0 and later, not 2.7.0. With Kickstart 1.3 the pointer isn't corrupted.

I'm guessing that corruption would actually happen with real hardware, but thought I'd mention it just in case it doesn't.

[Toni Wilen]

It is nearly exactly right. (Bottom line and sprite corruption mostly)

Copper list is different in OCS vs ECS Agnus modes and system assumes ECS Agnus if ECS Denise is detected.

ECS copper list has following lines

00000440: 008e 0181 [000 024] ; DIWSTRT := 0x0181
00000444: 0090 0281 [000 028] ; DIWSTOP := 0x0281
00000448: 01e4 0000 [000 02c] ; DIWHIGH := 0x0000
0000044c: 0092 0018 [000 030] ; DDFSTRT := 0x0018
00000450: 0094 0020 [000 034] ; DDFSTOP := 0x0020

I have no idea why, perhaps workaround for some chip revision bug. (Bitplane DMA enabled for few fetches from line 1 to 2..)

Because OCS Agnus does not have DIWHIGH, DIWSTOP becomes $102 = vertical display window stays open.

When DMA attempts to fetch sprite 0 SPR and CTL words, CTL can't be fetched because bitplane DMA is active with max overscan and OCS Agnus has recently emulated "sprite dma vs bitplane dma off by one" bug.

-> mouse pointer CTL is not fetched, sprite pointer gets "unaligned" (CTL data goes to DATA, first word that was supposed to go to DATA goes to DATB and so on) -> sprite is start position is correct (CTL) but data is corrupted.

Screen start position changes because DIW is already open (due to above copper instructions), starts when BPLCON0 is written at line $2a (actually display starts next line, $2b, due to yet another OCS Agnus feature), not when DIWSTRT is set to ($2c).

Interesting side-effects!

Only unexplained part is how sprite still stops at (mostly) correct position on real hardware instead of staying active until end of display or so. Logic analyzer testing soon.

[mark_k]

Thanks for the explanation.

Over in the Undocumented Amiga hardware stuff thread you wrote:

Last line of field works normally if A1000 Agnus. If later revision: last line inhibits both sprite and bitplane DMA. (This explains above demo's different OCS vs A1000 Agnus behavior)

That got me thinking, with A1000 Agnus maybe you can set overscan prefs to maximum height and not have the bottom line (or two for interlaced modes) of the WB screen blank/missing.

(These tests with Kickstart 3.1, PAL vertical overscan set to maximum.)
With OCS A1000 Agnus & OCS Denise: bottom line of WB screen is blank. There is a second blank line below that. [Same as with OCS Fat Agnus + ECS Denise.]

With OCS A1000 Agnus & ECS Denise: bottom line of WB screen is visible. Below that is a garbage line then an all-blank line. If you drag the WB screen down, it vanishes when you get within ~40 lines of the lowest position, reappearing as you drag back up. (I guess apart from the bottom line being visible, the other issues are due to Kickstart 3.1 assuming full ECS.)

Contrary to what I expected, in order for the bottom line of the WB screen to not be blank with A1000 Agnus, you have to configure ECS Denise, not OCS. Same as real hardware?

[Toni Wilen]

Hmm, need to check OS copperlist..

My last test was copperlist (with system taken over) that set as high as possible bitplane and changed last line's background color and last line also had visible bitplane graphics.

[Toni Wilen]

Everything is fine after all

Previous WB tests are incorrect, if no ECS Denise, last visible line is always 310, not 311. (copper waits for start of line 311 and then zeroes BPLCON0 = line 311 is blank).

If ECS Denise (or AGA): last visible line is really 311. Complete WB overscan is visible.

(Why this difference? I don't know). EDIT: "difference" as in different copper lists created by OS3.1 depending on Denise type. Hardware limits of course are still the same.

Line 312 is always blanked line if non-A1000 Agnus and this is outside of WB overscan area. (if long field mode)

[potato]

Toni, you are a genius.EOF

[Toni Wilen]

Perhaps..

Now emulation matches real OCS Agnus + ECS Denise sprite corruption correctly. Actually sprite didn't vertically stop, rest of the memory space was simply cleared (different config, used ACA500 for KS3.1, faster than ROM swap), disabling all fast RAM caused similar long corrupted sprite. (I didn't follow my own guidelines: always use exact same config..)

Only emulation bug was sprite "disarm" state, it is only disarmed by first DMA write to CTL (writing to CTL = disarm), I originally thought it will get disarmed by either DMA write (There was other sprite related bug that prevented this to work exactly right)

Because CTL write can't happen (bitplane DMA slot steals it), mouse cursor sprite becomes fullscreen 16 pixel wide vertical stripe with semi-random contents.

[phx]

Originally Posted by Toni Wilen

Only emulation bug was sprite "disarm" state, it is only disarmed by first DMA write to CTL (writing to CTL = disarm), I originally thought it will get disarmed by either DMA write (There was other sprite related bug that prevented this to work exactly right)

Which WinUAE version fixes that?

I got the following screen shot from one of my beta testers, using WinUAE 3.0.0. It shows sprite corruptions which are not visible on any real Amiga I tested (A500, A1200, A3000):


I remember we already talked about these sprite corruptions some weeks ago and you told me that the latest UAE version fixes it. Does my tester have to update the 3.0.0 version or is the problem still present?

Just contact me if you need an ADF image to reproduce the problem.

[Toni Wilen]

OCS only?

OCS Agnus (and A1000 Agnus) has undocumented feature (or bug) that causes bitplane DMA to steal sprite's second word dma slot even if bitplane DMA only needs following slot. ECS Agnus fixes it.

[phx]

Originally Posted by Toni Wilen

OCS only?

I will ask my tester. It's quite likely he is using an A500-OCS configuration.

OCS Agnus (or A1000 Agnus) has undocumented feature (or bug) that causes bitplane DMA to steal sprite's second word dma slot even if bitplane DMA only needs following slot. ECS Agnus fixes it.

Oh... so it might be a "real" problem?

Does only the A1000 use an OCS Agnus? This would explain I haven't seen it on real hardware. I could check my A1000, but it has not enough memory to run the game (1 MB required).

[Toni Wilen]

Originally Posted by phx

I will ask my tester. It's quite likely he is using an A500-OCS configuration.

Oh... so it might be a "real" problem?

Does only the A1000 use an OCS Agnus? This would explain I haven't seen it on real hardware. I could check my A1000, but it has not enough memory to run the game (1 MB required).

Both A1000 and Fat OCS Agnus have same bug, 8372A and later versions don't have it. This also was not emulated until recently. (2.7)

Examples: http://eab.abime.net/showthread.php?t=75094 http://eab.abime.net/showpost.php?p=...&postcount=686

[phx]

Originally Posted by Toni Wilen

Both A1000 and Fat OCS Agnus have same bug, 8372A and later versions don't have it. This also was not emulated until recently. (2.7)

OMG! I will see if I find an A500 with 8371 Agnus.

When this is true, then I have a problem. Is there any known workaround how to fix that (besides changing DDFSTRT to kill hardware scrolling or making the display window smaller)?

[phx]

Confirmed! WinUAE emulates the A1000-Agnus (8367?) and the 8370/8371 perfectly! I have seen exactly the same sprite corruptions on my A1000, after adapting a test program for 512K.

Now I have a big problem. Without these sprite tricks I cannot hold the frame rate in my game...

[Toni Wilen]

If you only need single 1 plane sprite or normal sprite with static data in DATB, just rewrite it once with CPU or copper. Updating DATB with copper every line also works but it may not be worth the trouble anymore..

[phx]

Originally Posted by Toni Wilen

OCS Agnus (and A1000 Agnus) has undocumented feature (or bug) that causes bitplane DMA to steal sprite's second word dma slot even if bitplane DMA only needs following slot.

Maybe this is getting off-topic and too technical now, but: which sprite's DMA slot is affected? It certainly is not any sprite in any situation?

In my game I have DDFSTRT=$30, wiping out sprite 7's DMA slot, so I'm loading SPR7DATA/B with the copper. And I see the corruption of SPR6DATB. Sprite 6 is a normal DMA sprite, with some horizontal position changes (SPR6POS) over the screen.

Originally Posted by Toni Wilen

If you only need single 1 plane sprite or normal sprite with static data in DATB, just rewrite it once with CPU or copper. Updating DATB with copper every line also works but it may not be worth the trouble anymore..

Sprite 6 needs both planes. So I might load it with the copper each line, like I already do with sprite 7.

[Toni Wilen]

Originally Posted by phx

Maybe this is getting off-topic and too technical now, but: which sprite's DMA slot is affected? It certainly is not any sprite in any situation?

Nothing is too technical!
I'll move posts later if it looks too off-topic.

In my game I have DDFSTRT=$30, wiping out sprite 7's DMA slot, so I'm loading SPR7DATA/B with the copper. And I see the corruption of SPR6DATB. Sprite 6 is a normal DMA sprite, with some horizontal position changes (SPR6POS) over the screen.

Sprite DMA slot located at cycle DDFSTRT-1 gets stolen by (nonexisting) bitplane DMA if OCS Agnus. It is always second sprite slot: CTL or DATB load.

Sprite 6 needs both planes. So I might load it with the copper each line, like I already do with sprite 7.

Ok, fastest solution is to let DMA load DATA and only use copper to load DATB, saves 1 cycle (1 sprite cycle and 2 copper cycles vs 4 copper cycles)

If sprite only appears once, you also don't need to use copper to load POS and CTL, just make sure line 25 has larger DDFSTRT.

[phx]

Originally Posted by Toni Wilen

Sprite DMA slot located at cycle DDFSTRT-1 gets stolen by (nonexisting) bitplane DMA if OCS Agnus. It is always second sprite slot: CTL or DATB load.

Understood. That make sense. DDFSTRT-1 wipes out the second DMA slot of sprite 6 in my case.

And with a normal DDFSTRT of $38, sprite 7's second DMA slot would be unusable? This means an OCS-Agnus system has always a problem with the last sprite? I never realized that before...

If sprite only appears once, you also don't need to use copper to load POS and CTL, just make sure line 25 has larger DDFSTRT.

Er... what is so special about (raster) line 25? SPR6PT is loaded at VERTB, so I would expect SPR6POS and SPR6CTL to be loaded by the DMA immediately during the next raster line (0 or 1?).

[Toni Wilen]

Originally Posted by phx

Understood. That make sense. DDFSTRT-1 wipes out the second DMA slot of sprite 6 in my case.

And with a normal DDFSTRT of $38, sprite 7's second DMA slot would be unusable? This means an OCS-Agnus system has always a problem with the last sprite? I never realized that before...

$38 is fine. $34 would break sprite 7.

Er... what is so special about (raster) line 25? SPR6PT is loaded at VERTB, so I would expect SPR6POS and SPR6CTL to be loaded by the DMA immediately during the next raster line (0 or 1?).

Sprite DMA is always inactive until line 25 (PAL) or 20 (NTSC).

[phx]

Originally Posted by Toni Wilen

$38 is fine. $34 would break sprite 7.

Ok. By looking at the DMA table in the HRM this becomes quite clear.

Sprite DMA is always inactive until line 25 (PAL) or 20 (NTSC).

This is completely new to me. Thanks!