English Amiga Board


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

 
 
Thread Tools
Old 12 February 2020, 08:24   #1
Auscoder
Registered User

 
Join Date: Jan 2019
Location: Brisbane
Posts: 43
AGA Scroll Instruction

Hi all, with the wonderful help of people here I managed to migrate my game to AGA. Working concurrently on [ Show youtube player ]and [ Show youtube player ] versions.

I wonder if I might ask you a question. For my AGA build. I am trying to get hw scrolling working with AGA Fetch Mode 1. And I have a few questions I just don't know for sure what the answer is.. These could do with some confirmation. For me the HW docs are very obscure or difficult for me to interpret. Probably more the later of the two.... So the questions I have :

1/ With fmode 1 do I have 32 pixels now to scroll? OCS is limited to 16 which used bits 0-3 & 4-7 of BPLCON1. First question, do I have 32 now in AGA fmode 1?

2/ I think I have 32, and because of this 4 bits are not enough for each playfield. So instead I need to use instead PFxH0 through PFxH7 (x for each playfield). Is that right - using only PFx0->PFX4 for 0-31?

3/ If Q1 and Q2 are right, whats the best way to write a scroll value to these bits... It seems a right mess out of order etc if this is the case. Lets say I have a scroll value of 0-31.... Is there some nice trick to do it? With OCS I would just add/sub.b #%1 or #%10000 with some masking to combine the playfields bits.. but this now seems significantly trickier.

4/ Considering all above, will each be a single low res pixel? How do I manage the sub pixel scroll I hear about all the time. Does this needed to be treated differently and do I have only half or quarter pixels with these?

For now I guess just considering FMODE1 if it keeps it simpler.

Lot of questions to throw at you I know. I have been searching and reading for quite a few days in my spare time and not had much luck finding info.

Cheers!
Auscoder is offline  
Old 12 February 2020, 09:46   #2
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,454
BPLCON1 bit are renamed in AGA:
Code:
BPLCON1
 +------+---------+---------------------------------------------------------+
 | BIT# | BPLCON1 | DESCRIPTION                                             |
 +------+---------+---------------------------------------------------------+
 | 15   | PF2H7=0 | (PF2Hx =) Playfield 2 horizontal scroll code, x=0-7     |
 | 14   | PF2H6=0 |                                                         |
 | 13   | PF2H1=0 |                                                         |
 | 12   | PF2H0=0 |                                                         |
 | 11   | PF1H7=0 | (PF1Hx =) Playfield 1 horizontal scroll code, x=0-7     |
 | 10   | PF1H6=0 | where PFyH0=LSB=35ns SHRES pixel (bits have been        |
 | 09   | PF1H1=0 | renamed, old PFyH0 now PFyH2, ect). Now that the scroll |
 | 08   | PF1H0=0 | range has been quadrupled to allow for wider (32 or     |
 |      |         | 64 bits) bitplanes.                                     |
 | 07   | PF2H5   |                                                         |
 | 06   | PF2H4   |                                                         |
 | 05   | PF2H3   |                                                         |
 | 04   | PF2H2   |       'old' 140ns (1 lowres pixel)           |
 | 03   | PF1H5   |                                                         |
 | 02   | PF1H4   |                                                         |
 | 01   | PF1H3   |                                                         |
 | 00   | PF1H2   |                                                         |
 +------+---------+---------------------------------------------------------+
Quote:
Originally Posted by Auscoder View Post
1/ With fmode 1 do I have 32 pixels now to scroll? OCS is limited to 16 which used bits 0-3 & 4-7 of BPLCON1. First question, do I have 32 now in AGA fmode 1?
Yes, for FMODE=1 you should use PFxH6.

Quote:
2/ I think I have 32, and because of this 4 bits are not enough for each playfield. So instead I need to use instead PFxH0 through PFxH7 (x for each playfield). Is that right - using only PFx0->PFX4 for 0-31?
No, PFxH0 and 1 are for quarter pixel scroll (35ns or 70ns).

Quote:
3/ If Q1 and Q2 are right, whats the best way to write a scroll value to these bits... It seems a right mess out of order etc if this is the case. Lets say I have a scroll value of 0-31.... Is there some nice trick to do it? With OCS I would just add/sub.b #%1 or #%10000 with some masking to combine the playfields bits.. but this now seems significantly trickier.
Yes, is a mess, you have to shift and mask (or use a LUT).

