English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 28 December 2014, 20:18   #1
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
Sprite corruption with OCS Agnus, ECS Denise, Kickstart 3.1

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.
Attached Thumbnails
Click image for larger version

Name:	OCSAgnusECSDenise.png
Views:	256
Size:	2.7 KB
ID:	42572  
Attached Files
File Type: zip OCSAgnusECSDenise_test.uae.zip (3.0 KB, 42 views)
mark_k is offline  
AdSense AdSense  
Old 29 December 2014, 14:00   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,512
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.
Toni Wilen is offline  
Old 29 December 2014, 17:59   #3
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,476
Thanks for the explanation.

Over in the Undocumented Amiga hardware stuff thread you wrote:
Quote:
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?
mark_k is offline  
Old 29 December 2014, 19:10   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,512
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 is offline  
Old 29 December 2014, 20:49   #5
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,512
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)

Last edited by Toni Wilen; 29 December 2014 at 21:45.
Toni Wilen is offline  
Old 29 December 2014, 21:43   #6
potato
Registered User

 
Join Date: May 2014
Location: uk
Posts: 24
Toni, you are a genius.EOF
potato is offline  
Old 30 December 2014, 10:10   #7
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,512
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.
Toni Wilen is offline  
Old 07 January 2015, 13:02   #8
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 983
Quote:
Originally Posted by Toni Wilen View Post
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):
Click image for larger version

Name:	winuae_v3.0.0.jpg
Views:	190
Size:	110.2 KB
ID:	42701

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.
phx is offline  
Old 07 January 2015, 13:16   #9
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,512
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.

Last edited by Toni Wilen; 07 January 2015 at 13:38. Reason: or -> and
Toni Wilen is offline  
Old 07 January 2015, 13:26   #10
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 983
Quote:
Originally Posted by Toni Wilen View Post
OCS only?
I will ask my tester. It's quite likely he is using an A500-OCS configuration.

Quote:
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).
phx is offline  
Old 07 January 2015, 13:58   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,512
Quote:
Originally Posted by phx View Post
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
Toni Wilen is offline  
Old 07 January 2015, 15:06   #12
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 983
Quote:
Originally Posted by Toni Wilen View Post
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 is offline  
Old 07 January 2015, 22:38   #13
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 983
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...
phx is offline  
Old 08 January 2015, 08:28   #14
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,512
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..
Toni Wilen is offline  
Old 08 January 2015, 10:17   #15
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 983
Quote:
Originally Posted by Toni Wilen View Post
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.


Quote:
Originally Posted by Toni Wilen View Post
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.
phx is offline  
Old 08 January 2015, 10:44   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,512
Quote:
Originally Posted by phx View Post
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.

Quote:
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.

Quote:
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.
Toni Wilen is offline  
Old 08 January 2015, 13:28   #17
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 983
Quote:
Originally Posted by Toni Wilen View Post
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...

Quote:
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?).
phx is offline  
Old 08 January 2015, 13:39   #18
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,512
Quote:
Originally Posted by phx View Post
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.

Quote:
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).
Toni Wilen is offline  
Old 08 January 2015, 15:27   #19
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 983
Quote:
Originally Posted by Toni Wilen View Post
$38 is fine. $34 would break sprite 7.
Ok. By looking at the DMA table in the HRM this becomes quite clear.

Quote:
Sprite DMA is always inactive until line 25 (PAL) or 20 (NTSC).
This is completely new to me. Thanks!
phx is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
Paula Agnus Denise (Amiga Music CD) at www.amigakit.com amigakit.com MarketPlace 6 09 July 2013 18:09
Wanted: Old A500 DENISE and FAT AGNUS chips 8bitbubsy MarketPlace 0 25 October 2009 13:11
ECS Denise .... when ? Another World New to Emulation or Amiga scene 9 13 February 2009 18:53
Chipset type: OCS / ECS Agnus Njinsa support.WinUAE 4 19 December 2005 00:29
ECS Agnus / Full ECS ChipSets.... Chapas support.WinUAE 7 17 June 2005 05:27

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 13:51.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.23407 seconds with 12 queries