Nuked-MD-FPGA – Emulating Sega Mega Drive chipset using decapped chips photos | Hacker News Reader

Nuked-MD-FPGA – Emulating Sega Mega Drive chipset using decapped chips photos

github.com

242 pointsretro_guy90 comments

Very interesting.

I'm curious if there are any specific shortcomings with modern Genesis/Megadrive emulation that spurred this, or if this is just a pure "for the love of the pursuit" effort.

I'm not sure of the exact state of the art, but I know that getting sound emulation perfectly right for the Genesis/MegaDrive has been a tricky issue over the years, even for Sega themselves. Though, my (loose) understanding is that the issue is moreso with getting the analog bits sounding right rather than the digital bits.

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...

Is the RTL autogenerated from the chip images? I looked at one file 68k.v and the variable names remind me of a decompiler.

I wondered the same thing. Otherwise that is a lot of code to write. The type of code that will cook your brain very quickly.

It's probably hand written but they didn't reverse engineer the purpose of each wire, only the netlist. Some of them are labeled, eg `irdbus_normal`.

guessing since the 68k and z80 cores are not specific to the genesis, they may have used another implementation (maybe https://github.com/nukeykt/Nuked-MD ?)

the genesis "specific" ym* cores look a lot more "authored"; commit history shows more activity around those files too

but thats just a guess... something that can generate verilog from chip images would be pretty cool...

There are assistant tools for reversing die shots, by the way. Semi-automatic, not sure if we've gotten to the point of fully automatic yet.

I can’t wait to see AI applied to reverse engineering of decapped chips.

Do we have tools for exposing specific layers instead of 2D images? It would, perhaps, be interesting to go with diagonal slices as we grind the chip and, aided by exaggerated vertical features, capture the full depth on a single pass.

If you are interested in more than 2D images, you might find this article interesting.

- The X-Ray Tech That Reveals Chip Designs: https://spectrum.ieee.org/chip-x-ray

What is a good fpga starter board that's big enough to load this? It's not obvious from the repo as a complete novice in fpga land.

AFAIK, an FPGA board is not enough, you also need the "compiled netlist" from the Verilog files, clock configuration and routing info, tailored to the specific FPGA/board you choose.

making notes

This is such a parallel universe of computing

Parallel, and much worse. Everyone out in the software land with their open languages, free compilers, and package repositories doesn't know how bad it is in FPGA land.

It feels like embedded development 20 years ago.

Aka the software that comes with the FPGA vendor. I think Intel, AMD, the Chinese vendors and some parts from Microchip have the software available for free.

Before intel acquired Altera they had some free (as in beer) software for it, helped me lots in grad as I could design, verify and simulate at home.

Kinda, sorta? This is like saying "a computer is not enough, you need a binary." What's here is the source code in Verilog. Once this is compiled by a Verilog toolchain, this produces a netlist (set of gates) which is synthesized into an actual bitstream (proprietary gate configuration file) for a specific FPGA hosted on a specific board.

In this case, the project isn't very documented but it looks like fairly generic Verilog without a lot of vendor specific extensions. So, what you need is a Verilog toolchain which can synthesize the source code into a netlist, and then into a bitstream, and the right set of extra code to target an actual physical piece of hardware.

Right now, it looks like the only board support that's checked into the repository is for the Icarus Verilog simulation environment: https://github.com/nukeykt/Nuked-MD-FPGA/tree/main/icarus .

But, the overall setup looks pretty simple and generic, so it should (hopefully) be possible to synthesize to your board of choice by reimplementing run.v and memstubs.v towards an actual hardware configuration.

Basically what you'd want to do to start trying to run this on real hardware is to build a hosting environment which wired the inputs and outputs from `md_board.v` into the real hardware provided in your environment, possibly by integrating other soft-IP (ie - you could attach a cartridge emulator of some sort to the cartridge lines, your choice of video encoder to the video output, and so on).

> proprietary gate configuration file

A fully open-source FPGA/CPLD and toolchain would be very disruptive. How hard would it be?

It could be manufactured by any number of smaller foundries with older processes. No need for a 3nm node for this.

I don't know the precise answer, but my guess is that it would be ported to the MiSTer or something like it.

https://mister-devel.github.io/MkDocs_MiSTer/#what-is-mister...

The core of the MiSTer looks pretty beefy.

https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=...

But what would it offer over this? https://github.com/MiSTer-devel/Genesis_MiSTer

The author is targeting the DE-10 Nano which is also used in MiSTer setups so that's probably the best choice

$300? Christ… I bought by MegaDrive+32X+MegaCD for less than that combined recently.

Tho I’m glad this project exists that’s… a huge chunk of change for a 30 yr old console

It's tens-to-hundreds of 30 year old consoles though, https://mister-devel.github.io/MkDocs_MiSTer/cores/console/

but yes, it is fairly excessive if you just want to play games, emulation is absolutely "good enough" and even indistinguishable for most. We do it for the love of the hobby ;)

