

Exodus - A cycle-accurate Mega Drive/Genesis Emulator - bane
http://www.assemblergames.com/forums/showthread.php?45726-Cycle-accurate-Mega-Drive-emulation-Exodus-coming-in-April!

======
bane
"This emulator is fundamentally different to every other emulator I know of,
in several critical ways. I'll publish more about that towards the time of
release, but most importantly, Exodus is not a Mega Drive emulator. Exodus is
a generic emulation platform, which allows systems to be assembled from
individual components at runtime. Nothing related to a particular system is
hardcoded. Exodus constructs a system from a set of discrete components,
manages the communication between those components, and keeps perfect timing
accuracy between each component. Other systems can easily be modelled without
modifying or rebuilding Exodus, it simply requires emulation cores for each
device in that system to be available."

Woah...this could be extremely cool.

~~~
Scaevolus
MAME has been doing basically this for 15 years-- arcade cabinets are
simulated by combining various common chips (CPUs, video drivers, sound
chipsets, ROMs...) with a small amount of glue code.

Moving the glue code from a .c file to runtime makes it faster to tweak, but
it's not a new idea.

------
aidenn0
""Most of the time, a timing problem is not going to occur. Given that
assumption, I want to execute my devices unsynchronized for as long as
possible. If something ends up happening in the wrong order, I want to roll
back to the previous point, and repeat the operation, this time with fore-
knowledge about the timing requirements". This is the execution model Exodus
uses. By executing in parallel for as long as possible, we can make use of
multiple cores. "

This is bad for an emulator; you want to minimize latency and jitter over
throughput. It doesn't matter too much if your game is fast enough for 98% of
the frames if the other 2% of the frames stutter.

~~~
Scaevolus
As long as each _frame_ ends up being ready on time, having variable latency
and jitter for segments of code is not a bad thing-- users can't tell.

~~~
aidenn0
I am highly skeptical that consistent frame rates will be possible with this
architecture; IIRC byuu considered and rejected such an architecture for bsnes
for performance reasons. Granted hardware has advanced since then, but single-
threaded performance hasn't advanced a whole lot in that time, and that's what
you're going to run into a bottleneck with this.

~~~
byuu
There were two reasons I rejected the idea. Foremost was that my goal was code
simplicity. Although true that most of the time you can run ahead without
issues, it is no small feat to be able to serialize tiny deltas that can then
be rewound when a synchronization error is detected (a full system state would
be far too costly to capture and rewind.) Further that with all of the pain
that traditionally comes with multi-threaded programming (especially in
portable C++), and I found cooperative threading to be far cleaner and easier
to debug, and thus, to refine accuracy on.

The second reason is that my approach ended up needing about 2GHz to run well
for the SNES. Nemesis' approach needs about the same, but also needs a quad
core to run well with the Genesis. Since I was able to pull off all I needed
with a single core, why require a quad core system? Any quad core will have a
fast enough individual core, after all.

That said, it's actually my approach that won't scale well, as mine is bound
to one core whereas Nemesis' approach is not. It's part of the reason I
haven't attempted the N64 or higher. If you ever want to see more accurate
Saturn emulation or similar, Nemesis' approach is going to be the way to go.

As an aside, we've been hearing about the 'end of the free lunch' for a decade
now. All I can say is my slightly overclocked i7-2600K runs my emulator nearly
twice as fast as my previous E6600. And I hear the Haswell will be 15% faster
per clock than the Ivy Bridge, which was 10% faster per clock than the Sandy
Bridge. That and it's clocked higher. I don't foresee us running out of
optimization potential any time soon, and by then who knows ... we may be able
to create graphene processors or something even more exotic. Necessity breeds
innovation.

The bigger concern on 'free lunch' is the push toward mobile devices and lower
power usage (longer battery lives.) But for that I think you will always want
a speed-oriented emulator, so programs like Snes9X and Gens are more
appropriate there anyway.

~~~
bane
_If you ever want to see more accurate Saturn emulation or similar, Nemesis'
approach is going to be the way to go._

My understanding is, with the mess of chips under the hood of the Saturn, that
emulating it well almost _requires_ cycle accurate emulation.

------
frozenport
How is Exodus different than MAME?

~~~
bane
Different goals it sounds like. MAME is intended to try and archive and
emulate every arcade game known, the emulation doesn't have to be 100% so long
as the experience of game is more or less playable. MAME likely contains code
that replicates hundreds or even thousands of discrete architectures, probably
sharing some common emulation cores, but lots and lots of custom code.

