Hacker News Reader

Actually decapping the original chips is very much a thing. See for example Chris Smith's work mapping out the innards of the ZX Spectrum ULA - http://www.zxdesign.info/book/insideULA.shtml .

It is, but these cores are almost exclusively not being done that way. Not yet at least. I hope that they will be, that would be really awesome. I paid $1200 last year for the SNES PPUs to be decapped for this purpose, but it's a truly enormous undertaking to map out those chips and then recreate it in Verilog. You're talking thousands of hours of work per chip. If anyone reading this is able to help with that effort, please do let me know, we could really use the help.

Not that this is necessarily helpful to you in the short term, but it strikes me as a good problem for machine learning (going from die pictures to transistor schematic.)

By decapped, do you mean delidded?

Theoretically it would be possible to automate this with a couple things:

- USB electron microscope to image the transistor topology

- CV lib to identify connections and generate corresponding Verilog code

“Decapping” is a more intense version of delidding where you use chemical agents or something similarly extreme (laser, plasma, milling) to remove the package (ceramic, plastic).

My understanding is that there are people who do it often enough that it is automated in the way you describe, but you still need someone with a lot of skill to spend serious time on it. Computer vision works wonders but there are errors which must be identified and fixed.

A lot of the chips people care about are can just be done optically, no electron microscope needed.

Ah, that’s a good distinction. I’d be pretty scared of damaging the hardware by doing that, but I’m sure there are some really experienced folks out there that would appreciate the hardware donation.

Decapping destroys the hardware.

That's exactly what's happening. There are loads of projects going on right now decapping old chips and reverse engineering them. From old CPUs like the 6502 to the Amiga Alice chip. It's just a matter of time before most of the retro systems are fully reverse engineered and documented.

That's generally not what's happening with the mister cores. I haven't looked at all of them, but the ones I have studied are very high level in implementation.

To the best of my knowledge, the Neo Geo core has certain chips based on a full decap and implementation in FPGA. Not the entire system though.

Neat. I'll have to look at that one.

FPGA cores are based on CPU emulators, so they aren't more accurate than the emulator, and decapping a chip doesn't help. FPGAs are written in languages like Verilog that are still high-level and do some probably misguided tricks to make it look like you're programming them with a vaguely C syntax.

> FPGAs are written in languages like Verilog that are still high-level and do some probably misguided tricks to make it look like you're programming them with a vaguely C syntax.

This is either incredibly badly explained or wrong. Verilog compiles to gate level.

The difference between Verilog and gates is larger than the difference between C and assembly?

Also, I think most decapping is done to read data tables out of ROMs, not to figure out what all the gates in a chip do.

> FPGA cores are based on CPU emulators

FPGA cores are literal CPUs.

Meant to say "FPGA emulators" there, the last emulator project I worked on called them cores.

No, they are not generally based on CPU emulators. FPGA emulators are more accurate than software based emulators, in part because they don't have to do gymnastics to awkwardly emulate things that are easily done in hardware. For example, the documentation for Amiga's custom chips specifies which cycles various DMA activity takes place. Replicating that in hardware is quite easy (just a few comparators wired up to a counter), but it's hugely expensive in software which leads to all kinds of nasty hacks to replicate behaviour games rely on.

It's similar with CPUs. CPU manuals from the 1970s and 1980s often specify the exact cycle counts for instructions while having simple bus interfaces and no caches. Coming up with cycle accurate hardware for these CPUs is not all that hard.

The Amiga is the last machine I ever had for which I was able to get complete specifications and schematics for and understand completely. Once the 386/486 came along, documentation of SMM mode and other internal details became restricted. Modern computers have so much hidden firmware that understanding the entire system is virtually impossible. In contrast vintage 8/16 (and some 32) bit machines can be completely understood by a single determined individual.

On FPGAs (depending on the hardware mapping), you get the benefit of lower latency. I consider this to be timing accuracy.

Say you have two implementations of an LED controlled by a switch: one which uses an FPGA and one which uses a microcontroller. The uC implementation must continuously poll peripherals connected to its GPIO pins at a set frequency; it must check the state of the switch, and then change the state of the LED. The FPGA, on the other hand, physically wires the switch to the LED; there is no lag when the state of the switch changes.

The FPGA implementation can be scaled to connect however many additional lights and switches you want (limited by the size of the fabric), with zero overhead lag. This is the parallelization benefit of FPGAs that you may hear about. For the uC implementation, you must add additional switches and lights to the polling loop, which brings down performance in linear time, O(n). This is the drawback of sequential processing.

