Page 2 of 8

Posted: Thu Apr 30, 2015 11:19 am
by Nemesis
Thanks for the report guys, I've pushed a fix for the error to the repository, and updated the download to include the fix. Here's a hotfix for anyone who's already downloaded it:
http://nemesis.exodusemulator.com/Exodu ... ensions.7z
Just extract the dll in that archive and replace the file in the "Plugins" subdirectory.

Posted: Thu Apr 30, 2015 11:25 am
by Nemesis
mickagame wrote:I m exploring the doc and the code and i m really impressed by your work.
My project would be to compil exodus as a dll core for retroarch.
Even if system is based on dll plugin u think nemesis would be possible to compil Exodus genesis émulation like a whole dll easily?
Yes, it'd be quite easy. If you look at the source, there's actually "Debug - Static" and "Release - Static" configurations to produce a single output exe file. I haven't maintained that build mode, it was mostly just there from before the plugin system was working properly, but it's really just a matter of a few header file fixes and a handful of source changes in the main Exodus project to get that working again.

Posted: Thu Apr 30, 2015 11:30 am
by Black Zero
Nemesis wrote:Thanks for the report guys, I've pushed a fix for the error to the repository, and updated the download to include the fix. Here's a hotfix for anyone who's already downloaded it:
http://nemesis.exodusemulator.com/Exodu ... ensions.7z
Just extract the dll in that archive and replace the file in the "Plugins" subdirectory.
Thanks!

Will try it out as soon as I get home.

Posted: Thu Apr 30, 2015 12:00 pm
by Eke
Thank you for the release ! I can not test the emulator since I still don't have a 64-bit platform but the sourcecode alone is already very interesting by itself, with a lot of comments (and lot of crazy thinkings / todo things 8) ).

I did not browse through the whole code yet but it seems to be extremely well organized and so far I like this very low-level approach. Although it might seem excessive sometime (it seems like your bus interface model is emulating every signals !), I understand this is part of Exodus philosophy and what makes this project kinda unique.

One remark though, in that xml model file:

https://bitbucket.org/exodusemulator/ex ... 201600.xml

Where does these clocks values come from ?

Code: Select all

			<System.SetClockFrequency TargetClockName="MCLK" ClockType="Direct" Value="53634165" />
			<System.SetLineState SystemLineName="NTSC" Value="1" />
...
TargetClockName="MCLK" ClockType="Direct" Value="53203400" />
			<System.SetLineState SystemLineName="NTSC" Value="0" />
I think all the values I've seen being reported were always 53693175 for NTSC and 53203424 for PAL. Not that it would make much difference but I was curious about it.

Posted: Thu Apr 30, 2015 1:32 pm
by Shadow
Nemesis wrote:Thanks for the report guys, I've pushed a fix for the error to the repository, and updated the download to include the fix. Here's a hotfix for anyone who's already downloaded it:
http://nemesis.exodusemulator.com/Exodu ... ensions.7z
Just extract the dll in that archive and replace the file in the "Plugins" subdirectory.
Thanks :)

Quick Test:

Sonic the Hedgehog 3: save works correctly.

Monster World IV: save works correctly.

Phantasy Star 2: save progress in all 4 empty slots at once. After that, game finds problems and trying to solve them, and then all slots empty.

Phantasy Star 4: displays two not empty slots (LV 08, LV 20) does not allow to rewrite.

Crusade of Centy: save progress in all 4 empty slots at once. But progress quite successfully loaded.

Beyond Oasis: save progress doesn't work, all slots empty.

Posted: Thu Apr 30, 2015 1:43 pm
by Black Zero
Eke wrote:One remark though, in that xml model file:

https://bitbucket.org/exodusemulator/ex ... 201600.xml

Where does these clocks values come from ?

Code: Select all

			<System.SetClockFrequency TargetClockName="MCLK" ClockType="Direct" Value="53634165" />
			<System.SetLineState SystemLineName="NTSC" Value="1" />
...
TargetClockName="MCLK" ClockType="Direct" Value="53203400" />
			<System.SetLineState SystemLineName="NTSC" Value="0" />
I think all the values I've seen being reported were always 53693175 for NTSC and 53203424 for PAL. Not that it would make much difference but I was curious about it.
What happens if you input those values into the XML file?
Interesting, might try it out...

Posted: Thu Apr 30, 2015 2:19 pm
by Oerg866
Hey nemesis!

Your emulator still SUXX! ;)

Image

I'm very, VERY impressed with the speed improvements, especially wrt VDP emulation.

Overdrive now runs full speed on ALL scenes on my PC (... via RDP connection because I'm not at home LOL).

Overdrive's emulation remains somewhat alright, although you did fix a few things, Exodus doesn't get it quite right yet. The screen above should not have the black interference on the right, the image cuts off a few pixels too early (horizontally I mean), and plainly "YOUR EMULATOR" still "SUXX" because it doesn't emulate that disabling display during horizontal blanking will interfere with sprite fetching.

The credits sequence exposes a few timing flaws (it is very precisely timed to wait the exact amount of time necessary to render the relevant text, any timing inaccuracies will break it)

Looking forward to testing all the debugging features later :D

Keep up the amazing work ;)

Posted: Thu Apr 30, 2015 3:50 pm
by tryphon
Thanks a lot, it's a wonderful tool.

I didn't want to post earlier because every time I posted to congratulate you when you announced a new release of Exodus, you delayed it :)

I reached the incredible framerate of 10 fps, it really is MUCH faster than the previous release (and it makes it a usable tool for debugging / hacking).

Posted: Thu Apr 30, 2015 7:17 pm
by King Of Chaos
Awesome work Nemesis! Noticed something though, I'm getting this in the error log when trying to load a module with TMSS enabled (without lockout);