Also, those original components have more than 25 years-old... They can fail anytime. DE10-nano is new hardware with new components which last other 25 years at least.

Realistically the only components that are likely to fail though are the capacitors, which are trivially replaced.

While other parts CAN fail it’s physical damage that’s much more likely a problem

I didn’t think MiSTer was particularly concerned with accuracy like this project is? Just implementation on FPGA.

Am I wrong there?

My feeling is that it’s more reverse engineering than this, which aims to be an exact replica of the original.

It depends on the core. For example Furrtek decapped the Neo Geo chips to write that core, and thus is extremely accurate.

Gotcha. So core dependent basically, rather than a specific project goal?

That tracks with what I thought. Great to know about the NeoGeo!

Yeah, the MiSTer project is really just a loose collection of people with a loose common goal. So the true accuracy of cores does vary a lot. Most users don't really care, as long as they provide a pretty accurate experience. I think most MiSTer owners (myself included) prefer it over emulation due to having no lag. I also really like that the MiSTer does not buffer any writes, so there is no shut down. Just turn it off when you are done, allowing my setup to be very console-like.

Replicating the physical interfaces does a lot for the quality of the emulation experience. Take, for instance, the C64 maxi: it’s physically a C64 (dimensions closer to a VIC-20, but that’s negligible) and, while the emulation is good, it feels much closer to using a cycle-accurate C64 over a PS/2 keyboard.

I don’t think the potential market for Amiga and ST keyboards for use with MiSTer justifies the investment, but I’d LOVE to see LK-411, Atari ST, Amiga, Sun, Symbolics, and other pre-PC-101 layouts as reasonably priced USB keyboards.

Unfortunately the original consoles will stop working and existing outside of museums over time; I see projects like this as archival work, so that in tens, hundreds, maybe thousands of years people can still rebuild and play these games.

Someone elsewhere pointed out that PS1 disks (or any disk based system for that matter) suffers from disk rot, so likewise, what is now considered piracy should also be considered archival work since the original disks will stop working.

something something entropy, something something the inexorable passage of time.

Oh absolutely: I fully support the project existing & data archival as well.

Just… ouch on the cost of running it. Limits the effective impact somewhat.

I think maybe that board is so expensive precisely because it's used for MiSTer.

FPGA vendors being taken over by cpu companies and generally not giving two Fs about manufacturing enough to satisfy demand is the reason https://octopart.com/5cseba6u23i7n-intel+%2F+altera-88365716

That price, isn't that just because you're looking at a development system?

Which you need to run this project.

I get why it’s expensive, but that doesn’t mean it’s not expensive.

Can the same FPGA be placed on a board more targeted to emulation that could, maybe, be a lot cheaper?

