Cycle accurate emulation: Exodus 2.0 + Open Source Release

Thanks for reporting the issue, I've fixed it in the mainline, and a few other bugs I noticed with the panel while I was checking it out. The next release will fix the problem.

I'm using a pretty cheap and nasty averaging calculation to get that value. I'm pretty sure it's not all that accurate.

That would be nice, I simply haven't bothered spending time on these kind of issues yet. This file:
https://bitbucket.org/exodusemulator/exodus/src/e7339975eba43964fb0f895f3fd7b1ab6893f440/Extensions/MDExtensions/MegaDriveROMLoader.cpp?at=default
This is where all the platform-specific nastiness of loading raw Mega Drive ROM files belongs. This class takes a random Mega Drive binary, inspects it, and generates a corresponding module file so that it can be loaded in Exodus. This is where SMD support needs to be handled. SMD format is problematic though, because it's insanely system specific. I'll be adding native support for interleaved files to the platform itself, but SMD is another level entirely. To do this in a generic way, you really need to convert the ROM. The loader can do this for you, but it'll still require a copy of the binary. I'm not going to add native SMD support to the platform itself, it simply doesn't belong there.

Could you give me some specific steps to reproduce this issue? I've tried every way I can think of, and couldn't find any problems here.

Not doing anything like that actually. In 32x32 cell mode on the Mega Drive, pixels aren't square, and on top of that, I support mid-screen changes between 32x32 and 40x32 cell modes. To avoid any loss of precision at the actual rendering step, each line is rendered as a strip of pixels, with an associated cell mode. The Image window itself then renders strips of textured quads with each line mapped to an individual polygon. All that said, nearest neighbour filtering is there. Check under "Settings -> Mega Drive -> VDP -> System Settings", and turn off "Enable Line Smoothing". That'll give you what you're after

No experience with that particular USB device, but there's certainly no custom support for any particular controllers. I'm just using standard Win32 API calls to the Winmm library to handle the input. If the device doesn't work correctly through that API, it won't work correctly in Exodus, or most other Windows software for that matter. If you couldn't get keyboard input to work though, that'd almost certainly be a window focus issue. Try clicking in the image window itself first. Input keys aren't hooked globally, each window handles them, so the image window needs focus in order to process the input. It'd be a problem if you're trying to interact with debug windows, but all "A" key events are being sent to the game input for example.

Agreed, I know the interface has issues with usability. It's actually a hard problem to solve in some cases though, because remember that Exodus is a generic platform. Almost all menu items come through plugins. Try renaming your "Plugins" folder and open Exodus, then check out the menu and you'll see what I mean. The bigger issue however, is that almost all settings are system-specific. Did you know that in Exodus, you can emulate more than one Mega Drive concurrently? Try it, go to "File -> Load System/Module", and select "MegaDriveTestSystem.xml". Now load in a ROM. You'll see you get to choose which cartridge port to map it to. Now load in another ROM for the other system. Now hit run. Both systems will run in parallel, keeping perfect timing. You could now build a device to emulate the "Zero Tolerance Link Cable" for example, and connect both systems together, and they'll talk to each other just like the real system, keeping perfect timing accuracy. Or, someone could build a system module to emulate Pong. They could even load Pong, two linked Mega Drives, a Master System, and a Game Gear all at once. What then is the input mapping window supposed to look like with these cases in mind? Obviously before you can ask about how to map input, you need to ask what you're mapping input for. Kega Fusion doesn't have to worry about this.

The menu is also problematic for similar reasons. The menu system has a structure, which is designed to allow multiple concurrently loaded systems, and multiple independent plugins, to all define settings and expose menu items, without collisions or ambiguity occurring. That system seems a bit cumbersome from a user's perspective though, when they're used to a hard-coded dedicated emulator, which has a known fixed list of settings and one dialog where everything is defined. I'm hoping to come up with ways to simplify menu navigation, but I've got no ideas on that right now that don't break the generic nature of the platform. Personally, I think a better option is to largely abandon the menu entirely for system-specific options, and instead visualize them in a form that's easier to navigate. I'm thinking of a settings window for example, with a tree view on the left showing the tree of all loaded systems and components within the system that define settings, and a main panel area on the right, where the component that's selected shows a docked settings window in the main panel area, or you can doubleclick or something to open a standalone window. A similar tree view approach could work for debug windows. This would allow you to quickly see everything at once, and open anything with a doubleclick, and the main menu can then be stripped of this stuff, and greatly simplified.

Anyway, this is an area that does need improvement. This platform has quite a different set of problems to deal with than other emulators though, because of the generic nature of the system, and that means the solutions are likely to be different too.

Usability issues are important, and they need to be addressed. I've been working on this emulator for over 8 years now though, and if I waited for all these issues to be ironed out before releasing it, it would never see the light of day. I've got ideas, but limited time. I'm hoping other people might be willing to contribute some of their own time and talents to improve the areas that are most important to them.

 

Hmmm, no matter what I do, I can't seem to re-create this problem. Can you let me know the exact version of Windows you're running? I'll have to give it a go on the same OS. It might be a quirk in the way window sizes are being reported on that version, there have been a few changes to this stuff in each version after XP.

There's no way to save the default ROM path right now. I know it's annoying, and something that needs to be fixed.

The "Sega Mega Drive ROM Loader" makes it possible to actually load a random Mega Drive ROM directly in the system. A ROM file is just a data dump out of context, you can't actually do anything with it without making some kind of assumption about what it's for. Exodus is a generic platform, so it can't make those kind of assumptions, and as such, exodus can't load raw ROM files, it can only load modules, which describe what is being loaded, and how to link it to the rest of the system. The Mega Drive ROM loader is an extension that becomes active when a "Mega Drive" system is loaded, and takes care of the platform-specific knowledge required to take a random binary ROM file, and present it as a module to the system so that it can be loaded in Exodus. This is also where game-specific loading "hacks" are applied, like knowing that SSFII is a 40-Mbit game with bankswitching hardware, or that Virtua Racing has an SVP processor attached (Exodus doesn't actually support these yet, but this is where that support would be added). You can bypass the loader completely, and write your own module file to define whatever you want to (like your own custom cart with special hardware), the ROM loader just makes it more convenient to do what 99% of people will want to do, which is just load an existing ROM file dump the way they do currently in other emulators.

Yep, the support will be quite comprehensive in this area. At a minimum, it'll need to be able to do everything natively that would be be required to load any of the interleaved or byteswapped ROM dumps that exist for arcade roms currently. I'll make the support as flexible and comprehensive as possible.

Thanks for letting me know! I've been told by my webhost that IPv6 should now work. I can't test this myself, but let me know if it seems to be working for you now.

 

Could you test This magic address and tell me if it works? If it doesn't, try http://[2604:4500:0000:0021:0000:0000:0001:0000].

 

I've made some DNS changes that should propagate over the next couple of days. They'll either fix IPv6 access to the main site, or totally break everything and make the site unusable for anyone. Time will tell. I'd be lying if I said I understood even half of what I'm doing with DNS config.

Based on my tests with http://ipv6proxy.net, the domain is now working over IPv4 and IPv6.

 

I've got no plans to do a port myself, but I've written the code to be quite easy to port. It'd be quite a bit of work to re-implement the user interface, but getting emulation itself and running should be quite easy. The project is open source now, so anyone can have a go at this if they want to. I won't personally be working on ports to any other operating systems anytime soon though.