CAVE 68k MiSTer beta core

[Johnpv]

Not sure what you are talking about here. MiSTer is definitely NOT plug and play. I like it quite a bit, but it does take a bit of setup to get going, especially for certain cores like NeoGeo and MSX.

The update_all scripts have made this a lot simpler and easier.

[BrianC]

Mine decided to stop working on me and shows a blank screen when starting up. I tried multiple sd cards, the mr fusion, the standard method, pc updater etc. It still shows the green and red lights, but only shows video via hdmi on the mr. Fusion boot screen. I agree the update all script does make things simpler. I did get a second mister and I hope I can get the first working again.

[dreadnought]

No one has made a 100% accurate core yet because the tech is still relatively new, and the people making this stuff are a tiny group of hobbyists who are mostly doing it for free in their spare time. Also bear in mind that 100% accuracy in simulation of a specific chip is not always required to obtain 100% game accuracy. The progress made on the earlier systems, however, is amazing. I challenge anyone to a bind test of original and cloned/simulated hardware via MiSTer for the earlier systems, and I can guarantee that the hit rate will be better than the vast majority of software emulators. What clinches it for me is the simulation of audio hardware, which has often been the biggest hurdle for software emulators. Playing on a MiSTer, it's one of the first things you notice - how much richer and more accurate the audio sounds.

I doubt very much the hit rate of real/fpga/emu systems would be a "guaranteed" win for FPGA. I'd love to see such test because I'm quite certain it'd yield quite a few surprises for the more zealous purists.

I used to think that the aim of FPGA is to "clone/replicate" original hardware in a 1:1 fashion, but when I actually got it it has transpired it's not actually the case and that many shortcuts and approximations are being applied along the way. That's not necessarily a bad thing but it does take a sheen off the huge "it's real hardware!" hype which is used to promote these things.

MiSTer is the leading platform when it comes to lag, CRT connectability, ease of use, the "feel" factor and, relatively, general cost. Which is why it's my number one machine for retro gaming atm. That does not mean it's flawless though, and that emulation is a redundant solution (eg arcade cores are nice, but it's not like I'm getting rid of my GM rig anytime soon -probably never- since only a fraction of MAME library is available).

[Bassa-Bassa]

so far
The Electric Underground has tested Dodonpachi all the slow down is there the guy has been playing it for years gave it a big thumbs up

https://www.youtube.com/watch?v=lZEsi_Ncdjs

I'm sorry, but that guy serves nothing for this purpose (and likely for any meaningful purpose). He's comparing MiSTer with Mame, not with the PCB, and he doesn't even know how to configure Groovymame.

The interesting part is whether if MiSTer's code includes more accurate wait states emulation than Mame's code

MiSTer isn't an emulator. It's more like a cloning of the original hardware at the transistor logic level.

But it does it using code. Code to emulate, indeed. If it uses code to emulate, it is an emulator. This discussion on the semantics never really had much sense.

That's what makes it a much more interesting prospect than software emulation, as it can basically mimic hardware perfectly. I don't own one (yet) but have played on one, and when it gets it right, the experience is indistinguishable from playing on original hardware.

Much like with a good Groovymame setup, in fact - give it a try too.

100% perfect emulation is barely any closer on this box than with any software you could get.

