108 page document about CAVE 1st Gen. Hardware on FPGA

[Keade]

AFAIK, only Pong and maybe another couple of very primitive games have been emulated with 100% accuracy (at circuit level).
EDIT: and, IIRC, it doesn't exist a CPU powerful enough to have them run at 100%. I remember reading an article some years ago where a water cooled overclocked i7 was able to reach 4% at most.

From what I understand, Pong had to be emulated at transistor-level since it is a TTL game, there is no meaningful in-between software abstraction.
MAME can run it at above normal speed on any decent computer. It is probably not the most complex game of its kind though

[Bassa-Bassa]

There are several inaccuracies for example in the 68000 emulator, one of the most important one being the lack of "wait states" emulation (you probably have already read about this) which results in incorrect speed (often compensated by lowering the CPU speed itself).

The fact that you're not able to discern the real thing from the emulation doesn't mean they're indistinguishable.
There are players who have put thousands of hours into some games and can tell you immediately.

AFAIK, only Pong and maybe another couple of very primitive games have been emulated with 100% accuracy (at circuit level).

EDIT: and, IIRC, it doesn't exist a CPU powerful enough to have them run at 100%. I remember reading an article some years ago where a water cooled overclocked i7 was able to reach 4% at most.

But doesn't stuff such as wait states just affect slowdowns? I mean, if a game is not as demanding as to trigger them originally (keeps a constant framerate), then we can expect virtually perfect Mame emulation, can't we? For example, could somebody distinguish between Columns PCB and Columns emulated with Groovymame (and the proper hardware)?


Also, can ESP RA DE/DDP/Guwange's emulation be virtually improved by tweaking the CPU speed when running them? Which percentages?

[Xyga]

Lacking waitstates affects many things but it goes from barely noticeable to a normal human, to very noticeable differences everyone can see.
Games that show only small differences are not a problem, generally those will only annoy players who know those games better than their family.

The 1st gen Cave games are emulated well-enough in MAME for most people who have a life, I don't think anyone ever bothered to tweak the CPU% to try and get a so-so imitation of whatever small slowdown difference in ESPrade or Guwange.
With those it is more meaningful to attend to things like input delay and clean/smooth refresh speed.

[Mantrox]

There are several inaccuracies for example in the 68000 emulator, one of the most important one being the lack of "wait states" emulation (you probably have already read about this) which results in incorrect speed (often compensated by lowering the CPU speed itself).

The fact that you're not able to discern the real thing from the emulation doesn't mean they're indistinguishable.
There are players who have put thousands of hours into some games and can tell you immediately.

AFAIK, only Pong and maybe another couple of very primitive games have been emulated with 100% accuracy (at circuit level).

EDIT: and, IIRC, it doesn't exist a CPU powerful enough to have them run at 100%. I remember reading an article some years ago where a water cooled overclocked i7 was able to reach 4% at most.

One thing is absolute reproduction another is 99.999%.
For historical purposes the first one is prefered, but from a player standpoint, if even after playing for thousands of hours you have to look really hard to be able to discern the difference, it isn't going to matter much; you're brain and muscle memory are going to adapt to the version you are playing anyway.

That's why i was asking if there were any measurements/tests made that could give us a rough idea of what the difference is. Even though it's kind of a moot point since the tests would have to be very specific, depending on the game\platform.
If, for example, there is considerably less/more slowdown on a particular game, that's a problem.
If there is a tiny bit of a difference in that slowdown, your brain will take care of that.

I'm always talking as a player.
The innovation doesn't stop if FPGA "cave consoles" come out. There still will be people out there looking for a 100% accurate hardware.
But if this FPGA hardware can keep players playing these games in the meanwhile, on a cheap, easy to use setup with the fexibility to output analogue and digital signals, it's a win win.

[Bassa-Bassa]

The 1st gen Cave games are emulated well-enough in MAME for most people who have a life, I don't think anyone ever bothered to tweak the CPU% to try and get a so-so imitation of whatever small slowdown difference in ESPrade or Guwange.

