V9990 - Discrepency between emulation and PowerGraph Lite

Master (162)

22-04-2018, 12:25

I have found what appears to be a discrepancy between the OpenMSX V9990 emulation and real hardware.

In my game I fill the background by filling a 4x192 pixel strip on the far left of the screen, and then doing an LMMM copy of area sized (252,192) from (0,0) to (4,0)... the idea being that the copy reads the bytes it just wrote, and fills the whole screen.

This works fine on OpenMSX, but on the real hardware it appears there is a 2 byte cache or other delay of some kind ,as the function was not writing the data it had just read, causing a 'streaking' of objects that got worse over time.

Changing the width of the copied area to 8 pixels resolved the issue.

I have a photo of the screen below, right is the correct one, left is the faulty one... note that even if the gradient was not copying, the 'flag' of the castle should have copied all the way across the screen if the copy command was working as expected.

Thanks,
Keith
http://www.chibiakumas.com/download/V9990Bug.png

ログイン/登録して投稿

By Grauw

Ascended (10821)

22-04-2018, 13:17

I think what’s happening is;

The V9990 LMMM always operates on 16 bits at once, which equals four pixels in 4bpp modes. Unlike the V9938 which operates per-pixel for LMMM, so it has HMMM for higher performance, the V9990 always takes 16 bits at once, masking off bits as needed on the edges.

For high performance, I think it’s pipelined to read the next unit of pixel data before it writes the previous result, so that the command engine does not need to wait for the read when moving on to the next unit.

But if you use an overlapping copy with the destination offset by 4 pixels, it means it’s shifted by exactly one internal processing unit. This would mean that as it writes those 4 pixels, the read will still have received the old value for them, and the copy won’t have the effect you would expect if you’d assume it writes first and then reads. If you increase the copy offset to 8 pixels, there’s an additional processing cycle between when a pixels’s value is written and when it’s read again, so it will work as expected.

By msd

Paragon (1532)

22-04-2018, 13:22

Nothing that can be solved by using he write mask?

By keith56

Master (162)

22-04-2018, 14:54

I have the write masks permanently set to 255, so I don't think that's it... I'd expect to see issues with my other sprites if that was it.
My game is working fine now just by changing the size of the copied area. it's just that the real hardware had a problem, and the emulation did not, so I suppose the 'emulator' should contain the same limitation.

By Manuel

Ascended (19680)

22-04-2018, 15:11

The V9990 emulation isn't at all as advanced as the V99x8 emulation in openMSX. Keep that in mind. We're very open to improvement patches, with a good motivation and explanation on why it is an improvement.

By keith56

Master (162)

22-04-2018, 15:18

The V9990 support openMSX already supplies is excellent... I've not seen any other difference at all, and I would not have been able to develop a V9990 game without OpenMSX's help

if this is outside of the scope of what it's planned to cover at this time, then that's totally fine, I'm just raising it so people are aware of it, I don't want to figure it out what the problem is, then keep it secret to myself.

By hit9918

Prophet (2932)

22-04-2018, 15:18

msd, you suspect the mask bits very often.
I think it is this way: you suspect that they are address masks. but I suspect it is data masks. to enable amiga bitplanes within a nonbitplane mode!

now, there are two bytes for the 16bit per pixel modi.
then one register hits every second byte.
and in parallax mode maybe every second byte is a whole different layer.
there is a bit the smell of address busines, but that happens only because there are multiple bytes in a 16bit word.
but still the mask register contents are always data mask, never address mask.

By Manuel

Ascended (19680)

22-04-2018, 15:53

I'm very happy you come up with such reports. But I'd be even happier if someone would reach out to us to help improving the emulation accuracy. It's a lot of hard work to figure out how the hardware works in detail.

By Grauw

Ascended (10821)

22-04-2018, 16:24

Manuel: Hopefully my theory on why this occurs is a workable one for a fix .

I was talking about the issue with Keith over Twitter, and because of this theory I suggested he try 8-pixel offsets, which indeed solved the issue, so to me that’s gotta be it .

About the write mask, as the VDP commands always operates on 16 bits at once, the mask is just a logic operation on those. For the 0 bits it selects DC rather than WC. A mask is used internally to deal with unaligned pixel coordinates, friendly of them to expose the functionality to the end user as well.

I have to say the V9938 often gets criticised here for its slow command engine implementation, after considering a bit more deeply the V9990 implementation, Yamaha really stepped up their game there.

p.s. So as the PC-Engine advertised being a “16-bit computer” due to having a 16-bit VDP even though the CPU was 8-bits, I guess with the V9990 our MSX is equally 16-bit, certainly if you add the R800!

By Manuel

Ascended (19680)

22-04-2018, 16:55

Keith, can you provide the buggy ROM to test a possible fix?

To be clear: no promises that it will be fixed, time is quite scarce these days. But without a test case, chances are much lower that it will ever be fixed.

By msd

Paragon (1532)

22-04-2018, 16:57

@Hit9918: i don’t suspect it is an address mask . It is a write mask.