vdp corruption

Página 1/5
| 2 | 3 | 4 | 5

Por norakomi

Paragon (1092)

imagem de norakomi

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 ?

Entrar ou registrar-se para comentar

Por turbor

Champion (485)

imagem de turbor

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.

Por gdx

Enlighted (4693)

imagem de gdx

21-11-2019, 09:20

These may be sprites.

Por Manel46

Hero (627)

imagem de Manel46

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.

Por norakomi

Paragon (1092)

imagem de norakomi

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.

Por sd_snatcher

Prophet (3471)

imagem de sd_snatcher

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?

Por Manel46

Hero (627)

imagem de Manel46

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 (5873)

imagem de NYYRIKKI

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?

Por Grauw

Ascended (10056)

imagem de Grauw

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.

Por Manel46

Hero (627)

imagem de Manel46

25-11-2019, 13:18

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

Por Manel46

Hero (627)

imagem de Manel46

25-11-2019, 17:21

Are you switching between screens modes?

Página 1/5
| 2 | 3 | 4 | 5