EHB sprites with AGA chipset ?

[FrenchShark]

Hello,

I am just wondering if the sprites will have EHB colors with the AGA chipset if :
- We have 6 bitplanes with BPLCON2.KILLEHB = 0
- ESPRM = 0010 and OSPRM = 0010 (colors 33 - 47 for the sprites)
Do we have half-brite sprites or is it just on the bitplanes ?

Regards,

Frederic

[Toni Wilen]

I haven't tested but I am absolutely sure bitplanes and sprites have separate processing path until priority selection logic merges sprite or bitplane pixels.

There is no HAM or DPF sprites either

[FrenchShark]

Originally Posted by Toni Wilen

I haven't tested but I am absolutely sure bitplanes and sprites have separate processing path until priority selection logic merges sprite or bitplane pixels.

There is no HAM or DPF sprites either

Hello Toni,

just a follow-up on this topic : after implementing the sprites and bitplanes display pipeline, I think you are totally right on the separate path.

I actually discovered that a double color palette is even necessary to correctly render the HAM bitplanes with sprites on top.

I still have a question about BPLCON4.BPLAM : under WinUAE (variable "bplxor"), it is only implemented for HAM modes.
Moreover, I am surprised that it alters the HAM commands. It would have been smarter for C= to put it on the color index path only so we could get 4 x 64 color palettes in HAM8 by poking bits BPLAM7 and BPLAM6 with the copper.
What about the other modes ? Dual playfield ? Half-brite ?
Can we swap palette and get 512 colors on screen in Half-brite mode ?

Something else : are you sure that the HAM6 mode on the AGA chipset should clear the lowest R,G or B nibble of the "ham_lastcolor" variable ? It should be more logical to duplicate the upper nibble to the lower nibble, like it is done with the palette handling.

in drawing.c:
case 0x10: ham_lastcolor &= 0xFFFF00; ham_lastcolor |= (pv & 0xF) << 4; break;
case 0x20: ham_lastcolor &= 0x00FFFF; ham_lastcolor |= (pv & 0xF) << 20; break;
case 0x30: ham_lastcolor &= 0xFF00FF; ham_lastcolor |= (pv & 0xF) << 12; break;
must be:
case 0x10: ham_lastcolor &= 0xFFFF00; ham_lastcolor |= ((pv & 0xF) << 4) | (pv & 0xF); break;
case 0x20: ham_lastcolor &= 0x00FFFF; ham_lastcolor |= ((pv & 0xF) << 20) | ((pv & 0xF) << 16); break;
case 0x30: ham_lastcolor &= 0xFF00FF; ham_lastcolor |= ((pv & 0xF) << 12) | ((pv & 0xF) << 8); break;

Regards,

Frederic

[Toni Wilen]

Originally Posted by FrenchShark

I still have a question about BPLCON4.BPLAM : under WinUAE (variable "bplxor"), it is only implemented for HAM modes.

It is used in all modes, HAM is special case in display.c, other more "normal" modes are handled in linetoscr.c (generated by genlinetoscr.c)

Moreover, I am surprised that it alters the HAM commands. It would have been smarter for C= to put it on the color index path only so we could get 4 x 64 color palettes in HAM8 by poking bits BPLAM7 and BPLAM6 with the copper.
What about the other modes ? Dual playfield ? Half-brite ?
Can we swap palette and get 512 colors on screen in Half-brite mode ?

I don't think these never were fully tested (if tested at all), HAM/DPF/EHB are very rarely used, HAM/DPF/EHB+BPLCON4 is practically never used.. I guess this is yet another boring project I need to do

EDIT: I just remembered I did test HAM few months ago and it required some updates.

Something else : are you sure that the HAM6 mode on the AGA chipset should clear the lowest R,G or B nibble of the "ham_lastcolor" variable ? It should be more logical to duplicate the upper nibble to the lower nibble, like it is done with the palette handling.

I am not sure

[FrenchShark]

Hello,

I have just finished the video pipeline (well, I still need to put the DIW masking). I put BPLCON4.BPLAM xor operation on the 8-bit address bus that goes to the palette RAM.

IMHO, there are only two logical locations for BPLAM : just after the bitplanes serializers or just before the palette RAM.

Between these two locations, I have the playfield and the priority logic.

Regards,

Frederic