If anyone does not see errors or glitches in the screen on real msx2
I think it is time to do a game in screen 8 with side scrolling....
Anyone willing ?
If anyone does not see errors or glitches in the screen on real msx2
I think it is time to do a game in screen 8 with side scrolling....
Anyone willing ?
Hey, ARTRAG how you have fixed the problem?
updating r18 only when vdp is not executing a cmd makes thing a little more complicated.
would be interesting to investigate why this corruption occours.
maybe the r18 is somewhat related to vdp cmd engine timings so altering it does phase out the internal vdp state machine used for memory accesses.
However, there must be a kind of sync at a scanline level that resync the cmd engine with the scanline counter, otherwise even doing split screens (or disable the screen) should cause the same kind of corruption because with screen disabled the access slots are more frequent.
Now, that we know a little more about v9938 timing i think would be worth to investigate, in order to find a less restrictive method to interact with R18.
By the way, the map incorrectly say that the corruption occour with sprites disabled. I've personally verified that the corruption appear regardless of the fact that the sprites are on or off
My theory is that r#18 offsets the timing of the access slots along the line counter, and if a byte was already enqueued and waiting for its slot, its assigned time slot cycle index is updated immediately while the VDP’s display pixel counter latches r#18 at the start of the next line. This misaligns the slot cycle index and makes it conflict with a VDP display VRAM access or refresh and corrupts.
Is this properly emulated on openMSX btw? I've been building some scrolls and experimenting with some more funky stuff and it appears to be safe to change VDP R18 while a VDP command is running and sprites are enabled? (Screen 5 btw).