Most game consoles don’t do any of this, though. The gamepad is polled by software.

On the NES and SNES, the buttons are connected to a shift register (e.g. 4021). The CPU triggers a latch and then reads out the shift register one bit at a time.

This was given as an example, not for you to straw man about the gamepad.

Don’t know what you’re getting at. You seem to have taken offense, and I think it’s because you misinterpreted what I wrote.

Your comment seemed to be positioned as a refutation of the prior comment (it could have been meant as an aside, but without something to indicate that it can be hard not to assume it's a counter). Unfortunately, if it was meant as a counter to the prior argument, countering just the example put forth does not actually address the argument put forth, so it it looks like a straw man argument itself (that is, addressing an example, even if it was presented by others, without making any attempt to address the position itself).

> ... countering just the example put forth does not actually address the argument put forth ...

The particular example put forth was a good example, and it's worth responding to. If you can come up with a better example, I'd love to hear it.

My argument is that the timing of inputs and outputs to consoles is heavily quantized, which gives you a lot more freedom if you want to create an accurate software implementation--depending on whether your goals are to emulate existing games or serve as a platform for experimentation. For example, the NES has lots of "timing tricks" but they are internal to the console, and at the scales it takes to render a frame of video, you can do a lot of work in software.

From https://news.ycombinator.com/newsguidelines.html

> In Comments

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

> If you can come up with a better example, I'd love to hear it.

I don't have a side in this discussion. I just stepped in to note one reason why you might have gotten the reply you did, since you specifically noted "Don’t know what you’re getting at." I was merely attempting to illustrate why I thought you might have received the response you did.

> My argument is that the timing of inputs and outputs to consoles is heavily quantized...

That's probably a good argument. That's not what you replied with though. If you had, I don't think you would have gotten the response you did.

>> > Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

That's as much a point against your comment as against the person that responded to you. Responding to a specific example instead of the position is not responding to the strongest possible interpretation. Then you get responses like you did.

Again, I'm not taking a position on this. I only bothered to comment at at because you seemed to indicate you didn't know why you got the response you did. Honestly, I thought you were likely presenting it as a slight tangent, not an argument, since it's fairly common here for people to view any response as someone arguing the other side once they get slightly heated in an argument.

> I was merely attempting to illustrate why I thought you might have received the response you did.

Oh, that's completely unnecessary. When I said, "Don't know what you're getting at," I was hoping that the commenter understood something that I didn't.

> That's probably a good argument. That's not what you replied with though. If you had, I don't think you would have gotten the response you did.

This is a good illustration of why the guidelines are there in the first place. Comment #1 was the weaker argument, comment #2 was the stronger comment. If you have a discussion with someone, you can get from comment #1 to #2 and beyond.

Telling me that if I had written comment #2 first is... not helpful! Because the process of writing comment #2 involved reading replies to comment #1!

This would be less about a user peripheral like the gamepad (which is obviously going to be read out exactly once per frame anyway) and more about getting subtle interactions between the CPU, memory/DMA, and specialized systems for graphics/audio correct. And not just correct after thousands of hours of work to smoke out the exact sources of specific title bugs, but correct essentially for free.

See for example the tale of an absolutely wild mGBA investigation that was posted here a while ago:

"What happens if an interrupt gets raised between prefetch and the data load? Will it start prefetching the interrupt vector before the invalid memory access? I quickly mocked this up in mGBA, turned on interrupts in the test ROM, and sure enough it broke out of the loop. So I tried the same test ROM on hardware and…it did not break out of the loop. So there goes that theory. Eventually I realized something. You saw that asterisk earlier I’m sure, so yes, there is one thing that can happen in between prefetch and the memory access, but only if the memory bus gets queried by something other than the CPU between the prefetch and invalid memory access."

https://mgba.io/2020/01/25/infinite-loop-holy-grail/

I don’t think that the FPGA based emulation will be “correct essentially for free”. The FPGA emulation itself is a lot more labor-intensive to create in the first place. In order to make it work equivalently to original hardware, you will need to accurately understand how the original hardware works, which is something you would need for software implementations too.

In general, software has a much lower cost of development than the cost of developing something for FPGA, and if you had something like a Verilog implementation of your emulator, it is not necessarily true that you need to run it on an FPGA—you can run it in software, or use it to verify a software implementation.

I think the real argument here for FPGAs is that some things are tricky to emulate with reasonable speed and accuracy in software. I don’t think the other arguments hold up—for example, arguments about latency—since the time scales involved are fairly generous (16ms to generate a frame of video).

> but correct essentially for free.

Definitely not. Per your example, "what happens if an interrupt gets raised between prefetch and the data load" is not a question that the type of emulation can answer. You can implement hardware as well as software that gets details like this right or wrong. In both cases you usually need an extensive catalog of observations or a full description of the original hardware to correctly emulate it functionally.

Okay, sure— that was sloppy. Obviously you're going to have bug fixes and unexpected side effects, behaviours, whatever which need to be tracked down in both cases.

But at least in the FPGA case you're directly simulating the behaviour of the discrete components such that their parallel, real-world interactions should tend toward accuracy. It should be similar to the step from HLE to LLE, where LLE is simpler, more accurate, and less hacky, but way less performant. LLE to FPGA would be a similar transition but without the performance penalty.

Sure, and for hardware this old the FPGA could re-implement the CPU (which ran at <4MHz) and the shift register at almost the exact frequency (or whatever frequency is necessary to reproduce the original behavior) of the original as necessary. Then you can run the original software without modification and get much closer to identical behavior and performance characteristics with much lower resource utilization. Granted, it won't be nanosecond perfect, but it will be a lot closer than you'll get on any current CPU.

I don’t think reproducing the exact behavior here is necessary, useful, or even interesting. You could use a USB gamepad and get behavior that is close enough that humans can’t tell the difference.

While I don't know the current status, with MAME in the mid 2000s, an update that added support for certain games usually involved changes... that broke a different set of previously working games. I remember having 3 MAME versions installed to play all the games that I wanted. That kind of emulation hell is greatly reduced when you simulate every bus and chip of the original hardware.

To give you an example: I don't remember which game it was, but it was a platformer, and when the character jumped, the game put the starting pitch of the jumping sound effect in the sound chipset, with the DSP doing the loss and pitch change on each cycle. The game moved the character according to certain value in some register of the DSP, so the game was working normally until you jumped, then the DSP emulation code did something like returning the original value or 0 (because 99.9% of the games just write there), and the game crashed.

That's because MAME is distributed as a single executable which combines support for all the machines it emulates. If there was a mega 'multiple arcade machine FPGA core' that supported thousands of machines in one then you would need to do the same kind of installation management as different parts of that codebase matured. But when using FPGAs you normally have a seperate core for every machine being simulated. By the emulation analogy, you're actually switching between many different 'MAME versions', or single-game emulators when you switch between games on your FPGA.

For me as an occasional hobby developer for old platforms it's interesting. Subtle differences in how emulators work compared to the original hardware has sometimes resulted in nasty surprises.

In the best world, I could use an emulator as a reference, but for now I have to keep the old hardware around for that reason and always make sure to test my code on it regularly. Even differences that have no impact on the entire software library are important in that sense.

For example, if I write an address to an OPL chip I normally have to wait a few cycles for the address change to be effected before I write a value. You can remove that limitation in an emulator and all software written for the original platform will still work, but the emulator will no longer be useful as a reference, because now I can write software that works in the emulator but not on the real system.

There's of course a use case for emulators that take these kinds of shortcuts for the purpose of running an existing software library, and that's how people were able to play SNES games on Pentium class hardware, but as a point of reference and complete functional preservation of the hardware platform itself, that isn't good enough.

I think big differentiator is that it is easier to get predictable latencies with FPGA where you control almost everything, compared to general-purpose PC which is not really that well optimized for hard real-time operation. So I believe "race the beam" style things are more easily accomplished with FPGAs, and also having tight audio-video sync. Although the PC emulation scene has been also doing some fairly incredible things too.

That's true, but I think it's also true that you could trim a bit more lag if you do it well.

you can find it here https://archive.is/fWosI

Quite a few of the FPGA soft cores related to 8 bit gaming are reverse engineered from either schematics, decapped chips, or both. Or they take pains to at least use the same number of cycles for each instruction, access SRAM or DRAM in the same way, etc.

Unless you have seen MISTer running (especially on an fixed HZ old school CRT monitor) vs running that same thing emulated on on a modern cycle-exact emulator. The difference is really noticeable.

This might come down to the emulator also running on a modern OS, which cannot guarantee at all times smooth framerates, whereas a dedicated FPGA can promise you that it's not running much more than the actual core needed to emulate that system.

Especially on a 50/60Hz CRT monitor the difference and latency from the controller to pixels to screen is noticeably faster and stuff like scrolling the screen and sprites are buttery smooth, just like in the original hardware.