vdp corruption

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

By DarkSchneider

Paladin (896)

DarkSchneider's picture

28-11-2019, 10:50

I'd recommend to remove all the intermediate DI/EI setting only the 1st DI and the last EI to be sure interrupts are not the reason, and use OTIR instead OUTI. If that fails, continue looking.

Also, I see that you read S#2 and check flag with RRA, but then do nothing if the previous command didn't finished and continue, so you could put another command when the previous one is executing. You have to hold continue reading S#2 until CE is zero. Just put after RRA:

RRA
JR NC, .vdpready

By gdx

Prophet (3241)

gdx's picture

28-11-2019, 12:20

Deleted because bad advice.

By DarkSchneider

Paladin (896)

DarkSchneider's picture

28-11-2019, 12:09

In any case is mandatory to check CE as can't put a command while executing another one. The code currently is unsafe and could crash at any moment. The best place to check CE is even before calling DoCopy.
And a fix, for JR in this case is not NC, but C, as CE works opposite than TR, and 1 means wait.

By Grauw

Ascended (8702)

Grauw's picture

28-11-2019, 19:34

DarkSchneider wrote:

I'd recommend to remove all the intermediate DI/EI setting only the 1st DI and the last EI to be sure interrupts are not the reason, and use OTIR instead OUTI. If that fails, continue looking.

Also, I see that you read S#2 and check flag with RRA, but then do nothing if the previous command didn't finished and continue, so you could put another command when the previous one is executing. You have to hold continue reading S#2 until CE is zero. Just put after RRA:

RRA
JR NC, .vdpready

There is a jr c,.vdpready already right after it restores s#0. Doing it sooner or disabling ints would block the ISR during CE polling. There is also no problem with OUTI, VDP registers have no access speed limit. There can't be ISR interference unless it touches register 17 which I doubt it does, and even if so it wouldn't result in the artefacts we're seeing. The routine is perfectly fine, I've been using a similar one for many years. It is from here.

By PingPong

Prophet (3499)

PingPong's picture

29-11-2019, 00:28

@norakomi: are you accessing vram while a vdp command is running?

By DarkSchneider

Paladin (896)

DarkSchneider's picture

29-11-2019, 09:37

Then could be hardware problem. Try another computer and/or TV. Try on OpenMSX i.e.

By Latok

msx guru (3708)

Latok's picture

29-11-2019, 13:38

No, same problem occurs on my GT as well....

By DarkSchneider

Paladin (896)

DarkSchneider's picture

30-11-2019, 10:32

Well then do as I mentioned previously. To be sure is not interrupt and/or access related, remove all but 1st DI and last EI, and use OTIR to transfer the command data.
If the composition takes multiple vblank to complete, that glitches could coincide with the interrupt.

By norakomi

Paladin (1010)

norakomi's picture

30-11-2019, 15:44

Aside from the copies what VDP registers are you accessing? E.g. what does setscreenon do?

The switchpage switches page:
switchpage:
ld a,(currentpage)
cp 1*32+31
ld a,2*32+31 ;set page x
jp z,.setpage
ld a,1*32+31 ;set page x
.setpage:
ld (currentpage),a

setpage: ;in a->x*32+31 (x=page)
ld (currentpage),a
di
out ($99),a
ld a,2+128
ei
out ($99),a
ret

the setscreenon sets the screen on
SetScreenon:
ld a,(vdp_0+1) ;screen on
or %0100 0000
.go:
ld (vdp_0+1),a
di
out ($99),a
ld a,1+128
ei
out ($99),a
ret

thats the only vdp access I do

By Manel46

Champion (493)

Manel46's picture

30-11-2019, 17:22

I don't understand how you do this. In screen 5 there are 4 pages.
In the page changes, it is not necessary to activate the screen. Try eliminating this.
If this is inside a loop, with more reason.

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