[v9990] palette split

Page 1/2
| 2

By Metalion

Paragon (1512)

Metalion's picture

17-05-2022, 09:06

Is it possible to make a palette split ?
(change the palette number of P1 layer B at HBLANK, and change it back at VBLANK)

Login or register to post comments

By GhostwriterP

Hero (663)

GhostwriterP's picture

17-05-2022, 18:08

yes

By Metalion

Paragon (1512)

Metalion's picture

18-05-2022, 20:22

Thanks Ghostwriter.
What about a layer priority split ?

You can set up priority of layer B over layer A using R#27, but only by 64 pixels increments.
I want to change that priority somewhere between the values of 128 and 192.
Is that possible ?

By GhostwriterP

Hero (663)

GhostwriterP's picture

18-05-2022, 21:59

Allotments... I never played around with that, so I would not know.
The thing is that the upper left 64x64 pixels will always be "A" as front, so I never found it that appealing... But I realize now that once you get below the first 64 display lines, in theory, it could be possible to swap "A" and "B" priority completely over full screen width (using PRY0 & PRY1), if that works it could be interesting after all indeed!
The question is whether or not the V9990 reads out that register during display period... and that is something I cannot confirm at the moment. But maybe someone else can?
You can also try out yourself.. if you do please let me know your findings!

By Metalion

Paragon (1512)

Metalion's picture

19-05-2022, 09:20

Yes, I will try for myself on my TMTLogic GFX-nine.

I need to set up priority to layer A from y=0 to y=164, and then switch priority to layer B after that.
Using static value of R#27 does not work for me: 128 is too early, and 192 is too late.

By the way, I will have a triple split @164 : layer B scroll, palette, layer priority !

By Metalion

Paragon (1512)

Metalion's picture

25-05-2022, 19:50

Well, the triple split (scroll, palette, layer priority) works on OpenMSX.
But it does not on real hardware !
Only scroll and palette split seems to work on real hardware (tested on TMTLogic GFX-nine).

Once I added the layer priority split, it seemed that the layer priority was reset.
- on hblank at line 164, I was setting layer B on y=[128,212] (PRY=2 in R#27).
- then on vblank, I was setting layer B priority on y=[192,212] (PRY=3 in R#27).
On real hardware, after hblank, the layer A had full priority.

Crying

By Manuel

Ascended (18791)

Manuel's picture

25-05-2022, 23:50

Please create a bug/issue in the openMSX GitHub tracker with a test program and the results on real hardware.

By Metalion

Paragon (1512)

Metalion's picture

26-05-2022, 08:09

I will. Is that here ?
https://github.com/openMSX/openMSX/issues

I wonder if it could be linked to the same issue about the scroll split (Y position being reset).
I will try to do further tests to explore that possibility.

By GhostwriterP

Hero (663)

GhostwriterP's picture

26-05-2022, 12:17

Bummer that it does not work!

Metalion wrote:

- on hblank at line 164, I was setting layer B on y=[128,212] (PRY=2 in R#27).
- then on vblank, I was setting layer B priority on y=[192,212] (PRY=3 in R#27).
On real hardware, after hblank, the layer A had full priority.

layer A only until line 192 I suppose? The values described above would suggest that at start of screen display the the allotment is set such that layer B gets priority at line 192 (PRY=3 in R#27). So, does writing completely reset to layer A full priority, i.e. PRY=0 in R#27? Or does de vdp simply ignore the register update and executes according the setting at start of display?

By Manuel

Ascended (18791)

Manuel's picture

26-05-2022, 15:08

@Metalion Yes, that's the place. Thanks!

By Metalion

Paragon (1512)

Metalion's picture

26-05-2022, 19:29

GhostwriterP wrote:

So, does writing completely reset to layer A full priority, i.e. PRY=0 in R#27? Or does de vdp simply ignore the register update and executes according the setting at start of display?

Whatever the value of R#27 I was writing (hblank: PRY=2 or vblank: PRY=3), after y=192, layer B had always the priority. And that was what I was seeing on OpenMSX. But on real hardware, the graphics from layer B disappeared after hblank. I can only suppose that the layer A had now priority, despite the fact that the R#27 value was different than zero.

I'm making a parallel with the scroll split, where the Y position is reset when changing value during display. So maybe the same thing is happening here. Which would mean that the value of R#27 would be correct, but since the Y position is offset, it would not work as expected.

If that's the case, then my layer priority split will never work, since layer B priority can only be changed 64 lines after the start of the screen. SInce hblank is @164, it would only be effective @164+64=228.

But again, it's only an hypothesis.
I need to do some additionnal tests to confirm that.

Page 1/2
| 2