"Asymmetric" DPF: possible?

[TCH]

Is it possible to create a DPF screen with different bitdepth for back and front planes? For example 3 bit for the front plane and only 1 for the back.

Any approach is ok, until it works.

[ross]

Originally Posted by TCH

Is it possible to create a DPF screen with different bitdepth for back and front planes? For example 3 bit for the front plane and only 1 for the back.

Any approach is ok, until it works.

No, playfields are always separated into odd and even.

So:

--- OCS/ECS
1: 1
2: 1 - 1
3: 2 - 1
4: 2 - 2
5: 3 - 2
6: 3 - 3
--- AGA
7: 4 - 3
8: 4 - 4

[a/b]

Exactly, because you can only specify how many active bitplanes are there in total (bugs excluded :P). So e.g. 5 could mean 3/2 or 4/1, and to avoid ambiguity (and some internal HW design limitations, perhaps) the rule is always N/N if even and N/(N-1) if odd.
If you really need other combos, single playfield and split the palette and bitplanes manually as needed. It won't give you all the features of DPF (e.g. scrolling per playfield), but in some cases it might suffice. Depends what you are doing.

[TCH]

@ross:
I don't understand. Why is that a problem? The bitplanes' pointers can be set individually; isn't there a trick or anything which makes the Amiga read less bitplanes for the back, than the front or vice versa? It is not a problem, if the bitplane pointer is used, until the memory and the time of reading the non-used bitplanes are spared.

@a/b:
Bugs excluded? Is there a HW bug which allows this?

[AestheticDebris]

@TCH No, it's just a fundamental limitation of DPF on the Amiga. Of course you could always leave a bitplane empty if you want to reduce how much blitting you need to do, but you still have to pay the DMA price for it.

[ross]

Originally Posted by TCH

@ross:
I don't understand. Why is that a problem?

Not a problem per se, the bitplane pointers are all separate, but then color management must be done carefully and the two playfields cannot use separate hardware scroll.
DPF is a convenience provided by the chipset to make life easier, but it lacks support for a defined management of how to allocate the bitplanes (they are distributed equally between even and odd).
See everything a/b wrote.

Bugs excluded? Is there a HW bug which allows this?

No, if you select 7 planes in OCS/ECS, Denise see it as a 6 planes display, but Agnus only fetches 4 of it.

[TCH]

Originally Posted by AestheticDebris

@TCH No, it's just a fundamental limitation of DPF on the Amiga. Of course you could always leave a bitplane empty if you want to reduce how much blitting you need to do, but you still have to pay the DMA price for it.

Cannot i disable the reading of the unused bitplane during the screen is beamed to the monitor via Copper, or anything else?

Originally Posted by ross

Not a problem per se, the bitplane pointers are all separate, but then color management must be done carefully and the two playfields cannot use separate hardware scroll.

Why? If a bitplane is unused, then it will not affect colors or scrolling. Or you mean, it's impossible to make it unused? If yes, if the entire plane is zeroed out, then it still will not affect colors (zeros will not add to the index) and scrolling a plane of zeroes is invisible, right? Or you meant something else?

Originally Posted by ross

DPF is a convenience provided by the chipset to make life easier, but it lacks support for a defined management of how to allocate the bitplanes (they are distributed equally between even and odd).
See everything a/b wrote.

That's okay, but cannot i prevent the machine reading a bitplane, when the screen is beamed to the monitor?

Originally Posted by ross

No, if you select 7 planes in OCS/ECS, Denise see it as a 6 planes display, but Agnus only fetches 4 of it.

But it will be still divided to 3-3 and 2-2, right?

Sorry, if i ask stupid questions, but i do not know the hardware that deep to see clearly.

[ross]

Originally Posted by TCH

Cannot i disable the reading of the unused bitplane during the screen is beamed to the monitor via Copper, or anything else?

No.
This also answers the next two questions.
Even if you completely zero the bitplane you would still have the data fetch.
So what would be the point of having 3+1, if you would have to fetch 5 planes anyway?

EDIT: in fact there are uses for this case (especially for effects in demos), but you must be perfectly aware of the strengths and weaknesses, but I don't think they are what you need because I imagine you would like to do this division to reduce DMA traffic

But it will be still divided to 3-3 and 2-2, right?

It's divided 3+3, it's Denise that handle DPF (planes 5 and 6 use static BPLxDAT).
This isn't how this 'bug' is usually used anyway, we're getting off topic

[TCH]

Originally Posted by ross

No.
This also answers the next two questions.
Even if you completely zero the bitplane you would still have the data fetch.
So what would be the point of having 3+1, if you would have to fetch 5 planes anyway?

Absolutely nothing. That was my question, if the fetch is inevitable or not. If it is, then it is pointless, asymmetric DPF is not possible. Too bad.

Originally Posted by ross

It's divided 3+3, it's Denise that handle DPF (planes 5 and 6 use static BPLxDAT).
This isn't how this 'bug' is usually used anyway, we're getting off topic

Okay, i think we are finished anyway.

Thanks for the answers guys.

EDIT:

Originally Posted by ross

EDIT: in fact there are uses for this case (especially for effects in demos), but you must be perfectly aware of the strengths and weaknesses, but I don't think they are what you need because I imagine you would like to do this division to reduce DMA traffic

Yep, that was my aim.