While there is some amount of software emulators “it’s not quite right”-ness, this is more spurred by the general availability of FPGAs with enough resources to “become” older consoles like the Genesis/MegaDrive.

But there already exist cores for Mister and Analogue Pocket. e.g. https://github.com/MiSTer-devel/Genesis_MiSTer

I have never worked under the hood of an emulation project, but my understanding is that the Mister/Analogue cores are best understood as an "FPGA implementation of existing software emulation."

In other words, they are not emulating the 68K, VDP, and other supporting chips on a gate-for-gate basis. They are emulating them at a higher level.

With the decapping of the Genesis' hardware, it should now be possible to truly emulate them at a 1:1 hardware level. This theoretically can lead to far more accurate emulation. I believe this is a lot more FPGA resource-intensive and may exceed what the existing MISTer/Analogue cores can handle, though I'm way out of my depth here.

> I know that getting sound emulation perfectly right for the Genesis/MegaDrive has been a tricky issue over the years, even for Sega themselves

I would definitely be curious to know why - the emulation of Genesis is notably behind most other video game consoles but I always assumed this was because of less interest and not because of any unique technical challenges.

Mostly it’s due to the secondary chips being a quirky pain. It’s emulation was ahead of many others for a number of years in the late 90s & 2000s but hit a wall

    hit a wall

Is there somewhere you'd recommend where I can read about the unsolved challenges of Genesis/Megadrive emulation?

I disagree that things hit a wall, but there are a lot of smaller unknowns:

- Work RAM refresh timing seems to be a bit variable and the exact logic for the timing has been unclear

- The exact point when scroll values are latched from the internal scroll RAM when in full screen scroll mode is unknown

- Precise cause of a CPU lockup when configuring a 68K->VDP DMA and then performing a normal access instead is also unknown

- Certain details of sprite rendering that can show up in certain edge cases are also a bit unclear

- The function of some of the VDP debug registers is unknown

There's a lot more like that, but that hopefully gives you the gist. Nuked-MD-FPGA (and its C-based predecessor) will hopefully make a lot of those questions easier to answer since Verilog/C with a lot of unclear signal names is still a lot more easier to interpret than a die photo.

Thanks so much for this. This is precisely the sort of nitty-gritty I was wondering about. I appreciate your time and your efforts in the emulation scene a lot.

I looked but couldn't find much information on remaining games that still have emulation issues. This was about all I found: https://ares-emu.net/compatibility/21?status=3000

Last I looked into it, even Overdrive 2 was emulated pretty well...

To be clear, the stuff I posted about isn't generally important for running games. Getting the whole commercial game library running is a goal that was more or less passed a long time ago (excluding stuff that depends on obscure peripherals anyway). The things in that list are obstacles to approaching the platonic ideal of perfect emulation and are sometimes problems for things like verifying tool assisted speedruns or catching bugs in homebrew development.

> This was about all I found: https://ares-emu.net/compatibility/21?status=3000

IIRC this game shipped with broken EEPROM code so it's a bit unclear if this is actually emulated incorrectly. Ares is really in great shape these days

I do have a couple minor open compat bugs in BlastEm (my public issue tracker is sadly not up to date...), but I believe these are just normal bugs and not "we don't understand how this actually works" kind of things.

EDIT: > Last I looked into it, even Overdrive 2 was emulated pretty well...

Yes. In BlastEm there's a one-line glitch in one of the scenes I haven't managed to figure out. In Ares, there's a single effect that doesn't work (border dissolve after the "arcade" scene) and a 1-line glitch in the arcade scene. Both are only visible if you have overscan enabled.

That is outstanding work. I can practically smell a physical MegaDrive burning somewhere every time I watch video of Overdrive 2 running on real hardware. My deepest respect and thanks for the work you've done on BlastEm!

“Wall” may have been hyperbolic on my part, but there’s no denying things sloooowed. Partly because it was the hard problems that were left!

Maybe but that's true for all systems (the last 1% of unknown are always the hardest and longest to figure) and Genesis emulation quality /hardware knowledge are certainly not behind other systems nowadays

For sure. I was talking… late 2000s/early 2010s era here. A decade or more ago

