The way this is going, this might be my new standard emulator to use! I look forward to it. What I might do is compare my hack on this emulator to the real hardware (RH). Using my hack, there a fair few differences between Kega and RH, and only one or two between Regen and RH. If I find 0 between Exodus and RH, you will receive a huge triple chocolate cookie.
Awesome, I've been waiting for this for a long time. But, I've got to ask... there's going to be Game Genie and Pro Action Replay cheat code support right? Perhaps I'll make the request of Exodus supporting Kega .pat files or the importing/conversion of .pat cheat files so I don't have to manually convert the countless files over to another emulator again. In terms of other requests mentioned, I'd have to say Sega CD/LD and 32X before any other systems because honestly they'd be more useful... and they're more closely tied in with the Genesis than Saturn and the Dreamcast. As far as I know, Genesis Plus GX supports lock-on of cartridges (S&K, S&K + S2 Upmem ROM, Game Genie, Pro Action Replay, etc.). It even supports the cheat code searching features of the Pro Action Replay 2 ROM.
The "bad" thing about the way GPGX implements those is that they're very specific selections in a "Lock-On" option, and it accesses specifically named ROMs placed inside the emulator's folder, so you can't change between versions on the fly or have S&K connected to a Game Genie, for example. The way MESS does it when using a GUI like QMC2 is, you first select any kind of Lock-on cartridge and then another tab (or two in case of the Sufami Turbo) appears where you can select the game to insert, which is more flexible.
Suddenly from out of nowhere, Nemesis. Good to see you again - and that Exodus is still going, to boot! I remember that post linked earlier in this thread on CulT - great to see you're at a point you can make a public release of this thing. =)
All these years later and you still post the most amazing shit. Good to know you got the magic flowing still.
Sounds good! Have you perhaps tried getting Sega Pico software on this? Quite a few of the games break the current emulators, so it's probably a good check for getting things "cycle accurate" on an emulator that doesn't strain modern CPUs. As someone who follows BSNES and works to improve the state of Super Famicom/Satellaview emulation I'm curious to see how this will turn out. I hope it lives up to the hype this thread is generating.
So basically, this will be Mame/Mess done right, on the (very) long run? That sounds awesome, since the only time MAME did not suck was when Aaron was handling it. Also, the cores will still be fully commented for hardware documentation, right? That's something that will make an interesting read. Still offering testing if/when you decide to crack that thing! I now have 16 Saturns (I think), all with different motherboards. Shit, I really need to publish the info I have on that thing, but I first need to build a system for it, and the more modular I want that to be, the longer it takes to finish it.
Just wanted to chip in to say that I am also eagerly anticipating this, it sounds fantastic - great work! I do have a couple of questions: first, I see there is a nice-looking 68k disassembly view - how much is there in the way of debugging? I have found that a decent debugger seems to be lacking amongst Megadrive emulators. Second, any plans for Linux support? If not, I suspect I will have a go at porting it myself once the source it released
I wanted to chip into this because I am astounded. I don't fully understand everything but having something this open ended, this accurate with full debugging and analysis tools is simply incredible. I'm going to chip in and ask for 32X and MegaCD inclusion, as well as Game gear and Master system as I feel that they all tie together pretty well. May I ask a little question, with what you say about the level of customisation and the modular approach you have taken, could emulators of more complex architecture be built in future I.e N64 or Playstation?
Actually, if you have chip-accurate Genesis emulation, then how hard would chip-accurate Master System emulation be? IIRC the Genesis can play Master System games as it is; it just needs something to get the cartridges to fit in the slot. This is why you can put MS games on a Genesis flash cart and run them with few issues, isn't it?
SMS is easy compared to MD as it is fully synchronous. I will make a cycle accurate SMS emulator for SMSDMA centric development uses in nearer future.
Not on the first release. It may seem trivial to add, but since I'm building a generic emulation environment, a feature like that is actually a lot of work to implement, since nothing can be "hard-coded" specifically in order to support it. It'd actually be far easier to make the real Pro Action Replay/Game Genie devices work within Exodus than add the integrated code support most Mega Drive emulators provide. There is an extension system which allows just these kind of things to be built, but there's a bit of work involved (say, about a week's worth), and there might be a very minor performance impact involved in adding the necessary hook. Still, I will be adding this after the first release, but I'll let people vote on it to see how soon I work on it. Haven't looked at it at all, but I am familiar with the Pico hardware, and not too much would need to be done in order to support it. It's not very high on my list of priorities though. I'd certainly work on MegaCD/32x support first personally. When I release the SDK though, there's nothing stopping someone else having a go at getting the Pico working. Yep, that's precisely what this is, with the key differences that Exodus is designed to emulate any system, not just the Mega Drive, and Exodus is also designed as a powerful debugging tool as well. It has the potential to be, yes, and I've designed it with the idea that it will be that in the future, so the architecture should accommodate it. I can't possibly do that alone though. Ultimately, Exodus will end up supporting as many systems as other people are able and willing to contribute to achieve that support. I personally will be pursuing pretty much every Sega system ever made, in whatever order I end up doing them, but outside of that, it's going to be largely up to other contributors to help improve support. The debugger is very extensive, with a lot more features planned. I designed the debugging features using my own list of what I wished I had back when I was doing rom hacking. I'll be very interested in user feedback as to what improvements and new features people want. Debugging features are usually quite quick and simple to implement. As for Linux support, no, there will be no support for Linux on release, and I have no intention of making a Linux port myself, but I designed the system from the ground up with portability in mind, with the full expectation that other people would want to port it to other platforms, so you should find it quite easy to do so. Yes, that's very much the intention, and the platform was designed with this in mind. I will be attempting emulation of master system compatibility mode in the Mega Drive hardware at a later date. There's a bit of hardware testing to do in order to confirm how that actually works, but I don't expect it'll cause too many concerns. There's a little bit of work to do on the VDP first though. The initial release I'm making won't have mode 4 support for the VDP, since there are a lot of hardware tests I still have to do to confirm how this works. Charles MacDonald has been doing some testing on that aspect which should reduce the amount of time I have to spend doing hardware tests on everything myself.
What makes this significantly different from RetroArch, aside from the obviously more accurate Genesis emulation?
I've never used RetroArch, but from what I can see, there's only about as much in common between Exodus and RetroArch as any other emulator. RetroArch may use a plugin system, but it's completely different to the plugin system in Exodus. From what I can see, plugins for RetroArch need to implement a "system", so that means a plugin needs to be written for each platform, IE, one for the Mega Drive, one for the Master System, etc. Each plugin is responsible for actually doing all the work for each element in the system, and performing the communication between all devices and managing timing between them, and if any code is common between each system, it's up to each plugin to figure out how and if to share that code. Adding additional systems requires creating a new plugin, even if all the elements in that system have already been used in other supported systems. Plugins in Exodus emulate individual discrete chips or devices, IE, like an individual CPU, video device, or audio device. The Exodus platform itself manages all communication between devices, and handles the timing and synchronization issues, and systems themselves are defined purely by XML, so adding support for a system that already has all its devices emulated just requires writing an XML document to describe the mapping between the devices.
Glad to hear it! Real GG/PAR device support would be awesome too, but sadly I have games with codes that exceed the GG's 5 code limit. Seriously Nemesis, you're awesome.
I know I'm not being terribly constructive by asking but we're starting to approach the end of April; thoughts on how long before you're ready to release it? More than anything I really want to say you're a badass for doing this. This is one of the cooler emulation projects I've ever heard of and it's really cool that after putting that much work into it that it's finally all coming together for you. I'm excited to play with it