very same fpga chip alone is more expensive than DE-10 nano https://octopart.com/5cseba6u23i7n-intel+%2F+altera-88365716 Be sure to send your thanks to EC, FTC and the Antitrust Division of the DOJ. Altera and Xilinx mergers clearly were super beneficial to customers and the market, competition has never been better with both competing by rising prices and cutting volume in unison.

https://ec.europa.eu/commission/presscorner/detail/en/IP_15_...

https://www.sec.gov/Archives/edgar/data/768251/0001193125153...

Yikes.

But I wouldn't place too much blame on the companies - COVID wrecked a lot of supply chains as well - as anyone who runs emulators on RPis will be able to confirm.

Covid showed companies new way forward. Cut supply and bump prices, this is the source of all semi shortages. There was no earthquake, no one ran out of rare ingredients, corporations simply cut fab orders.

rpi shortage is a direct result of Broadcom (Avago) deciding to stop manufacturing chips that dont generate hundreds of millions in revenue a year. FPGAs were same deal, post merger Xilinx/Altera cut manufacturing.

Here is Nvidia not making more GPUs instead of lowering prices to something market would bear https://www.extremetech.com/gaming/report-nvidia-has-practic...

The de-10's price has more than doubled since covid hit.

I’m curious how this compares to Analogue’s implementation for their Mega Sg.

Analogue hasn't given a lot of detail about how they developed the Mega Sg, but to the extent that they did any reverse engineering beyond what the emulation community had already done they seem to have used similar techniques. At one point they had an identical compat bug as in my software emulator (order that bytes were updated in VRAM was swapped causing a single-frame glitch in the bike shop of one of the Road Rash games). I don't think they were using my code as a reference, but it does suggest use of similar documentation sources or similar reverse engineering techniques.

By contrast, this is the first effort (well second if you consider the nukeykt's initial C version) to try and recreate the entire system from analysis of silicon die photos. If you just want to enjoy some old games the difference is probably not particularly important, but Nuked-MD-FPGA is already passing some tests that the Mega SG does not. The screenshot in the lower right corner of the "Progress" section is a timing torture test ROM that the Mega SG fails at least 40 subtests for (I say at least because the results I've seen for Mega SG are from an earlier version of the ROM with fewer subtests).

I love what Analog does, I've got their Gameboy device on my wishlist. I can't yet warrant buying it since I don't actually own any Gameboy cartridges so it'd be roms and the like, but still.

Have you ever been in contact with them? I can imagine your and their skillsets would be very compatible with each other.

If you're okay with the moral implications (I am because the original manufacturer/publishers don't make the games available anymore so it's literally impossible to give my money to them) There are cheap flashcarts available, so you can live a better experience than you ever could with the original hardware.

I’m less interested in playing old games than having an accurate description of the hardware to study and visualize. Hopefully one day they’ll release their source so we can see where they differ with your project.

Thanks for explaining the screen grab from the torture test ROM; this is brilliant!

> Hopefully one day they’ll release their source so we can see where they differ with your project.

Just to be clear, Nuked-MD-FPGA is not my project. I'm the author of a traditional software emulator who happens to have been following development of this with keen interest. I do agree that it would be interesting to see the source of the Mega Sg though.

Will it run on the MiSTer?

or included in that project(?) providing MiSTer for any FPGA?

Very cool. I suppose this means someone could wire this to MiSTer or Analogue Pocket, or are they lacking the correct fpga requirements?

They will both likely come in the coming weeks, based on what the creator wants and general enthusiasm. Since it hasn't been wired up to a top, the ports would likely be fairly simple.

I wonder how interesting the Genesis VDP would be for a retrocomputer project. Is there a good detailed doc for software development? I looked around and there isn’t much I the most obvious places and formats.

This was also done by Furrtek for the Neo Geo FPGA core for the MiSTer project.

Wasn't the Genesis dev machine a Sharp x68000?

perhaps among some (never heard this before), but I know people who used Amigas and Deluxe Paint.

Reply on news.ycombinator.com