What about Progear? This is one of those examples, aside of CV1000 titles, which is quite often used to illustrate how bad MAME is regarding slowdown reproduction. Has a better value for CPU % been found after all these years or did everybody think 'why bother' as well?

[Xyga]

The 1st gen Cave games are emulated well-enough in MAME for most people who have a life, I don't think anyone ever bothered to tweak the CPU% to try and get a so-so imitation of whatever small slowdown difference in ESPrade or Guwange.

What about Progear? This is one of those examples, aside of CV1000 titles, which is quite often used to illustrate how bad MAME is regarding slowdown reproduction. Has a better value for CPU % been found after all these years or did everybody think 'why bother' as well?

Different hardware, the cps2 slowdown issues in some games are maybe more apparent than in 1st gen Caves, but far from being as dramatic as the cv1k case.

MAME sets a default 74% underclock on cps2 startup, that value is probably not the best but it's not like Progear is ruined because of that, it's still very playable and not overly different from playing the pcb.
It's not that accuracy doesn't matter but you cannot put them all on the same level, missing wait states is either minimal or big issue.
The games that already look like 95% or even 90% like the original are fine for as many players, like good ports.

The question is, for 1st Gen Caves, will the FPGA alternative make enough a difference VS. something like GroovyMAME to justify the price ?

Dunno, but since like maybe 9 out of 10 people who try the latter can't figure why and how to use it or lack the minimal required hardware to actually benefit, and its MAME base having become a kind of stinker for users over time anyway, knowing people I'm gonna bet they'll prefer paying for all the FPGAs anyone with a business sense will throw at them.
People are tired of struggling with emulators that disappoint if they lack a degree in configuration science, or to wait literally decades to see progress with the games they'd like to play as well as possible in emulation.

So ... KA-CHING!
Make it rain FPGA's.

[donluca]

I can only speak for Progear because I don't have any 1st gen CAVE PCBs, but the difference is definitely there, it's one of those things which you don't notice until you recognize you've reached the last stage without losing a single life consistently on PCB vs playing it on MAME. My setup was GroovyMAME on a Sony BVM so it was "lag free".

The other difference which can be felt, always referring to CPS2, is in Super Street Fighter II/Turbo where there are some combos/contexts which have pretty strict timing.
If you think about it, the fact alone that MAME has to downclock the CPU to 74% to get the speed *almost* correct it's a pretty big warning sign hanging there.

I've never read the source code of CAVE's 1st gen driver on MAME, but if it uses the same 68k code to emulate it we can assume it has incorrect speed/timing as well.

[Xyga]

Sure, there are differences, just not massive ones like it is the case with cv1k (sorry to sound redundant)

That default 74% underclock was something they did to make the CPU run the equivalent of 10MHz instead of 12 or something, wasn't it?

Maybe it's not the best global value and several CPS games could work better with a little CPU adjustment, though nothing that can replace true wait states emulation.

Although not as crucial it's the same problem as with cv1k games though, we have the tools (Groovy is ideal for OC tweaking) but actually finding useful sliders values demands concerted effort.

You need people playing the pcb's and people adjusting the emulator all working together, good luck with that...I dare anyone to motivate people to participate, create and maintain a thread dedicated to that, and defend it against the inevitable über-persistent trolls that will team up to utterly destroy it and make everyone quit.


Over/underclocking emulation topic aside, it'd just be interesting to see how much better the FPGA alternative does VS. a proprer Groovy, the question 'Really worth it?' stands even though I believe I've already answered it in saying people will buy those anyway, even if the improvement only means like a 5% or sumthin better accuracy.

(especially if they come in a cardboard box)

There again thorough comparisons would be needed, and they probably won't happen either.

[pbsk8]

https://www.youtube.com/watch?v=BYSXY-xh_aE



I hope this gets released on the mister soon, it will be the time to buy one finally

[el_rika]

