English Amiga Board


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

 
 
Thread Tools
Old 01 November 2017, 03:55   #1
FSizzle
Registered User

 
Join Date: Nov 2017
Location: Los Angeles
Posts: 5
7th sprite corrupt with DDFSTRT of 0x30

I'm having a weird problem with my 7th sprite being corrupt when I start my DDSTRT earlier (0x30 instead of 0x38) in order to have HW scrolling.

I fully expect to lose the 8th sprite, but I'm puzzled why the 7th sprite appears, but doesn't display properly.

Here is my full window setup:
DIWSTRT = 0x2C80
DIWSTOP = 0xF4BC
DDFSTRT = 0x0030
DDFSTOP = 0x00D0

Am I missing something really obvious here? Have i misunderstood the DMA timing diagram?
FSizzle is offline  
AdSense AdSense  
Old 01 November 2017, 04:44   #2
ReadOnlyCat
Code Kitten

 
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 46
Posts: 1,012
Quote:
Originally Posted by FSizzle View Post
DDFSTRT = 0x0030
DDFSTOP = 0x00D0

Am I missing something really obvious here? Have i misunderstood the DMA timing diagram?
DDFSTRT
is the only one which matters and with 0x30 you should indeed only lose the 8th Sprite (Sprite 7).

Are you sure that you are feeding Sprite 6 with proper data? It could be as simple as your Sprite data being corrupted by another bug in your code.

Toni has discovered a number of weird behaviors regarding data fetches but I do not recall anything which matches your case.
ReadOnlyCat is offline  
Old 01 November 2017, 08:39   #3
FSizzle
Registered User

 
Join Date: Nov 2017
Location: Los Angeles
Posts: 5
Thanks for confirming that at least what I'm trying to do should work I do suspect it's something wrong with my code, but I'm a little stumped as to what it might be.

If I change the DDFSTRT to 0x38, the 7th sprite displays correctly. Similarly, if I change the sprite to use any of the first 6 slots it also displays correctly, so if the bug is somehow in the sprite setup, it's very subtle.

I've noticed that the way the sprite is corrupted is very specific - it's almost as if the second word fetch for each line is being inhibited, including the sprite data ptr not being advanced. For example, with the sprite data for each row as follows:

1111000000000000 0000000000000000
0000111100000000 0000000000000000
0000000011110000 0000000000000000
0000000000001111 0000000000000000

it actually ends up displaying as alternating lines:

1111000000000000
0000000000000000
0000111100000000
0000000000000000
0000000011110000
0000000000000000
0000000000001111
0000000000000000

It appears the same in Win-UAE and FS-UAE - I guess i can try the real HW next. I'm open to other ideas about what else I should check if you have any
FSizzle is offline  
Old 01 November 2017, 09:52   #4
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,772
All OCS Agnus variants (fixed in ECS/AGA) have sprite DMA bug/feature: single cycle just before bitplane DMA starts is not available for sprites, it kills dma transfer to sprite's second control word/data word (if bitplane DMA start is early enough) causing sprite to become damaged, for example previously loaded DATB is visible.

In other words, if OCS Agnus, when documentation says only sprite 7 gets killed due to bitplane DMA, sprite 6 second word DMA slot also gets stolen by bitplane DMA and so on.
Toni Wilen is offline  
Old 02 November 2017, 02:24   #5
Photon
Moderator
Photon's Avatar
 
Join Date: Nov 2004
Location: Hult / Sweden
Posts: 4,451
Correct, basically left side overscan steals sprite channel DMA slots one bitplane per 8px. (See the moon sprite in the DYSP part of Uncle Tom Sonix, and surely any game with horizontal scrolling would use the 7th sprite.)

