Question about AGA display data fetches

[FrenchShark]

Hello,

I am actually working on the ECS/AGA DMA sequencer of Minimig.
For OCS/ECS, we all know the relationship between DDFSRT and DIWSTRT register :
- For low-res, the fetches must start 8.5 color clock cycles before the display.
- For hi-res, the fetches must start 4.5 color clock cycles before the display.
This is clearly explained in the HRM.
(See the two nice attachements I have made)

What about AGA ? Since the hi-res and super hi-res also support 8 bitplanes, the fetches must always start 8.5 cycles before the display.
The AGA fetches are not faster, they are just wider (up to 64 bits per fetch).
I guess DDFSTRT = $003C with DIWSTRT = $2C81 does not work in hi-res if # of planes > 4, right ?

Regards,

Frederic

[Toni Wilen]

DIWSTRT/DIWSTOP has nothing to do with display DMA processing.

DDFSTRT can have "illegal" values and display still looks normal except one small detail, in some cases offset gets added to bitplane delays. (search "delayoffset" in uae sources. undocumented feature. Game 'The New Zealand Story' is good example)

More undocumented stuff: DDFSTRT 0x18 is real limit but DDFSTOP can be larger than number of clocks per line: OCS = display works normally, ECS/AGA = DDFSTRT is ignored, display dma always starts at 0x18.

Since the hi-res and super hi-res also support 8 bitplanes, the fetches must always start 8.5 cycles before the display.

Not really. It isn't exactly delay but time from "start of bitplane dma block" to "end of bitplane dma block". Output shift register starts shifting data when last plane (plane 0) gets written to (dma or not dma). Cycle diagram and length of "dma block" depends on resolution and fmode.

All OCS/ECS mode on AGA hardware have exact same cycle diagrams. (as long as FMODE=0)

[FrenchShark]

Originally Posted by Toni Wilen

DIWSTRT/DIWSTOP has nothing to do with display DMA processing.

DDFSTRT can have "illegal" values and display still looks normal except one small detail, in some cases offset gets added to bitplane delays. (search "delayoffset" in uae sources. undocumented feature. Game 'The New Zealand Story' is good example)

OK, I am going to look at it.

More undocumented stuff: DDFSTRT 0x18 is real limit but DDFSTOP can be larger than number of clocks per line: OCS = display works normally, ECS/AGA = DDFSTRT is ignored, display dma always starts at 0x18.

I have the hardware explanation for that : 2 comparators are used, one for DDFSTRT and one for DDFSTOP. When the first comparator triggers, a "ddf_enable" flag is set, when the second comparator triggers, "DDF enable" is cleared. On OCS, "ddf_enable" is also cleared during the beginning of a scanline, not on ECS/AGA. The hardware limit is created with another flag "ddf_limit"that is cleared during the first 24 cycles of a scanline (hence 0x18) and set for the rest of the scanline.
The logic is : IF (ddf_enable AND ddf_limit) = 1 THEN use bitlplane DMAs.

All OCS/ECS mode on AGA hardware have exact same cycle diagrams. (as long as FMODE=0)

In my post I was talking about fetches with FMODE = 1 or 3. When FMODE = 0, you cannot use more than 4 bitplanes in hi-res.


For example, the DMA bitplane chronogram for FMODE = 3 in lo-res should be:

Plane #8 \
Plane #4 |
Plane #6 |
Plane #2 | 64-pixel fetch
Plane #7 |
Plane #3 |
Plane #5 |
Plane #1 /

24 cycles available

Plane #8
Plane #4
Plane #6
Plane #2
Plane #7
Plane #3
Plane #5
Plane #1
...
etc

To retrieve 320 lo-res pixel you need 5 fetches instead of 20.

Regards,

Frederic

[Toni Wilen]

Originally Posted by FrenchShark

In my post I was talking about fetches with FMODE = 1 or 3. When FMODE = 0, you cannot use more than 4 bitplanes in hi-res.

Oops, yea, you are right, 8 dma cycles always needed (+bonus 0.5)

I have the hardware explanation for that

I thought it is something like this:

"ddf_enable" never gets turned off because hpos == DDFSTOP does not happen and there is another condition that inhibits display DMA cycles unless hpos >= 0x18. OCS probably have "hard stop" at the end of horizontal line that clears "ddf_enable" but it was removed from ECS because it introduced programmable start/stop positions.

(same end result anyway)

btw, it is possible to set DDFSTRT and DDFSTOP so that display gets totally corrupted. I don't have exact values but DDFSTOP needed to be very close to last cycle and DDFSTRT needed to be "non-aligned". Tested on A1200 PAL mode but probably does the same on ECS too.

[TheDarkCoder]

Many years ago I did many experiments with settings of these registers (in particular I wanted to avoid to set negative values in BPLxMOD when unnecessary). From the equations I derived, it seems to me that:
1) For fmode==0 (or OCS and ECS) is of course as you said, and for SH-res fetches have to start 2.5 cycles before DIWSTRT

2) for fmode==1 or 2,
for lo-res and hi-res fetches "delay" is 8.5,
for sh-res is 4.5

3) for fmode==3
for all res fetches delay is 8.5

hope this matches your test and is of any help!

[Toni Wilen]

Originally Posted by TheDarkCoder

for lo-res and hi-res fetches "delay" is 8.5,
for sh-res is 4.5

(checked uae sources and thought about it more..)

This is correct, fmode=1 and shres means 4.5 because it has max planes of 4 not 8. (8 shres planes need 64-bit fetches)

[FrenchShark]

Thank you guys,

this is very useful.
Obviously, my DMA bitplane microsequencer will have 5 "programs":
- 2-fetch sequence (SHRES FMode = 0)
- 4-fetch sequence (HRES FMode = 0, SHRES FMode = 1)
- 8-fetch sequence (LRES FMode = 0, HRES FMode = 1, SHRES, FMode = 3)
- 8-fetch sequence followed by 8 free cycles (LRES FMode = 1, HRES FMode = 3)
- 8-fetch sequence followed by 24 free cycles (LRES FMode = 3)

Regards,

Frederic

[TheDarkCoder]

Yep i think those 5 "programs" covers all possible combination fmode/res