vdp corruption

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

By Eugeny_Brychkov

Paragon (1106)

Eugeny_Brychkov's picture

30-11-2019, 23:37

If it works in the emulator and does not work properly on the real machine, then timing is the issue. Put 4 NOPs after every OUT($99) and OUT($98)/OUTI instruction and see if anything changes. If issue will go away, remove NOPs one place after another and notice when they will be back.
Also note that bugs on the screen have a pattern, they are not chaotic. They clearly go from top left corner diagonally down the screen.
I did not see the mention or code showing when you switch pages. You must ensure that you switch pages when vertical retrace is in progress, switching in the middle of display may cause artifacts on the screen. Keep in mind that polling register S#0 for vertical scan flag is a bad idea: real VDP has a bug when interrupt occurs, flag is not set yet, you read 0 in bit 7, and this read resets internal flag which did not materialize in bit 7 yet. The only reliable way to detect VR is through ISR.

By Grauw

Ascended (8508)

Grauw's picture

01-12-2019, 16:46

Eugeny_Brychkov wrote:

If it works in the emulator and does not work properly on the real machine, then timing is the issue.

Not necessarily, it may be a glitch that the emulator doesn’t emulate.

Eugeny_Brychkov wrote:

I did not see the mention or code showing when you switch pages. You must ensure that you switch pages when vertical retrace is in progress, switching in the middle of display may cause artifacts on the screen.

Hmmm… this may be a candidate.

In principle it should not. The switch will happen in the middle of display sure, and it generally looks better to sync the switch to avoid screen tearing. But the pixels should be showing either the contents from the one or the other page, not some glitch that exists in neither page, and several pixels wide.

I’ve also never observed glitches like this in a stable page split… But I must admit I probably have never tested this on a real MSX, since I do always end up covering up the split in horizontal blanking or with a blanked line, likely before I test on the real MSX.

So it may be there on real hardware, although if so it would be surprising to me since afaik there isn’t any kind of multi-pixel pre-fetch cache going on or anything like that. Except… in screens 10-12 YJK mode. I wonder if the V9958 does something different in the fetching than the V9938 even when YJK mode is not enabled.

A sprite table split could cause such glitches, since it is pre-fetched each line. But that doesn’t seem to be used here.

Is this issue unique to the turboR, or does it also occur on MSX2 or MSX2+? And also, is the turboR in R800 mode or Z80 mode? What if, for the sake of testing, you put a halt before the page switch so that it is delayed until vblank? (Though that will sync the whole thing so probably make it disappear anyway without finding the underlying issue.)

By norakomi

Paladin (1003)

norakomi's picture

03-12-2019, 22:51

Quote:

I did not see the mention or code showing when you switch pages. You must ensure that you switch pages when vertical retrace is in progress, switching in the middle of display may cause artifacts on the screen.

FOUND IT !!
you were right, this was the issue.
I expected screen tearing at max, but not these strange artifacts.
I still don't quite understand it, but all I did to solve the issue was add a HALT instruction before the switchpage.
This way switchpage always happens at VBLANK.

Thanks everyone for the help !!!

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