Bug: Chris Covell's CPU Test shows bad timings for VRAM access #56
Comments
dshadoff
changed the title
pceDev16
added
bug
|
Reviewing the code in file src/hw_video/huc6270/vdc.cpp, there doesn't appear to be any system of video access arbitration between VDC and CPU. (The MWR register setting would describe the nature of the access rotation, and wait states would be injected based on slot misses). An example of how this should work can be found in MiSTer, here: |
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.
|
Validated, but this issue will be kept open until a more accurate solution is found |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
CPUTest here: https://www.chrismcovell.com/CPUTest/index.html
This appears to be related to the Wonder Momo issue.
On the "X-Cycle Instructions" area of CPUTest, all of the TAI/TIA accesses to/from VRAM run too fast on Mednafen.
Example: "TAI<VRAM # 32 F3" appears to be roughly 2 or 3 pixels short of a full scanline on real hardware; on Medafen, it oscillates between 22 and 38 pixels short of a full scanline.
The text was updated successfully, but these errors were encountered: