Hi all, after a long hiatus, I'm picking up development of Exodus again. You should see a steady stream of commits going forward. My current focus is on adding full correct sub-opcode level timing to my 68000 core, with cycle accurate DTACK handling and bus delays. This is the key missing step to making Exodus indistinguishable from the real hardware, and unlocking support for a bunch of games that currently fail due to polling loops on the VBLANK flag (which other emulators hack the timing of to work around). After that I plan to add a kind of "logic trace" mode where the full bus state is logged. This opens up the possibility of building automated testing against recorded bus traces on the real hardware, which will make it easy to find and fix any timing issues, as well as verify the correct operation of the emulator against the real hardware, as well as allow verification of FPGA emulation cores against Exodus, and vice versa. That'll be invaluable as support expands to the MegaCD, 32x, and beyond (Saturn, arcade, etc). I've also simplified the licensing model. Exodus is now MIT licensed going forward. Feel free to use the code wherever and for whatever. I'll be posting updates on the main website, as well as on the official forums over at SpritesMind.
Wonderful news! And I'm particularly excited about Sega CD and 32X support in the future (whether you yourself add that or someone else). 32X especially since, as I understand it, has weak emulation to date in terms of accurate timing and such. Also, I went to SpritesMind several months back... that place looks dead, more than Sega-16! Running out of places to promote things that doesn't involve social media.
This is very good to hear. I know that the various Mega Drive projects available for MiSTer are all somewhat approximate, mainly due to bus issues, and I'm certainly optimistic for the potential of a cycle-accurate test-suite, especially one that might cover the expansions. Especially with the MIT license.
Yeah, the humble Mega Drive becomes a bit of a monster when you add the 32x and MegaCD. From a timing perspective it's worse than the Saturn, there's a lot of different processors that can interact over shared buses. The good thing about Exodus is it will make that timing problem relatively easy to solve - with accurate timing information. There'll be a decent amount of hardware testing to gather that data, but once the correct timing is known it'll be straightforward enough to implement. Yep, pretty quiet these days, but on the other hand the SegaXTreme forums are very active. Hopefully it'll bounce back. I should try and make an effort to communicate more to keep people updated and show progress. That can be part of keeping the enthusiasm going. When you're working away on something for about 6 months with nothing you can release yet, it can start to feel like a drain. Not sure what I should do about that. A lot of people do Patreon and things like that nowadays, but I don't really want to create a paywall or expectation for money. Don't know if I want to create a discord server just for this, and it's better to support people via a forum than discord. Maybe just a thread on the forum I post on, or perhaps I should post more news articles on the site, or even make a blog. Any thoughts? What would you do?
If DOOM and Chaotix have periodic freezes, you'll know you're emulating it right. Those games were notorious for freezing. It's the only thing that kept me from beating DOOM on actual hardware. At least Chaotix has a save feature to rely on when things go wrong. I've not seen either of those games freeze on emulators so far.
You could use a system I've seen being used for inspiration. I've been keeping eyes on another project in the meantime, there's a Genesis emulator named BlastEm that's attempted to mitigate the "drought of releases" issue much like the GameCube emulator Dolphin's approach: any time there's a change accepted in the program's source code, it gets added as a public experimental EXE to test out on your PC. All of the past-present EXEs are stored in a archive consisting of all of the changes that were made. There's a forum (and relatively recently Discord) dedicated to shotgunning which versions have regressions and what else to add. That ecosystem could be added to Exodus, given that the source code is out on GitHub already. mGBA uses the "news article" approach that just details which changes have been made, so you could consider that too. Spoiler: note by the way i haven't checked on Exodus since the pandemic started so i dont know if you've tried this before or not
Yep, good point. I'll be setting up some proper CI/CD with automatic releases on GitHub, that'll give those regular releases. I've also done projects that use conventional commits, which has the advantage of making an automatic changelog.
I wholeheartedly recommend starting a blog. Even if you end up working on a project for ages with seemingly no end in sight, you're at least able to put together a few blog posts explaining what problems you've been solving. It helps solidify that feeling of progress, I find, and it's pretty natural to write entire pages of information when it's all fresh on your mind. It's also very fun to go back and read months or even years later, to remind yourself of what you've accomplished. I maintain a blog that documents the development of my own Mega Drive emulator, though I also cross-post it to here and SSRG for maximum reach. If the likes are any indication, it seems to keep people engaged. I'm not too sure what the difference would be between maintaining a blog and posting more news articles on your site. Aren't they the same thing?
I have nothing technical to contribute because I'm an idiot at the end of the day, but let me tell you this: if you'll ever plan to make it multilingual, I'd be up to help you with the Italian translation. For free, of course. And I'm sure there would be many other volunteers from many different countries to get you covered if you'll want to take that direction, adding Spanish and perhaps Japanese to begin with would definitely help you reach more audiences who still refuse to speak English.
For proper translation support I'd need to change the way I do the frontend. Right now it's all raw Win32 and GDI calls. The backend is OS agnostic, so that could be ported, but the GUI is all Win32 specific. The way forward with that would be to develop a new frontend in C# (which I have a lot of experience in), and for the GUI either MAUI or Avalonia (I've used WPF a lot on the traditional .NET framework). I'm kind of in a holding pattern waiting to see if .NET MAUI adds Linux support, which if it does will be my pick, otherwise it's Avalonia. I'm prioritizing emulation accuracy right now though, so I'm going to get the Mega Drive fundamentals where I want them first and foremost. It might be worth biting off that frontend transition before expanding into 32x and MegaCD though. There's a LOT of debug windows in Exodus, and new platforms are just going to add more. Yeah, I should probably do that. Thanks for the advice.
I think it's fair to say Exodus is for all intents and purposes an emulated developer console what with its extensive debugging features, so the prospect of seeing this extended to the Mega CD is exciting. I've really delved into the hardware lately, and while Blastem and GPGX are good at the surface, both (but especially the latter) still have significant accuracy issues with regards to finer hardware details, and there seems to be a dearth of information about the hardware in general (notably, there's at least one documented hardware feature that has yet to emulated anywhere as far as I can tell.) While I can't contribute directly (I'm not a high-level programmer at all), I am planning to write a test ROM or two that could provide some useful information for ensuring accuracy.
Glad to see this going again! I do wonder: with the new repo site, will old unresolved bugs tracked on previous websites be given issue numbers on GitHub? Also, happy birthday, Nemesis!
That's actually the most useful thing of all. Test roms are a form of irrefutable documentation of how things actually work, while also acting as a regression test to ensure things are being done properly. Writing test roms can be time consuming, so any help in that area is greatly appreciated!
Everything was tracked on a Jira instance previously. While in theory I could carry that forward, in practice I'm planning to discontinue that and just use GitHub issues. I'll have to go through the tickets and see what I want to carry over.
