Welcome, Guest
The State Of Emulation Software
(1 viewing) (1) Guest

TOPIC: The State Of Emulation Software

The State Of Emulation Software 14 years, 1 month ago #503

Having been away from the emulation scene for about 3/4 years or so and happily emulating MAME games in that time, I wanted to inquire what the state of the Mac emulation software scene is. I know, that, NES, SNES, GameBoy (variants of) Master System, Megadrive and most Arcade ROMs up until 1998 where pretty much perfected and running fine on OSX the last time I looked.

Just, I wonder what the state of N64, Playstation, Dreamcast, Sega Saturn etc are? Some of those had very loose work in progress type development happening on them but where at best interesting if not unplayable for 90% of the games.

I know, I could probably go digging here, WiKi's, on Google, download ROMS, compile stuff and try and find out but I thought I would ask people knowledgeable about it, people here of course .

I also think this would make a great news story post.

Re: The State Of Emulation Software 14 years, 1 month ago #510

I was going to include something like that in my "current state of Mac gaming" feature, but decided to leave it out because it's just too big a topic. I may attempt a standalone feature like a "State of Emulation on the Mac" feature at some point, though, if no-one does so before me.

Niemann was working on articles for individual platforms, but he's been busy updating the site.

As for answering your main question, here's what I can think of off the top of my head: SNES emulation is getting closer to technical perfection with the cycle-exact BSNES. Richard Bannister's other 20+ emulator projects continue to carry much of the Mac emulation scene.

The other 8-bit and 16-bit consoles have had mixed development. Kega Fusion, the everything-before-Saturn Sega emulator, is up to a great standard, with fast and compatible Sega CD/Mega CD support especially notable.

PlayStation emulation had pretty much stalled until recently, with the development of PCSX-Reloaded. There was talk of a Java-based emulator, but I don't know what happened to that.

Dreamcast emulation was approaching playability with LxDream, but there hasn't been anything new in months.

As far as I know, mupen64plus is the only N64 emulator under active development on the Mac. It accurately plays "many" games.

Yabause -- a Sega Saturn emulator -- was last updated in May last year. I haven't tried it, but it's supposed to have decent compatibility and mixed playability.

PS2 emulation is being worked on with a port of PCSX2. Gamecube and Wii emulation is in progress with Dolphin.

On the computer side, Mini vMac is under active (but slow) development), and has made some progress. Sheepshaver has had a couple of updates, but nothing major that I can recall. ScummVM (not technically an emulator, I know) has made major ground in its efforts to support nearly every 2D graphical adventure ever made.

Amiga emulation has made almost no progress. Various Atari systems are getting work done on emulators. Likewise for the Spectrum, Amstrad, and other 80s computers.

I'll leave it to others for more specific responses -- I haven't been doing much emulation lately.
Last Edit: 14 years, 1 month ago by mossy_11. Reason: added some links

Re: The State Of Emulation Software 14 years, 1 month ago #511

Great reply, brings me up to speed a little bit. cheers!

Surprised by Dolphin especially. They seem to be running Wii games and more. That is quite an achievement actually.
Last Edit: 14 years, 1 month ago by Mucx.

Re: The State Of Emulation Software 14 years, 1 month ago #513

BSNES? Really? I must not have it configured right. I've tried it on 2 systems and have been disappointed with it's performance. I get more out of SNES as bulky as it can seem.

I seem to encounter:
Glitchy Audio
Skipped Frames constantly

Any advice to make it run smooth? I have it set up like his other emulators I run yet this one just can't keep up.

Re: The State Of Emulation Software 14 years, 1 month ago #514

Try switching speed to "Run as fast as possible." Using a less-demanding graphics filter can make a (very) slight difference also.

BSNES is very demanding even on new hardware. It may be that your computer just can't quite handle it. If that's the case, stick with SNES9X, which is less accurate but has far better performance.

Re: The State Of Emulation Software 14 years, 1 month ago #515

Yeah it must be my hardware. But in all honesty it's the SNES it shouldn't take as much power as BSNES is demanding. Don't get me wrong Bannister does good work. I'm not a programmer I'm just looking at all the power my mac has and what little power is needed to run an SNES. If this were a 3d system ok I could buy that but we are still pushing 16bit lower color pallets.

Re: The State Of Emulation Software 14 years, 1 month ago #525

The idea behind BSNES is to be as exact as possible. That takes a lot of computing power. You can take a lot of short cuts in emulation to fake certain things that the software runs as it should, but here the author didn't want to rely on tricks but rather get games to run by making the emulator exactly replicate how the hardware works (at least from the view of the software).

Take for example the C64. With it's roughly 1 MHz clock and older hardware it is way less complex than the SNES. The rule of thumb I once heard was that you need roughly ten times the speed to get full speed emulation. I guess that was just CPU emulation, because once you get other hardware and have to synchronize everything, it becomes much more complicated.
I ran C64 emulators on my Acorn RiscPC with a 200 MHz StrongARM. It worked, but the more exact (and thus more compatible) VICE didn't run at full speed. The basic Frodo was fast enough, but the more exact FrodoSC was even slower than VICE.
VICE was fast enough on my 550 MHz Pentium III, but as soon as I tried to enable the more exact reSID sound emulation it was crawling. I'm suspecting that you need a 1 GHz machine to run a C64 emulator that is exact enough to run every software that was ever written for the real hardware.

One of the main differences between a rough and an exact emulator is the timing. I was shocked once when I read an article by Aaron Giles about the timing of MAME. It seems that it was using the vertical blank in the beginning. I.e. it displayed the whole screen and then checked if it should do anything else, like sound etc. When you have a NTSC screen that's 60 times a second. That might be enough for a system that doesn't run too much software and wasn't around for too long. But in the case of a hardware like the C64 or the SNES, where the programmers had years to know every bit by heart and squeeze every cycle to the maximum, such rough timing just doesn't cut it. The most exact thing would be to work with the actual clock of the system, so in the case of a C64 that would mean to perform certain checks not 60 times but about 1 million times per second, that's a big difference!

Aaron Giles actually came up with a different timing idea, because they had lots of problems with systems that had multiple CPUs. Here's the article, if you are interested:
www.aarongiles.com/mamemem/part6.html

EDIT: In the end, if Snes9x or ZSNES is good enough for you, just use these. As I said, the author of BSNES didn't intend to compete with these in terms of speed or even compatibility, he just wanted to see how far you can get by emulating what the hardware does, without any short cuts or tricks, and also document the hardware as he went along.
Last Edit: 14 years, 1 month ago by M.I.K.e.

Re: The State Of Emulation Software 14 years, 1 month ago #526

Interesting article -- the MAME project sure had a lot of problems to overcome on the way to its current state. I was surprised to find I actually understand most of it.

Systems programming still scares me. (Yet I'm about to do a university subject on operating systems and networks!)

Re: The State Of Emulation Software 14 years, 1 month ago #527

Good luck on that project.
I remember that I programmed a consumer/producer problem together with another student (each had one of the two applications). I guess we did something wrong with the shared memory. We were sane enough not to run the test on our machines but on a third one with the "on" command (we had access to the computer lab on the weekend, so no one else was around). I guess we developed the remote logout for HP/UX, because as soon as both processes ran the OS went straight back to the login screen. Ah, those were the days...

Also try to plan a whole lot more time than you think you might need. The first exercise was easy (word count), but the second one was a whole lot more complex. The other student and me met at 3 PM, and I thought we'd be done before dinner for sure. Well, I came back home around 3 AM...
For our other programming sessions I always brought something to eat with me

Time to create page: 0.17 seconds