For DDFSTRTs of $2c and $34 you can still use 1 bitplane sprites!
Photon is offline  
Old 02 November 2017, 03:35   #6
FSizzle
Registered User

 
Join Date: Nov 2017
Location: Los Angeles
Posts: 5
Thanks for the great info everyone. Looks like I'll need to shrink the window by 16 pixels on the left if I want that 7th sprite to work reliably on all hw (on the plus side I'll get the 8th one back also).
FSizzle is offline  
Old 06 November 2017, 14:19   #7
borchen
Registered User

 
Join Date: Jan 2016
Location: NL
Posts: 7
Quote:
Looks like I'll need to shrink the window by 16 pixels on the left if I want that 7th sprite to work reliably on all hw
If you want full use of all sprites AND make use of HW scrolling, isn't it possible to extend the right margin of the visible windows by 16 pixels? Ofcourse the whole screen will be offset by 16 pixels to the right...
Or is this a noob-answer?
borchen is offline  
Old 10 November 2017, 04:20   #8
FSizzle
Registered User

 
Join Date: Nov 2017
Location: Los Angeles
Posts: 5
It's possible to have the screen finish 16px later, thus keeping the full width, all the sprites and scrolling, as far as I can tell, but it introduces some new potential problems.

Firstly, I think this would be considered to be entering the overscan area, so you are now risking the image being cut off on people's screens. If someone has a monitor like the 1084s they can adjust the position, but someone on a TV is not able to do that usually. Even the defaults of something like WinUAE would at best put this to the very edge of the window and maybe even cut off some pixels. It also think it looks bad to be so off-center like this.

Secondly, I am relying on some precise copper timing to align palette switching at the left and right edges of the window. For reasons I don't fully understand, pushing the window further to the right starts to exhibit some odd timing problems that make it not possible to reliably line up the right window edge and copper palette switches (timing seems to not be consistent).
FSizzle is offline  
Old 10 November 2017, 13:28   #9
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,003
Quote:
Originally Posted by FSizzle View Post
For reasons I don't fully understand, pushing the window further to the right starts to exhibit some odd timing problems that make it not possible to reliably line up the right window edge and copper palette switches
I guess you lost some Copper DMA slots to Bitplane DMA by moving DDFSTOP to the right. So the Copper can no longer execute your WAIT instructions in time?

BTW, sprites 6 and 7 still work, you only lost their DMA slots. Which means you could also load SPRxDATA/SPRxDATB with the copper, at the beginning of the line and still use those sprites.
phx is offline  
Old 11 November 2017, 18:36   #10
FSizzle
Registered User

 
Join Date: Nov 2017
Location: Los Angeles
Posts: 5
Quote:
I guess you lost some Copper DMA slots to Bitplane DMA by moving DDFSTOP to the right.
I decided to investigate this a bit, so I created a small test (with sprites and bitplanes disabled), which changes the color at the right edge of the screen, setting the wait at each pixel position around 0xDC (+/- 16 pixels):

Code:
for ( uint16_t i=0; i<32; ++i )
{
    // Left
    CopperList_WaitH( cl, 100 + i, 0x40 );
    CopperList_Move( cl, 0x180, ( i & 0x1 ) ? 0xF00 : 0x0F0 ); // Red/Green
    // Right
    CopperList_WaitH( cl, 100 + i, 0xDC - 16 + i ); 
    CopperList_Move( cl, 0x180, 0x000 );
}
This creates a stable stepping pattern on the right side of the screen until it goes past 0xDC, at which point the color change no longer happens at the expected time. It also alternates between odd and even frames as shown in WinUAE below. My assumption is that this is another quirk of the HW.




Quote:
BTW, sprites 6 and 7 still work, you only lost their DMA slots. Which means you could also load SPRxDATA/SPRxDATB
You're absolutely right. The trouble is that it makes them impractical for fast moving objects when combined with an already complicated copper list that is full of delicate per-frame timing for multiplexing and various other tricks.
FSizzle 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
"Reminder LAG meeting 42 will be held on Saturday the 7th of March 2015" rockape News 0 28 February 2015 15:16
LAG meeting 37 will be held on Saturday the 7th of June 2014. rockape News 1 07 June 2014 19:38
"REMINDER LAG meeting 34 will be held on Saturday the 7th of September" rockape News 5 01 September 2013 18:15
Melbourne Amiga User Group (MAUG) - 7th of July NovaCoder Amiga scene 16 08 July 2011 09:37
"LAG 21 is booked for Saturday 7th of May" rockape News 3 08 May 2011 00:31

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 01:26.


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