-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug in concurrent copy in screen 8 #81
Comments
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: ***@***.***>
|
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. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the attached ROM, the screen is scrolled horizontally in screen 8
The plotting involves that, for one column of pixels out of 16, the z80 and the VDP copy engine work on the same column.
On real HW and in openmsx ,the z80 is faster than the vdp copy engine and the pixels are correctly updated.
In webmsx the copy engine seems instantaneous, so the z80 cannot update the column of pixels before it get copied.
The result is a black stripe each 16 pixels and a broken scrolling.
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
The text was updated successfully, but these errors were encountered: