Bug: CPU <-> VRAM access wait states #5
Labels
bug
Something isn't working
Comments
|
See also issue #56 for more detail |
dshadoff
added a commit
to dshadoff/mednafenPceDev
that referenced
this issue
Jul 7, 2022
Mednafen does not respect the time-slicing of the MAWR (Memory Access Width Register) register, which arbitrates between accesses for the CPU versus those used for video display. This Pull Request doesn't accurately fix that, but it does approximate correct timing more closely. During Active Display, CPU shares access with display based on MAWR timing; when a CPU access is made when it's not the CPU's 'slot', there is a wait state introduced. This PR adds penalty cycles on a 50% ratio basis during active scan, rather than emulating the exact timing of the time slots, so it is only an approximation. It also does not impose penalty cycles during HSYNC, when sprite prefetch would take place, so this will also continue to be an inaccuracy for the time being.
|
Closing this as a duplicate of #56 , and due to the fact that Wonder Momo's issue is fixed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There are wait states unaccounted for, in the CPU->VRAM interface.
Wonder Momo is a particular example of this; the same interrupt is used for both the raster interrupt and VBLANK; it assumes that is it on one or the other, based on the sequence, after initiated. The large block transfer into VRAM is one of few transactions which take place before the interrupt is set, so the result is that the wrong-sequenced interrupt is actually in place.
For proper wait-states, consult the implementation used in MiSTer (primarily VHDL):
https://github.com/MiSTer-devel/TurboGrafx16_MiSTer
The text was updated successfully, but these errors were encountered: