SH3/CV1000 emulation in MAME: CPU and blitter settings for emulating slowdown

Started by el_rika, March 28, 2020, 05:03:05 PM

Previous topic - Next topic

el_rika

Oh, thank you for the feedback and observations!

Watching a couple of Akai Katana vids led me to believe that there's a difference due to the shot spread, but as you say, it's most likely the accumulation of greens and/or golds. Need to watch more  :righton:

EOJ

Type C can accumulate green energy orbs more rapidly and more often than the other ship types, which leads to more slowdown. So in that regard you could say Type C has more slowdown overall. There may be a minor effect with its shot as well, but honestly the game has so much slowdown even when you're not shooting, I don't notice anything extra that is induced merely by the act of shooting.

This should be the easiest game to get better slowdown emulation in MAME compared to the X360 port, because 50-60% of the slowdown is missing in the port. Even 60-70% accuracy in MAME would be a big improvement.
My score archive
twitter: @cavexstg
youtube: @cave-stg
Xbox gamertag: eojx9999

el_rika

Good info there. It did seem to be the case at first glance .

I always tend to settle for a bit more slowdown in these games myself. Just love the dramatic near miss feeling it gives  ^-^

EOJ

For emulation I think it is best to aim for accuracy, not 'a bit more slowdown than on the PCB', even though perfect accuracy is not possible in MAME. From what I have tested out thus far, no MAME emulation of any Ikeda SH3 game is more than 70% accurate (the ports are more accurate in basically every case). Yagawa stuff fares noticeably better (e.g. MMP and PS can be set to have more accurate slowdown in MAME than in the ports) except DFK BL, which is on par with the Ikeda stuff in terms of accuracy (probably because it is an Ikeda game in its core programming).



My score archive
twitter: @cavexstg
youtube: @cave-stg
Xbox gamertag: eojx9999

xygax

Aim for accuracy? I don't know if I should laugh or cry.

Again it is a waste of time researching this using an outdated build. For the Nth time some ingame behaviours changed a bit after the recompiler was introduced (0.192 mem loadings that can influence slowdowns in places). Also using a proper up-to-date build you wouldn't have to deal with crashes and workarounds.

In short whatever you guys find here is in part of no use to users of proper up-to-date builds, and of course no use for the future.

The people who pushed for doing the wrong, uneducated choice of going for outdated cv1k emu ruined the chance of this 'project' to be at least a little serious, as expected from the SRR (Shmuppers + Retroarch = Retardation) typical combo recipe for inacccurcy and promotion of anti-progress, and the ugly clickwhores a la Mark_MSX will surely further promote mediocrity since that's what they exist for/live off.

Aim for accurcy = start with using a proper up-to-date build period.

Retroarch culture is people who don't understand the serious problem of sticking with heavily outdated versions of software, it's a cancer of our times for the world of emulation and development as a whole, a disservice to video games.

Damned Brandolini's law is the essence of the internet.  :displeased:


EOJ

My score archive
twitter: @cavexstg
youtube: @cave-stg
Xbox gamertag: eojx9999

el_rika

Testing a bit of Akai Katana, another gorgeous game full of pretty effects.

I've been studying this for the past week (still don't fully understand all the elements of proper scoring - do i actually need to graze bullets with the captured orbs and gold?! or they mature on their own after a fixed time?) and i have a good idea on what it needs to properly run in mame.

As i assumed earlier and EOJ confirmed, type C slows down the game most, and it's a very noticeable difference in slowdown, with any of the ships, between an option full of matured orbs, small orbs and no orbs.

A guy on nico did pcb runs with all characters without ever going into Bubble mode (not an easy thing to do :oogle: ), which is very helpful for testing.
There are sections in this game where, especially with C and B, the game slows down so much that i think it's in single digits. Possibly the slowest slowdown in any Cave   cv1000 game.

B ship:
https://vimeo.com/426182216

Cpu 47.00 mhz
Blitter delay 68%

C ship needs a faster Cpu clock and lower blitter value (60%), while A ship needs a lower Cpu and considerably higher (i settled for 72%) blitter.

el_rika

Muchi Muchi Pork!

