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.
6 replies on “Research into CV1000 Blitter performance and behavior”
Your cave.buffis.com hostname doesn’t seem valid: the report can be downloaded at
http://buffis.com/docs/CV1000_Blitter_Research_by_buffi.pdf
[…] https://buffis.com/research/cv1000-blitter-research/ […]
Hello,
I do have a question : in your document, you say “Blitter will read pixel data as 64 byte chunks from SRAM (16 SRAM CLK Pulses)”
Could you care to give more details ? I can’t find any SRAM chip on the motherboard and the only RAM is the SDRAM for the main CPU then…
( https://www.world-of-arcades.net/Cave/Hardware_SH3/Hardware.htm links to doc for each chip on the board.
CPU memory is https://www.world-of-arcades.net/Cave/Hardware_SH3/mt48lc2m32b2.pdf ) which is 32 bit wide.
Sorry if I dont have a clear understanding of what you wrote… I hope you may be able to clear my understanding of the system.
Hi! Glad you read the doc.
Regarding the terminology… I honestly don’t know why I wrote SRAM. Maybe I thought it to be a short form of system RAM? This is indeed the main RAM that the CPU.
Each clock pulse during the read, it will read 32 bits (bus width as you mentioned). It does this for 16 CLK pulses so 32*16 bits which is 64 bytes.
Glad I could reach you ! And thank you very much for the clarification.
It obviously all make sense now. 🙂 Sorry for making such request but I’d like to keep in touch if I have further question regarding the blitter and Cave CV1000 in general, could you send me a test mail ? ( My email is posted with the message, so you should be able to see it even if it is not visible for visitors on your blog)
Absolutely. Done.