byuu is the developer behind the bsnes and higan SNES emulators, writing about emulation accuracy and game preservation.
HN links it for the bsnes emulator and the libco coroutine library. Commenters also cite his UI toolkit and a user script.
>How long is the list of games that zsnes doesn't have 100% accuracy
Plenty of popular games. http://board.zsnes.com/phpBB3/viewforum.php?f=16
Notably, Yoshi's Island glitches out to the point of unplayable-ness in around half a dozen levels under ZSNES, the first one being 'Touch Fuzzy Get Dizzy'. This is the most high profile example.
bsnes is the only emulator that lets you play yoshi's island properly, which happens to be many people's favourite game on the platform.
The problem is down to some games exploiting timing tricks in the graphics subsystem to achieve transparency-like effects and so on. All the emulators apart from bsnes compute the graphics line-by-line, which breaks these tricks. bsnes draws it's output pixel-by-pixel, like a real snes, which is much more computationally intensive.
"The reason is because while a scanline renderer runs at a mere ~15.75khz, a clock-based renderer would run at ~10.75mhz. That may not seem like a lot, but when you are writing an emulator that claims absolutely flawless interprocess communication, that means synchronizing two separate processors over ten million times a second."[1]
All that context-switching makes your processor mad.
The main reason for bsnes is homebrew snes developers' need of a bit-for-bit accurate snes emulator. These people need an emulator that will help them test code they are planning to flash to a cart and run on a real snes. ZSNES and other emulators designed to simply run commercially produced…
At the hardware level, the author of BSNES recently wrote up an excellent rant on sources of latency in modern machines https://byuu.org/articles/latency/
But, most of what you are talking about is software latency. At 1/30th of a second each, software pipelining systems seem cheap individually but pile up very quickly. Hit a button, read the button, react in AI, react in animation, react in physics, react in graphics, process in the GPU, process in the display device. These can easily add up to 5/30ths of a second with poorly planned software. In the middle of all that, the animation and audio has aesthetic requirements for smooth transitions that can insert a 1/2 second lag in the middle of that process. Now we're up to 20/30ths.
Regarding animations: I've been in convos with managers requesting character animations to be "Smoother, but more poppy!" because of the conflicting needs of aesthetics and control latency. The best compromise I've found is to design a smooth transition, but have the underlying representation pop and the visuals skip immediately to mid-way through the animation.
My favorite bragging point: the code in the necdsp folder (and the CPU core itself at component/processor/upd96050) there was used by Stephen Hawking when they emulated his old voice machine that used the same chip.
http://pawozniak.com/emulator/
Pretty cool that the same NEC uPD772x chip was shared between a text-to-speech engine and Super Mario Kart.
If you want to know everything there ever was to know about the chip, I mirrored every PDF datasheet I could find on it on my site:
https://byuu.net/datasheets#uPD7720
It has one of the most wild ISAs I've ever encountered, using a strict Harvard architecture and 24-bit VLIWs (very long instruction words.) Every opcode can do over a dozen different things in the same instruction at the same time. Writing code for it is quite the challenge.
The day of the first, "lost package", and receiving the letter are the same: February 14th.
https://byuu.org/emulation/preservation/lost-package/:
As of the time of writing, February 14th, 2017 — this
package has yet to arrive.
https://byuu.org/emulation/preservation/found-package/
On February 14, 2017, I received the following letter
from USPS:
They totally left out this when making their initial post. Part of the package arrived, with a letter by USPS - the package didn't mysteriously vanish. It's a little different story. I don't know why they wouldn't have mentioned it. In the initial story, he blamed USPS for being incompetent on taking control of the delivery; in the second he blames Deutsche Post for a bad packaging job.
>audio CDs which I've found don't use checksums or other mechanisms to prevent small defects from mangling the bitstream
Redbook audio CDs does use CIRC error correction, by storing 8 bytes of parity data inside each 33 byte F3 frame. It is not enough to correct all errors though, and Yellowbook data CDs stores extra correction codes on top of it. (276 bytes for each 2352 byte sector).
(and there's also issue below F3 frame level about EFM modulation, whether merging codes are generated properly to keep DSV low enough)
See: https://byuu.net/compact-discs/structure/ https://john-millikin.com/%F0%9F%A4%94/why-i-ripped-the-same-cd-300-times https://john-millikin.com/%F0%9F%A4%94/error-beneath-the-wavs
They do, absurdly enough. See for example BSNES, https://byuu.org/ , here's a quote from their most recent release notes: "If the coprocessor firmware is missing, bsnes will fallback on HLE where it is supported, which is everything other than SD Gundam GX and the two Hayazashi Nidan Morita Shougi games."
See past HN submissions about the extreme lengths BSNES goes to in order to get this data: https://news.ycombinator.com/item?id=3675123 , "In order to extract these programs from most of the DSPs, we had to decap the chips, scan them in with an electron microscope, and 'tweak' the processors to allow us to dump their protected program ROMs."