Exodus - A cycle-accurate Mega Drive/Genesis Emulator(assemblergames.com)
assemblergames.com
Exodus - A cycle-accurate Mega Drive/Genesis Emulator
http://www.assemblergames.com/forums/showthread.php?45726-Cycle-accurate-Mega-Drive-emulation-Exodus-coming-in-April!
21 comments
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.
Moving the glue code from a .c file to runtime makes it faster to tweak, but it's not a new idea.
The gem5 simulator (http://www.gem5.org/Main_Page) sounds like it works in a similar way to let you hook together different components and simulate different systems. Although gem5 is a research tool and not targeted to specifically emulate real devices.
""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.
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.
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.
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.
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.
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.
It should be possible, providing you can keep enough information to handle potential rollbacks (you should be able to limit yourself using regular sync points which would make that job easier), especially if you keep profiling information to keep track of areas of code that do require synchronisation.
Main thing you need to ensure is that all the modules accurately track internal time so that synchronisation events do work accurately.
Main thing you need to ensure is that all the modules accurately track internal time so that synchronisation events do work accurately.
"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.
this sounds cool. i'm not huge into the emu scene, but i haven't come across any emulator that has a debugger.
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.
http://nocash.emubase.de is the website if you want to check them out.
> but i haven't come across any emulator that has a debugger
Mednafen, Stella, FCEUX just to name a few
Mednafen, Stella, FCEUX just to name a few
[deleted]
How is Exodus different than MAME?
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
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
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.
The amount of custom code in each architecture is minimal-- it's mostly setting up memory maps and connecting the various chip emulations together.
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.
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.
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.
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.
MAME is a project to emulate Arcade games. This is a project to emulate Sega Genesis/Megadrive games. Although many already exist, they use a lot of different tricks to help performance. Some of these hacks can cause game-breaking timing problems in some games. A cycle-accurate emulator takes a lot more processing power, but allows for the most accurate emulation of the games.
Sounds beautiful, can't wait to see it!
Woah...this could be extremely cool.