What's new
By:
Filters

Research into CV1000 Blitter performance and behavior

buffi

buffi

Champion
Joined
Aug 12, 2019
Messages
1,081
Reaction score
2,363
Location
Sweden
So I've had some fun in December, and feel like I have a good understanding of how the CV1000 Blitter behavior and performance works now.
I wrote a big chunky 22 page document about it, and it's here.

https://buffis.com/research/cv1000-blitter-research/

This should make it possible for someone else to do cool things probably.

Let me know if you have questions on how the CV1000 Blitter works. I've spent a lot of time staring at it now.

Merry Christmas and happy new year!
 
Much thanks for your work!

I have a question, about how clipping affects performance, i.e. how smart or dumb it is implemented, but as I see it is subject of "future work"
I'm also suppose this may vary in different firmware versions
 
MetalliC said:
I have a question, about how clipping affects performance, i.e. how smart or dumb it is implemented, but as I see it is subject of "future work"
I'm also suppose this may vary in different firmware versions
Click to expand...

Yeah, I haven't had much time to look at it yet.
Basically need to find a good easy to replicate test-case for it and look what happens.

My hope is that the drawn sprite box in Object Test in MMP Special Mode is partially clipped (should be easy to check, but I havent had the time), which should make it easy to see what's up.

That was basically my next thing to look at, but at this point I just wanted to this into a mostly finished state, and then iterate on it. Need a break first, this took a while :D

edit: Also regarding clipping, something I'd like to figure out is if sprites drawn fully outside of clip area are just ignored, which would make sense. That seems harder to find a test case for though that's consistent.

It's not really feasible with my current setup to attach probes and find it during gameplay. Needs too many points of connection.
 
MetalliC said:
Much thanks for your work!

I have a question, about how clipping affects performance, i.e. how smart or dumb it is implemented, but as I see it is subject of "future work"
I'm also suppose this may vary in different firmware versions
Click to expand...

Ok, so had some quick looks at this, and my first observation was that I didnt see any obvious changes to writes to ”clipped” areas as its called in MAME.

Looking at Object test on MMP pcb, it becomes obvious that these are in fact not clipping instructions at all. See pics below
77C5F853-9C20-44A3-A075-81FFF1AF0E74.jpeg

34C87562-F739-45B6-9756-BD779D4D696A.jpeg


Object mode allows drawing stuff from VRAM, so you can position that the boundaries for the two ”frame buffers” or whatever the name is.

On pcb, you can see Sprites cross the edges that MAME assume is clipped.
 
Last edited:
To clarify a bit what I mean on the pictures, this shows drawing from the top-left buffer. On the top image, there is sprites drawn to the right of the Blue data into the uninitialized VRAM memory, that MAME assumes is clipped.

On the bottom image, this is also the case, but in this case below.

Areas marked below in pics.

clippy.jpeg

clippy2.jpeg


TL;DR: Writes to 18000014,18000018, 18000040, 18000044 seems related to signaling to the Blitter which area to render output from (there's two images written to every other frame as a double buffer). One of the signals is "Frame to output from", while other is "Frame to draw to now".

The "Clip" blit operation seems marked active when drawing to the actual Frame, but its not really clear to me why or what it means. It does not appear to be clipping related though.
 
Actually, it could be possible that there is clipping, but its not at the 320x240 visible area. Looks like Blitter will happily draw 32 pixels outside of visible area in each direction.

Example1: Draw some sprites out of screen
22523CE3-53C8-497D-AA2A-BDFF2C3D57D8.jpeg


The non-visible parts will stay in that area surrounding the drawn buffer in VRAM when inspecting
5345C797-FDD6-414B-A335-596987F409D9.jpeg

(These sprites are drawn after a C0000001 blitter Operation)

If playing game for a bit and looking at vram, it looks like the stage parts are drawn 32px around the visible area of the two buffers
B656CD62-0863-4B8A-BA15-7894867719EC.jpeg


And just to make sure its not special background handling or anything, bombing at edge of screen and immediately hitting test mode will show the outside of the bomb sprite
0835E650-6C2E-4335-A441-4C5CE8C37F1C.jpeg


As mentioned, it is possible that there is a clipping rect of 384x304px, but theres not really any solid evidence for it yet.

Either way, it really feels like it shouldnt matter for emulation performance.
 
buffi said:
As mentioned, it is possible that there is a clipping rect of 384x304px, but theres not really any solid evidence for it yet.
Click to expand...
Well, I take that back I guess, since there is definitely some sort of clipping going on here.
If I disable clipping completely in mame, I get fun artifacts due to the CPU drawing some stuff to the wrong buffer, which I can see in the Blitter operations list.

I guess 384x304px is the way to go then.

Would be interesting to see how clipped stuff is handled though. Will play around, even though i suspect its not very impactful for performance
 
Last edited:
buffi said:
Will play around, even though i suspect its not very impactful for performance
Click to expand...
Well, I take that back. There's definitely something funky going on with how games use "clipping" and drawing.

For some games, and areas I see a LOT of sprites having draw ops outside the active buffers being drawn, in a way that appears to be ignored on PCB (since there would otherwise be massive slowdown). A very extreme case is the transition before s1 boss in galuda2, which does a bunch of big writes that seem ignored.

Maybe some game codes just doesn't want to move stuff out of/into the blitter ops list, and just move sprites that should no longer be active to a clipped out position instead.

Definitely needs more digging there
 
Looking at galuda2 and there's some cursed stuff going on in that game.
From looking at blitter operation lists in mame, I have no idea why there isn't slowdown in the animation before the "input options" startup menu.
I'm clearly missing something there, and it will be fun to go digging.

Edit: Ok, I figured out what I had wrong in my code. Doc seems correct though!
 
Last edited:
MetalliC said:
I have a question, about how clipping affects performance, i.e. how smart or dumb it is implemented, but as I see it is subject of "future work"
Click to expand...

The future is now!

https://buffis.com/research/more-cv1000-research-now-featuring-clipping/

TL;DR:

- Sprites drawn fully outside of visible area will be ignored. This has some fun implications when there's a long sequence of them.
- Sprites crossing the boundaries, with some parts visible will still draw outside of clipping area. This is also what I saw with MMP earlier in this thread, but I can see it in the logic analyzer on Pink Sweets too
 
Fun thing I just realized which I guess is related to clipping.
As I mentioned earlier in this thread, the MAME handling is incorrect and it clips too much.
And in MMP, this can lead to sortof funny things.

Look at the top black waves at the edge of screen (especially top) when bombing with Rafute:
0002.png

Those should not be black

Not really delay related but still fun
 
You must log in or register to reply here.
Back
Top