Quote:
4/ Considering all above, will each be a single low res pixel? How do I manage the sub pixel scroll I hear about all the time. Does this needed to be treated differently and do I have only half or quarter pixels with these?
See above

Cheers.
ross is offline  
Old 12 February 2020, 10:08   #3
Auscoder
Registered User

 
Join Date: Jan 2019
Location: Brisbane
Posts: 43
Quote:
Originally Posted by ross View Post
BPLCON1 bit are renamed in AGA:
Code:
BPLCON1
 +------+---------+---------------------------------------------------------+
 | BIT# | BPLCON1 | DESCRIPTION                                             |
 +------+---------+---------------------------------------------------------+
 | 15   | PF2H7=0 | (PF2Hx =) Playfield 2 horizontal scroll code, x=0-7     |
 | 14   | PF2H6=0 |                                                         |
 | 13   | PF2H1=0 |                                                         |
 | 12   | PF2H0=0 |                                                         |
 | 11   | PF1H7=0 | (PF1Hx =) Playfield 1 horizontal scroll code, x=0-7     |
 | 10   | PF1H6=0 | where PFyH0=LSB=35ns SHRES pixel (bits have been        |
 | 09   | PF1H1=0 | renamed, old PFyH0 now PFyH2, ect). Now that the scroll |
 | 08   | PF1H0=0 | range has been quadrupled to allow for wider (32 or     |
 |      |         | 64 bits) bitplanes.                                     |
 | 07   | PF2H5   |                                                         |
 | 06   | PF2H4   |                                                         |
 | 05   | PF2H3   |                                                         |
 | 04   | PF2H2   |       'old' 140ns (1 lowres pixel)           |
 | 03   | PF1H5   |                                                         |
 | 02   | PF1H4   |                                                         |
 | 01   | PF1H3   |                                                         |
 | 00   | PF1H2   |                                                         |
 +------+---------+---------------------------------------------------------+

Yes, for FMODE=1 you should use PFxH6.


No, PFxH0 and 1 are for quarter pixel scroll (35ns or 70ns).


Yes, is a mess, you have to shift and mask (or use a LUT).


See above

Cheers.
Ross thanks!

So : PFxH2->PFxH6 for regular lowres pixel scroll, and then I guess logically its PFxH2->H7 for 31-63 right?

If I want to use 35ns (set bit 0, clear bit 1) or 70ns (clear bit 0, set bit 1) or something more?
Auscoder is offline  
Old 12 February 2020, 10:22   #4
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,454
Quote:
Originally Posted by Auscoder View Post
Ross thanks!

So : PFxH2->PFxH6 for regular lowres pixel scroll, and then I guess logically its PFxH2->H7 for 31-63 right?

(but FMODE=3)

Quote:
If I want to use 35ns (set bit 0, clear bit 1) or 70ns (clear bit 0, set bit 1) or something more?
11->+35ns+70ns=+105ns->+3/4pixel
ross is offline  
Old 12 February 2020, 10:27   #5
Auscoder
Registered User

 
Join Date: Jan 2019
Location: Brisbane
Posts: 43
Quote:
Originally Posted by ross View Post
11->35ns+70ns=105ns->3/4pixel
ohhhhhhhh! Thank you
Auscoder is offline  
Old 13 February 2020, 03:47   #6
Auscoder
Registered User

 
Join Date: Jan 2019
Location: Brisbane
Posts: 43
Maybe I am missing something still

I went ahead and precalc the BPLCON1 scroll word for Playfield 1 (0-63) like so

Code:
scrollTable64:	dc.w 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15 ; 0-15
                dc.w 1024,1025,1026,1027,1028,1029,1030,1031,1032,1033,1034,1035,1036,1037,1038,1039 ; 16-31
                dc.w 2048,2049,2050,2051,2052,2053,2054,2055,2056,2057,2058,2059,2060,2061,2062,2063 ; 32-47
                dc.w 3072,3073,3074,3075,3076,3077,3078,3079,3080,3081,3082,3083,3084,3085,3086,3087 ; 48-63
Code:
BIT                                FEDCBA9876543210
PF1 Scroll value 16 looks like   #%0000010000000000 (1024)
PF1 Scroll value 17 like........ #%0000010000000001 (1025)
PF1 Scroll value 32 like........ #%0000100000000000 (2048)
PF1 Scroll value 33 like........ #%0000100000000001 (2049)
PF1 Scroll value 48 like........ #%0000110000000000 (3072)
PF1 Scroll value 49 like........ #%0000110000000001 (3073)
For PF2 I just shift left the LUT result by 4

