Lmix_LxU blending test looks broken on core3.1.5

[ped7g]

Areas which should be transparent and display white background there is the $E3 pink colour instead.

It's not clear whether the blending-mode changes from core3.1.5 make the original setup of test invalid and this is correct result, or the original test should have displayed the screen as before and this is new core bug.

Investigate:

• if the test sets up blending mode explicitly enough (account also for the state modification by NextZXOS)
• if the pink or white background should be result of such setup with new core
• fix the test or report core bug
• and BTW add test for the new blending modes
• and probably improve the old test as well, as even core 3.0 produced different results depending whether ula+tiles or just-ula was blended.

[ped7g]

The setup was way from core2.0.x times, not doing anything explicit about new regs like $68, $6B, $70, ...
But even after modifying the setup to be more explicit the visual results are still same.

With further research the pink is coming from "fallback colour" $4A register.

My current hypothesis is that core3.1.5 has bug. The blending mode is described as:
"(U|T)S(T|U)(B+L)" which in my understanding means this:

• first "(U|T)" is opposite layer to the second "(T|U)" (i.e. what is not used for blending, could be shown above every other layer)
• the second "(T|U)" is the source of data for blending, either only ULA pixels, or only Tilemode pixels or both ULA and Tilemode pixels as single input layer (the LoRes layer acts as ULA pixels in case of enabling LoRes mode). This is what becomes "B" in the following "(B+L)"
• the "(B+L)" is meant as the blending method of some kind of ULA related pixel ("B") and Layer2 pixel. The color channels are simply added together (clamping the maximum value to 7).

Now the transparency rules should be like this ... long pause, looking for official docs... didn't find any, so this is unofficial info I got probably directly from Allen long ago:

• ("UP" is "ULA pixel - non transparent", "LP" is Layer2 pixel non-transparent, "UT"/"LT" are ULA/L2 transparent pixels)
• UP + LP = blending + priority from LP
• UT + LP = LP (with priority)
• UP + LT = UP (with priority from LT (!)) (this one seems malfunctioning in core3.1.5)
• UT + LT = transparent pixel (fallback colour register as there is nothing "under" the blending layer

There were recent changes adding the "front" non-blend layer (first "(U|T)") which I did not test yet and the failure in Lmix_LxU is happening between the LoRes vs Layer2 blending.

Needs further explanation/confirmation from Allen, if this is happening or I messed it up somewhere... :)

[ped7g]

Allen confirms this is by-design change, i.e. "UP + LT" case should really result in transparent pixel with 3.1.1+ cores.

We are still discussing it, if this is going to stay like this, but seems likely to stay, so the test needs to be fixed then.

[ped7g]

Test updated to core3.1.5 blending rules, photos updated, description fixed.

Open: extend the test or create new test to exercise all the new core3.1.5 combinations, with ULA vs Tilemap capable to be displayed separately.

[ped7g]

the core 3.1.10 (since 3.1.3? But test-confirmed on N-Go with 3.1.10 core) "(U|T)S(T|U)(B+L)" meaning:

• nextreg 0x68 bits 6:5 configures non-blending/blending layers, the "U|T" and "T|U" are non-blending, the "B" are the blending layers.
• non-blending Tile layer is above/below Sprite layer (!) depending whether it has flag above/below Ula layer (verified in test)
• non-blending Ula layer is above/below Sprite layer depending also on Ula above/below Tile layer (hypothesis, not verified)
• blending Ula|Tile + Layer2 is always at bottom, except when Layer2 priority color is used to raise above everything else.

Open: extend the test or create new test to exercise all the new core3.1.5 combinations, with ULA vs Tilemap capable to be displayed separately.