Fmode and blitter speeds

[Jobbo]

For AGA how do different Fmode settings affect blitter speeds?

I imagine that the peak blitter bandwidth is unaffected but you can free up more DMA slots that would've been needed for bitplanes and sprites otherwise.

I have a demo effect that's using HAM5 which isn't possible on AGA. To make it compatible I'm detecting AGA and using HAM6, but this uses more bandwidth so the blitter ends up running slower for AGA. I'm thinking that I can get the speed back with Fmode, sound right?

How accurate at this stuff is Winuae when emulating an A1200?

Thanks

[ross]

Originally Posted by Jobbo

For AGA how do different Fmode settings affect blitter speeds?

I imagine that the peak blitter bandwidth is unaffected but you can free up more DMA slots that would've been needed for bitplanes and sprites otherwise.

Yes for bitplanes, see how they are 'packed':
https://eab.abime.net/showpost.php?p...65&postcount=2
Not for sprites, they are just wider but same DMA slots usage.

I have a demo effect that's using HAM5 which isn't possible on AGA. To make it compatible I'm detecting AGA and using HAM6, but this uses more bandwidth so the blitter ends up running slower for AGA. I'm thinking that I can get the speed back with Fmode, sound right?

Yes, I've also patched some code this way.
Just change BPLCON0 from $7a00 to $6a00 and setup the masks previously in BPL5/6DAT as fetched data.
Even FMODE=x2 is more than enough to recover loss of blitter speed due to the two more bitplane fetches needed.

EDIT: uh, I realized that I have described to you what is usually used for a 7bpls/HAM4+ effect
But obviously the same also applies to the HAM5 (BPLCON0=$5a00), indeed in the latter case you only have a bitplane of difference, so even less speed loss for the blitter.

How accurate at this stuff is Winuae when emulating an A1200?

In CE mode the AGA chipset emulation is absolutely consistent, you may have differences in CPU cycles, but in that case it is your code that has to adapt to the different possible processors speeds.

Cheers.

[Jobbo]

Thanks Ross.

I have AGA allocating an extra blank plane just like you described.

Fmode 4x seems to more than do the trick in Winuae to gain back the speed loss, but I wanted to double check.

I also find I need to adjust Ddfstop. With Fmode set to 4x it seems like I need to stop the display fetch early by 48...64ish pixels.

Does anyone know the exact rules for how Ddfstop should be setup? I know there's different rules for low and high resolution so I imagine the full rule set for AGA gets a bit complicated.

[ross]

DDFSTOP is where the last BPL DMA fetch is done, dependently of is wide.

So DDFSTOP=DDFSTRT+(px-DMA_width)/2 works.

Example: 320 px, DDFSTRT=$38, FMODE=4x ->

DDFSTOP=

$38+(320-64)/2=

$B8

EDIT: however if you put values slightly >$b8 (like $c0) there would be anyway a further fetch (so 320+64..), so you can use a 'range'

[Jobbo]

That's what I've tried and it works fine for fmode 0, 1 and 3 but not for fmode 2?


Maybe there's a Winuae bug, it seems to swap each display word pair around in that mode.

Edit, it's not swapping them but it seems like the second word is a copy of the first word, or something like that.

[Toni Wilen]

DDFSTOP does not equal last fetch. (This is very common error, HRM does not explain it very well). After DDFSTOP has matched, there is always one more complete bitplane DMA "block" (all enabled planes fetched) before DMA stops.

End result can still be same even if value is technically wrong because there is 8/16/32 possible DDFSTOP values that have same result.

[Toni Wilen]

Originally Posted by Jobbo

That's what I've tried and it works fine for fmode 0, 1 and 3 but not for fmode 2?

Maybe there's a Winuae bug, it seems to swap each display word pair around in that mode.

You probably didn't expect it but it is correct behavior
FMODE=2 is useless. (EDIT: it has same cycle sequence as FMODE=1 so nothing useful was lost)

[Jobbo]

Originally Posted by Toni Wilen

You probably didn't expect it but it is correct behavior
FMODE=2 is useless. (EDIT: it has same cycle sequence as FMODE=1 so nothing useful was lost)

I was expecting the same behavior as FMODE=1 but instead it does something very strange. I wonder if anyone found a creative use for whatever is happening.

[ross]

Originally Posted by Toni Wilen

DDFSTOP does not equal last fetch. (This is very common error, HRM does not explain it very well). After DDFSTOP has matched, there is always one more complete bitplane DMA "block" (all enabled planes fetched) before DMA stops.

