English Amiga Board


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

 
 
Thread Tools
Old 09 January 2017, 09:17   #1
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 180
Question Bordersprites restrictions (AGA chipset)

On my original hardware, an Amiga 1200/020, a display error in conjunction with borderspriters in the left overscan-region occurs. As a change the error doesn’t exist on WinUAE (3.3.0). So lean back, Toni.

The Routine
A horizontal starscrolling of vertical reused 1x bandwidth attached bordersprites which use hires/super-hires positioning on a 320x256 display with two colours in 4x fetchmode (DDFSTRT $38, DDFSTOP=$a0). All eight sprites are used. The starscrolling has four different planes with different speeds. The attached sprite pairs are SPR01 = foremost plane1 with the largest/fastest balls and priority over the rest of the sprites, SPR23=plane2, SPR45=Plane3, SPR67=most backward plane4 with the smallest/slowest balls and the lowest display priority.

The Display-Error
SPR4/5 and SPR6/7 are displayed with the wrong colours between the horizontal (lores) positions $5b-$68. After position $68 everything is fine. Sprite pair SPR 4/5 starts with this error earlier than SPR6/7. This effect appears during the whole display (all 256 rasterlines). The Sprites pairs 0/1 and 2/4 are not affected. Turning off the bitplane-DMA with zero bitplanes in BPLCON0 doesn’t have any influence on the display error.

Theory 1
My first theory is that the sprite-DMA seems not able to display these sprites correctly because it is blocked by other, higher priorized DMA devices. I’ve seen in the DMA time slot allocation diagram of the HRM that for Sprite 5-7 other DMA devices could also use their slots. I’ve marked them red.
HRM says that these slots are also available for Blitter, Copper and 680x0. But the blitter is not used and the copper doesn’t execute any commands in this display region. So only the 680x0 could steal these cycles from these sprites. But when I did the screenshot, I stopped the routine, so there is also no 680x0 activity. The diagram also confirms that the sprites 4/5 are blocked earlier that sprite 6/7.

Theory 2
My second theory is, that the display-error occurs if the sprite should be displayed in the same region while it is fetched there by DMA. For SPR4 this would be between lores position $4a-$50 , SPR5=position $52-$58, SPR6=position $5a-$60, SPR7=position $62-$68. Paired together in attached mode this would mean that SPR45 are loaded between position $4a-$58 and SPR67 between position $5a-$68. The sprites are visible before these regions because the fetched planedata of the previous line is used.

To make things clearer, I’ve also included a little video https://www.dropbox.com/s/llfcdahmpt...rites.AVI?dl=0 and a screenshot of this effect to show how it appears on my multisync monitor. I’ve manipulated the display with the BPLCON4 so that the background-colour within HSTART-HSTOP/DDFSTRT-DDFSTOP is changed to emphasize the left border area.

Maybe you, Toni, could explain this phenomenon.
Attached Thumbnails
Click image for larger version

Name:	Slot-Allocation-Diagramm.jpg
Views:	241
Size:	45.4 KB
ID:	51655   Click image for larger version

Name:	Screenshot-Overscan-Sprites.jpg
Views:	264
Size:	461.9 KB
ID:	51656  
dissident is offline  
Old 09 January 2017, 09:53   #2
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,213
I think I have seen this effect previously in some of my bitplane/sprite tests but I forgot about it because I was always examining some other problem.

I am sure your theory #2 is correct. Sprite is not horizontally armed when horizontal comparison matches = sprite's shift register won't get loaded or only SPRxDATA gets loaded (and DATB gets previous line's data, I guess) if match position is after sprite's DATA DMA but before sprite's DATB DMA slot.

SPRxDATA write does the horizontal arming.

It can't be #1, copper, blitter or cpu can't steal sprite cycles. (Only bitplanes can steal sprite cycles).
Toni Wilen is offline  
Old 09 January 2017, 18:10   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,213
Do you have some example code that shows this (and does nothing else)? Because I am so lazy to test it myself.. You can email if you prefer to keep it secret. Executable only is fine, I don't need sources.
Toni Wilen is offline  
Old 09 January 2017, 20:38   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,213
My first guess can't be right, it has nothing to do with armed status. (It is always good idea to check HRM and current emulation code before guessing anything too weird..)

It is most likely really simple reason: horizontal comparison matches after DATA has been loaded but before DATB: DATB still has previous line's data.
Toni Wilen is offline  
Old 09 January 2017, 21:58   #5
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 180
Lightbulb

Quote:
Originally Posted by Toni Wilen View Post
I am sure your theory #2 is correct. Sprite is not horizontally armed when horizontal comparison matches = sprite's shift register won't get loaded or only SPRxDATA gets loaded (and DATB gets previous line's data, I guess) if match position is after sprite's DATA DMA but before sprite's DATB DMA slot.

SPRxDATA write does the horizontal arming.

It can't be #1, copper, blitter or cpu can't steal sprite cycles. (Only bitplanes can steal sprite cycles).
Okay, thank you for your quick reply, Toni. So I was not totally wrong with my theories. Fine.

