Bug in concurrent copy in screen 8

[artrag]

Bug in concurrent copy in screen 8

[ppeccin]

I see the problem... Thanks for reporting. In WebMSX VDP commands are in fact instantaneous. Only the time it would take to finish is correctly (approximately) reported on the completion flag. But in the current implementation, the transfers do happen instantaneously, so race conditions between CPU, VRAM and the Raster (screen rendering) are not accurately simulated. All titles we tested so far worked, as they did not make any assumptions about the actual underlying transfer process. I suppose that would even be incorrect, since the process is "opaque" on the VDP. As per specification the data should be ready in memory before the transfer is started, and there is a flag to indicate that the process is complete. Software should not count or depend on how (sequence, timing, etc) the transfers are made internally on the VDP. It's not defined on the spec. You could even see discrepancies on real HW on different versions/revisions. But yes, that is a known issue... This function is less accurately simulated in WebMSX, and could be improved. Paulo

…

On Sun, Mar 20, 2022 at 3:22 PM artrag ***@***.***> wrote: In the attached ROM, the screen in scrolled horizontally in screen 8 The plotting involves for one column out of 16 that the z80 and the VDP copy work on the same column. On real HW and in openmsx the z80 is faster than the vdp copy engine and the screen is correctly updated In webmsx the copy engine seems instantaneous, so the z80 cannot update the column of the screen before it get copied. The result is a black stripe each 16 pixels and a broken scrolling. mytestrom[KonamiSCC].zip <https://github.com/ppeccin/WebMSX/files/8311905/mytestrom.KonamiSCC.zip> Try the rom in attach on openmsx and webmsx (KonamiSCC mapper) Press Enter to pass the flame screen and use right/left arrows to scroll — Reply to this email directly, view it on GitHub <#81>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFOLICQJK4NAUNCR6LWYYDVA5UG5ANCNFSM5RF3AVXA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[artrag]

My code is tested on v9938 and on v9958 and works well on both. The timing is guaranteed by the size of the involved data (the vdp moves 8 bytes for each byte moved by the z80) and by the margins used in the timings.
I can assure you that no revision on the above chips can behave outside the timing bounds assumed by this software