vdp corruption

Page 1/5
| 2 | 3 | 4 | 5

By norakomi

Paragon (1092)

norakomi's picture

20-11-2019, 22:08


I got some vdp corruption.
I can't seem to figure out what causes this.
Does anyone have an idea ?

Login or register to post comments

By turbor

Champion (486)

turbor's picture

20-11-2019, 22:45

Looks a little like the corruption you get when doing screensplits...
Are you writting some of the controller registers at this point? page swapping during display was one of those things that caused a few pixels (like 4 or so) to be "randomly colored". A lot of the old diskmagazines had trouble with this.
Also updating some of the spritetables can cause this flicker iirc.

By gdx

Enlighted (4706)

gdx's picture

21-11-2019, 09:20

These may be sprites.

By Manel46

Hero (627)

Manel46's picture

21-11-2019, 12:07

In case they are sprites, try activating bit 1 of R # 8. This inhibits them.
If you use vertical scroll hardware, the correct thing is to place the sprite tables at the end of the vram.

By norakomi

Paragon (1092)

norakomi's picture

24-11-2019, 17:42

I turned off sprites, this wasn't the issue.
The vdp corruption only occurs on real hardware, not on the emulator.
I'm not using screensplits. I do page swapping (after building up the screen).
I'm not using r#18.

By sd_snatcher

Prophet (3473)

sd_snatcher's picture

24-11-2019, 18:23

I was also going to say that they were sprites.

Let's get some more info to try to map the problem:

1) What's your real machine? Any mods?

2) Are there any CPU-to-VDP accesses occurring at that area of the screen?

By Manel46

Hero (627)

Manel46's picture

24-11-2019, 21:58

One issue to consider, is that operations with the vdp, take their time. Sometimes it is worth putting a "halt" strategically, which apart from synchronizing with the sweep, adds a small timed.
Another question is, especially if you use the vdp in the interruptions, but if not also, inhibit the interruptions to write in it.


Enlighted (5876)

NYYRIKKI's picture

25-11-2019, 08:37

Strange... If you can tell your exact hardware specs & what you are doing when this happens, then maybe we can guess the most likely cause...

This looks to me a bit similar problem that many early VGA cards (and V9990 IIRC) had while changing color palette on the fly, but AFAIK V99x8 has not ever suffered from this kind of problems. I would say that you now manage to somehow make VDP so busy that the VRAM read (to screen) fails during screen draw. How? I have no idea, it should not happen. With this little knowledge I can only suggest to try to add some NOPs here and there.

More information about VRAM timing: http://openmsx.org/vdp-vram-timing/vdp-timing.html

norakomi wrote:

I do page swapping (after building up the screen).

Maybe you should wait to end of current screen draw first?

By Grauw

Ascended (10068)

Grauw's picture

25-11-2019, 10:41

That’s very strange, I can’t think of anything that would cause that kind of artifact... Indeed I would suspect sprites, but if it also happens with sprites disabled...

Since it is spread out across the screen, it seems to be related to something that happens continuously in the main loop. What exactly are you doing in the main loop? What VDP accesses are you doing?

At this moment I suspect it is not some mysterious VDP glitch, but rather a result of modifying the VDP or VRAM during display, e.g. two related writes which are not atomic so you get to see an intermediate value on screen. The difference between emulator and real MSX could be to do with VRAM initial contents (which the emulator always cleanly resets to 0).

For example you could be writing to the sprites attribute table continuously in the main loop, the first couple of sprites having proper values but the others getting garbage, and then after writing the entire table setting the Y coordinate of the last active sprite to 216 to hide the remaining sprites. But since this is not atomic and during active display, the intermediate incorrect state of the sprites table shows up. In the emulator all these patterns are 0 because that’s what VRAM is initialised to, however on the real MSX the VRAM may be initialised to something else or have remaining data from a previous boot.

Anyway since you already tested with sprites disabled it’s probably not that, but nevertheless I would think it’s something along those lines. As said, knowing more about what exactly you’re doing with the VDP in the main loop or frame update would help pinning it down Smile.

By Manel46

Hero (627)

Manel46's picture

25-11-2019, 13:18

In the video they show the bookmarks area.
Use "split screen"?

By Manel46

Hero (627)

Manel46's picture

25-11-2019, 17:21

Are you switching between screens modes?

Page 1/5
| 2 | 3 | 4 | 5