Love everything about this game, except for the bosses, mostly because they lack a health bar or audio cue of some kind. Maybe they'll grow on me    ^-^

Cpu 53.55 Mhz, blitter delay 53%

https://streamable.com/vh6pcn - level 1

https://streamable.com/cfpdff - level 2 and 3 (half)

Maybe a little faster at times, though pretty good overall (level 4 boss slows down just a little bit more than on pcb). This game is soo delicious and sucking in those big golden porky heads is incredibly satisfying.


Daifukkatsu Black Label

This game is pure madness, bullets everywhere, the hud and your ship completely vanishes, hyper quickly becomes a double edge sword, the soundtrack is blood pumping...what can i say, a masterpiece   :righton:

Cpu 41.57 Mhz, blitter delay 57% (Strong/Power)

https://m.youtube.com/watch?v=S7kxrY5R5jw&t=172s - level 1 and half of 2 Green Strong

https://m.youtube.com/watch?v=xmXpWdfVEnQ&t=4s - level 1 and half of 2 Blue Power

https://m.youtube.com/watch?v=LpuUDgMpkw8&t=283s - level 2 and 3 Green Strong (got ultra lucky in a couple of spots).

!youtube/streamable always add a bit of annoying stuttering in some moments, so ignore it!  :'(

This game's timings are very very dependant on rank and shot type. As with all games heavy on special effects, blitter is the first to byte from lasers and explosions, while Cpu goes after the rest (bullets).
The game is fastest with A, a bit slower with B and (slightly slower) with C, like most Cave games with this forumla.
Level one and three bosses on Strong/Power with a full red rank, as well as a couple of dense bullet pattern moments (before mid boss level 3, begining of level 4) are important and reflect well the overall slowdown of the rest of the game.

If anyone knows a pcb Strong/Bomb no Ura no Hyper level 4 mid boss footage (preferrably B ship), it'd help a lot

Bomb style needs 1 Mhz more with B and C, otherwise some instances are a bit too slow (ex.level 1 boss 3rd pattern full red).

trev1976

what an interesting thread, I currently run a 360 plus UVC for my cave ports but id love to one day just have a PC that does everything rather than having to mess about with so much equipment.

el_rika

So, Futari Black Label.

No need to reiterate how amazing this one is.

There's a lot to be said about this game and how the emulation handles it, but i'll keep it short.

On pcb, contrary to the norm, sometimes Reco produces more slowdown, sometimes Palm does that (ex. as opposed to Daifukkatsu where the rule is that blue always slows down the game more, and red less ). So the logic is not clear cut, and this made analysing and tweaking much more time consuming.

Reco maniac:
Cpu 45.26 Mhz, Blitter Delay 54%
Palm maniac:
Cpu 46.08 Mhz, Blitter Delay 56%

Reco god:
44.54 Mhz, Blitter Delay 56%
Palm god:
44.33 Mhz, Blitter Delay 56%


Overall level 2 boss and certain Larsa patterns are great for the CPU values, while level 3 and 4 bosses and again Larsa, for blitter.
In-levels and mid bosses, line up very well with these boss values.
Also, the more agressive/point blank the game is played, the more slowdowns happen. Superplayers tend to always play like this, for those red aura gems  :shock:

