OpenMSX / G9K / Real hardware issue / V9990

I'm not saying that was not a bug on my side (V9_SetLayerPalette was fixed yesterday).
I'm saying that the bugged code works fine on emulators and not on real hardware.
For an accurate emulation of V9990, the emulators should not display correctly when PLTM is not 0 in P1 and P2 mode.
That said, I don't know the detail of what is going on when this is not the case, but I suppose the V9990 try to interpret tiles colors as 8-bits colors.

I will make more test to confirm that the emulation issue come from PLTM setting (I'm pretty sure ^^), but it will be hard to understand what is going on exactly with invalid setting.
If I can confirm that is a PLTM problem, emulators could at least trigger a warning when PLTM is not zero in P1 and P2 mode.
And like pizzapower said, it should be nice to also trigger a warning when trying to read from a write-only registre, or write to a read-only one.

I did some experiments with my V9990 sample and the result is...interesting.
The register R#13 is defined as follows:

//-----------------------------------------------------------------------------
// R#13 - Palette control register - Write only
//-----------------------------------------------------------------------------
//  7   6   5   4   3   2   1   0
//  TM1 TM0 YAE PIH TO5 TO4 TO3 TO2
//  │   │   │   │   └───┴───┴───┴── Still screen palette No. offset
//  │   │   │   └────────────────── Palette No. increment control at color palette read-out
//  │   │   │                        0: After P#1 read-out, R#14 palette pointer undergoes an increment.
//  │   │   │                        1: R#14 palette pointer is not changed by P#1 read-out.
//  │   │   └────────────────────── Selection of YJK (YUV) and RGB mixing mode (valid when in YUV and YJK modes)
//  │   │                            0: Only YJK (YUV) image is displayed.
//  │   │                            1: YJK (YUV) and RGB images are displayed together.
//  └───┴────────────────────────── Selection of color palette mode
//                                   0: Palette mode
//                                   1: 256 color mode
//                                   2: YJK mode
//                                   3: YUV mode

So, in P1 or P2 mode, the 4 MSB are supposed to be 0 while the 4 LSB designate the palette to use for the tiles plane(s).

What happens on real hardware if we set MSB in P1 and P2 mode?
- Bit #4 (PLTAIH): No impact on the rendering (but changes the access to the palette register).
- Bit #5 (YAE): No impact on the rendering when PLTM is not YJK or YUV (as expected).
- Bits #6 & #7 (PLTM):
-- 0 (Palette): Expected value.
-- 1 (RGB): This is the interesting behavior. The tiles colors are modified but sprite colors are preserved (see bellow).
-- 2 (YJK) and 3 (YUV): Full screen color changed (sprites turn black).

This is pure speculation, but when PLTM is RGB, the screen being in red and blue gradient, I think that the 4-bits of each pixel of the P1 and P2 mode are interpreted as the 4 LSB of the 8-bits coding of the RGB mode (2 out of 2 blue bits, and 2 out of 3 red bits).
It may be the same for the YJK and YUV modes, but the patterns are much less understandable.

On OpenMSX and WebMSX, setting R#13 MSB don't change the display.
I will send a report to the emulators' GitHub.

The sample program is available here: https://msxvillage.fr/upload/msxgl_v9990.zip (in ROM or DOS .com format).
Key [1], [2], [3] and [4] toggle bits 4 to 7 of R#13.