chipsynth MD is a musician-targeted emulator of the MegaDrive's sound chips; one of the authors goes into the difficulty of recreating things at https://www.youtube.com/watch?v=VLxTHYGLKY0

(From memory: they sourced a variant of the sound chip with digital output, characterized the DAC that way, then built a test suite to compare emulator behavior with a real chip)

> I would definitely be curious to know why - the emulation of Genesis is notably behind most other video game consoles but I always assumed this was because of less interest and not because of any unique technical challenges.

I guess it sort of depends on what you mean, but I don't think there are dramatic differences in emulation quality between the Genesis and other consoles of its generation. Admittedly, I am rather biased since I'm the author of one of those, but I think outside the add-ons Genesis emulation is in pretty good shape overall. Both Ares and BlastEm acquit themselves well on the most demanding demoscene prod[0] for the system and even Genesis Plus GX is fairly accurate for a more performance-focused emulator.

Now none of those are perfect and I think it would probably be fair to say that they are less-perfect than Higan is/was for the SNES (though it wasn't perfect either), but I don't think the delta is huge.

Now once you add the Sega CD and 32X things are definitely worse, but those combined systems are considerably more complicated to emulate than any of the base consoles of that era while also being much less popular.

[0] https://www.pouet.net/prod.php?which=69648

One of the reasons is that there's like half a dozen different hardware revisions of the original Genesis/Mega Drive, and Sega simplified the sound hardware quite a bit over the years, changing its tone and the relative volume of the different sound sources. You can record a genuine Mega Drive, show it to somebody who grew up owning a different model, and they'll complain about how inaccurate the emulation is.

>I would definitely be curious to know why - the emulation of Genesis is notably behind most other video game consoles

Not sure where you are getting this from but I think that's far from true.

For years we had Kega Fusion which was able to run most (if not all) commercial games without any issues and was the pioneer of accurate Genesis sound emulation.

Then we have had emulators like Genesis Plus GX with better accuracy and close to 100% compatibility with all licensed and unlicensed games for quite a few years now.

A little more recently, we have Blastem then Ares emulators with devs more focused on improving accuracy for those interested in getting all test ROMs passing in their emus. Sure it isn't the NES emulator scene where you have have like hundreds of emulators to choose from but how many of them are accurate/compatible enough? Comparing to other systems from same time area (SNES, Neo Geo, PC Engine, etc), I would say Sega 8-bit and 16-bit fans have pretty much similar choices than others.

What is sure is that I don't know much system with cycle-accurate C and Verilog emulators based on chips die analysis. That alone shows how much Sega hardware has a dedicated base of talented people still reverse-engineering and documenting it after all these years, even when existing emulators are already good enough to play the majority of games without noticeable issues.

I can't speak to the Genesis specifically, but in general software emulation introduces tiny inaccuracies, in the form of missed inputs (because of things like context switches - it's important to note that, while these old consoles were hilariously slow compared with modern hardware, they were single-threaded), slightly incorrect emulation speed, things like that.

For most people, myself included, this doesn't matter at all.

For people looking for an extremely "pure" original experience, this is the closest you can get to original hardware - which is getting both more expensive and lower quality with time.

For the competitive speedrunning scene, incorrect emulation speed is a non-starter in some categories, and dropped inputs are a huge problem when they happen.

How do context switches cause dropped inputs? My understanding is that input in modern OSes works like this: the kernel reads the input device or handles an interrupt from it, it passes the input event to the window manager, which puts it into the queue of the relevant app. The UI thread of the app then eventually picks it up and processes it. I see how this can cause delayed inputs, but dropped?

I don’t think the old gaming hardware really ran an OS in the way you think of it.

IIRC the cartridges were effectively just PROMs (I could be wrong and maybe they were fabbed / silicon and didn’t get programmed) which held the application code.

Video game cartridges were typically mask ROMs, but the effect is the same. There was virtually no software resident in the console; everything the user interacted with was running from the cartridge.

(The Genesis had a tiny ROM for the TMSS licensing check, but that was only 2KB, most of it image data -- and it was only used during system startup.)

