Exodus исходный код

Обновлено: 08.05.2024

Current Release
Release Archive
Documentation
Source Code

Optional: Building SDK Documentation

The Exodus SDK support documentation is build from XML documentation files within the repository itself. To build it yourself locally, do the following:

Open "ExodusDocumentation.sln" from the root of the Exodus repository in Visual Studio
Select "Build -> Build Solution" to create the documentation

The created documentation files will be in the "Documentation" folder in the root of the Exodus repository

Current Release

The current release of Exodus is version 2.1. Download links for all required files are provided below.

Exodus requires the Microsoft Visual C++ runtime to be installed before it can run. If you're not certain you already have this installed, please download and install the runtime before attempting to run Exodus. If you get an error about a missing dll when attempting to launch, the runtime is probably not installed correctly.

Please note that although Exodus is currently setup to load an emulated Sega Mega Drive system by default, this will change in the future as support is added for more systems.

The compilation process for Exodus has been designed to be as simple as possible. There are however a few steps involved in getting up and running the first time, especially if you don't currently have the required tools installed. The following article will walk you through the steps for obtaining the source code for Exodus, and compiling it on your own computer.

Please note that Windows is the only supported platform for compilation. Feel free to experiment with other platforms if you wish, but no support is currently provided for this.

Optional: Building Unit Tests

To compile the unit test projects for Exodus (only one right now), do the following:

Current Release
Release Archive
Documentation
Source Code

Exodus - Home

Welcome

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.

Wednesday, 01 July 2020 09:54

Migration to GitHub

Written by Nemesis Thursday, 30 August 2018 06:18

Exodus 2.1 Release

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:

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

Bug fixes:

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

Return to active development

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.

Thursday, 30 April 2015 23:58

Exodus 2.0.1 Release

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

Obtaining Third Party Libraries

There are a few third party libraries that are currently required in order to build the Exodus repository. In order to obtain the required third party libraries, navigate to the "Third" directory in your local copy of the Exodus repository, and download the following files into the subdirectories that exist in that folder.

For each compressed file you've downloaded, you now need to extract each one directly into the folder it's in. IE, if the archive name was "SomeArchive.zip", and it contained a compressed folder called "SomeFolder", after you extract, you should have SomeFolder sitting in the same directory as SomeArchive.zip. (Note: Catch and htmlhelp are exceptions to this rule. Catch must appear in a subdirectory called "Catch", and htmlhelp must appear in a subdirectory called "htmlhelp".). Ensure that you fully extract ".tar.gz" files. You need to extract the contents of the .tar file within the .gz file too.

Setting Up the Development Environment

Exodus currently uses Visual Studio 2013 as its development environment. Theoretically other IDE's could be used, as long as support exists for compiling MSBuild projects, but the only officially supported IDE is Visual Studio 2013. With the recently released Visual Studio 2013 Community Edition (note: This is different from the previous Visual Studio 2013 Express Edition), you get effectively the same IDE as Visual Studio 2013 Professional, but it's free for private and open-source development. If you don't have a license for a commercial version of Visual Studio 2013, I recommend using the Community Edition.

To setup your development environment, do the following:

Download and install Visual Studio 2013 Community Edition (ISO Image: http://go.microsoft.com/?linkid=9863609)
Download and install the Windows SDK (Web installer only)
Download and install the VisualHG plugin for Visual Studio
Open Visual Studio and select the "Tools -> Options" menu item
Select "Source Control -> Plug-in Selection" from the tree control on the panel
Choose "VisualHG" from the combobox as the current source control plugin, and press ok.

Compiling Exodus

With your development environment setup, you're ready to compile Exodus. This can be done on the command line with MSBuild, but the easiest way is within Visual Studio. To compile Exodus, do the following.

Open "ThirdPartyLibraries.sln" from the root of the Exodus repository in Visual Studio
Select "Build -> Batch Build" from the main menu
Click "Select All", then "Build". This will build all the different platform and build configuration variations of the third libraries, which makes things simpler.
Open "Exodus.sln" from the root of the Exodus repository in Visual Studio
Select "Build -> Configuration Manager" from the main menu
Pick the configuration and platform you want to build. Usually that'll be the "Release" configuration and the "x64" platform
Select "Build -> Build Solution" to compile Exodus
Press Ctrl+F5 or select "Debug -> Start Without Debugging" to launch Exodus

Note that you can compile individual plugins under the "Debug" configuration and leave everything else as a release build. This is usually the way you'll want to work if you're developing a plugin. A full debug build runs very slowly, so you would generally compile just the individual components you want as debug, such as one or two plugins, and possibly the system itself, while leaving unrelated plugins as release builds.

Optional: Running Profile Guided Optimization

Official release builds of Exodus are given a speed boost through the use of Profile Guided Optimization. This technique involves instrumenting the code during compilation, and manually running the program with that instrumentation through a series of tasks, to gather information about what areas of the code are actually bottlenecks and runtime, then feeding that information back into the linker so that it can do a smarter optimization step. This has shown to increase average performance in Exodus by a modest 15% over a standard release build. If you do a normal build of Exodus on your local machine however, this optimization will not have been applied, so you can expect to see around a 15% performance degradation compared to the official release builds. If you want to optimize your own builds, you can do the following:

Switch to the "Release - PGORebuildOptimized" solution configuration
Do a full clean and build of the solution
Switch to the "Release - PGOInstrument" solution configuration
For each project you want to instrument, right click on that project in the solution explorer and select "Build".
Right click on the "Exodus" project and select "Profile Guided Optimization -> Run Instrumented/Optimized Application". If the compiler asks you if you want to rebuild out of date projects, say no.
Run the program through a series of test cases. These should be designed to stress-test the particular projects you're instrumenting.
Close Exodus when your test cases are complete
Switch to the "Release - PGOOptimize" solution configuration
For each project you instrumented, right click on that project and select "Project Only -> Link Only <ProjectName>".
If any projects fail with a message about timestamps not matching, switch to the "Release - PGOUpdate" solution configuration and attempt the link step on them again, and they should succeed.

As you can see, this is a fairly manual process, and takes some time to run through. I wouldn't recommend trying to instrument everything at once, because the performance will be heavily degraded and the performance profile of the emulation cores will change due to bottlenecks in the system and other cores, which will affect the usefulness of the profile data. The selection of the actual test runs is important too. If you're instrumenting a graphics core, you need to run a program which uses the features of that core, so that the various code paths can be explored and profiled at runtime. You should ideally only instrument individual assemblies, or small batches of assemblies, together in the same run. This allows you to make shorter, more focused test runs, and produces a better performance profile.

Obtaining the Exodus Source Code

As for the proper way, you need to have a Git client installed, and clone the repository from GitHub. There are a variety of ways to perform this task that vary between platforms, and a step by step guide is not provided here at this time. Refer to external instructions around performing a clone operation from a GitHub repo for your platform/tool of choice.

Читайте также: