A long time ago, I was a MSX and MSX2 programmer

Page 9/12
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11 | 12

By ARTRAG

Enlighted (6551)

ARTRAG's picture

21-12-2012, 23:13

no jitter on real hw.
Openmsx fails also emulating this demo TR in r800 mode
see openmsx bug report

By hit9918

Prophet (2905)

hit9918's picture

21-12-2012, 23:20

Wait. Openmsx jitter is different in fullscreen mode.
So then it isn't about different blitter speed of openmsx, it is windows issues.

By PingPong

Prophet (3770)

PingPong's picture

22-12-2012, 10:17

hit9918 wrote:

So maybe it is this:
The blitter actually does sync every scanline
But only in blank mode it is fast enough to reliably sync to a changed R18.

No it's not so. in blank mode it does not have to sync VRAM raster accesses with cmdengine accesses. like this:

if (blanked)
{
       blitter_access = true;
}
else
{
       blitter_access = ( [ some_counter_derived_by_vdp_clock ] % some_value) == 0
}

for example, in the old tms, while in screen 2 there is an access every 8us for the z80. this slot is derived by dividing a clock counter by [some_value]. The vdp logic can, in this way arbitrate which accesses is devoted to.
A similar thing, surely exists on V9938. But here here is a little more complex, because it's needed to take into account the R18 value, that starts +/- delayed the scanline counter. Our guess is that cmd-engine is surely synched at the start of the command, (because it's unexpected to change R18 while a command is running). Maybe it's also synched at every HBLANK or VBLANK we do not know exactly.Surely it's not synched while changed in the middle of the scanline
However, while screen is blanked, because one scanline require no memory access, all this synchronization can be (and probably is) avoided. So in vblank R18 does not matter.

By hit9918

Prophet (2905)

hit9918's picture

22-12-2012, 23:09

@PingPong,
you are telling why blitter does not wreck in blank area. That is the part one can easily imagine.
The unsolved question is WHAT did make blitter sync so it does not wreck as display GOES ON AGAIN with a different R18 value.

A theory:
In the scanline where display will go ON again.
The blitter still is in a fast mode state from previous scanline.
The blitter comes out of the previous scanline without a "tail of things still to do" that would happen in slow mode.
So it suceeds to sync to R18.

By hit9918

Prophet (2905)

hit9918's picture

22-12-2012, 23:16

@ARTRAG, can you test whether it is enough to turn off sprite DMA and leave display DMA on.

This would mean one can have splits without display gap, just only sprite gap.

By PingPong

Prophet (3770)

PingPong's picture

23-12-2012, 09:19

@hit9918:

hit9918 wrote:

@PingPong,
you are telling why blitter does not wreck in blank area. That is the part one can easily imagine.
The unsolved question is WHAT did make blitter sync so it does not wreck as display GOES ON AGAIN with a different R18 value.

Yes. this is clear.

hit9918 wrote:

A theory:
In the scanline where display will go ON again.
The blitter still is in a fast mode state from previous scanline.
The blitter comes out of the previous scanline without a "tail of things still to do" that would happen in slow mode.
So it suceeds to sync to R18.

the vdp engine is a state machine, it does not work with a tail, nor i think the vdp has to "manage tail of things to do".
Instead, i agree with you, we need to find what is triggering the R18 value sync.
I'm not sure, but time ago, i've found that changing R18 in vblank DOES NOT remove the problem.
Now, because ARTRAG does another thing maybe that during the screen split, one event triggering the R18 sync is the screen on/screen off switch.
Maybe the simple trick to enable / disable the screen allow to remove the glitch.
Things that should be verified are:
- Does change R18 in VBLANK causes errors? (i guess yes)
- Does the trick of screen off->WAIT 2 scanlines->change R18->screen on in VBLANK work?

By PingPong

Prophet (3770)

PingPong's picture

23-12-2012, 09:22

@hit9918:

hit9918 wrote:

@ARTRAG, can you test whether it is enough to turn off sprite DMA and leave display DMA on.

This would mean one can have splits without display gap, just only sprite gap.

I do not think is a vdp speed issue. Only a change of status problem. So IMHO sprites have nothing to do with R18 & cmd engine.
Again , i think you are thinking that the VDP is more sophisticated than probably is.

By hit9918

Prophet (2905)

hit9918's picture

23-12-2012, 17:14

@PingPong,
"I'm not sure, but time ago, i've found that changing R18 in vblank DOES NOT remove the problem"

Maybe the sprite DMA is still on below the border to calculate colision bits?

Just as an idea I thought that maybe display DMA alone does not trigger the bug.
Then display split could go without a gap. Just ideas for test cases, I got no real MSX2.

No matter what, it is awesome to have a method to get the blitter run 99% of the frame.

By ARTRAG

Enlighted (6551)

ARTRAG's picture

24-12-2012, 19:25

Whatever is the HW problem here are my last files where I think any bug has been solved (bot on z80 and r800)

https://docs.google.com/open?id=0Bx4kWAc-fapqSk9RbWJQWHNaUXc

Merry Christmas!
:santa:

By Maggoo

Paragon (1214)

Maggoo's picture

25-12-2012, 06:36

PingPong wrote:

@hit9918:

hit9918 wrote:

@ARTRAG, can you test whether it is enough to turn off sprite DMA and leave display DMA on.

This would mean one can have splits without display gap, just only sprite gap.

I do not think is a vdp speed issue. Only a change of status problem. So IMHO sprites have nothing to do with R18 & cmd engine.
Again , i think you are thinking that the VDP is more sophisticated than probably is.

Actually i do remember from my old days that disabling sprites would cause problems when updating R18 multiple times during the screen refresh. No idea why, it just does (had the problems with multiple effects). Enabled the sprites and the problem was gone.

Page 9/12
2 | 3 | 4 | 5 | 6 | 7 | 8 | | 10 | 11 | 12