Quote:
Originally Posted by Toni Wilen View Post
Do you have some example code that shows this (and does nothing else)? Because I am so lazy to test it myself.. You can email if you prefer to keep it secret. Executable only is fine, I don't need sources.
I've sent you an e-mail with the exe-file(s).

Quote:
Originally Posted by Toni Wilen View Post
My first guess can't be right, it has nothing to do with armed status. (It is always good idea to check HRM and current emulation code before guessing anything too weird..)

It is most likely really simple reason: horizontal comparison matches after DATA has been loaded but before DATB: DATB still has previous line's data.
I guess I will change my routine that way, dropping the use of SPR6/7 to avoid the obvious display error in the overscan region. The error with SPR4/5 is not so obvious, because there, it's only at the beginning of the overscan region.
dissident is offline  
Old 10 January 2017, 22:37   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,213
Fixed. It wasn't even directly chipset emulation related, it was just a side-effect of lazy evaluation (delay something as long as possible until it really needs to be done) which assumed that DMA mode sprites can't have side-effects and can be delayed until end of scanline (or until next CPU or copper sprite-register access if earlier than end of scanline).

Fixed was very simple: test sprite's X-coordinate against sprite's SPRxDATB DMA slot in DMA emulation, if coordinate is smaller, do pending sprite decisions immediately. Test prevents useless CPU usage increase with "normally" positioned sprite.
Toni Wilen is offline  
Old 11 January 2017, 08:41   #7
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 180
Quote:
Originally Posted by Toni Wilen View Post
Fixed was very simple: test sprite's X-coordinate against sprite's SPRxDATB DMA slot in DMA emulation, if coordinate is smaller, do pending sprite decisions immediately. Test prevents useless CPU usage increase with "normally" positioned sprite.
Very good, Toni.

Quote:
Originally Posted by Toni Wilen View Post
This wasn't exactly right.

It is first write to BPL0DAT that also enables sprites.

Write to BPL0DAT enables bitplane shift registers inside Denise (this is nothing new, Agnus DMA does this automatically internally). My guess is that there is logic that outputs background color as long as BPL0DAT has not been written to.

Test used: DDFSTRT set to 0x80, put sprite on left side of screen. It is not visible. Use copper to write to BPL0DAT on left side of screen. Single raster line of sprite is now visible + 16 pixels of bitplane data that was written to BPL0DAT.

Perhaps useful for some weird tricks, not sure
I guess the OCS-hardware behaves the same way, if you do this trick with the write to the BPL0DAT register at the beginning of the scanline to display sprites outside the border in the blanked area to simulate "bordersprites" on OCS.
dissident is offline  
Old 11 January 2017, 09:32   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,213
Quote:
Originally Posted by dissident View Post
I guess the OCS-hardware behaves the same way, if you do this trick with the write to the BPL0DAT register at the beginning of the scanline to display sprites outside the border in the blanked area to simulate "bordersprites" on OCS.
I didn't test but I am sure there are no differences between ocs/ecs/aga. It is just a side-effect of how sprite DMA fetches are done, single sprite line needs two separate fetches and sprite can be loaded to output shift register even if its data has not been fully loaded (or even not loaded at all)

I think it should be quite easy to work around it by having multiple sprites (one normal, one that has second plane shifted by one pixel vertically and so on) and selecting correct depending on sprite's x-coordinate.
Toni Wilen is offline  
Old 11 January 2017, 23:38   #9
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 180
Quote:
Originally Posted by Toni Wilen View Post
I didn't test but I am sure there are no differences between ocs/ecs/aga. It is just a side-effect of how sprite DMA fetches are done, single sprite line needs two separate fetches and sprite can be loaded to output shift register even if its data has not been fully loaded (or even not loaded at all)

I think it should be quite easy to work around it by having multiple sprites (one normal, one that has second plane shifted by one pixel vertically and so on) and selecting correct depending on sprite's x-coordinate.
I’ve changed my routine, so that the sprites are now visible in the border region without setting the bordersprite-bit in BPLCON3. Works fine on my original hardware, an A1200/020.

Between line $2c-$12b the copper sets with x-pos=$6 (minimum) the register BPL1DAT=0.

The display error at the left border can be prohibited, waiting with the copper for the x-pos=$38. But as a consequence, the left overscan region gets blanked and the sprites are disabled.

The values of these register remain the same: DDFSTRT=$38, DDFSTOP=$a0, FMODE=4x for one bitplane.

Important: To see the sprites outside the border, it is necessary to change the horizontal window-limits (DIWSTRT/DIWSTOP/DIWHIGH) to the overscan values HSTART=$5b and HSTOP=$1c7. Otherwise the sprites are only visible in the standart region if you use for example HSTART=$81, HSTOP=$1c1. The display error at the left border is the same as with real bordersprites. At the right border the sprites disappear much sooner like the real bordersprites, if you use HSTOP>=$1c8. It seems that they can’t have the horizontal lores-positions greater $1c7.

