OpenMSX / G9K / Real hardware issue / V9990

Page 3/4
1 | 2 | | 4

By GhostwriterP

Paladin (682)

GhostwriterP's picture

09-09-2021, 19:42

I got this one for you (NTSC only):

----------------------------------------------------
       |                  COMMAND (kb / frame)
 MODE  |--------------------------------------------
 60Hz  |  LMMM  |  BMLL  |  BMXL  |  BMLX  |  LMMV
----------------------------------------------------
P1 sON |  6.125	|  6.125*|  7.875 |  7.250 | 12.875
   sOFF|  9.125 |  9.125*| 11.500 | 10.375 | 19.250
----------------------------------------------------
* double in case of copying to plane A en B at the same time.

I remember there was an even more detailed one on GitHub, used for tuning speed in openMSX if i am not mistaken.

By Trebmint2

Master (242)

Trebmint2's picture

09-09-2021, 21:36

GhostwriterP wrote:

I got this one for you (NTSC only):

----------------------------------------------------
       |                  COMMAND (kb / frame)
 MODE  |--------------------------------------------
 60Hz  |  LMMM  |  BMLL  |  BMXL  |  BMLX  |  LMMV
----------------------------------------------------
P1 sON |  6.125	|  6.125*|  7.875 |  7.250 | 12.875
   sOFF|  9.125 |  9.125*| 11.500 | 10.375 | 19.250
----------------------------------------------------
* double in case of copying to plane A en B at the same time.

I remember there was an even more detailed one on GitHub, used for tuning speed in openMSX if i am not mistaken.

Wow that's slower than I hoped... I'm going to have to beg Jorn for the interrupts so I dont have to hang waiting for commands to finish Smile

By Manuel

Ascended (19223)

Manuel's picture

11-09-2021, 15:09

GhostwriterP wrote:

That test case already exists: Beast
directly from github link as issue to be solved, guess it snowed under ;)

This issue should now be solved. Please try the latest development build. The cause was totally different than you thought, though. See the issue link :)

By aoineko

Paladin (806)

aoineko's picture

05-09-2022, 21:56

Are there any known issues in V9990 emulation with OpenMSX?
I am developing a V9990 module for the MSXgl C library and would like to know how much I can rely on OpenMSX to test it.

By Grauw

Ascended (10681)

Grauw's picture

05-09-2022, 23:02

The openMSX developers do what they can and fix bugs as they are found, so I don't think there are major known issues. But the software lineup to test with is small and there aren't many demoscene productions that really push the hardware. There also hasn't been as much research done as e.g. for the V9938.

So do not rely solely on V9990 emulation, it is not bad but relatively immature, and issues are still found on a fairly regular basis. Definitely test on real hardware, and if you do run into a difference, definitely report it to the openMSX team.

By pizzapower

Master (133)

pizzapower's picture

13-09-2022, 07:33

I tried using R#22 to disable layers in P1, but it's not working. At least not on OpenMSX. Any ideas? Here is my code:

static __sfr __at(G9K_REG_DATA) port_p3;
static __sfr __at(G9K_REG_SEL)  port_p4;

void enable_register(uint8_t reg, uint8_t bits)
{
    port_p4 = reg;                              // select register reg
    uint8_t tmp = port_p3 | bits;               // read value and change bits
    port_p3 = tmp;                              // ... and write it back
}

inline void disable_bank_a()
{
    enable_register(22, 0x80);
}

By pizzapower

Master (133)

pizzapower's picture

14-09-2022, 19:42

Seems like changing bits 8 and 7 is not documented in the official V9990 programmer's manual, even if g9klib supports it. Can we implement this on OpenMSX?

By Manuel

Ascended (19223)

Manuel's picture

14-09-2022, 22:11

If you understand exactly the behaviour on real hardware and have test cases for it, then it can possibly be implemented.

By aoineko

Paladin (806)

aoineko's picture

30-11-2022, 01:19

Hi,
I found an issue in V9990 emulation for both OpenMSX and WebMSX.

In P1 and P2 mode, I was setting only the 4 LSB of R#13 (PLTO) to change tile layers palette.
It work well on emulators but color was bugged on real HW.
Forcing all 4 MSB to 0 solved the problem.

I don't know exactly what other bits have to be reset (this register is write-only), but I suspect bits 6&7 (PLTM).

Here is my sample program:
https://github.com/aoineko-fr/MSXgl/commits/main/projects/sa...

- Version from November 15th only work on emulators.
- Version from November 30th work both on emulators and real HW.

By pizzapower

Master (133)

pizzapower's picture

30-11-2022, 03:11

aoineko wrote:

Hi,
I found an issue in V9990 emulation for both OpenMSX and WebMSX.

In P1 and P2 mode, I was setting only the 4 LSB of R#13 (PLTO) to change tile layers palette.
It work well on emulators but color was bugged on real HW.
Forcing all 4 MSB to 0 solved the problem.

I don't know exactly what other bits have to be reset (this register is write-only), but I suspect bits 6&7 (PLTM).

Here is my sample program:
https://github.com/aoineko-fr/MSXgl/commits/main/projects/sa...

- Version from November 15th only work on emulators.
- Version from November 30th work both on emulators and real HW.

PLTM0 and PLTM1 should aways be 00 in P1 or P2 mode, since that is the right setting if you are using palette mode.

Palette Control 

       B7    B6    B5    B4    B3    B2    B1    B0  
R#13  PLTM1 PLTM0  YAE  PLTAIH PLT05 PLT04 PLT03 PLT02

PLTM1 PLTM0  Selection of color palette mode
  1     1    : YUV mode
  1     0    : YJK mode 
  0     1    : 256 color mode
  0     0    : Palette mode

But checking your code, that's not what you were doing:

inline void V9_SetLayerPalette(u8 a, u8 b) { V9_SetFlag(13, V9_R13_PLTO_MASK, ((b & 0x3) << 2) + (a & 0x3)); }

Since V9_SetFlag reads a write-only register by invoking V9_GetRegister:

inline void V9_SetFlag(u8 reg, u8 mask, u8 flag) { V9_SetRegister(reg, V9_GetRegister(reg) & (~mask) | flag); }

And ~mask in this case was 0b11110000, which allows whatever you read from V9_GetRegister to set the MSBs. So it's not exactly an emulation issue when you invoke a non-defined behaviour. You are probably reading some random bus value and setting PLTM1 and/or PLTM0 with something that is not zero. Emulators don't implement unexpected behaviours, but maybe they could warn you if code tries to read write-only registers.

You could save the previous value in backup memory (say, a V9_RG13SAV byte) and use that ORed with the new value. That's the usual way MSX changes a specific set of bits on write-only registers. ;)

Page 3/4
1 | 2 | | 4