29 September 2015, 16:28 | #1 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
How does AGA impact modulo?
I am just playing around with AGA for the first time really and have a 320x256 256 colour picture that I am putting up on screen. I have set fmode to %11 so I can show superhires too.
When using lowres I have to do -8 to the expected modulo. (40*7-8) When using hires I have to do -8 to the expected modulo. (40*7-8-40) When using superhires the modulo behaves as expected again.(40*7-40*3) Could this be related to the fetch positions or something? Is there a formula I should follow? (So much stuff I have forgotten after all these years...) All this using WinUAE. |
29 September 2015, 17:11 | #2 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
so you're showing an interleaved picture..
Iirc, you do not need to subtract anything.. are you sure, your ddfstrt/ddfstop are correct? There are formulas, but don't remember them off the top of my head any longer :-( |
29 September 2015, 22:38 | #3 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
Not at all. I just nicked something somewhere on the net to throw up a picture for OCS and then I re-used it.
Code:
dc.w diwstrt,$2c81 dc.w diwstop,$2cc1 dc.w ddfstrt,$0038 dc.w ddfstop,$00d0 |
29 September 2015, 22:43 | #4 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,573
|
AGA in higher fetch modes needs different DDFSTRT/STOP values. STRT/STOP alignment requirements are much larger (depends also on resolution).
|
30 September 2015, 18:52 | #5 |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
Modulo is unaffected by the fetch mode, but since you are now effectively fetching 64 bits at a time, you have to align all bitplane data on 64 bits, and you have to stop fetching earlier. For a standard 320 wide screen, starting at $38 and stopping at $A0 works fine.
|
01 October 2015, 02:07 | #6 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
$A0??? Yikes. (Gonna try it.)
I though perhaps it would be $B8 - or perhaps that is just half as much as I should math it out to. Fitting that old formula to AGA is ...requiring more think. Last edited by NorthWay; 01 October 2015 at 02:08. Reason: wording |
01 October 2015, 12:54 | #7 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
Dang! That worked. In fact, I even got $9A to work. (But not $98.)
Which sums up as $9A-$38 = 98. 98 of what? Doesn't anyone have a proper formula for AGA please? |
05 October 2015, 09:12 | #8 |
Registered User
Join Date: Dec 2007
Location: Dark Kingdom
Posts: 213
|
Many years ago I did some experiments and developed a formula... but I need some time to find it in my records :-)
|
05 October 2015, 21:45 | #9 |
Registered User
Join Date: Sep 2015
Location: Germany
Posts: 260
|
Here are some DDF-values I use. They might help you I hope:
Code:
DDFSTART_128_pixel_right_aligned EQU $98 DDFSTART_128_pixel_1x EQU $68 DDFSTART_128_pixel_2x EQU $58 DDFSTART_192_pixel_right_aligned EQU $70 DDFSTART_192_pixel_1x EQU $58 DDFSTART_192_pixel_2x EQU $58 DDFSTART_192_pixel_4x EQU $58 DDFSTART_256_pixel_right_aligned EQU $58 DDFSTART_256_pixel_1x EQU $48 DDFSTART_256_pixel_2x EQU $48 DDFSTART_512_pixel_right_aligned EQU $58 DDFSTART_512_pixel_4x EQU $48 DDFSTART_320_pixel EQU $38 DDFSTART_640_pixel EQU $38 DDFSTART_overscan_1x EQU $30 DDFSTART_overscan_2x EQU $28 DDFSTART_overscan_4x EQU $18 DDFSTOP_128_pixel_left_aligned_1x EQU $70 DDFSTOP_128_pixel_left_aligned_2x EQU $58 DDFSTOP_128_pixel_left_aligned_4x EQU $40 DDFSTOP_128_pixel_1x EQU $90 DDFSTOP_128_pixel_2x EQU $80 DDFSTOP_192_pixel_left_aligned_1x EQU $90 DDFSTOP_192_pixel_left_aligned_2x EQU $88 DDFSTOP_192_pixel_left_aligned_4x EQU $60 DDFSTOP_192_pixel_1x EQU $b0 DDFSTOP_192_pixel_2x EQU $a0 DDFSTOP_192_pixel_4x EQU $80 DDFSTOP_256_pixel_left_aligned_1x EQU $b0 DDFSTOP_256_pixel_left_aligned_2x EQU $a0 DDFSTOP_256_pixel_left_aligned_4x EQU $80 DDFSTOP_256_pixel_1x EQU $c0 DDFSTOP_256_pixel_2x EQU $a0 DDFSTOP_320_pixel_1x EQU $d0 DDFSTOP_320_pixel_2x EQU $c0 DDFSTOP_320_pixel_4x EQU $a0 DDFSTOP_512_pixel_left_aligned_1x EQU $b0 DDFSTOP_512_pixel_left_aligned_2x EQU $a8 DDFSTOP_512_pixel_left_aligned_4x EQU $a0 DDFSTOP_640_pixel_4x EQU $c0 DDFSTOP_overscan_1x EQU $d8 DDFSTOP_overscan_2x EQU $c8 DDFSTOP_overscan_4x EQU $c0 Long ago I had a formula for the DDF-registers. I'll try to find it. Last edited by dissident; 16 March 2017 at 10:18. |
06 October 2015, 11:40 | #10 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
Just for the record, I'm trying for shits&giggles to lay out a lowres 336x240 display window (preferably mid adjusted so stealing one sprite then), with a 4x fetch showing 232 pixels (104 pixels on right hand side covered by hw sprite overlay) 4+4bp dual playfield with scrolling. Odd bitplanes (or whatever is used for the lower playfield) could be copper re-written midline to wrap around the display.
And that is basically Gauntlet if you wonder. Have anyone tried a hostile port of any 68K arcade machine? Last edited by NorthWay; 06 October 2015 at 14:56. Reason: Checked sizes |
06 October 2015, 21:05 | #11 |
Registered User
Join Date: Sep 2015
Location: Germany
Posts: 260
|
As promised here's my formula for calculating the DDF-values, NorthWay . Just make your choice by removing or setting the semicolons. This formula doesn't support OVERSCAN-modes.
As an example I use lores, 320 pixels, 4x mode: Code:
;Constants for calculating the DDF-value color_clock_speed EQU 280 ;ns (for a memory cycle in a scanline) lores_pixel_speed EQU 140 ;ns hires_pixel_speed EQU 70 ;ns shires_pixel_speed EQU 35 ;ns horizontal_blanc_stop EQU $40 ;15 kHz screen pf1_x_size EQU 320 pixel_per_line EQU pf1_x_size ;variable parameters ;Choose your kind of datafetch here ;pixel_per_datafetch EQU 16 ;1x ;pixel_per_datafetch EQU 32 ;2x pixel_per_datafetch EQU 64 ;4x ;Choose the resolution here datafetch_clocks EQU (pixel_per_datafetch*lores_pixel_speed)/color_clock_speed ;lores ;datafetch_clocks EQU (pixel_per_datafetch*hires_pixel_speed)/color_clock_speed ;hires ;datafetch_clocks EQU (pixel_per_datafetch*shires_pixel_speed)/color_clock_speed ;shires ;Choose your kind of datafetch/resolution for DDFSTRT here ;DDFSTRTBITS EQU horizontal_blanc_stop-datafetch_clocks ;15 kHz, lores, hires, shires 1x DDFSTRTBITS EQU horizontal_blanc_stop-(datafetch_clocks/4) ;15 kHz, Lores 4x ;DDFSTRTBITS EQU horizontal_blanc_stop-(datafetch_clocks/2) ;15 kHz, Hires 4x move.w #DDFSTRTBITS,d0 ;Just for testing... ;Choose your kind of datafetch/resolution for DDFSTOP here ;DDFSTOPBITS EQU DDFSTRTBITS+(datafetch_clocks*((pixel_per_line/pixel_per_datafetch)-(lores_pixel_speed/lores_pixel_speed))) ;lores DDFSTOPBITS EQU DDFSTRTBITS+(datafetch_clocks*((pixel_per_line/pixel_per_datafetch)-1)-(datafetch_clocks-(datafetch_clocks/4))) ;lores 4x ;DDFSTOPBITS EQU DDFSTRTBITS+(datafetch_clocks*((pixel_per_line/pixel_per_datafetch)-(lores_pixel_speed/hires_pixel_speed))) ;hires ;DDFSTOPBITS EQU DDFSTRTBITS+(datafetch_clocks*((pixel_per_line/pixel_per_datafetch)-1)-(datafetch_clocks-(datafetch_clocks/2))) ;hires 4x ;DDFSTOPBITS EQU DDFSTRTBITS+(datafetch_clocks*((pixel_per_line/pixel_per_datafetch)-(lores_pixel_speed/shires_pixel_speed))) ;shires ;DDFSTOPBITS EQU DDFSTRTBITS+(datafetch_clocks*((pixel_per_line/pixel_per_datafetch)-1)-(datafetch_clocks-datafetch_clocks)) ;shires 4x move.w #DDFSTOPBITS,d1 Here 256 lines as an example: Code:
;Constants for calculating the DIW-value pf1_y_size EQU 256 visible_lines_num EQU pf1_y_size MINROW EQU $2c ;15 kHz ;Here we calculate the values for DIWSTRT ;disp_win_HSTART EQU ((DDFSTRTBITS+datafetch_clocks)*2)+1 disp_win_HSTART EQU ((DDFSTRTBITS+(datafetch_clocks/4))*2)+1 ;lores 4x ;disp_win_HSTART EQU ((DDFSTRTBITS+(datafetch_clocks/2))*2)+1 ;hires 4x ;disp_win_HSTART EQU ((DDFSTRTBITS+datafetch_clocks)*2)+1 ;shires 4x disp_win_VSTART EQU MINROW DIWSTRTBITS EQU ((disp_win_VSTART&$ff)*DIWSTRTF_V0)+(disp_win_HSTART&$ff) move.w #DIWSTRTBITS,d0 ;Here we calculate the values for DIWSTOP disp_win_x_size EQU pixel_per_line/(lores_pixel_speed/lores_pixel_speed) ;15 kHz, lores ;disp_win_x_size EQU pixel_per_line/(lores_pixel_speed/hires_pixel_speed) ;15 kHz, hires ;disp_win_x_size EQU pixel_per_line/(lores_pixel_speed/shires_pixel_speed) ;15 kHz, shires disp_win_y_size EQU visible_lines_num disp_win_HSTOP EQU disp_win_HSTART+disp_win_x_size disp_win_VSTOP EQU disp_win_VSTART+disp_win_y_size DIWSTOPBITS EQU ((disp_win_VSTOP&$ff)*DIWSTOPF_V0)+(disp_win_HSTOP&$ff) move.w #DIWSTOPBITS,d1 ;And here we calculate the values for DIWHIGH (ECS&AGA only) DIWHIGHBITS EQU (((disp_win_HSTOP&$100)>>8)*DIWHIGHF_HSTOP8)+(((disp_win_VSTOP&$700)>>8)*DIWHIGHF_VSTOP8)+(((disp_win_HSTART&$100)>>8)*DIWHIGHF_HSTART8)+((disp_win_VSTART&$700)>>8) move.w #DIWHIGHBITS,d2 |
06 October 2015, 21:20 | #12 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
Thanks. I'll be checking them out whenever work sets me in idling modus.
|
06 October 2015, 22:37 | #13 | |
Join Date: Jul 2008
Location: Sweden
Posts: 2,269
|
Quote:
For a 336 pixel wide screen you probably intend to use 8 pixels overscan on both sides, with 32-bit fetch-mode you would then have to start fetching at cycle $28, wiping out 3 or 4 sprites, and in some cases as early as $18, wiping out 7 sprites. With 64-bit fetch-mode you will have to start at $18 right away. |
|
07 October 2015, 09:29 | #14 |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
Unfortunate. Thanks for pointing that out.
Luckily there is a quick and dirty hack: Move the sprite overlay panel to the left side! They didn't really think through the AGA design, did they? A bit and a half of a hack job... |
07 October 2015, 11:46 | #15 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,643
|
|
07 October 2015, 16:23 | #16 | |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
Quote:
And my hand math is fubar as I got 38/B9 instead of 38/A0 as it assembles to. |
|
07 October 2015, 16:43 | #17 |
Total Chaos forever!
Join Date: Aug 2007
Location: Waterville, MN, USA
Age: 49
Posts: 2,200
|
@NorthWay
Since the sprite panel is now on the left side, you could use only the highest priority sprites with the bordersprite bit initialized to let the panel overlap the border. That should let you overlap the lower-priority sprites' fetching to allow more sprites to be available. (Please let me know if this actually turns out right, I've been meaning to try that myself.) |
08 October 2015, 21:34 | #18 | |||
Registered User
Join Date: Sep 2015
Location: Germany
Posts: 260
|
Quote:
http://gopherproxy.meulie.net/telefi...ro6/hardware.i For example the DIWSTART register: Bits 15-8 are the vertical start position v7-v0. Bit 8 has the hexvalue $100. It is the multiplier for the bits 15-8 or the bitfield 15-8. $100=DIWSTRTF_VP0. Or you can also say DIWSTRTField_VP0. If we have the startvalue $2c we can calculate $2c*DIWSTRTF_VP0 and we get the value $2c00. The bits are now at the correct position. I didn't include the equals because I thought it is understandable. Sorry, my fault. When you code in assembler for so many years much things become universal for you. I've attached the file for the DIW-equals. Quote:
Quote:
In the 1x mode it takes 8 clocks to fetch 16 lores pixels. In 4x mode 8 clocks fetch 64 lores pixels. The next 3x8 clocks are not used and free for other devices like the blitter or the copper. You can find more infos about my attempt to explain this phenomen in my screenshot: |
|||
09 October 2015, 01:04 | #19 | ||
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 854
|
Quote:
And shouldn't the display window be enough to show the sprite? Quote:
- Restrictions on where AGA DDFSTRT can be (exactly the same as OCS from the looks of it). - If modulo changes by having the fetched pixels run past the DDFSTOP and/or display window. (i.e. displayed data or fetched data) - If anything can trigger a new fetch out of schedule (like writing to the bitplane pointers) (I don't think so.) - Where(when) next line addresses are calculated from modulos. - Where the displaying of the fetched pixels starts (i.e. fetch here, pixels there, and being different depending on resolution) - Bitplane fetch order (though others here have made good timing visualizations of this) So if I want to futz with the bitplane pointers with 8bp then I should really set up a copper wait that is at start of fetch or in the middle of it, let copper stall while fetching eats cycles, and do my updates. |
||
09 October 2015, 03:52 | #20 | |||||
Code Kitten
Join Date: Aug 2015
Location: Montreal/Canadia
Age: 52
Posts: 1,178
|
Given how cheap C='s execs were, it seems unlikely that much of the machinery of AGA is different from ECS so I would expect it to behave similarly.
Quote:
The display window has no influence on fetches or other registers. It just indicates when to output bitplanes instead of background. Quote:
Cf first question. Quote:
Quote:
I have no idea about the timing, I would guess it was probably simpler to keep the exact same timing for fetches and spread apart groups of 64 pixels but I do not know the constraints of page mode so I could be completely wrong. Quote:
In your case, if two consecutive fetches are always separated by the same number of cycles (which might not be the case in 4x mode) then maybe you could update each bitplane pointer just before it gets used for fetching so you would not have any graphical glitches. That's certainly doable in 4 bitplanes for AGA but I have no idea if it's possible above that since I'm very fuzzy regarding AGA copper cycles and bitplanes timing. So in essence I cannot help you much but I like the topic so I tried nevertheless. |
|||||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
BLITZ BASIC 2 "floor,ceiling and modulo% equivalent" | Raislin77it | Coders. Blitz Basic | 10 | 19 July 2015 05:24 |
Min. and Max. modulo values? | AGS | Coders. Asm / Hardware | 7 | 07 February 2014 12:40 |
Impact / Impact 95 | andreas | HOL contributions | 11 | 06 July 2007 17:42 |
Impact a2000-hc | Drake008@ | support.Hardware | 0 | 22 March 2007 13:54 |
Impact | Bombjacker | support.Games | 0 | 02 February 2003 12:48 |
|
|