Welcome

Details
Written by: Nemesis

Welcome to the official website for Exodus, a unique and powerful emulation platform. Please use the main menu above to learn more about Exodus, and to gain access to support and downloads.

Yet another blog....

Details
Written by: Nemesis

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.

Return to active development - now MIT licensed!

Details
Written by: Nemesis

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.

Migration to GitHub

Details
Written by: Nemesis

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 Release

Details
Written by: Nemesis

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:

  • EX-301 - Created the new VDP pixel popup info window
  • EX-316 - Upgraded projects to target VS2017
  • EX-318 - Fixed DPI issues, and made VDP plane viewer resizable and zoomable
  • EX-326 - Performance improvements
  • EX-339 - Added support for Gens KMod internal debug features on undefined VDP registers
  • EX-334 - Added support for stepping over "counted loop" opcodes such as DBRA
  • EX-336 - Added "run to" option in disassembly window, and improved controls and hotkeys.
  • EX-342 - Saved the last used ROM directory path to the system preferences

Bug fixes:

  • EX-295 - Fixed incorrect clearing of Z80 registers on a reset
  • EX-296 - Fixed the 32-bit build target
  • EX-297 - Fixed the naming of M68000 registers in the generic register window
  • EX-298 - Fixed a deadlock and several other issues with the VDP plane viewer
  • EX-299 - Made more room for the FPS counter in the VDP Image status bar
  • EX-302 - Fixed an error with the sample rate for YM2612 and PSG audio log files
  • EX-303 - Fixed an access violation in the joystick access code that occurred if the connected joysticks didn't have consecutive ID numbers starting from 0
  • EX-304 - Fixed the title of the system settings window
  • EX-312 - Fixed disposal of event handles in AudioStream library
  • EX-313 - Fixed bug in M68000 ABCD opcode
  • EX-314 - Fixed active disassembly end location appearing as zero on startup
  • EX-322 - Incorporated remaining fixes identified by Francis during GCC compilation work
  • EX-323 - Fixed M68000 LINK opcode disassembly issue identified by ryanfaescotland
  • EX-325 - Fixed excessive VDP rollbacks and intermittent deadlocks
  • EX-327 - Fixed main window appearing at incorrect size on startup when using saved layout
  • EX-328 - Fixed identified system deadlock case
  • EX-271 - Worked around redraw issues with lockable register edit boxes when docked
  • EX-331 - Fixed access violation when generating savestate in S315_5313::GetScreenshot
  • EX-332 - Fixed threading issue when removing breakpoints
  • EX-307 - Fixed the display of sprite pixels in palette column 15 when shadow/highlight mode is active
  • EX-333 - Fixed disassembly display in trace log
  • EX-337 - Fixed identified threading issues with system execution
  • EX-338 - Fixed DPI issue with dashboard drop targets
  • EX-341 - Fixed BCD flag errors in M68000 core based on new research

Return to active development

Details
Written by: Nemesis

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.....

Exodus 2.0.1 Release

Details
Written by: Nemesis

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:

  • EX-291 - Improved default workspace loading to restore the main window size and maximized state before the main window appears, removed the maximized state as the default state, and changed the "Mega Drive Clean" workspace to not be maximized.

Bug fixes:

  • EX-289 - Fixed an error in the Mega Drive ROM loader which prevented games that used SRAM from loading
  • EX-290 - Fixed a bug in the way embedded ROM file selection was saved which prevented saved systems with an embedded ROM specified from loading
  • EX-292 - Fixed a race condition in the ViewManager which intermittently caused two "Image" windows to appear on startup
  • EX-293 - Fixed several issues with device key mapping which prevented new key assignments being made

Exodus 2.0 released, project now open source!

Details
Written by: Nemesis

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.

Note that you won't see a massive improvement in Mega Drive game compatibility with this version, as the focus has been on other areas, like performance, user interface, and the plugin API. There are still a number of games I know of that will greet you with a black screen for example when you try and load. This is due to the fact that although Exodus aims for cycle-level accuracy, it's not actually there yet, and there's a number of games that use a kind of wait loop against flags on the VDP that technically requires at the very least sub-opcode level timing emulation to pass. No other emulators have sub-opcode level timing emulation for their CPU cores, but they use incorrect timing on the VDP as well in order to make the tests pass.

The biggest thing that needs to be done for Exodus at this stage in order to improve Mega Drive compatibility is write Z80 and M68000 cores that emulate individual bus cycles, rather than emulating at an "opcode" level. For the M68000 at least, nobody seems to have ever done this, and a lot of information needs to be gathered on the hardware in order to determine the correct timing and order for each bus access within instructions. Emulating it properly will also require a major change to the bus system, which I currently have in the works. I was originally planning to have this bus change in Exodus 2.0, but I didn't want to delay the release any further. The bus system redesign, along with cycle-exact M68000 and Z80 cores, will now be my primary focus of development for the next major release. After this is complete, Exodus will have CPU emulation which is truly cycle-exact.

