Is a NES game able to detect if it is being emulated?

[AlexE]

Perhaps I should rephrase: what is an "achievement" in an NES game, and what makes it "valid", and why would you want to address the validity with an anti-cheat mechanism? The key part that I'm very curious about is the NES context, specifically. Do you just mean you want to prevent people from cheating at your game?

For example, if someone puts in the Konami Code and gets 30 lives and beats the game, that shouldn't warrant an achievement celebrating the player's steadfast will to beat the game with just the initial 5 lives.
Maybe an achievement on a NES game could be a small pop-up that says "You Got an Achievement" and then they can be viewed on the Start screen. It's entirely a luxury item and it's there mainly as an afterthought. If you look up "NES Achievements", there are leaderboards and achievement lists made for NES games already. Putting them in-game would cut out the middleman.

[rainwarrior]

Okay, I understand. Basically all you want to do is detect "cheat" conditions and display different messages to the user depending on them?

If that's what you meant, I don't really have anything to add that wasn't already said in this thread. (It can be done, partially, but it's prone to error and easily defeated.)

[Alp]

Is a NES game able to detect if it is being emulated or not? If so, could it be possible to detect if a save state has been made and loaded? It'd be neat to screw with the player for CHEATING.

Well, I know that a ROM can be set up to detect real hardware, but I'm not sure if you could reverse that to emulation. (I learned a neat coding trick over on 2CH, that allows you to hardware-lock your games. Take that! Reproduction community! )

[lidnariq]

I mean, you can always invent a new mapper. Depending on how much effort you go to, and how much effort someone else wants to go to, it'll delay the amount of time before the game is emulatable.

Note that making a new mapper that is conspicuously different in capability from existing ones will make development harder, because being able to test in FCEUX's or NO$NES's debuggers makes game development so much easier.

Obviously, if you design a mapper that's just like MMC3 but the registers are completely scrambled ... like Mapper 112 compared to Namco 108 ... then getting it to work is just a matter of developing with a known mapper, and the changing some compile/assemble time constants.

And if you're versed in C, adding your new mapper to your private build of FCEUX to do development debugging with isn't too hard.


Arguably, Sachen's games are basically nothing but doing this, over and over. (except they were trying to prevent reproductions, not emulators).

[infiniteneslives]

You could effectively accomplish this by use a mapper design that's not supported by any emus. Kind of makes developing your game a challenge though.. There are some simple flash operations you could do though using standard mappers with nuances of current cartridge hardware standard features.

Save state detection might be accomplished by having some hardware on the cartridge with its own state you could compare to the emu. Perhaps a counter implemented flash rom. But in this case it's doubtful the emu would even support flash rom emulation. So effectively if you break the game in emus, you also prevent save states with same effort.

A cheap security token would be based on the assumption that your physical cartridge was created with flash memories. You could write to the flash memories to enter manufacturer ID mode and other such flash commands which are predominantly not emulated in today's emus. I'm guessing the few emus that support flash emulation for homebrew development don't do so for every mapper under the sun. And even if they did, they are probably no going as far as to emulate accurate the random nature of sector erase and byte program times.

[lidnariq]

Perhaps a counter implemented flash rom. But in this case it's doubtful the emu would even support flash rom emulation.

FCEUX grew support for the SST39xxx Flash protocol with the UNROM512 board (see rev3071). It uses FCEUX's PRG RAM abstraction, basically copying the .NES to conceptual RAM on initial load, and then just using the copy in "RAM" thereafter.

They even implemented the "erase chip" command, because why not.

not going as far as to emulate accurate the random nature of sector erase and byte program times.

Given that the SST39xxx ABI is already implemented in FCEUX, adding pedantic timing requirements to it would be easy. Especially since the SST39xxx parts have ≈constant programming time.

Really, the entire calculus here just comes down to
- How much effort you want to put in
- How high priority of a target the game is for someone to get working in an emulator
- How much time you want to buy between public release of your hardware and emulation

Once it's mostly emulated, any edge cases will be fixed proportionate to how often they're encountered and their severity.

[AWJ]

(I learned a neat coding trick over on 2CH, that allows you to hardware-lock your games. Take that! Reproduction community! )

What's the trick? It sounds like what ROM hackers do all the time by accident And it's generally not a good idea--if your hack or homebrew does something that only works because of emulator flaws, you're not just locking out hardware reproductions, you're locking out future (and even extant) more-accurate emulators.

[Alp]

What's the trick? It sounds like what ROM hackers do all the time by accident And it's generally not a good idea--if your hack or homebrew does something that only works because of emulator flaws, you're not just locking out hardware reproductions, you're locking out future (and even extant) more-accurate emulators.

That's irrelevant, the trick relies on an obscure bug in the actual hardware, that's not emulated.

Besides, the developer who published the trick, distributes his ROMs packaged inside a custom emulator executable. No need for increased accuracy, in this case.