No, really, what is the advantage of this type of emulation vs mame/fbn (i'm talking 1st gen Cave)? All these games are already 90% (hell maybe 99% in most cases) accurate via emulation, right down to the pcb glitches.
Doesn't this [mister core] have the same issues as any emulator? (lack of documentation, manpower, etc).
What's this about "ease" of use. How hard is to put a rom in the roms folder and play?

Will this at some point in the near future clone the cv1000 games flawlessly? Honestly, what's the catch?

Is there any benefit to this compared to emulation?

No matter how good software emulation is, I believe there is always going to be at least 1 frame of added lag. This being a hardware solution won't have that. It should be the most accurate way to play it outside of the actual PCB. Though it should be noted that the no added lag is for the analog output. For the HDMI side of things if the hdmi equipment (monitor, tv, receiver, switch etc) you're using doesn't like out of spec refresh rates you'll need to use the video mode that can add some lag but makes the refresh 60hz. I don't know how much it would be in this case, some one with more knowledge than me would have to chime in here.

Guys, check the Groovymame forums (be patient with the search there, though), next-frame response has already been achieved... It's a complex subject (it depends on when the input gets polled originally, for starters) and I'm no expert, but the frame delay feature and powerful enough hardware do the job.

http://forum.arcadecontrols.com/index.p ... msg1648835

[Plasmo]

He's comparing MiSTer with Mame, not with the PCB, and he doesn't even know how to configure Groovymame.

What are the slowdown differences between Dodonpachi on PCB vs. Mame? I thought Mame was a pretty accurate emulation?

[bcass]

But it does it using code. Code to emulate, indeed. If it uses code to emulate, it is an emulator. This discussion on the semantics never really had much sense.

Nope. The systems it clones aren't running through a software layer, as per traditional emulation. Instead they are running on a hardware layer, a hardware layer that essentially apes the original hardware, and allows the original game code to run natively. Software is only used to reconfigure the FPGA at a hardware layer when the chip is initially configured to ape the chip(s) it is cloning, just prior to the native game code being executed.

[SPM]

I had a teacher in college obsessed with FPGAs. His line of investigation focused on it. Santiago are you here?
The guy was a fucking genius, maybe I'll bring this project to his attention... who knows if he's into shmups

[Bassa-Bassa]

He's comparing MiSTer with Mame, not with the PCB, and he doesn't even know how to configure Groovymame.

What are the slowdown differences between Dodonpachi on PCB vs. Mame? I thought Mame was a pretty accurate emulation?

It's supposedly pretty accurate indeed but still not totally there due to the MC68000 not being perfectly emulated. Not first hand experience with this game, mind you, that's what any Mamedev will say regarding this CPU (check 'wait states'). With Dangun Feveron and Esprade (same hardware) it's more evident, though, sprites don't disappear when they do on real hardware (Esprade's energy bar after the bosses die being the most evident, and there's even a report in Mametesters related to Feveron's countdown in Time Attack).

But it does it using code. Code to emulate, indeed. If it uses code to emulate, it is an emulator. This discussion on the semantics never really had much sense.

Nope. The systems it clones aren't running through a software layer, as per traditional emulation. Instead they are running on a hardware layer, a hardware layer that essentially apes the original hardware, and allows the original game code to run natively. Software is only used to reconfigure the FPGA at a hardware layer when the chip is initially configured to ape the chip(s) it is cloning, just prior to the native game code being executed.

You can come and call it 'ape' instead of 'emulate' but it won't change the fact that that software is code to emulate another hardware ('emulator'). And as such, it's prone to present the same issues as 'traditional' emulation, namely 'lack of documentation that prevents from achieving total accuracy'. The hardware layer format indeed opens the possibilty unlike 'traditional emulation', but I don't think you and me will ever see that for any meaningful system, therefore, a Groovymame/Emudriver setup is equally valid (and it has been for many years before the MiSTer project, by the way, it just seems it's been evading Youtubers' attention for being aimed at CRT users, unlike MiSTer and co.).

[mikejmoffitt]

You can come and call it 'ape' instead of 'emulate' but it won't change the fact that that software is code to emulate another hardware ('emulator'). And as such, it's prone to present the same issues as 'traditional' emulation, namely 'lack of documentation that prevents from achieving total accuracy'.

It is correct to say that it is subject to the same pitfalls of not having adequate documentation to make a precise 1:1 clone, but HDL is literally not software.

[Bassa-Bassa]

It's code. I was quoting bcass there, actually.

[mikejmoffitt]

It's code. I was quoting bcass there, actually.

What bcass wrote was correct, but it looked like you were saying that the FPGA is running emulation code, and that's why I responded that way. If I misunderstood then that is my mistake.

[Lethe]

With Dangun Feveron and Esprade (same hardware) it's more evident, though, sprites don't disappear when they do on real hardware

The sprite limit was implemented in MAME midway through last year. Or is it still not correct?

[mikejmoffitt]

With Dangun Feveron and Esprade (same hardware) it's more evident, though, sprites don't disappear when they do on real hardware

The sprite limit was implemented in MAME midway through last year. Or is it still not correct?

I noticed that - it's very close. I made some test ROMs I need to dig up, it is just barely off.

Because the sprite IC pauses its assertion of /DTACK for when the 68k accesses sprite VRAM, I believe the amount of sprites drawn for frame n will cause a little more CPU slowdown on frame n-1 when sprite VRAM is being accessed, which might be a little frustrating to model in MAME.

[Bassa-Bassa]

I didn't know that there had been recent improvements, actually. Interesting.