What about Progear? This is one of those examples, aside of CV1000 titles, which is quite often used to illustrate how bad MAME is regarding slowdown reproduction. Has a better value for CPU % been found after all these years or did everybody think 'why bother' as well?

I find 65% to be a closer to pcb value for Progear. The slowdowns are smoother, less jerky and seem to behave closer to pcb in terms of speed and duration. It heavily depends on the playstyle however.Try it and tell me what you think.

[neorichieb1971]

Is there a chance of an FPGA Cave jukebox?

[Bassa-Bassa]

What about Progear? This is one of those examples, aside of CV1000 titles, which is quite often used to illustrate how bad MAME is regarding slowdown reproduction. Has a better value for CPU % been found after all these years or did everybody think 'why bother' as well?

I find 65% to be a closer to pcb value for Progear. The slowdowns are smoother, less jerky and seem to behave closer to pcb in terms of speed and duration. It heavily depends on the playstyle however.Try it and tell me what you think.

Hey, thanks mate. Unfortunately, I never played the PCB, so hopefully the members here used to it can check it out and share their opinions. Let me mention here, as Xyga told us, that Groovymame does save the CPU % setting unlike official Mame.

[Xyga]

I find 65% to be a closer to pcb value for Progear. The slowdowns are smoother, less jerky and seem to behave closer to pcb in terms of speed and duration. It heavily depends on the playstyle however.Try it and tell me what you think.

Hey, thanks mate. Unfortunately, I never played the PCB, so hopefully the members here used to it can check it out and share their opinions. Let me mention here, as Xyga told us, that Groovymame does save the CPU % setting unlike official Mame.

I've played bit at 65% and there are certainly more slowdowns, and even though I haven't played the pcb much and last time was a long time ago, I feel that's more slowdowns than the original. Several hot parts become much easier like this.
(there are a few pcb runs online that seem to show less slowdowns than the 65% setting as well)

NB: '65%' set by slider can be imprecise because of the poorly thought UI not showing thenths and hundredths.
To set a precise value, because the actual granularity is of 1000, one should always move the slider in short increments and count, knowing that there are 10 steps between every displayed change in the ones.
(which explains why it moves so slowly, tip: press Ctrl to move slider x10, but you can also edit cfg directly)
In the game's dedicated .cfg file (see cfg folder) AFAIK exact 65% should be "Overclock CPU :maincpu" value="645"

[el_rika]

Yes, after more testing, 65% seems a bit too slow in very heavy moments. I'm focusing on 67- 68% right now, which is definitely closer, though different playstyles will allways be hard to properly compare.

Agree, it's a good ideea to go step by step when setting the CPU.

[Xyga]

Agree, it's a good ideea to go step by step when setting the CPU.

Not specifically thinking of Progear but a lot of games seem to have a 'switch spot', where a precise CPU% value changes the behaviour of the game, bringing what we expect.

Like in garou motw terry's stage 3 background animation is fixed at 98%, exact value = 983 in the cfg, which we cannot see in the UI and almost certainly need to edit manually to be sure.
Meaning 00.01% made a difference.
But that's an easy one.
Imagine if it's actually the same for cv1k games, finding the 'switch spot' for even a single game could take an eternity.

[el_rika]

Imagine if it's actually the same for cv1k games, finding the 'switch spot' for even a single game could take an eternity.

I'm working on exactly that. But i can say 100% that on pcb, at least some parts, are fine-tuned per-scene, outside the general CPU %.

That means that, for a few spots to trigger the appropriate slowdown, the CPU would beed to be in the low 20s, which will break the rest of the game. The good news is that, those spots are few and not really significant in terms of scoring or difficulty, if the overall CPU is set just right.
For example, i find Mushihime-sama (ultra) to run very well at 38% CPU. No blitter value, just underclocking. All the important slowdown is triggered, with a few small exceptions. Sometimes there is a bit more slowdown than it should, while some scenes have a little less, but it is well within a 90% fidelity in my opinion, which is pretty damn close.
38% seems to be the sweet spot for Futari 1.0 and 1.5. as well (there is a small stutter in menu and after defeating a boss when the screen fades to white, but really minor).