When scrolling it jumps something like it is not accounting for bit 10 (H6)

Checked fmode -- definitely 1
Checked byte shift when wrapping is +4
Check scroll pixel count is 32

Is maybe sub pixel scroll enabled, but for test I changed the scroll code to scroll 16 pixels and +2 bytes... But of course not 4 byte aligned so bitplane corruption shown, but scrolling smooth + correct, so I am doubting sub pixel is an issue.

I am running tests only on PF2, so possibly its my shift of the LUT results? Everything here PF1->PF2 looks just shifted 4 in the BPLCON1 diagram.

I am not touching any other bits (H0/H1) here, so they are 0... and passing the LUT result with shift for PF2 to BPLCON1 in copper.. just for now trying to get 0-31 working on a single playfield.
Auscoder is offline  
Old 13 February 2020, 08:33   #7
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,454
What is the value used for DDFSTRT?
You must have suitable values to use the new bits available in BPLCON1.

Can you post code / copper list?
ross is offline  
Old 13 February 2020, 09:08   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,653
Yeah, DDFSTRT is "unaligned" if BPLCON1 seems to work unexpectedly (display jumps to left when you increase BPLCON1 value). You don't need "aligned" DDFSTRT, simply add opposite offset to value you write to BPLCON1. For example if you need specific DDFSTRT to prevent too many disabled sprites.

Note that this is not AGA-specific but much easier to accidentally trigger under AGA because of higher alignment requirements.
Toni Wilen is offline  
Old 13 February 2020, 09:31   #9
ross
Per aspera ad astra

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 49
Posts: 2,454
Quote:
Originally Posted by Toni Wilen View Post
Note that this is not AGA-specific but much easier to accidentally trigger under AGA because of higher alignment requirements.


I like DDFSTRT=$34 on OCS.
It allows me to have SPR6 unaltered and adds a small overscan.
ross is offline  
Old 13 February 2020, 10:47   #10
Auscoder
Registered User

 
Join Date: Jan 2019
Location: Brisbane
Posts: 43
Quote:
Originally Posted by Toni Wilen View Post
You don't need "aligned" DDFSTRT, simply add opposite offset to value you write to BPLCON1. For example if you need specific DDFSTRT to prevent too many disabled sprites.
Interesting so to confirm add the negative of value I write to DDFSTART which is subtract BPLCON1 value from DDFSTART. Or do you mean inverse? if BPLCON1 value is scroll 8, then add 24 to DDFSTART. Second feels like it would need each Playfield to have same values either to work as intended here?

Quote:
Originally Posted by ross View Post
What is the value used for DDFSTRT?
You must have suitable values to use the new bits available in BPLCON1.
Can you post code / copper list?
Hard to supply a copper list as it is dynamic generated and populates values on runtime state... but fortunate DDFxxxx part is hard coded mostly..

Code:
		dc.w    $0092,48+DDFSTARTSTOP_PADDING
		dc.w    $0094,200-DDFSTARTSTOP_PADDING
With DDFSTARTSTOP_PADDING to 8, scroll works like you discussed, though with some delay like artifacts at left edges like in image attached. These are not matching all the way down because of multiple different BPLCON1 values for horizontal splits. The yellow is COL0 copper...

With DDFSTARTSTOP_PADDING to 0, my default scrolling broken as I discussed in this thread.

This DDFSTARTSTOP_PADDING value also modifies DIW.. So that explains why screen is now less wide (+8 left and -8 right)

I clearly need to understand the DDF/DIW relationships better than I do. Trying to achieve wide as possible screen with scrolling.
Attached Thumbnails
Click image for larger version

Name:	scroll.png
Views:	50
Size:	16.0 KB
ID:	66168  
Auscoder 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 scroll horizontally? AChristian Coders. Asm / Hardware 13 20 August 2018 17:14
Scroll with the mouse? BarrySWE support.Apps 14 29 May 2012 22:16
help me smooth scroll rusty71 support.WinUAE 7 21 November 2011 15:36
Hardware Scroll tutorial? Lonewolf10 Coders. Tutorials 14 24 January 2011 00:08
ERROR: Top Gear 2 AGA (Missing GFX & Illegal Instruction) Retro-Nerd project.Killergorilla's WHD packs 17 25 April 2009 22:02

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 15:24.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.11072 seconds with 16 queries