End result can still be same even if value is technically wrong because there is 8/16/32 possible DDFSTOP values that have same result.

Toni, so what are the 'official' value for a 320px screen, FMODE=4x, DDFSTRT=$38? DDFSTOP work from $a0 (EDIT: actually $9a ) to $B8.
But I tend to use the value calculate with my simple formula, because that's what the system seems to use when generating copper lists...

[Toni Wilen]

Originally Posted by ross

Toni, so what are the 'official' value for a 320px screen, FMODE=4, DDFSTRT=$38? DDFSTOP work from $a0 to $B8.
But a tend to use the value calculate with my simple formula, because that's what the system seems to use when generating copper lists...

Formula works because DDFSTOP "origin" is BPL1DAT write position but it is more like accidental side-effect

Originally Posted by Jobbo

I was expecting the same behavior as FMODE=1 but instead it does something very strange. I wonder if anyone found a creative use for whatever is happening.

More details here: http://eab.abime.net/showthread.php?t=86883

[ross]

Originally Posted by Toni Wilen

Formula works because DDFSTOP "origin" is BPL1DAT write position but it is more like accidental side-effect

ah, ok
However fortunately it is easy to be sure and check for a correct value.

In any case, there is values of all kinds in AGA productions, even absurd things corrected through the modulo and wasted dma fetches...

[Antiriad_UK]

I've not done any AGA programming since coming back to Amiga but in my macros include from when I had my A1200 i'd set up these values. Can't remember if I got it out of some dodgy photocopy of the AGA spec I had or if something I just made up because it looked to work for OCS and AGA. It comes to $b8 for fmode=4x, 320px. What value does the OS use?

MEMORYFETCHMODE	equ	0		;0 (OCS),1 or 3 
	ifeq	MEMORYFETCHMODE
DDF_INCREMENT	equ	1
	else
DDF_INCREMENT	equ	(MEMORYFETCHMODE+1)&$fffe
	endif	

*************************************************************
DDF_START set $38
DDF_WORDWIDTH set 20
DDF_STOP set DDF_START+((DDF_WORDWIDTH-DDF_INCREMENT)*8)

[ross]

Originally Posted by Antiriad_UK

DDF_STOP set DDF_START+((DDF_WORDWIDTH-DDF_INCREMENT)*8)

That is equivalent to the formula I've posted :

DDF_WORDWIDTH*16=px, DDF_INCREMENT*16=DMA_width

[Jobbo]

Sorry to resurrect this thread but I've been looking at this code again and wondering if HAM5 is even a problem for AGA.

I think I had assume it was because of earlier HAM7 trick tests. But I tried it in Winuae and it seems fine.

Before I delete my AGA specific code path can anyone confirm whether it's needed or not?

Thanks

[ross]

Yes, it should work fine.

I wrote inaccuracies.
See old message #2 and subsequent message for details..

The corner cases that I mentioned would foresee that HAM5 leaves the freedom to manually use BPL5DAT and that HAM could be usable with 5 bitlanes on AGA, which is not possible.
Sorry paraj, I dragged you into my mistake

[paraj]

If you post a test executable I (or someone) else can try it out on on an A1200. If you avoid the corner cases that Ross mentions I don't see why it wouldn't work like on an ECS machine at least.

[Jobbo]

Thanks. I’ll test on my 1200 to be sure. But seems like I just got confused at the time and then did a bunch of unnecessary work.

[ross]

Gah.., sorry.
I probably still mixed the HAM4+/7planes/OCS mode with the regular one.
In OCS/normal HAM the unused plane is automatically set to 0, so there is no corner cases (no weirdness with BPL6DAT).

To sum up:

OCS/ECS: HAM works at any bitplane depth.
- HAM4: both missing bitplane will be 0, so a 'regular' 16 colors mode
- HAM4+/7: 4 bitplanes for Agnus, 6 for Denise, so you can manually use BPL5DAT and BPL6DAT to make effects
- HAM5: the missing sixth bitplane will be 0, only blue color component can be modified
- HAM6: regular HAM

AGA:
- HAM bit enable HAM mode only in 6 or 8 bitplanes mode
- this means that to emulate HAM4+ and HAM5 modes you need to enable HAM with 6 bitplanes and let the DMA do a full data fetch (and 'emulate' the effect)

So yeah, you need a separate path in your code to handle the different chipsets.

If there is something more I will add a note