Exeodus appears to be more like a framework for describing different system
architectures and enabling cycle accurate emulation (see BSNES/Higan [1]). As
a test case, the author focused on the Mega Drive/Genesis...but it sounds like
if you have a descriptor file of an architecture and the necessary components
available, you could cycle-accurate pretty much anything, even systems that
never existed!

I can imagine a community of authors that put together a library of different
system descriptions that you load before loading a ROM or a disk image.

1 - <http://byuu.org/higan/>

Exodus is intended as a general purpose, cyc

~~~
Scaevolus
MAME prefers 100% accuracy over playability, and does cycle-accurate
emulation.

The amount of custom code in each architecture is minimal-- it's mostly
setting up memory maps and connecting the various chip emulations together.

~~~
byuu
MAME/MESS certainly boasts of favoring accuracy, but the results are hit and
miss.

When you emulate an arcade architecture with three games made for it, you
don't have much code to stress test your emulation. Nor can you really expect
someone to spend ten years perfecting completely unused hardware features for
a system with 100% compatibility already.

Much work is put into emulating 3D video chipsets in software, which is
fantastic for preservation (unless you like that most N64 emulators to this
day rely on 3dfx Glide wrappers); and then they seemingly throw out all of
that goodwill by implementing their CRT simulation using HLSL, which only runs
on Windows boxes. Even GLSL would have been much more in line with their
portability vision. It's just a weird contradiction.

And then of course, most of the MESS cores simply don't have the volunteers to
compete with the standalone emulators.

And here is the concern I have with both MAME/MESS and Exodus: the idea that
you can build a system by linking up some discrete components and call it a
day. It's great on paper, and practically a necessity when you start emulating
dozens of systems with many shared features. But no two chips are exactly
alike. There are countless variations of 6502's with slightly different
opcodes (the NES' Ricoh 2A03 famously disabled BCD due to patent concerns) and
timings. A lot of chips have a lot of functionality that is simply never used.
Example: the SNES CPU and Apple II GS both have the WDC 65816's /ABORT line,
yet it's not connected to anything on the SNES; it would be foolish for an
SNES emulator to add the special abort handling to every opcode even though
it's impossible to use. And now look at ARM: every last ARM vendor adds their
own spin on chips. Sure, you could make a generic ARM core, and fill it with a
billion #ifdef's for each chip manufacturer, but then you'll end up with,
well, ... a mess.

And then the whole system for interconnecting everything ... when the only
tool you have is a hammer, every problem starts to look like a nail.
Architectures like MESS are about having one design that hundreds of
volunteers can jump into, understand, and start extending to rapidly support
new systems. But this results in code that doesn't much resemble how the
original hardware worked, and in fact simply becomes a nuisance when design
limitations prevent increasing accuracy further. For instance, MESS' SNES
emulation is suffering due to this reason.

If you want optimum code for a specific system, I think you need to design a
specific emulator around that system's unique design characteristics and
challenges. But I also think the MAME/MESS approach serves a vital role as
well in handling the more obscure systems that can't get the same level of
attention as a classic console with a 4000+ game library. If not for MESS, we
wouldn't have Super A'can emulation, for instance.

~~~
bane
glad to see you jump in here, I'm guessing you can provide _way_ more useful
of an opinion on Exodus that us laymen ;)

Looking through the site, there appears to also be a philosophy around clear,
well structured, well documented object oriented code for things in
Exodus...which of course means that some of the more hacky optimizations are
right out.

------
lubujackson
Sounds beautiful, can't wait to see it!

------
pasquinelli
"Exodus is also an extremely powerful debugging, development, and analysis
environment, which I'm hoping will be able to serve as a very useful tool for
communities involved in development, hacking, and reverse engineering, to be
able to do more complex and thorough debugging and testing in software, where
you can trust that if it runs properly in Exodus, it will run the same way on
the real hardware, and vice versa."

this sounds cool. i'm not huge into the emu scene, but i haven't come across
any emulator that has a debugger.

~~~
jbit
Indeed it's rare, but not unheard of. For example the "nocash" series of
emulators has extensive debug support (breakpoints, memory viewers,
disassemblers, hardware traps, etc)

<http://nocash.emubase.de> is the website if you want to check them out.