Espgaluda 2 (Muchi Muchi Pork as well) on the other hand, seems to be programmed a bit differently. As far as i can tell, it uses quite a bit of the CPU to load some assets in realtime. It hapends at the begining of level 1, randomly in level 2 and middle of stage 3. This translates into small stutterings for about 3 - 4 seconds. The lower the CPU is set, the more noticeable the stuttering is. So, for the slowdown to trigger when entering the kakusei and ultra kakusei, but also mitigate as much as possible the stuttering, a CPU of 46% is atm my choice. It does not trigger some minor slowdown (just like with the other games), but it does when the screen gets saturated with purple, very very close to what you get on pcb. High level scoring is possible (i managed 32 mil on stage 1 on my phone ), though if it weren't for the CPU decompressing the assets in realtime, a slightly lower CPU value would have been even better.

Ibara BL is smooth and gorgeous, very very close to youtube pcb videos at 48 % CPU. Trains in stage 3 maybe have a bit more slowdown, but it's pretty damn close.

[Xyga]

Could you please share the cfg's values instead of just % ?

Also, are those settings for your phone and an old MAME build, or the latest Groovy on a proper PC ?

That sort of research demands sharing precise information.

[Bassa-Bassa]

That sort of research demands sharing precise information.

And a dedicated thread. Surely many people would be willing to contribute or discuss, it's really a subject which needs a communty and I can it see becoming one of the stellar threads of recent times here, and even Mame developers could use the information at some point.

[Xyga]

That was attempted before and heavily trolled at. You can also be certain that the first and only reaction that'd get from any passing MAME dev would be total rejection, and the only thing we'd gain would be to end up virtually burned at the stake.
Sorry but that's real, I'm not even joking.

EDIT: if it's Groovy you could open one at BYOAC and it would be well-received, but not if it's the smartphone thing (I too only want to do this with Groovy properly set and nothing else)
EDIT2: trying at cave-stg.com would probably not be rejected, though EOJ himself will personally have no interest.
EDIT3: we can also bring this to neo-source although I don't know how testing stuff on Groovy at their place will be received.
Problem remains though that without the cooperation of a reasonable number of shmuppers it'll be almost mission impossible and a fruitless, dead thread anyway.
cave-stg sounds like the best place since EOJ's paid much attention to ports and slowdowns accuracy, but he rejects emulation so the possibility kinda cancels itself.

[el_rika]

I don't have a PC that can run these games sadly. I only play them on the go.
However, i tried 3 different mame versions in Retroarch and all behave exactly the same in terms of CPU underclocking, so i'd assume the CPU values would be universal, or at least very very close.
Here are a couple of quick vids showcasing the behaviour of Mushihime-sama at 38.0 % (ultra mode) and Espgaluda 2 at 47.5% with a decent score.

https://m.youtube.com/watch?v=huEORRBOeBY
https://m.youtube.com/watch?v=VVh8NyNPLi0&t=106s

[Xyga]

I'm sorry but I don't trust unspecified older builds running in a RA port on a smartphone. I'm really against that and I wish RA would remove the old cores already.

To begin anything older than 0.191 should'nt be trusted as behaving completely similarly to the current up-to-date builds for cv1k, and I'm not sure other things haven't changed since then that would affect the results too because it's been a long time.
In RA you should use only the very latest MAME core for this, hopefully they have updated the downloadable to that, and since it doesn't feature saving CPU% slider anyway well it's not convenient.

Honestly if you're serious about this you should get a refurbished PC, one that can run those games doesn't break the bank, it's not more expensive than an entry smartphone like sub-200, just pick one with an Intel like i5 @ 3Ghz or more that scores 2000 STP (Single Thread Performance) with Passmark, or not too far from that score.
I've found several under 200 bucks in minutes just browsing amazon's refurbished desktop PCs, all small form factors.

47.5%

