nesdev.com

http://www.neogaf.com/forum/showthread.php?t=940813

I think this means that Gameboy emulators will now be under control by Nintendo. Nintendo can remove them at any time. They're ruining the fun. And there's nothing we can do

The only parts of a patent with any legal weight are the dates and claims. (The description is there mostly to help interpret the intent of the claims.) Here's the key claim of application US20140349751:

So the patent covers automatic enabling of speed/accuracy tradeoff options in an emulator based on a ROM's hash. Nintendo has been kicking this one around in the USPTO for a long time. Fortunately, the Game Boy is a fairly simple system, and emulators should be able to run every official game (other than perhaps Prehistorik Man) without hacks. Any emulator that can run homebrew should be immune to the patent.

The other part of a patent is the dates, which determine when the patent expires. Patents filed in 1996 or later expire 20 years after the priority date, which in the case of this patent appears to be 2000 or so. I don't see how this patent is going to have a usefully long term.


EDIT: Added the actual application number

_________________
Pin Eight | Twitter | GitHub | Patreon

Okay thank you very much! Now I can go and start developing for GBC.

Even though the patent talks about Gameboy, those claims sound more applicable to N64 emulators...


When did emulators start using hashes and such to enable game-specific hacks? There might be prior art that would invalidate this patent.

Probably about as early as emulation became popular (which would be late '90s). Does anybody know if any emulator from the same era as Genecyst or Nesticle did it?

EDIT: wait, this patent was filed in 2014, so that completely destroys it in terms of prior art （・＿・） The real deal would be the older one then.

Check the priority date. This is a continuation of a fairly old patent application.

See also discussion on Ask Patents

_________________
Pin Eight | Twitter | GitHub | Patreon

Ah. Well, I agree not to do automatic enabling of speed/accuracy tradeoff options in an emulator based on a ROM's hash anyways, because I believe it is not a good idea anyways (except perhaps Nintendo's own emulators). And certainly any correct implementation needs to be able to run homebrew games as well as the official games (with accuracy), otherwise the implementation is not correct.

But, I think I may have read somewhere that there is a few official games where the header won't tell you the mapper properly (there isn't the way to do so it seems); I consider it OK for a software implementation (but not for a hardware implementation) to fail to execute these programs correctly. To make the implementation complete though, there would need to be some way of specifying such files (perhaps support to add one additional "mapper override" file which specifies various parameters that you can set for the game).

_________________
.

Correct. The iNES header won't distinguish StarTropics from Low G Man, and the common emulator hack of ignoring the MMC3's WRAM disable and write protect bits to get MMC6 games working breaks LGM. Nor is there a reliable way to distinguish SOROM and SXROM from SNROM and SUROM, or distinguish among the various VRC bit assignments.

But fortunately, I today discovered that the official site for iNES (fms.komkon.org) has gone NXDOMAIN. This leaves NES 2.0, which clearly distinguishes MMC3 from MMC6 and the MMC1 boards from one another by their WRAM size, and which has submappers for the VRCs.
Edit: As of the next morning, it was back up. The DNS server must have gone down.

_________________
Pin Eight | Twitter | GitHub | Patreon

The site going down doesn't mean the format will stop being used anyway =P (especially with all the existing dumps)

This was granted as US Patent 9,839,849 on December 12, 2017. Priority is still claimed to an application filed in September 2000. Its claims still boil down to turning speed hacks on and off based on a ROM hash:

1. A method of adapting operation of an emulator, the method comprising:
- executing, on a processor, an emulator capable of running a plurality of different binary applications, each of said plurality of different binary applications having an associated identity;
- recognizing, by the processor, an associated identity of a binary application for running by the emulator;
- the processor accessing a stored data structure that specifies a function(s) and/or feature(s) for selective activation depending upon the recognized identity of the binary application;
- automatically adapting, by the processor, a behavior of the emulator to the binary application based on the specification of the function(s) and/or feature(s) depending on the recognized identity of the binary application; and
- generating, by the processor, an audio visual presentation using the adapted behavior of the emulator running the binary application.

2. The method of claim 1 wherein recognizing includes inspecting the binary application.

3. The method of claim 1 wherein automatically adapting includes activating game-title-specific emulator options.

4. The method of claim 1 further including dynamically tailoring the operation of the emulator for particular applications or games.

5. An emulation system comprising:
- a processor executing an emulator capable of running a plurality different binary applications, each of said plurality of different binary applications having an associated identity;
- a data storage coupled to the processor, the data storage storing a data structure that specifies an emulator function(s) and/or feature(s) for selective activation depending upon a recognized identity of a binary application commanded to be run by the emulator;
- the processor being configured to recognize an identity of a binary application commanded to be run by the emulator and automatically adapt a behavior of the emulator to the binary application based on the stored data structure specification of a emulator function(s) and/or feature(s) for selective activation depending upon the recognized identity of the binary application commanded to be run by the emulator;
- the processor being further configured to generate an audio visual presentation using the adapted behavior of the emulator.

6. The system of claim 5 wherein the processor is configured to inspect the binary application to recognize the application.

7. The system of claim 5 wherein the processor is configured to activate game-title-specific emulator options.

8. The system of claim 5 wherein the processor is further configured to tailor the operation of the emulator for particular applications or games.

9. The system of claim 5 wherein the processor is further configured to selectively skip frames in order to maintain speed of the application when the application becomes graphically intensive.

The Google Patents page for this patent shows "2022-05-20: Adjusted expiration", whatever that means.

_________________
Pin Eight | Twitter | GitHub | Patreon

That sounds a lot like per-game hacks? That said, the 3DS VC emulator has some of those, for example Pokémon's emulator-enabled trading screen.

_________________
The French Lord of Laziness (and a huge Legend of Zelda fan)
https://github.com/ISSOtm
ASMu is laifu <3

In the case of the discussion that prompted this bump, byuu was referring to an emulator that applies speed hacks most of the time but disables them on a per-game basis. One example is scanline-at-a-time rendering, which works for most licensed games for Game Boy except Prehistorik Man and most licensed games for Super NES except Air Strike Patrol.

_________________
Pin Eight | Twitter | GitHub | Patreon