Despite the lack of perfection with the CPU cores at this stage though, Exodus is already much more accurate than other emulators at Mega Drive support for graphics and sound. Exodus has the most advanced YM2612 core ever written, as it was written entirely from scratch during my detailed reverse engineering of the YM2612 back in 2008.

In terms of the VDP, Exodus is the only Mega Drive emulator that has a cycle-exact VDP core, which allows it to emulate many quirks and tricks of the real hardware that other emulators can't, like Direct Color DMA. Aside from rendering accuracy, the VDP core is also fundamentally more accurate in handling basic communication from the CPU. Try this test ROM for example, which tests VDP port access:


http://nemesis.exodusemulator.com/MegaDrive/Tests/VDPFIFOTesting/VDPFIFOTesting.zip
(Detailed discussion: http://gendev.spritesmind.net/forum/viewtopic.php?p=20975#20975)

This test ROM isn't perfect, a couple of the tests fail intermittently on the real hardware, but it's pretty stable, and it's very thorough and brutal. Even Exodus doesn't get a perfect score here yet, it gets 121 out of 122. Most other Mega Drive emulators will only score around 20 or so. I'm hoping with Exodus now open source, other Mega Drive emulators which are still being maintained can use Exodus as a reference, and improve their accuracy on these kind of tests too.

Anyway, I hope some other people can make use of this. It's been a very long road to get to this point. Exodus was around 200,000 lines of code at the last count, and most areas of the code have gone through numerous revisions to get to where they are now. I daren't even estimate the number of hours that have gone into this project. I hope you find it interesting and useful.

EDIT: I forgot to say, if you want to check out the debugging features, you'll be best off using one of the pre-made workspaces. Select "File -> Load Workspace" from the main menu and select "Mega Drive Debugger.xml". That'll give you a pretty good debug environment ready to go.

Exodus 2.0 and Open Source release on 30th April 2015

Details
Written by: Nemesis

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.

The extremely long delay between these releases highlights the need more than anything for this project to become open source, so that other people can contribute. With the improvements that have been made to the plugin system and overall architecture in Exodus 2.0, I'm now ready to take that step. Opening up the sourcecode on a public host like Bitbucket will make it easy for people to get involved in the development of this project, and to do their own mid-development builds. Source code contributions will be able to be submitted through pull requests, just like many other projects that are managed through these systems. Issue tracking will be public and visible through a Jira server, where users will be able to see information and receive notifications about the progress of the project. Public forums and the suggestions page will continue to give support and help direct future development.

This is a really exciting step for the Exodus project, and it's been a very long process for me to get to this point. I'm looking forward to the upcoming release, and I hope a few other people out there might like what they see, and want to get involved in adding new emulation cores or features to the platform.

Upcoming Exodus 1.1 and full open source release

Details
Written by: Nemesis

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 sourcecode for the upcoming version 1.1 release of Exodus will be hosted publicly on BitBucket, where I will push mid-release changes from then on. It will act as the live, central source repository for this project. The sourcecode will include an SDK for building your own plugins which can integrate with existing Exodus builds, and there will be documentation provided for that SDK, describing each interface and giving a basic overview of how the emulation platform works and is designed to be used. If you want to build your own emulation cores, you can develop and release them separately from Exodus if you want, or, if they meet the quality standards, have them adopted into the main Exodus repository to be included in future releases. Extensions can also be written which add new features and tools to the environment itself. This could be an integrated source editor and compiler toolchain for example, or maybe just a single new debug window for an existing emulation core. These can also be developed separately if you wish, and later merged into the main repository after review. I'll be doing code reviews and quality checks for any "pull requests" into the main repository, to ensure the goals and quality standards of the project are maintained, but I more than welcome contributions by others, so if you feel you have something you want to contribute, by all means, develop it. I'll be around on the support forum to answer any questions or offer any guidance.

In addition to the public source repository, I'll also be making a JIRA server public for issue tracking in Exodus, where you can see what bugs and improvements are currently in the system. The JIRA server will only be read-only for public access, with myself and any future maintainers being the ones who update the content, but the idea is to provide a transparent development process, where you can see what's being worked on, and along with the current suggestions page, vote for and influence future development work.

This is still a few more months away at this stage, but I wanted to let anyone who's watching that things are happening, and this project will be opened up soon, so watch this space.

Page 1 of 2