Small inconsistency with 9938 VDP timings...

Page 2/4
1 | | 3 | 4

By gdx

Prophet (2977)

gdx's picture

01-08-2019, 15:47

shram86 wrote:

i.e. set the location of VRAM access (I store these in hl and increment accordingly) then immediately load. I don't quite understand how a RAM buffer can help in this particular circumstance, and I don't see any solution besides NOP.

The two NOPs are insufficient on many MSXs if I remember well.

By Grauw

Ascended (8373)

Grauw's picture

02-08-2019, 13:09

A-ha. So you’re reading during vblank, and assuming you don’t need to wait then. That explains it:

During vblank all the access slots are free for the CPU and VDP commands to use, so writing can be done without waiting. However since for reading the VDP needs to wait for an access slot to pre-fetch the data, the CPU may still need a (short) wait before the read buffer at 98H is filled.

Reading the openMSX research I think the data should be ready in just 32 VDP cycles (~6 CPU cycles), but maybe I don’t have the full picture.

Sprites enabled also doesn’t matter during vblank btw.

Regarding the MSX assembly page, waits are only needed for VRAM reads and writes, if I still have it saying somewhere on the MAP that you need waits for VDP register reads and writes then please let me know and I’ll fix it :). A lot of the documents there were written a long time ago, under the same mythical knowledge that I mentioned earlier, so there could be some legacy remaining here and there.

By shram86

Expert (88)

shram86's picture

01-08-2019, 16:49

Ah, this explains it, thanks guys.

@gdx do you have more information? (my model is HB-F1XD mk2, stock).

What data do you think the openMSX team needs to emulate this timing more accurately?

By DarkSchneider

Paladin (860)

DarkSchneider's picture

01-08-2019, 20:03

Sure, report it.

By wouter_

Champion (417)

wouter_'s picture

01-08-2019, 21:12

Hi,

I did (most of) the research Grauw is referring to. And I implemented this in openMSX. To the best of my knowledge this is the most accurate known description of the V9938 timing, but it's still only a model and it's not 100% accurate.

I believe the emulation cannot be made more accurate by only tuning the parameters in this model (e.g. by using stricter cycle limits for the time between setting the VRAM address and reading/writing the data, as discussed in this forum topic). Because when we do that we also break other MSX software that is currently working fine (both in emulation and on real hardware). So instead, I think, the model should be extended with additional rules, corner cases, exceptions, ... I have no clue what those extensions should be.

Investigating this stuff is _very_ time consuming, and I have no immediate plans to continue working on this. But I'm willing to support/help anyone who can invest that time. In other words, help would be much appreciated.

By shram86

Expert (88)

shram86's picture

02-08-2019, 01:00

wouter_, thanks for the reply. Don't worry, I understand this being super low priority.
The emulation of the VDP is very difficult to begin with, much less edge cases like these. (Without a unique code path to handle direct VRAM reads immediately after setting VRAM target with sprite mode on, this issue would never occur anyway.)

To cap this off I'll just say I disabled sprite rendering and deleted the NOPs and that fixed the issue as well, so it was indeed the vdp command buffer/access window timings.

Thanks again all - I'll just have to remember this in the future and be diligent about testing on hardware.

By DarkSchneider

Paladin (860)

DarkSchneider's picture

02-08-2019, 08:39

Yes definitely is a VRAM access issue. The test are usually made in SC5, that involves less accesses, only bitmap color and sprite (if on). On SC4, VDP has to access, per pixel, to the pattern layout (at least once per 8 px), the pattern gfx, and the pattern color, and also sprites if on.

By Grauw

Ascended (8373)

Grauw's picture

02-08-2019, 10:07

shram86 wrote:

To cap this off I'll just say I disabled sprite rendering and deleted the NOPs and that fixed the issue as well, so it was indeed the vdp command buffer/access window timings.

If disabling sprites matters it means you were rendering outside of vblank... fine, but that would explain why it wasn't fast enough. Maybe inside blanking it is fast enough to read immediately after all, if my previous calculation was correct.

You can easily see how long your ISR takes by changing the background colour until it's done.

shram86 wrote:

Thanks again all - I'll just have to remember this in the future and be diligent about testing on hardware.

Always important! OpenMSX is an accurate emulator which is definitely good for development, and emulators also make it easy to test many different machines and configurations so they’re actually good tools to improve compatibility. But there's always going to be cases where the emulation does not match with the real thing, so it remains important to test with that.

DarkSchneider wrote:

The test are usually made in SC5, that involves less accesses, only bitmap color and sprite (if on). On SC4, VDP has to access, per pixel, to the pattern layout (at least once per 8 px), the pattern gfx, and the pattern color, and also sprites if on.

Those articles by Wouter (openMSX) that I mentioned have really nice charts.

By DarkSchneider

Paladin (860)

DarkSchneider's picture

02-08-2019, 12:59

Grauw wrote:

Those articles by Wouter (openMSX) that I mentioned have really nice charts.

Yes that's very good article (link broken, but already knew and read them), but more oriented for technical than for programmer, just like the timmings on data sheets on official manual. Also is nice to get some concept for planning the design to maximize its usage under some circumstances. The memory slots availability on different cases were really useful.

Page 2/4
1 | | 3 | 4