Observations:
There are a couple of instances (boss 3 and 4) where, depending on how homing (mostly Reco's little bugs) connect to the boss body, an extra 1 or 2 seconds of slowdown occurs. I've seen it in pcb vids and it seems to also be dependable on how much of the boss's body is on screen, so it's somewhat random.

In maniac, 2nd level Boss, first salvo of last segment, is a bit slower with Palm laser, if it connects the center of the boss. Shot has no issues.
In maniac (to lesser extent God) level 3 boss first salvo is slower with Reco if laser hits frontal compared to pcb. Last pattern also depends on positioning, but it is slightly slower as well.

[In these bosses, it depends a lot on how soon/late you create that ~ 3 seconds continuous white flash, with laser/shot, on the boss's body. It seems superplayers actually use this to their advantage, creating a bit more or a bit less slowdown in those quick moments]

Larsa's first salvo in maniac is just a little slower with Reco's laser compared to pcb, though i've seen it go slower in some pcb vids while a bit faster in others.

Larsa in god is very good with both ships :wink:


Maniac:
https://vimeo.com/471737529/ (Reco maniac lvl1,2,3)

https://vimeo.com/471731416/ (Reco maniac lvl1)

https://vimeo.com/479581629 (Palm maniac lvl1,2)

https://vimeo.com/479582830 (Palm maniac  lvl3 boss)

https://vimeo.com/475076907/ (Palm maniac lvl4 boss)


God:
https://vimeo.com/476652165  (Reco god lvl1,2)

https://vimeo.com/477588588  (Reco god lvl2)

https://vimeo.com/user107095125 (Reco god lvl3 boss)

https://vimeo.com/476787078  (Reco god lvl4)

https://vimeo.com/476856294 (Reco god lvl4 mid boss to boss)

https://vimeo.com/479470121 (Palm god lvl4 boss to lvl5 mid boss)

- as always, there are some stutters from vimeo conversion.

Note: There is a behaviour on pcb that can not be replicated (without completely breaking everything else):
Palm (and to a lesser extent Reco's) laser effect seems to have a greater impact on slowdown in less busy scenes in certain levels. Easily observed in superplays at the begining of level 4, where Palm's laser visibly slows down the speed. Other similar moments don't seem to behave the same, with Palm not slowing down the game this dramatically.
This somewhat supports Trap15's old idea that different bleding methods need different blitter values. Thankfuly it happends only in a couple of small instances, the overall blitter and cpu values taking over quite quickly.

Cheers to all.

el_rika

Revisiting Mushihimesama and Futari 1.5.

My initial analysis for both games was flawed, and the results not as good as they could have been, so i re-tested and compared to pcb runs, with better understanding of how the games behave and how mame handles the blitter delay.
There are surprisingly few pcb runs available for these games at high quality in maniac and ultra modes, so thanks to those that helped me find them :)

The new numbers are much better and i think, as accurate as emulation allows it atm and for the forseable future.

Mushihimesama Futari 1.5:

Reco Normal (maniac):

CPU 47.7 mhz, Blitter Delay 57%

https://youtu.be/D-Qd5cz_tCc lvl1and 2

https://youtu.be/qBU3W4jsHbI lvl3

https://vimeo.com/492447261 lvl2 and 3+boss

https://vimeo.com/492351257

https://vimeo.com/488979653 lvl5

https://vimeo.com/492842604 lvl4+boss,5 and Larsa (potato quality, but showcases how accurate Larsa is)


RecoNormal has a more stuttery normal shot slowdown compared to PalmNormal. The 360 port mitigates this a bit by adding longer slowdown sections in most instances.

Palm Normal (maniac):

Cpu 48.5 Mhz, Blitter Delay 57%

https://youtu.be/oloBwbrLPIo lvl1

https://youtu.be/ZpZmRlHV0Cc lvl3 boss

https://youtu.be/IY2eKyVMZ6I lvl1,2,3

https://youtu.be/kGD3sHywIdM from lvl4 boss to Larsa

https://youtu.be/MQKTuvXmBy4 lvl5

Normal Palm's shot slows down the game most. Does that on pcb as well. In mame it may be a bit slower in some instances, though definitelly in the 10% range. Tried to show that behaviour in a couple of spots on bosses.

Abnormal Palm (maniac):

Cpu 41.5 mhz, Blitter Delay 56%

>footage coming soon<

The normal shot on pcb slows down the game more than in mame, so the game is a bit faster overall in mame. Laser on the other hand slows down the game (lvl3 boss) a bit more than on pcb.
Overall the game is faster (less slowdown) than with Normal Reco and Palm.

Abnormal Reco, Original and Ultra, waay out of my league to properly test them.


Mushihimesama:

Cpu 41.77 Mhz, Blitter Delay 57% (Ultra mode)

I mostly use Wide Shot, as do 99% of the players.
My inital cpu clock speed was too low. This one is the sweet spot for the Cpu dependant patterns (boss1 first salvo, level 2 bullet cancelling sand-worms circular salvos) and overall speed. Level 3 is where the Blitter Delay is important, as there is a lot of in-out slowdown on pcb to be observed.

https://youtu.be/Vui28Eaes-M lvl1,2,3

https://youtu.be/elwYtjxbQlo lvl1,2,3,4,5(half)

https://youtu.be/uuTuL9inw50 lvl5

Maniac mode:
Cpu 48.0 mhz, Blitter Delay 57%

>footage in the future<

Edit: long overdue maniac footage:
https://youtu.be/4MpB3ig9uAk
https://youtu.be/fvQO2MFUDGU
https://youtu.be/r4PtTA-1yEU
(sorry for the slight vibration sound that pops up)

Plays very very close in maniac and probably original as well (never tested it).

Youtube always adds some kind of resample and small extra stuttering to these vids, so that's unfortunate.

el_rika

So, further testing on a laptop (windows) with a recent mame version, revealed that the post 0.192 cv1000 driver needs 2.3 mhz less for the CPU, to match the speeds shown in this topic.
Only tested two games (Mushihimesama ultra and DfkBL), but it's definitelly around this % difference for all.


While a bit off topic, i'd like to share a couple of visual enhancements that are possible for the Cave shmups, thanks to the mind blowing edge detection implementation and recent improvements in the scalefx shader (Spooky of libretro gets the credit, my excuses if i'm mistaken). It's like a hardcore AA solution for 2D 240p  :righton:

It's a custom preset made by me, with added scanlines and a touch of cel shader (which in my opinion makes games with dirtier artwork, like Progear, Esprade look astonishing). They also look so much better in motion.

Progear

https://imageupload.io/g/rEyuLyOT1l
https://imageupload.io/g/n0rku22YNV
https://imageupload.io/g/hC7SgYpAVi
https://imageupload.io/g/m9hkgqFRlA
https://imageupload.io/g/tS47Xc4c3Y

Esprade

https://imageupload.io/g/eCzr54CDTe
https://imageupload.io/g/n3YWQMuKCB
https://imageupload.io/g/EzWALHoJsB

Espgaluda

https://imageupload.io/g/fdOg8jEidZ
https://imageupload.io/g/7SMbuoKuc5
https://imageupload.io/g/MuULBVbKna

Ketsui

https://imageupload.io/g/aElg87H63M
https://imageupload.io/g/zQqjs07FwH
https://imageupload.io/g/b3cMSmzaeL

Mushihimesama

https://imageupload.io/g/BxATWY3qm8
https://imageupload.io/g/n5BNeutmUz

Espgaluda 2

https://imageupload.io/g/yK1Qx3Im0q
https://imageupload.io/g/F6PyoDVR0F
https://imageupload.io/g/BepR0GsLcr
https://imageupload.io/g/O50RmwC7ly

Ibara Black Label

https://imageupload.io/g/dL03yBxVrv
https://imageupload.io/g/8rv0Po0ToV

Daifukkatsu 1.5

https://imageupload.io/g/6GCDSERomG
https://imageupload.io/g/gJM5PeNZ61

trev1976

Hi

Does anyone have a list of the best available setting for these games ?

I know they wont be a 100% but it would be nice to set these up in mame with what people regard as the best settings in 2021

I really hope someday these games can be made perfect through emulation as the PCB's are out of the question now for most of us.

Thanks

el_rika

The updated settings presented here in this very topic are the best. Scroll through the posts (start with theast page).

trev1976

Ok no problem,  I only ask as I was looking for settings for DSMBL and come across some conflicting opinions.

I'll dig through this thread and make my own list in notepad so I can refer too.

It's a shame no one has done a specific core on retroarch just for SH3 but its obviously not that easy as I'm sure we would of seen one by now.

Thanks.

el_rika

Dsmbl was one of the hardest games to analyse, as every character's shot/laser has quite different impact on overall game speed.

Here is the summary, to save you time:

Deathsmiles MBL:
53.35 / 54 (Windia)
53.04 / 56 (Follet)
52.53 / 58 (Casper)
52.53 / 58 (Sakura)
53.35 / 55 (Rosa)


trev1976

Quote from: el_rika on November 01, 2021, 03:50:56 AM
Dsmbl was one of the hardest games to analyse, as every character's shot/laser has quite different impact on overall game speed.

Here is the summary, to save you time:

Deathsmiles MBL:
53.35 / 54 (Windia)
53.04 / 56 (Follet)
52.53 / 58 (Casper)
52.53 / 58 (Sakura)
53.35 / 55 (Rosa)

Hi

My copy of Mame has a slider for CPU overclock but only goes up and down in increment's of "1" is this the correct setting

https://ibb.co/Pr0rWRg

Thanks


xygax

If you wanna do this right use GroovyMAME 0.237, the very latest with all properly working saving sliders with decimals precision added, not whichever core on retroarch.
RA is of no help since the only versions it supports that have saving sliders are too old.
Also older versions of standalone MAME and Groovy have their lackings and quirks too that are annoyances if not liabilities for tweaking slowdowns in cv1000 games, so ppl shouldn't waste time with those, no RA, no old build period.
If they're worried about roms well the up-to-date sets are basically everywhere now every month, the years of struggling are over, I think a lot of users still haven't noticed.
So emulation of cv1000 has been the most up-to-date in recent MAME and Groovy follows its drivers development faithfully, that includes the small adjustments to performance and refresh rate MAMEdev have done over time, which some very thick-skulled ppl with a phone and old-ass RA cores still don't understand even after years of telling them that it DOES make a difference for this research, and that results done with old versions are useless to share.

- Get GroovyMAME 0.237 (whoever: complain only to yourself if you get an older version and experience issues, missing stuff etc)

- First in Groovy's mame.ini edit this way for a basic flat panel use (not crt):
cheat                     1
monitor                   lcd

- Then launch a game and in the ingame menu go turn blitter delay on then reset (F3)

After that you're free to adjust both CPU% and blitter sliders, it'll all be saved.
CPU slider uses % but you can see the Hz in the machine information menu if you want.

You're also free of using other sliders that do save too, frame_delay to minimize lag, and vsync_offset to eliminate tearing if you have some.
The higher frame_delay the more often your inputs are at pcb-level of delay, although reaching 8 is tough on both CPU and GPU, and 9 almost impossible on heavy games.
NB: abusing vsync_offset has a huge toll on performance so it's better to reduce your frame_delay level instead.

Use Portaudio to reduce sound latency, and HLSL if you want, they do work in combination with everything else of course, up to you to learn how to configure them.
HLSL is rather old but at least it's still there.
Personally tho I prefer a simple light filtering, I just use the following in mame.ini (Groovy's)
autofilter                0
autostretch               0
filter                    1
prescale                  2
It's a bit blocky but clean and colors are good.

But you CANNOT use BGFX or change anything else in the configuration that has to do with video backends or sync if you don't know exactly what you're doing.
This is not baseline MAME nor RetroArch nor FBN or whatvever, Groovy has got its specifics that most new users break by touching settings they shouldn't have, but hey Groovymame forums on BYOAC exist.
Anyway for playing tweaked cv1000 games you don't need to know more.
(Would you want to play more games like the 1st gen Cave games or older Toaplans with benefits of frame_delay, I recommend increasing from 2 to 3 the following:
sync_refresh_tolerance    3.0)

Groovy's as good as arcades emulation gets on a simple PC and normal monitor without breaking emulation accuracy.
Anyone who wants actually better get yourself a GSYNC setup or dive into the other possibilities with flat panels and CRTs that actually exist and work, using groovy or not.
Don't fall for the BS snake-oil RA and shmuparch are selling on lag and refreshes, well, I guess most ppl do, and it's too late for them to realize, plus retro arcades got old so it's preaching in a desert.  :P

el_rika

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).

trev1976

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.


xygax

Quote from: el_rika on November 06, 2021, 09:50:55 AM
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.

Quote from: trev1976 on November 06, 2021, 10:10:26 AM
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!]  :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. 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 !  :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]

el_rika

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


buffi

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

peg

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.

buffi

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.

el_rika

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.

buffi

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.