Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

I suspect a lot of these bugs, especially those related to timing, were not intended specifically as anti-piracy/anti-emulation; given that the games are developed for a single platform, it's common that programmers would naturally explore and exploit the full capability of the platform, whether officially documented or otherwise. Relying on instruction, CPU-GPU, and even cartridge access timings is thus perfectly reasonable.

One way to get "perfect" emulation is to completely reverse-engineer the system down to the transistor level, wherein the timing relationships between all the components are revealed. I believe this has been done only for a very small number of game consoles, of which I'm aware of are the Atari VCS/2600[1] and NES[2]. Even a GameBoy hasn't been analysed to this level, much less a GBA or DS.

Also, this: https://trixter.oldskool.org/2015/04/07/8088-mph-we-break-al...

[1] http://blog.visual6502.org/2014/10/atari-2600-simulation.htm...

[2] https://github.com/SourMesen/VisualNes

Yeah some of this do not seem like bugs, but more like devs making full use of their sole and direct access to the hardware while the game is running.

After all, the Nintendo hand held line may well be closer to the NES and C64 than a modern PC or smartphone.

A lovely example of a bug in a game that may as well be intention is a use after free memory bug in the DOS version of SimCity. This went uncaught during development because DOS didn't have the checks in place as modern OSs do. But trying to run it on Windows and you get an error.

So what Microsoft did in the name of backwards compatibility and user friendliness was to program and exception for the SimCity binary.

Similarly the stability of Win9x was kinda compromised by how the cmd window had virtually all the capabilities of DOS. This to the point of being able to poke various BIOS memory areas.

The article is about bugs in emulators, not the games they emulate.

It is more about emulation accuracy than out and out bugs.

It is about how certain games behaves in ways that may or may not be bugs in a strict sense, but still go outside the expected environment set down by the hardware documentation while still functioning on the actual hardware.

So be it cmd in Windows, or Dosbox, if one want to run the unmodified SimCity binary from back then it will have to allow it to access ram after it was freed. Because when it worked back then, but do not work now, where is the incorrect behavior (or bug if you will) actually located?

The goal of an emulator is to reproduce the behaviour of the original machine, whether that behaviour was expected by it's designers is irrelevant. If it can't do so, for whatever reason, then it's a bug as far as I'm concerned.

> One way to get "perfect" emulation is to completely reverse-engineer the system down to the transistor level, wherein the timing relationships between all the components are revealed.

What do you gain with transistor level that you don't alreaady get with RTL level?

RTL level is good enough for digital simulation, but the uninitialized S-DSP with Magical Drop sounds like it depends on analog effects. Transistor level would let you simulate this.

Unfortunately even VisualNES experiences some inaccuracies compared to real hardware. I've only personally found an issue caused by it in one game (Who Framed Roger Rabbit,) and the effect isn't noticeable if you're not looking for it. But it is there.

Also SNES and a few others : https://en.m.wikipedia.org/wiki/Higan_(emulator)

Edit : related article : https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...

higan doesn't emulate the SNES down to the transistor level. It's cycle-accurate, but it still runs at full speed on modern PCs. Transistor-level emulation would be maybe orders of magnitude slower.

Reply on news.ycombinator.com