5,473 karma · joined January 21, 2012
Cooperative threads like this let you completely avoid having to develop state machines for each cycle within state machines for each instruction, etc. They let you suspend a thread four levels into the call stack, and then immediately resume at that point once other emulated processors have caught up to it in time. That lets you do fun tricks like only synchronizing components when required, so it can in some instances end up not only far more elegant, but also much faster than state machines, when they're used well.
I wrote a bit more about this and showed some examples here if anyone's interested: https://near.sh/articles/design/cooperative-threading
I also use them for my web server because I like them, but there are probably better ways of doing that.
The caveat is that it doesn't always work, and it makes the power requirements even more unbalanced. Some might also see it as a form of cheating to go below the original game's latency. If you want to match the original game's latency precisely, FPGAs are the way to go right now for sure.
If you take the SNES core, my software emulator has 100% compatibility and no known bugs, and synchronizes all components at the raw clock cycle level. It also mitigates most of the latency concern through a technique known as run-ahead. But it does require more power to do this.
But in most cases, it is emulation, as the lead developer will attest.
https://github.com/MiSTer-devel/Main_MiSTer/wiki/Why-FPGA
"From my point of view, if the FPGA code is based on the circuitry of real hardware (along with the usual tweaks for FPGA compatibility), then it should be called replication. Anything else is emulation, since it uses different kinds of approximation to meet the same objectives. Currently, it's hard to find a core that can truly be called a replica – most cores are based on more-or-less functional recreations rather than true circuit recreation. The most widely used CPU cores – the Z80 (T80) and MC68000 (TG68K) – are pure functional emulations, not replications. So it's okay to call FPGA cores emulators, unless they are proven to be replicas."
But there's nothing wrong with emulation for preservation, until we get to a point where we can wide-scale clone these older chips down to the transistor level through analysis of delayered decap scans. And even then, emulation will be useful for artificial enhancements as well as for understanding how all those transistors actually worked at a higher level.
It's also not a total solution: by taking many more transistors to programmatically simulate just one, it limits the maximum scale and frequency of what it can support. N64/PS1/Saturn has not yet been fully supported and is still theoretical, but likely, to be possible. Going beyond that is not possible at this time.
Software emulation and FPGA devices should be seen as complementary approaches, rather than competitive. The developers of each often work together, and new knowledge is mutually beneficial.
It's not that simple though. You're likely to be part of a broader community and simply deciding to leave that community, and all of your friends, over the actions of one person, is not very reasonable. Often times we are forced to be around people we don't particularly like. When that person does something valuable, they get a level of protection from being reprimanded for their bad behavior that isn't afforded to outsiders of the group, so kicking out such people often becomes difficult as well.
The numbers vary depending on the technical prowess of your audience. Probably at least half the visitors to my site would be using ad blockers. If one were to use server-side logging (at the HTTP request level), it would not be blockable, and your numbers would be accurate save for any bot spam inflating it.
I understand it was less practical to do this for say, the NES or SNES. But it should have been done for the GBA. It's not just important for future hardware to be able to easily emulate GBA games, it also protects against product refreshes breaking games, something that plagued quite a few classic Game Boy games as newer models came out and fixed bugs in the older models.
Another example: there are several GBA games that dereference null pointers, but it works because there is no memory protection fault hardware in the GBA. Since the BIOS is mapped to address 0 and yet locked out from reading post-boot (in a failed anti-copying mechanism), you have to emulate the open bus behavior to run these games correctly as a result.
There are also several anti-emulator routines in the GBA library, such as lying about the type of save memory (flash, EEPROM, or SRAM) that a given game actually has (by including strings in the ROM from the Nintendo SDK used to access them.)
I would prefer to not bother him unless it was a last resort, but that is indeed an option if my breadboard idea does not work out and no others are up to the task of decapping the PPUs.
Oh it absolutely won't, it's only the external state. It's just another important piece of the puzzle that I think would help us out a lot.
Solving this would most likely require reverse-engineering the netlists from a decapped die scan.
I've since (post article writing) learned that a German forum found a hidden test mode that outputs digital RGB values, but it has a lot of issues on various edge cases, so while it's not a perfect solution, it's definitely a huge help along the way if we can get a testing rig set up around an appropriately modded SNES.
Not only is there unitialized RAM and I/O registers, and some analog effects, the really big elephant in the room is that the system has two oscillators. A ~21MHz CPU/PPU crystal oscillator, and a ~24MHz SMP/DSP ceramic oscillator.
Given that not only do these exact frequencies change between systems due to margins of error on clocks, they also change slightly as the system runs (and gets warmer, for example.)
Every SNES game has sound routines that synchronize the CPU to the SMP.
It wouldn't be possible to make a literal 1:1 play log unless you a) ran a custom register and memory initialization at system startup, and b) replaced the two oscillators with a much faster single oscillator and then used a clock dividier to drive both the CPU and APU off of it.
(You can TAS certain SNES games anyway, of course. It really depends on how the game is programmed to react when the exact CPU<>SMP communications change. If it seeds a random number generator based around the PPU H/V counters that are polled after a CPU<>SMP sync for example, forget about it.)
We are still at a point where minor changes can result in dozens of "change detected" triggers, of which we are not sure how to determine whether they represent corrections or regressions (it's usually not at all obvious.)
I've also been weary of building a large "accuracy testing suite" for the SNES, on the fear that if I come to the wrong conclusion on something, others will emulate that inaccuracy and won't question it because of deference to my code.
Tests also have the unfortunate side-effect of being gamified (example: http://tasvideos.org/EmulatorResources/NESAccuracyTests.html), which is a very bad thing. Failing a test because we don't know the answer is infinitely better than passing the test using am unverified guess. But when people reduce a comprehensive and complex set of tests into a percentage score, you get a very skewed picture of what actually matters. (think of how browsers jumped through hoops to pass the Acid CSS tests back in the day.)
It is however something that's important, and hopefully I'll have the time one day to work on this more.
The PPUs themselves output only analog RGB, there's an analog pin for each color channel rather than a digital pin for each color bit.
On some level, I don't doubt it's possible to build a test harness that can automate things based on the analog RGB values with some fuzzy matching, but if we are going that far, it just makes more sense to snoop the bus traffic directly. That would reveal a lot more information and in digital form.
Like programming and reverse-engineering, I taught myself the basics of electrical engineering.
The Neo Geo Pocket's SoC is basically nothing but raw logic circuits for explanations of how things work. Imagine 200 pages of diagrams like this: https://i.imgur.com/2LZ2UWY.png
(oh and as a bonus, the diagrams often contain errors.)
If you're only looking to create a basic emulator, you can mostly get away without knowing all of this stuff by reading tech docs and the source code of other emulators. But if you really want to get low-level and get things clock-cycle accurate, or want to work on a system that's not been well-emulated to date, digital logic pretty much a hard requirement.
> And actually want to do it outside of compensated labor?
From 2004 - 2018 for the SNES, it was mostly only me. As of today, three people.
In general only one person is really needed. I couldn't say if someone else would have taken my place had I not been around. I suspect so, given how popular the SNES continues to be. Whether they would have done a better job of it than I have is a question that often keeps me up at night.
In any case, the answer is certainly "not nearly enough."
The way we've gotten as far as we have is that not every combination needs to be tested. It is a ballpark estimate on my part, but I'd estimate us needing a few million tests to have a high degree of confidence our emulation is correct.
If we had to make those tests into visual patterns on a screen that had to be checked by eye each time, it would be overwhelming even if we only needed a few thousand tests made.
I can test code on a live SNES extremely easily with my 21fx board ( https://github.com/defparam/21FX ), but it's still far too much to do this by hand.
Have you tried Google search lately?
It is almost never the case in technology that the superior product wins. It's the first to market with a really killer product. It takes massive inertia to displace an incumbent, and Google managed it because search engines prior to it were nearly useless portals (Yahoo, AltaVista, AskJeeves, etc.)
The requirements and conditions to displace Google now are virtually impossible, and that's even before factoring in their massive data profiling advantage.