Toni, if you want, I could send you my revised routine by mail for testing purposes. Please remember, that my routine is AGA only. I haven’t got an init-routine for the OCS yet.

Last edited by dissident; 12 January 2017 at 09:03.
dissident is offline  
Old 12 January 2017, 12:00   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,213
I don't think I need any test cases anymore. Only remaining part is confirming that glitches happen exactly at right x coordinate positions. I'll do it later..

This test is needed because some sprite operations that happen exactly at the same time as DMA write use previous data and some use new data.
Toni Wilen is offline  
Old 12 January 2017, 23:14   #11
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,213
Positioning is exactly correct in emulation but I found another side-effect (and confirmed it also happens on ECS A500):

If sprite start xpos is before xDATB/xCTL fetch, sprite's last line gets duplicated, line that normally would have been blank (line that DMA engine uses to fetch next xPOS and xCTL words) will have same sprite graphics as previous line.

It happens because condition that loads words to shift register is: must be "armed" and horizontal comparison matches. Sprite stays armed until next xCTL write, if horizontal comparison matches before xCTL DMA fetch, sprite is still armed and shift register will get loaded with previous line's xDATA and xDATB. Result is repeated extra line.

(This is not yet emulated, it is more tricky to implemented without other side-effects)
Toni Wilen is offline  
Old 13 January 2017, 10:09   #12
dissident
Registered User

 
Join Date: Sep 2015
Location: Germany
Posts: 180
Quote:
Originally Posted by Toni Wilen View Post
Positioning is exactly correct in emulation
Sure, your emulation works correctly. My monitor seems to display more of the right border region than it is necessary. That's what I meant.

Quote:
Originally Posted by Toni Wilen View Post
but I found another side-effect (and confirmed it also happens on ECS A500):

If sprite start xpos is before xDATB/xCTL fetch, sprite's last line gets duplicated, line that normally would have been blank (line that DMA engine uses to fetch next xPOS and xCTL words) will have same sprite graphics as previous line.

It happens because condition that loads words to shift register is: must be "armed" and horizontal comparison matches. Sprite stays armed until next xCTL write, if horizontal comparison matches before xCTL DMA fetch, sprite is still armed and shift register will get loaded with previous line's xDATA and xDATB. Result is repeated extra line.

(This is not yet emulated, it is more tricky to implemented without other side-effects)
If I'm right, this would confirm my secend theory that the sprites are visible in the overscan area before their data is fetched, because the fetched planedata of the previous line is used.
dissident is offline  
Old 14 January 2017, 16:13   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,213
Quote:
Originally Posted by dissident View Post
If I'm right, this would confirm my secend theory that the sprites are visible in the overscan area before their data is fetched, because the fetched planedata of the previous line is used.
Exactly. Unfortunately this "feature" seems to be totally useless for anything interesting...

Last line doubling should be emulated properly now.
Toni Wilen is offline  
Old 09 January 2019, 16:52   #14
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,406
Hi Toni, there is something wrong in border sprite emulation, probably related to patch you have done here.

All 'bad' sprites behavior in low x-coordinates works only if BRDSPRT=1.
(tested on AGA 64bit sprites and latest WinUAE)
ross is offline  
Old 09 January 2019, 17:37   #15
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,406
hmm, there is also something wrong with BRDSPRT=1.

I think that all the situations in attached images indicate something strange.
Sprites not y-multiplexed, latest image with BRDSPRT=0.

Attached also a little executable (joy button to toggle BRDSPRT bit).
Attached Thumbnails
Click image for larger version

Name:	pollo1.jpg
Views:	79
Size:	46.4 KB
ID:	61526   Click image for larger version

Name:	pollo2.jpg
Views:	57
Size:	50.7 KB
ID:	61527   Click image for larger version

Name:	pollo3.jpg
Views:	64
Size:	48.3 KB
ID:	61528   Click image for larger version

Name:	pollo4.jpg
Views:	65
Size:	44.5 KB
ID:	61529  
Attached Files
File Type: zip pollo.zip (2.5 KB, 15 views)
ross is offline  
Old 11 January 2019, 19:53   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,213
Fixed. I tried to optimize handling of this feature a bit too much..
Toni Wilen is offline  
Old 11 January 2019, 22:19   #17
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,406
Perfect! Now it behaves as I remember from the old days .

Thank you,
ross
ross 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
How to detect AGA chipset installed from C? earok Coders. C/C++ 3 04 June 2016 03:31
Auto-setting chipset to "original" on AGA startup MethodGit Coders. General 16 11 March 2016 18:47
Best way of detecting the AGA chipset? Steve Coders. Asm / Hardware 13 25 January 2014 23:08
Copper color-changing restrictions? Dan Locke Coders. General 24 01 February 2010 04:00
EHB sprites with AGA chipset ? FrenchShark Coders. General 4 17 September 2009 07:37

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


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.08948 seconds with 15 queries