Sorry but again I cannot set such value, it's not displayed as such in current MAME/Groovy, as I said sharing the cfg's values is the safest and most accurate way.

For me researching cv1k CPU% OC = using a PC with up-to-date MAME/Groovy, nothing else. We have a similar goal but we don't drive the same road and ride different types of vehicles.
Sorry. ¯\_(ツ)_/¯

[el_rika]

Retroarch does not have this core that i use. I explained in a previous topic how i made it work in Retroarch.
The mame build i use, is version 0.157. Latest mame available in Retroarch (0.192 if i'm not mistaken) is, simply put - crap - in terms of performance, on the admitedly low-mid range system (compared to a desktop pc) that i use. Mame 0.174 is the newest that can provide a decent speed, though still twice as slow as 0.157.
As i am more away than at home where i could use a desktop, these are the tools i can work with.

The .cfg does not save the CPU settings sadly. The way i got to these values is by counting each step and comparing to a mame core (0.174) which has numerical values.

When i am 100% confident about the rest of the game's numbers (i try to emulate as high level play as i can, so i can properly compare to available PCB gameplay), i will update my topic, and seeing how there's almost zero information on this topic, it can at least be used as a starting point for anyone interested, though i very much doubt that:
1. there are more than 3 other people in the world that care about this and
2. cv1000 CPU% settings are different between mame versions.

Sorry for hijacking the topic guys

Cheers!

edit: i just realised that we can have an exact number for underclocking, not involving any .cfg
Just after setting the CPU%, go back in mame menu to Machine Information or Game Information, and verify the main CPU value. It should reflect the underclock changes. For Mushihimesama, i have 38.809 mhz, and for Espgaluda 2, i have 48.230 mhz.

[Xyga]

MAME and cv1k emulation have changed since then, the games don't run like they did back then, the core emulation and performance of the games, their behaviour, has changed, yes they have, after the recompiler reworking blitter delay values were wrong, the loading stutter was gone from several points in games, etc.

Using such ancient versions of MAME the testing results you get are no good for people using modern builds, I'm sorry but I am not going to use such old MAME versions nor recommend people to do that.

NB: of course you cannot find the cfg's , those did not exist back then, MAME has changed so much it is like we're talking about two different emulators. We can't share settings properly because we are not using the same emulator.

There may be extremely few persons apparently interested in this, but if we did find working values that achieve a closer reproduction of the pcb's behaviour, more people would flock to it.
Yet asking them to downgrade to ancient MAME builds, and therefore also not use Groovy, is a no-no, mega nope for me.

Sorry, use a working PC and up-to-date MAME/Groovy or your results are meaningless.

[bcass]

I've played bit at 65% and there are certainly more slowdowns, and even though I haven't played the pcb much and last time was a long time ago, I feel that's more slowdowns than the original. Several hot parts become much easier like this.
(there are a few pcb runs online that seem to show less slowdowns than the 65% setting as well)

NB: '65%' set by slider can be imprecise because of the poorly thought UI not showing thenths and hundredths.
To set a precise value, because the actual granularity is of 1000, one should always move the slider in short increments and count, knowing that there are 10 steps between every displayed change in the ones.
(which explains why it moves so slowly, tip: press Ctrl to move slider x10, but you can also edit cfg directly)
In the game's dedicated .cfg file (see cfg folder) AFAIK exact 65% should be "Overclock CPU :maincpu" value="645"

Do you know which version of MAME allows this? GroovyMAME (0.183) does not save the Overclock CPU setting in the game's cfg file. Same with other versions of normal MAME builds that I have tested.

[qmish]

I don't know if this is a fitting thread to ask...

I was reading various IKD recently, and noticed him saying that PGM hardware was somehow weaker/inferior than Atlus/Cave hardware they used for DDP1 and other games.
However, it seems like both were using Motorola 68000 cpu, and Cave 1st Gen processor was 16 mhz, while PGM1 had it in 20 mhz.

So, eh, perhaps anyone knows what were reasons why IKD was claining PGM as weaker one?