Cycle accurate Mega Drive emulation: Exodus coming in April!

There is definitely room for optimization. I've deliberately avoided over-optimizing the cores in the interests of keeping the code readable and flexible. I'm sure there are some good performance gains that could be still obtained without impacting the design very much though.

Some of the rendering optimizations you mention though won't work for the Mega Drive VDP very well without compromising the accuracy though, simply because it's an incredibly complex, quirky beast, with a lot of different video modes, and various bugs, and lots of interactions between different settings. I'm also emulating the rendering at a cycle level. Data and register settings are latched by the VDP for rendering at the same cycle as the real hardware. Very little is cached or buffered on the Mega Drive VDP, and mid-line changes to pretty much anything is possible. Since I want to keep the rendering cycle accurate, that really limits how and when I read and process the raw data for each plane.

You'll find you can press alt+enter to make the image window fullscreen, so it's not purely for debugging, but what hasn't been done yet, which I plan to add in the future, is a way for both audio and image buffers to be "managed" by Exodus itself. Right now, it's up to the individual devices to manage their audio and video outputs, but when Exodus is able to manage those itself, it'll open up a lot more options for applying video and audio filtering, and new features like video logging, central control over attenuation for each sound device, etc. When Exodus manages those featuers itself, it'll also be possible for extension plugins to add new features that operate or affect video and audio output for any device.

I actually have a slightly different view on that. Newer systems are often actually much simpler than older systems from a timing point of view. The Mega Drive isn't a simple beast to emulate and keep everything in time. You've got two independent processors running on two independent buses, both of which can, at any time, take ownership over the other bus and directy access anything mapped to it. You've got two independent audio devices, and one video device which can take bus ownership for DMA. You've also got older processors without any cache, so they hit the external bus constantly. You also have very complex bus logic, with a memory map which changes dynamically and has all kinds of quirks.

Compare that to a newer system, like the Dreamcast for example, and it's a very different story. You've got one processor with a decent cache, one graphics chip, one sound chip, and much simpler bus logic. I also suspect the graphics chip is much more of a "set and forget" kind of device, with less rendering-related information coming back, meaning it'll be easier to do all the processing for the video in parallel. Since Exodus is very good at running devices in parallel, I think with an efficient SH4 and PowerVR2 core, you could pull quite a decent framerate in Exodus.

 

Accurate software emulation of PowerVR2 alone can be way too much for current CPUs.
And i don't think it's possible to make accurate emulation using hardware - with OpenGL 4.x or DX11 you can get very close but it still won't be perfect.

 

It would be very demanding to do entirely in software, no doubt. The best chance to make it work though is to look at how the real hardware does it: With lots of separate pipelines. It should be possible to have multiple render threads working together on the one frame. If the hardware can manage it, we should be able to do something similar in software. In this way, you can benefit heavily from additional cores. It's also likely you could make use of the GPU, even if not for actual image rendering, for raw number crunching if nothing else.

At any rate, if it's possible to make a low-level PowerVR core run at full speed on a modern computer, it should be possible to do it in Exodus.

 

I think a big performance gain could be had from utilizing cuda / open cl. x86 cpu's can't crunch numbers like a graphics card.

 

Isnt that exactly what he said in the post you quoted?

 

Looks very nice! Hope I can try it soon. Thanks!

 

I posted on the Sega 16 forum but it ran well for me full 60 FPS on an i7 920 OC to 3.6 Ghz with 12 GB ram. Fairly feature free for but expected for a 1.0 release. But the debug option and options to control the processors and debug etc which to me mean little much be awesome for programmers. Really cool seeing the VDP pallete and sprites and accessing the memory on the rom. But prett useless for the average game player. Hopefully will see improvements to the front end and addition of Sega Cd Nd 32 X support. And porting the emulator to other systems like SNES or Saturn to prove how easy it is supposed to be in this program and to see if it will actually give a true Console accurate SNES emulation. Even full screen in only took 50 percent of my CPU resources but my memory was running 50 percent utilization which is as high as I've seen it. Never seen my memory used go over 6 GB even when stress testing.

 

It depends on if you emulate it like everyone else has or whether you emulate bus contention between the cpu and dma devices. You have to keep track of when they are on the bus or the games won't run at the right speed.

 

I'd be emulating DMA accurately. That's should be quite simple to achieve with the work I've already done. DMA devices can just assert bus request lines when they want bus ownership, and when they gain bus ownership, the SH4 would be locked behind them, so it'll detect when they release the bus and resume from the correct cycle. That kind of system is already implemented working for VDP DMA in the Mega Drive, and it has no overhead when DMA is not in progress.

The Dreamcast really will seem trivial after doing the Mega Drive, it's the Saturn I'm worried about. That system is a monster. I fully expect I'd be able to get Dreamcast emulation running much faster than the Saturn.