Recent Posts

Pages: 1 2 [3] 4 5 6 7 8 9 10
For wait states, I think they are pretty well understood, or well... at least not hard to understand.

On SH-3 there's two registers WCR1 and WCR2 which specifies the number of wait cycles for any external access. These writes are simple to get by just looking at the values the games write there on startup.
The issues is that RAM access (Area 3/CS3) is cached, which means that only cache misses will generate wait states. Emulation of cache behavior like this is very tricky, and would require a lot of research. Most likely, this is the #1 thing that needs to be resolved to get proper slowdown, and any messing around with current sliders will aproximate it poorly.

For blitter, the sliders will just set the time that the blitter will report busy after any write. Pretty sure this is just a way to inject _some_ amount of waits into the blitter, which might make sense, but without more knowledge about how it's actually supposed to behave, I don't think splitting up delay more will add much use.

It's definitely possible to make proper slowdown emulation, but it's just so much work that someone has to do, and there's not really any good shortcuts.
CAVE Games / Re: Video link thread
« Last post by emphatic on November 07, 2021, 01:39:59 PM »
Ketsui new world record 599.7 Million by Magolor:
Even with the current state of the core emulation, what would help a bit for some extra % towards even better acccuracy in some cases (ex. Ab Palm in Futari 1.5 or Rosa in DS), would be sepparate blitter settings for different blending effects.
Both MetalliC and Trap15 fancied this idea back then, and after analysing these games a lot these past years, i'm convinced that it would make quite a difference in these particular cases.

Very doable, and obviously it's not about being pretty, it's about the end result.
It's gonna be pretty and fancy when all the wait states and other factors will be fully understood.
Yeah, as I wrote, the settings are useful to make something that behaves better than default. They definitely have value.
Trying to approximate down to 0.1% values is meaningless though. Just pick something vaguely ”right”. Exact values for actual slowdown doesnt exist, since they dont map to same slowdown behavior on hardware.
I wouldn't say it has no value. EVen though I own all the cv1000 pcbs (well except the impossibly rare ones like akai limited and mushi matsuri) I still like to have mame for practice.

I would never play the cv1000 stuff "seriously" in mame but I do appreciate having something to use that works ok enough for some save state practice, especially for bosses.
Coordinated research for cv1k timings would tbh not have much to do with the current blitter/cpu settings.

At best, tou can use those sliders to get something better than the mame default, but it will still always be an incorrect approximation due to it bot really representing the actual slowdowns of the pcb.

The cpu underclock helps being the slowdown closer to the real thing by just decreasing the clock speed, instead of using the actual sh3 wait states. These wait states are known, but the main issue is that caching makes it very hard to emulate the behavior, since only some ram acceses will actually trigger waits.

The blitter delay also just injects a fixed delay to some blitter instructions. This seems unlikely to map to the actual behavior.

Proper research + accurate emulation would require:
- Rewrite sh3 logic to use wait states for external access.
- Emulate simulated sh3 caching (very hard)
- Research blitter behavior under heavy load on a pcb. Could be done by a benchmarking prog rom written over jtag, but also loads of work.

Messing around with blitter is more of a rough tuning to get something better than ”no slowdown whatsoever”, but exact values per game will not be a thing. This is also why you end up with different percentqges per stage/ship when you are poking around with it.

Badically tl;dr:
- Current sliders are flawed, and no matter the setting will not be accurate
- They can still lead to better playability than default
- ”Research” in exact percentages doesnt have much value. Just pick something vaguely correct
- Actual research into fixing this is a lot of work, which explsins why noone has done it
1.The 2 mhz is not random, it's tested.
2.The blitter code is exactly the same since 10 years ago.
3. RA is not jank.
4. There is no "coordinated research" for cv1000 slowdown. I am the only person to ever take this seriously and actually test, compare, provide hard proof and numbers.
5. Nobody is forcing you to lurk this topic, when you can do your own research with the latest version of whatever you want (i already explained to you that by the time you finish your research, 20 new mame version would have been released, so you won't be up to date ever)
6. Calm down, deep breath

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.


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!]  :cool:

* 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. 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: 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 !  :righton:

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]

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.

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).
Pages: 1 2 [3] 4 5 6 7 8 9 10