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.

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.