How does AGA impact modulo?

[NorthWay]

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.

[hooverphonique]

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 :-(

[NorthWay]

Originally Posted by hooverphonique

are you sure, your ddfstrt/ddfstop are correct?

Not at all. I just nicked something somewhere on the net to throw up a picture for OCS and then I re-used it.

    dc.w    diwstrt,$2c81
    dc.w    diwstop,$2cc1
    dc.w    ddfstrt,$0038
    dc.w    ddfstop,$00d0

The puzzling part was that it wasn't consistent (with what I expected).

[Toni Wilen]

AGA in higher fetch modes needs different DDFSTRT/STOP values. STRT/STOP alignment requirements are much larger (depends also on resolution).

[Leffmann]

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.

[NorthWay]

$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.

[NorthWay]

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?

[TheDarkCoder]

Many years ago I did some experiments and developed a formula... but I need some time to find it in my records :-)

[dissident]

Here are some DDF-values I use. They might help you I hope:

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.

[NorthWay]

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?

[dissident]

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:

;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

And I've got also a formula for calculating the DIW-values. The values are calculated in lores.
Here 256 lines as an example:

;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

[NorthWay]

Thanks. I'll be checking them out whenever work sets me in idling modus.

[Leffmann]

Originally Posted by NorthWay

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?

I don't think there's any way of doing this with 32 or 64-bit fetch-mode if you want both horizontal scrolling, and overscan on the left side of the screen.

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.

[NorthWay]

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

[hooverphonique]

Originally Posted by NorthWay

They didn't really think through the AGA design, did they? A bit and a half of a hack job...

also lot's of compromises to maintain ECS compatibility, I guess..

[NorthWay]

Originally Posted by dissident

And I've got also a formula for calculating the DIW-values. The values are calculated in lores.
Here 256 lines as an example:

The DIW part did not assemble as-is; it is lacking some of your constants.

And my hand math is fubar as I got 38/B9 instead of 38/A0 as it assembles to.

[Samurai_Crow]

@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.)

[dissident]

The DIW part did not assemble as-is; it is lacking some of your constants.

It's quite simple, NorthWay. I just translated the bitpositions in the registers DIWSTART/DIWSTOP/DIWHIGH into hexvalues. It's like in the asm include file for the hardware registers "hardware.i" for the INTENA/DMACON registers:

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.

And my hand math is fubar as I got 38/B9 instead of 38/A0 as it assembles to.

Just what Leffmann said:

For a standard 320 wide screen, starting at $38 and stopping at $A0 works fine.

The formula is correct. For a lores display with 320 pixel you need a DDFSTOP value $a0.

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:

[NorthWay]

Originally Posted by Samurai_Crow

(Please let me know if this actually turns out right, I've been meaning to try that myself.)

I found the BORDERSPRITE setting, but it references ESCENA which I can't seem to remember nor find.
And shouldn't the display window be enough to show the sprite?

Originally Posted by dissident

You can find more infos about my attempt to explain this phenomen in my screenshot:

Good one. What might complete the picture for an explanation is:
- 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.

[ReadOnlyCat]

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.

Originally Posted by NorthWay

- If modulo changes by having the fetched pixels run past the DDFSTOP and/or display window. (i.e. displayed data or fetched data)

If I recall correctly what Toni wrote in a past thread the modulo is added to the value that the bitplane pointers have after the last data fetch. When it is actually added I can't recall. Maybe It is possible to modify the pointers after DDFSTOP and before the modulo gets added but it is just simpler to re-set the pointers right before DDFSTART instead if you really need to do it.

The display window has no influence on fetches or other registers. It just indicates when to output bitplanes instead of background.

Originally Posted by NorthWay

- If anything can trigger a new fetch out of schedule (like writing to the bitplane pointers) (I don't think so.)

Does it happen on ECS? Then, possibly, but if not then it is unlikely that they changed anything given that AGA was made in a rush.

Originally Posted by NorthWay

- Where(when) next line addresses are calculated from modulos.

Cf first question.

Originally Posted by NorthWay

- Where the displaying of the fetched pixels starts (i.e. fetch here, pixels there, and being different depending on resolution)

Probably same as ECS: small delay after bitplane 0 is fetched. The clock is the same so I would guess that delay is the same but this is just a guess.

Originally Posted by NorthWay

- Bitplane fetch order (though others here have made good timing visualizations of this)

The order is the same as ECS.
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.

Originally Posted by NorthWay

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.

I spent a bit of time a few months ago thinking about it and drawing a cycle diagram to determine when to perform and how to order bitplane pointers updates for ECS and it is quite messy.

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.