Code: Select all

14:15:17.141	4 - Error	System	Missing ModuleID, EmbeddedROMName or FilePath attribute for System.LoadEmbeddedROMData!
I see why too;

Code: Select all

<System.LoadEmbeddedROMData ModuleID="0" DeviceInstanceName="Boot ROM" InterfaceNumber="0" FilePath="Genesis TMSS BIOS (U) [c][!].gen" />
It's saving the above but it's looking for the following;

Code: Select all

<System.LoadEmbeddedROMData ModuleID="0" EmbeddedROMName="Boot ROM" InterfaceNumber="0" FilePath="Genesis TMSS BIOS (U) [c][!].gen" />
Looks like a bug with naming where EmbeddedROMName is the expected field but instead it's saved as DeviceInstanceName.

Also, how do you save window size and location? It starting maximized isn't too appealing to me (especially on a 1440p screen!).

Now, who do I have to bug about Game Genie/Pro Action Replay cheats support (using the standard .pat files from Kega and Gens)? :P

Posted: Thu Apr 30, 2015 8:21 pm
by PaHgoM
Hello, Nemesis. Great job, I was waiting for release, but there is some problem: I can't configure controls. I use arrows near numpad, and when I press them in "Auto Mapping" mode, nothing happens

Posted: Thu Apr 30, 2015 8:27 pm
by Black Zero
Well I tried the patch and it started the games alright but now I got some other issues.

Neither Rockman World or Mega Man The Wily Wars starts at all, it's just an big black empty screen staring at me and the controls doesn't get saved for some reason.

I open up Exodus and configure the control accordingly, I play some games and then I close and I have to configure it again the next time I start Exodus.

BTW I got my Sega Gensis bios dump that I used in Fusion, how do I use it here?

Posted: Thu Apr 30, 2015 8:37 pm
by mickagame
The site is offline and i would like create a project to compil exodus.
Does someone has the instructions provided of the site in other place?

Posted: Thu Apr 30, 2015 8:40 pm
by tryphon
Obtaining and Compiling Exodus Source
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.


Obtaining the Exodus Source Code

The sourcecode for Exodus is hosted Bitbucket at https://bitbucket.org/exodusemulator/exodus. You have two different options for downloading it to your computer: the quick and dirty way that'll get you the code in one step, but without any of the code revision history, and make it hard to pull in updates or contribute changes, or the slightly longer but proper way. I'd strongly recommend the latter. If you really just want the latest files with no fuss, the quick and dirty way is to grab the latest zip snapshot of the current development mainline from the downloads page of the Bitbucket repo.

As for the proper way, you need to have a Mercurial client installed, and clone the repository from Bitbucket. The steps below walk you through installing my recommended Mercurial client for Windows, and cloning the Exodus repository. If you already have a Mercurial client installed, and you're familiar with its use, you can perform this step in the way you're most comfortable with. Here's the step by step guide:

Download and install the latest version of TortoiseHG
Open "TortoiseHG Workbench" from the "TortoiseHG" folder in the start menu
Select the "File -> Clone Repository" menu item
In the "Source" field, enter the following address: https://bitbucket.org/exodusemulator/exodus
In the "Destination" field, browse to the folder where you want the source files to be placed. You'll probably want to make a new folder and select that (IE, "Exodus").
Press the "Clone" button to download the repository
With the source repository now properly cloned, you'll have access to the revision history for files in the repository, and you can pull in new changes to the repository as they are added. For information on how to do this, refer to the TortoiseHG Documentation.



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.

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.

Under the "expat" directory, expat 2.1.0 (Direct Link: http://sourceforge.net/projects/expat/f ... 1.0.tar.gz)
Under the "libjpeg" directory, libjpeg 9a (Direct Link: http://ijg.org/files/jpegsr9a.zip)
Under the "libpng" directory, libpng 1.6.12 (Direct Link: http://download.sourceforge.net/libpng/lpng1612.zip)
Under the "libtiff" directory, libtiff 4.0.3 (Direct Link: http://download.osgeo.org/libtiff/tiff-4.0.3.zip)
Under the "zlib" directory, zlib 1.2.8 (Direct Link: http://zlib.net/zlib128.zip)
If you want to build the documentation, under the "htmlhelp" directory, Microsoft HTML Help Workshop (Direct Link: http://go.microsoft.com/fwlink/?LinkId=14188)
If you want to build the unit tests, under the "catch" directory, Catch (Direct link - https://github.com/philsquared/Catch/archive/master.zip)
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.



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.



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


Optional: Building Unit Tests

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

Open "ExodusTests.sln" from the root of the Exodus repository in Visual Studio
Set the configuration and platform you want to build, and compile.

Optional: Contributing Changes

Contributions to Exodus are welcomed! Please ensure that the code you're contributing fits with the design philosophy of Exodus. If you're making a significant modification or addition, it might be worthwhile making contact on the forums first to check if your changes might overlap or be affected by other upcoming changes. Once you're ready to make a code submission however, do the following:

Create an account on Bitbucket if you don't already have one
Agree to the Contributor License Agreement, ensuring you enter your Bitbucket username. You only need to do this once, not per submission.
Follow the standard procedure for Forking, Modifying, and Submitting a Pull Request on Bitbucket
Any code contributions to the Exodus project are greatly appreciated. This project can only meet its intended goals of supporting a wide variety of platforms through the contributions of others.

Posted: Thu Apr 30, 2015 8:43 pm
by mickagame
Thanks !!!!!!!!!!!!!!!!! Help me very much !

Posted: Fri May 01, 2015 12:40 am
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. :)

Get it now from the current releases page at http://www.exodusemulator.com/index.php ... nt-release

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