I'm going to start using this news feed as a development blog, to keep people updated with what's happening with upcoming changes, and how development is going in general.
Right now I'm trying to break through a barrier to cycle accurate emulation that no software emulator has done to date. The 68000 processor in the Mega Drive is clocked at around 7.61Mhz, meaning 7,610,000 cycles per second. A single opcode usually takes between 4 and 40 of those cycles to execute, but it can be a lot more than that for MOVEM opcodes, and potentially hundreds for multiply and divide operations. Here's the kicker - the 68000 processor can release the bus to share with other devices, such as for DMA operations from the VDP, or banked memory access from the Z80. The real 68000 processor will respond to bus requests within 2 cycles, or if it's currently actively performing a bus operation itself, at the end of the current bus cycle (4 cycles typically, but can be longer). This means there are around 3,805,000 timing points each second where external requests to obtain the bus need to be checked and responded to in order to get perfect timing accuracy. Right now, Exodus only checks between opcodes, meaning most bus ownership requests are delayed. Most other emulators only synchronise between cores and check for access requests at fixed points, usually thousands of cycles in length. Both are incorrect, and can easily impact timing sensitive code.
There are several challenges in overcoming this barrier. The first is performance. If you want to respond to bus requests accurately within 2 cycles, you need to be checking at 3,805,000 points during execution of your 68000 core for bus access requests each second, and more than that, you need to keep your cores "in sync" so that you don't find out about an access attempt after you've already passed the time when it should have been processed. There is an unavoidable performance hit in doing this. Exodus has a design that aims to minimize that cost, but it will be there. Most of it is already being taken by the platform, hence why Exodus requires more processing power than most (all?) other Mega Drive emulators out there. It was designed to solve these problems, but that means an execution model which has a lot more overhead for synchronisation, because synchronisation is happening a lot more frequently. That's the cost of cycle accurate emulation.
The second barrier is the more annoying one IMO. Your "traditional" emulation core would step through one instruction at a time. If the next instruction is an ADD opcode, you execute it in one go. That's simple, logical. Let's simplify and say it looks something like this:
void AddOpcode(source, target)
{
sourceData = source.read();
targetData = target.read();
result = sourceData + targetData;
target.write(result);
}
If you now can grant the bus at between 1 to 13 discrete points within the execution of that single opcode though (for ADD this is correct), what does that look like in code? You can't just call a single linear function for that opcode with one entry and return point anymore. You could try and have blocking calls within the function, so that the execution of the AddOpcode function is suspended until the bus is returned... but then you can't do savestates, because how can you save the current execution state and resume it later when you leave a blocked thread like that? You could try and wait for the processor to be between opcodes for a savestate request to be actioned, but what if you have two processors constantly swapping the bus between each other? They might never reach a point where both are between opcodes and all threads are unblocked.
The best way forward is to turn your opcode execution steps into a kind of state machine, where you can step through the opcode one internal step at a time. That makes the code unfortunately more verbose, and much less branch predictor friendly, so slower, but it looks something like this:
bool AddOpcode(source, target, currentStep)
{
bool done = false;
switch (currentStep)
{
case 0:
sourceData = source.read();
break;
case 1:
targetData = target.read();
break;
case 2:
result = sourceData + targetData;
break;
case 3:
target.write(result);
done = true;
break;
}
++currentStep;
return done;
}
This is what I'm currently working on doing for Exodus. This will give truly 100% perfect timing accuracy for the CPU cores, which will be essential when expansions like the MegaCD and 32x come along, which makes the number of bus interactions very complex.
There's actually more to it than this. Part of the work I'm currently doing involves adding perfect handling of DTACK to handle wait cycles during bus access, and group 0 exceptions like bus and address errors, but I'll write more about that at another time.
I'm happy to announce I have now started work on Exodus again. You can expect a fairly steady set of updates over the next few months as I get the repo into shape. No hard plans on what will be in the next release or when that will be, but it'll be coming during the year. I've also made the decision to simplify the licensing model, and as of today Exodus will be governed by the MIT license, a much more permissive licensing model. Feel free to use and adapt the code however you see fit. Any contributions or attribution you want to make back to this project would be greatly appreciated, but not required.
With the accelerating decline of Mercurial support in the industry in general, and the decision by Atlassian to drop Mercurial support from BitBucket in particular, it's past time for me to migrate the Exodus source repository to a new home. Although Exodus hasn't seen much love from me in recent years due to real life keeping me busy, I'm still here in the background biding my time until I can invest in this project again. To give the Exodus code a home until that happens, I've just migrated the repository over to GitHub. Although I have a fondness and personal preference for GitLab, GitHub has become the de-facto standard home for open-source projects over the last decade, and I see no reason to fight that trend. You can now find the Exodus source repository hosted under GitHub at https://github.com/exodusemulator/Exodus. Future development will be based from this location, and the website has been updated to reference this new home.
Exodus 2.1 is now available in the downloads area. Note that you'll need to install the Visual C++ 2017 x64 runtime too if you don't have it, which is available there too. There's quite an impressive list of bugfixes in this release. Job EX-303 in particular fixes a crash that could occur if you had a joystick or gamepad connected, which affected a fair number of people in the previous release. There's also pretty good performance improvements. I measure around a 30% speed improvement overall from Exodus 2.0.1, which is pretty substantial. I've made the VDP plane viewer a but nicer by making the window resizable and making the plane region zoomable, which is nice, but I'm particularly proud of this little nugget:
It's a pixel info dialog you can turn on via "Debug->Mega Drive->VDP->Debug Settings". Just float your cursor over any pixel, and it'll tell you exactly what caused it to appear there. This plays nice with layer removal, so you can peel off a layer at a time and see what's behind it if you want to, and where that pixel came from. It even works for CRAM writes during active scan. Being able to reverse the VDP render pipeline like this was relatively easy in Exodus because of how much info the VDP core holds on to, but it still took a bit of work to pull this off. Give it a spin and let me know what you think. It's great for diagnosing those mystery single line or pixel errors you can get while making something.
Here's the full list of user-facing changes in this release:
Enhancements:
Bug fixes:
After a long hiatus (over 3 years!), I'm finally returning to give this project some love. At the end of the day, this is just a hobby, and it has to move aside when real life issues require more of my time. Although I can't promise that won't happen again in the future, circumstances have changed, and I do find myself with the time to work on this project again. At this stage I believe this will continue to be the case, and I'll be able to consistently move this emulator forward.
I'm keeping things low key for now, but I'll be putting out a new release very soon, possibly in less than 24 hours. This release will include performance and usability enhancements, a few new features, and various assorted bugfixes. This is mainly a housekeeping release, to clear the decks for bigger work to come.
I've been pondering what I should be focusing on for new development over the last few days, and I feel to stay true to the goals of this project, that has to be accuracy. Although there are a lot of new cool features and enhancements I want to build, Exodus currently falls well short of where it should be in terms of accuracy, and this is primarily down to a lack of sub-opcode level external bus timing accuracy in the 68000 core. While no other Mega Drive emulator does this correctly either, they bend the timings of other system events to work around this limitation and make mainstream games run. I have deliberately avoided doing that in Exodus, and as a result there are numerous games I know of that don't function correctly as a result. This is where I'll be focusing the next development stages, aiming to get 100% cycle accurate M68000 and VDP interaction as a priority. You need to be able to measure accuracy though, so this process will involve hardware testing, and producing test ROMs. By the end of this process, I'll deliver some ROMs which can act as a regression test and a measuring stick, to compare timing accuracy between emulators and the real hardware. I already know roughly how it's going to work, and it's going to be pretty well impossible to bodge, so it'll be interesting to see the results. If you thought OverDrive 2 was brutal on emulators, just wait for this one.....
I'm pretty happy with the release of Exodus 2.0 overall, but as expected with only me testing the build prior to release, there were a few bugs in some areas I hadn't tested for awhile. There have been enough issues fixed to justify a patch release, so Exodus 2.0.1 is now available for download! Considering it was 2 years between the first two releases, I think 18 hours between these last two is a bit of an improvement. :)
Enhancements:
Bug fixes:
Exodus 2.0 has now been released! You can download the new version now on the current releases page. I'm dedicating this release to my beautiful wife Judi, and my two boisterous little boys Justin and Aiden.
As promised, Exodus is now also open source. Check out the Source Code section for instructions on how to obtain and compile the source, and information on how you can contribute code changes to the project.
Good news, everyone! Although my previous plans to release Exodus 1.1 last year were shelved, due to a lack of time to work on the project for much of last year, things are back on track now though, and a shiny brand new 2.0 version of Exodus will now be released 30th of April 2015, exactly 2 years after the first release. This release will contain major user interface and performance improvements, as well as a lot of back-end work on the plugin model. Most importantly, I'm now ready to take the project open source. At the same time as the release, the source repository for Exodus will go live on Bitbucket.
So I've been pretty silent on this website since the first release of Exodus. Some family trouble came up mid last year, and with a newborn and 2 year old child on top of that, there wasn't a lot of time for me to work on this project for much of the year. I've been doing heavy development for several months now though, working towards the next release. The biggest part of what's coming in the next release isn't feature improvements though, it's the promised open sourcing of this project. A project like this is too big for one person to do alone, and I'm very open to anyone who wants to contribute to move this project forward, be it with new emulation cores, debug features, or bug fixes, all of it helps to improve Exodus and build it up. My main focus since the last release has been on making some critical internal source code changes I felt were required to complete, before other people start writing code on top of this platform.
The first public release of Exodus is now available in the downloads section. This has been a very long time in the works, with countless hours spent getting it to the point it's currently up to. I hope you like what you see. There's a lot more planned for the future though, so keep an eye out for updates. If you have any feedback you want to give, or if you encounter any problems while trying to use Exodus, please contact me via the support forums, and I'll do my best to help. Also remember to check out the suggestions page if you have any great ideas to improve Exodus, or if you want to see and vote on ideas other people have submitted.
Thanks for your support.
A number of people have asked me what the minimum system requirements will be in order to run Mega Drive games at full speed in Exodus. That question is a little hard to answer, since the speed at which Exodus is able to run does depend on the code itself that's being emulated. Code with very tight timing requirements is likely to execute slower than code with very simple timing requirements. I also haven't exhaustively tested performance on different hardware platforms or different games. That said, after gathering some feedback, here's my recommendations:
I thought for awhile there that I'd never get this place online, but here we are. This is the official website for Exodus, the soon to be released emulator. The release date for Exodus is the 1st of May 2013. I'm making what I hope to be the final, release-ready build right now as I write this article.
It's been a long road getting to this point. I first started working on Exodus in late November 2006, with a focus on the Sega Mega Drive. About 3 months later, I had an emulator capable of playing quite a few Mega Drive games, minus support for sound. I've released preview versions of this emulator several times in a limited capacity, but it's always been far from what I wanted it to reach, until now. Almost 7 and a half years after I began work on Exodus, I'm finally ready to make the first full release.