It seems recent mame versions only work like this.
Small increments affect the performance a little, but you're still good.
Very important though: my numbers are used on older mame version. Newest mame versions need 2 mhz less for CPU values (blitter is the same).
You've been told for years and not just by me that using an old version like you do means people who use up-to-date builds will have different results than yours on cv1000 slowdown adjustments, you're just holding progress on cv1000 tweaking and disrupting the potential of coordinated research, since ppl can't work together in the same software conditions.
Performance of the cv1000 driver and refresh rate have changed more than once by MAMEdev's work on the driver, even if those were little changes in appearance, considering how very sensitive this blitter+CPU% business is, just stating a random 'just minus 2mhz' doesn't cut it, you're not taking this seriously refusing to use an up-to-date why should ppl trust you stating such an approximation ? RA is jank, forces ppl to use old software, and is therefore unreliable, you shouldn't encourage ppl to follow your example for something that requires actual progress and cooperation.
Hi
OK, thanks for the detailed responses, I'm planning on making another more upto date GM PC in a couple of months running a I7 3770 & HD7570 , I'm currently on 0.220.
I also will be using this in my Astro & Aero so will be using a CRT.
I havnt got a clue how to update mame after i have it all set up and am always to scared to try just in case I mess all my hard work up.
You don't have to go the whole mamecab deal
now to play the right stuff the right way.*
0.220 is old, you're better starting with a fresh install which is done in minutes if playing Cave cv1000 games and tweaking slowdowns and lag properly is what you want.
Also getting full sets of the very latest roms these days is easy as pie, I can't tell without breaking the rules but heh, just lurk around it's relatively fresh news.
[moar, big rant!] 
* To clarify; there's long been a big misunderstanding in the little world of arcades and emulation; GroovyMAME is definitely NOT limited to CRT usage, it's actually superior to every other build as a standalone MAME to use even on your average PC with a LCD, and it works with nVidia or intel iGPU too, of course.
It features non-destructive lag mitigation, saving sliders for Blitter delay and CPU%, also working in combination: Portaudio lag reduction and HLSL.
comes with mame.ini also as a convenience for those who don't like to use command line to produce one.
Actually it can do its own fashion of variable refresh even on some PC flat panel monitors that don't officially feature that, and without even installing CRT_Emudriver (I have two monitors that support that groovy exclusive feature, such monitors are rare but not so much when you know what to look for), though in this case it requires and AMD card. Well...in fact there's a way on nVidia cards too tho using fixed modes.
That's something no other build features, heck it can even do custom 4K modelines on the fly, so it's in reality the best both for CRT
and LCD/flat panels.
GroovyMAME is an improved MAME as a whole, in no way just limited CRT use then. It pioneered pretty much every feature that improves the experience in arcades emulation since about 2012 when frame_delay was introduced, then it brough to other builds things like the default (but limited to only 1 frame) lag reduction baseline MAME features now, and previously integer scaling, Portaudio lag reduction, saving sliders, support for exact refresh modes outside 60 for displays that normally don't, all that on top of its initial goal of being a CRT-oriented build.
Groovy by itself can eliminate almost all the lag beside that game's natural/inherent's. In practice that means it can kill the 2~3 frames of lag other builds produce the moment you use any form of sync setting (whether vsync type or double/triplebuffer type), there then Groovy goes even further as it can as well compensate for input delay on the very last troublesome frame where all other builds tend to register inputs too late.
In total it kills 4~3 frames of lag when you put it against BGFX and d3d/ogl, litterally putting your total lag at the door of pcb-level of delay (compared to that the 'lag reduction' feature currently in MAME removes only 1 frame, it was ported from Groovy but is only a portion of the real deal and therefore nowhere as effective. I've seen lots of ppl on forums have misunderstood that dramatically)
Today Groovy is so well rounded and polished that you don't even have to edit tons of ini files and such, anyone can use it with just the few steps I've listed above, if anything RA or FBN are sensibly harder to set up than it.
I'm baffled that all the arcades communitites have basically ignored it all those years and instead embraced broken garbage like RA, shmupmame, shmuparch or whatever that's anything but the actually best of the best.
Dang there's even a lag tester that's been developed by Oomek specifically with a pluging to test MAME's lag and that proved Groovy is everything it claims:
http://www.gameinputlagtester.com/ no one gave a damn.
There's such a thing a 'too good for people to believe', probably, even if they have it before their eyes they can't believe it's just there and it's free and easy to use.
But an influencer giving them a pre-configured RA with old-ass core and utterly accuracy-breaking settings ? a lag-reduction method that allows players to perform with less input delay than even the original game's hardware and its performance record still be validated ?...everyone's fine with that, total trust !
Makes me think also of the FPGA scam which has helped some people make big money arguing solely on semantics, while in reality they were selling extremely overkill emulation setups just housing further developed and therefore with improved code accuracy against some old MAME drivers that haven't been touched in ages. Haze sait it himself, those FPGA builds don't offer superior per-se properties vs a pc and software emulator, they don't magically resolve things like missing timing delays (the reason we we are here btw), they've just had developer working harder and further than mamedevs did on those specific games. And FPGAs being weak there's no hop to emulate stuff like cv1000, it'll always be old games up to the mid-90's at best.
I've seen some people throw insane amounts of cash on this on the sole belief 'FPGA is hardware emulation therefore it is by nature superior', oh God, the BS ppl will accept if you give it to them like it's
the cure.
I once believed ppl in this hobby were smarter than rich kids buying $3000 computers to play COD, but after over a decade spending time with them I've realized; wherever you go the reason why snake oil sells anyway, is probably the same.
Whatever criticism ppl migh have had against MAMEdev and their policies along the years can be argued about over ana over, whatever, it stands that they're still by far the only ones we can fully trust when it comes to judging of the rationality and quality, and GroovyMAME following their lead matches those requirements. When they say retroarch does BS and harms real valuable emulation and its development, well that's pretty damn true and we have prime examples like we've seen here.
TL;DR for your quality arcade emu fix trust MAME and legit builds like GroovyMAME, inform yourselves, don't trust RA's and derivates like shmuparch's snake-oil narratives.
Use
up-to-date builds, they're here, they're not hard to use, the roms are around too, to play the best way possible you don't have to go for ages-old outdated builds and romsets that misinformed ppl recommend, the newer cutting edge stuff is better for so many rational reasons: use it !
And that's what you need for Cave CV1000 slowdown tweaking period.
[/rant, which im sure no one will give a damn about but heh, guess that was my last attempt wherever at bringing some light against the dominant obscurantism in that field. thats the nerdiest thing ill do this year and hopefully last]
