I’ve spent some time in December looking into CV1000 Blitter behavior to figure out how it performs in terms of slowdown. I feel I have a good understanding of how it works now, and have put together a doc describing it.
View/Download it here: CV1000_Blitter_Research_by_buffi.pdf
Why do this?
The current simulation of this Blitter in MAME is quite impressive as a high-level reproduction, but there doesn’t seem to have been much time spent researching the timing of operations.
This document aims to document how the behavior and timing of the Blitter actually works, and people can utilize this to make something that’s mostly accurate.
Also it is very fun to attach a Logic Analyzer to a PCB and figuring out how it works.
Preemptively Answered Questions
Q: But what about tuning Blitter Delay in MAME
A: Trying to tune the existing Blitter Delay slider in MAME doesn’t really make any sense, since the slowdown introduced from it doesn’t have anything to do with how it works on real hardware. It’s still arguably better than no slowdown at all, which used to be the other option, but that’s about it.
Q: Will this make CV1000 emulation run with proper slowdown?
A: Probably not really. While this should make it possible to have the Blitter part of emulation more accurate, there’s still no emulation of SH-3 Wait States either, which means that slowdown that’s due to CPU not having time to finish processing before VBLANK due to waiting will still not be accurate. I have no idea how much this matters for most games.’
Q: How much work is it to implement this?
A: It should be very simple. And the simplest thing to do would be:
- Rip out all the existing Blitter delay logic.
- When sending a Command to start Blitter Operations, estimate the time they will take to compute.
- Don’t return “Ready” for the Ready Requests until that time has passed.
This still doesn’t reflect how it’s performs on real hardware (where Operations are running concurrently with the CPU, and requesting new Operations when the existing ones are done executing), but in practice I don’t think that should really matter in terms of experienced gameplay performance.
Feedback?
If you have feedback on the document, or suggestions for further work, please reach out to me on Arcade-Project forums, Github or in comments on this blog.