Yes yes everyone here gets that. The question is why would emulation on a modern OS lead to dropped inputs.

If running under Ubuntu, even some of the native software can't handle keyboard events properly. For example, open 'Text Editor', try to open a file, and in the dialogue search for 'hello world'. Notice that if the system is under load, you will in fact search for 'hdlrow olle'.

This feels like a problem with the Linux desktop stack. Never had this problem neither on macOS nor on Windows. When the system is under heavy load, the events are usually buffered and the app processes them in a quick succession as soon as its UI thread gets to run.

It's clearly just a bug that the event order gets reversed somewhere.

Yes, console games of that era ran on bare metal. My question is how running an emulator of such a console on a modern preemptive-multitasking OS could cause dropped inputs.

In a modern application on a modern OS, USB events are buffered. You don't get hard guarantees about how quickly they reach your application. But they will get there albeit often with multiple frames of latency.

On 8/16bit consoles everything was tied to the video chip. You essentially have to do your CPU work (including polling the controllers) during the vblank interval, a short time window that occurs 60 times per second on NTSC systems. This is essentially a zero-lag arrangement (max latency is 1/60th of a frame, average is 1/30th of a frame) but if you miss a controller input it's gone forever.

I'm not entirely sure how emulators handle this. They could deliver buffered controller inputs to the emulator on successive input polls for guaranteed delivery, but then the emulated software is going to see a lot of inputs with wacky timing that may or may not screw with game logic (think of a fighting game where you need to input specific things in sequence in specific time windows) so simply dropping inputs may be preferable to delivering a log jam of inputs.

As you are intuiting, this isn't generally an issue on modern hardware. Emulated games play fine. But, also... if you have a chance to sit down with real hardware connected to a CRT... it feels different. 1/30 frame of lag vs. multiple frames.

I _think_ the argument is that the emulator runs on a per-frame basis, and the treatment of very short sub-frame-duration button presses may be different?

Afaik no emulator runs at frame granularity.

Emulators have tons of sync points, less than real hardware, but still plenty. The more sync points you add the slower emulation gets most of the time. Do we emulate transferring x length of bytes to a buffer in another part of hardware (video ram for example) one system bus wide word at a time or do we just cope it all at once and move on? etc.

> Do we emulate transferring x length of bytes to a buffer in another part of hardware (video ram for example) one system bus wide word at a time or do we just cope it all at once and move on? etc.

Syncing aspects of the emulated hardware with each other is easy. You still have to count clock cycles somewhere. So you just execute the necessary number of CPU cycles while your DMA is running, then set the flag that it's done or whatever. And you have to do the same thing with hardware timers anyway — you trigger an interrupt after X clock cycles.

It's syncing the emulator itself to real time that's tricky.

Don't most games of the era basically only poll inputs once per frame anyway? The Mega Drive six button controller basically relies on that behaviour, and the list of games that need to be forced into 3 button mode is quite short.

For starters, you can't run this kind of emulator on a per-frame basis (i.e. run all the game code for one frame, then wait for vsync on the host system, then repeat) if you want sound. Games rely on running at a certain clock speed and they generate sound by writing to the registers of the sound chip. They sometimes do it more frequently than the refresh rate of the screen. You have to sync with real time much more often than once per frame for everything to work as intended.

That doesn't make sense. You're confusing inside-emulation time with outside-emulation time. It's entirely possible to run an emulator for a frame at a time and get the sound right; the emulator just needs to run things in the right order or with the right internal synchrony.

It's also entirely possible to run an emulator at many times real-time and get the sound output correct, however you use it. You can use this to quickly get wav/mp3 copies of game music, for example.

Can’t you just queue up a frame of sound and then play it?

You should look into MDFourier. "MDFourier is an open source software solution created to compare audio signatures and generate a series of graphs that show how they differ." The Genesis was one of the primary targets for this software, and for that reason I believe that Genesis sound emulation is very accurate.

https://junkerhq.net/MDFourier/

Genesis sound emulation is indeed tricky because there were multiple variants of the sound hardware in the Genesis over the years. Some emulators model multiple variants.

https://www.reddit.com/r/emulation/comments/104tgvs/sega_gen...