Possible ocs/ecs chipset bug? (palette flicker)

[vagrant]

Watching Seven Seas by Andromeda, I notice there some ugly palette flickering during fades between pictures. Very noticeable with title screen (see pic.)
There are videos on YT which suggest it's been behaving like this for very long time (7+ years).

I usually only see this type of 'palette flicker' issue with AGA fastest possible/jit modes.. but in this case it is only AGA chipset displays the fades correctly(!).
CPU type and cycle exact modes look to be irrelevant.
Tested with standard quickstart configs.

[Toni Wilen]

I can't see any flickering.

[Foebane]

I have seen what may be palette flickering on OCS/ECS, but I think it's more how the routines for fading were written, like the odd-numbered colours were faded one step on one frame, with the even ones on another frame, if you know what I mean.

Some demos, especially AGA on faster models that can use JIT, have exhibited horrendous palette flickering when fading in and out, or even just animating the graphics. In that case, I find that turning off JIT is a good start to reduce it, and maybe slow down the CPU as well. One demo in particular gave me trouble this time last year ("Beats" by Loveboat) and the issue was well-discussed here then. Maybe look for "palette flickering" on these boards, especially UAE?

[Toni Wilen]

Flickery-like behavior can be normal in slow OCS/ECS fades due to limited color component range (4 bits), it also depends on fade algorithm.

[Foebane]

Exactly, Toni. I wouldn't worry, Ed, that flickering on fades on OCS/ECS is normal. Some just fade better than others.

[Tomislav]

If it is flickering as on original hardware that just means that emulation is good. Nothing to change.

[vagrant]

It is not normal
Watch; first is AGA repeated x3.. then OCS/ECS x3
[ Show youtube player ]

[Toni Wilen]

I don't care about videos, you never know what kind of extra processing is done by recorder or youtube..

Anyway, it still looks normal for slow OCS/ECS fade.

[vagrant]

I can only test on real a1200 (and it works fine).. but all my 500's have faulty drives - or no drive at all.
I don't remember it happening under OCS.. but it was at least 10 years ago and memory could be corrupt

[Foebane]

I already have that demo in my collection and I just checked it on A500 and A1200 for you on WinUAE, and I'm getting the same thing: the fade looks bad on A500 and good on A1200.

Checking Pouet.net for this prod (http://www.pouet.net/prod.php?which=5373), it came out long after AGA was released in Europe, so I can only assume that the group responsible for this slideshow programmed enhancements for AGA machines so it would look better? It's the best explanation I can think of.

[vagrant]

I must have watched a hundred times back in the day, my favourite slideshow!
Only reporting as 'possible bug' because it seems weird I've never noticed it before.. but maybe this is simply the case, don't know
I'll try and resurrect one of my a500's.

[britelite]

Originally Posted by ED-209

It is not normal
Watch; first is AGA repeated x3.. then OCS/ECS x3
[ Show youtube player ]

Based on that video I'd say it's pretty obviously a 24bit fade on AGA and 12bit fade on OCS. So no WinUAE bug here, it works as it should.

[Foebane]

Exactly what I thought, Britelite.

[ross]

Cannot be the only reason.
Yes, there is 12/24 bits differences but not so accentuated, if properly written an ECS fade cannot be so wrong.

I guessed there is a rounding error somewhere.
So I inspected the copper list and found the problem.

For some odd reason Andromeda guys zeroed the low bits color components (maybe not understanding AGA behavior?) so the colors are not the same in OCS/ECS and AGA!
AGA designers did the only and right thing to maintain compatibility: mirror low bits with high values so tint are better spread an the b/w spectrum are saturated. This copper list break this rule .

If you fade this different colors then obviusly there are rounding error when you have less bits available.

[EDIT: in fact, watching the video carefully can be seen that all AGA colors are less saturated]

[vagrant]

Britelite: obvious to a coder perhaps

Well I managed to get a 500 working anyway;
Behaves exactly the same as winuae, so only my memory that is bugged

I also managed to find an stock a600 in the dungeon (it's a magic dungeon).. under ECS the title screen is completely trashed, as is every picture displayed afterwards. So not replicating winuae in this case.

Useless information? Probably... at least I have the hardware ready to do proper testing now before boring Toni with premature assumption.

[vagrant]

Originally Posted by ross

so the colors are not the same in OCS/ECS and AGA!

Interesting.. I noticed the purple background during end part is a lighter shade under AGA.

edit: and thanks to everyone for investigating of course

[ross]

Well, effectively there is other strangeness.
On AGA, KILLEHB is used but the 32 high colors are the same tint as lows but with halfbrite self imposed .

EDIT: can be explained in case of recycling of the copper list and images that actually have 64 real colors in the slideshow.
But if your image is from start EHB why not use it in AGA?
Two different fading routines is mandatory in this demo or a better one..

[Toni Wilen]

Originally Posted by ED-209

I also managed to find an stock a600 in the dungeon (it's a magic dungeon).. under ECS the title screen is completely trashed, as is every picture displayed afterwards. So not replicating winuae in this case.

I narrowed this down to ECS Denise. Same happens with A600 and also with A500 if it has ECS Denise (8373R4)

I still don't know why. Perhaps demo has strange AGA detection and misdetects it when only ECS Denise is installed? (EDIT: No, it isn't AGA detection) Or it writes to some ECS Denise/AGA registers that coder assumed are only in AGA?

EDIT: That was really stupid bug. BPLCON2 ECS Denise new bits were ignored, only AGA enabled them. Demo sets KILLEHB.

EDIT2: Fixed. Now palette is "correctly corrupted" if ECS Denise

[vagrant]

Excellent Toni
Glad the thread had some use in the end

[ross]

Originally Posted by Toni Wilen

EDIT: That was really stupid bug. BPLCON2 ECS Denise new bits were ignored, only AGA enabled them. Demo sets KILLEHB.

Interesting
So practically you have a BPL6PTx pointed DMA fetch that goes to "nothing" (if i'm not wrong is an ECS feature for a genlock mask).
Is the last loaded value in BPL6DAT used to compose the final colour?
(no, i'm not for an ECS only mask effect..)

However, it looks a lot like a bug than a feature.
Much better if they used a bit for "bitmap genlock mask active".
This forces a specific control on the KILLEHB bit use.