Embedding a ROM in an emulator

Say I want to port an NES game to PC (presumably Windows). This game uses a simple discrete mapper and CHR RAM and doesn't rely on any raster tricks other than a sprite 0-triggered pattern table split for the title screen. My first guess was to embed a ROM in an emulator designed to run only that ROM. I know this method works on mobile, though input on mobile needs to be rethought more than it would on PC. Anyone here have experience with "porting" an NES game to PC in this manner?

I played around with something like what you are talking about in the halfNES emulator since I could follow the source code enough to modify the emulator.

I didn't really embed it but you could. What I did was have it auto-load an encrypted rom from a web location. The web location was also encrpyted in the java program but obviously it wouldn't be hard to figure out where the program is going to
download the rom

And I also kept the rom encrypted in the emulators memory and decrypted it on the fly

I couldn't figure out how to do it in nestopia as the C code is too complex for me to follow. It should be simple in theory.

Why bother with all that encryption ? If it is such an issue that the ROM is found inside the project folder somehow, then just reprogram the game directly for the PC (it should be a simple step since there is less technical constraint).

However, if you target is to play the game emulated, I would not even bother doing a NES verison (actually, this is the kind of game development I'm hesitating towards going into, since programming in 6502 assembly is so annoying for so little benefit of "real hardware" that almost nobody uses anymore...).

The NES version of the game in question is completed and working on my PowerPak. I just want to do the equivalent of Virtual Console to make a PC port, so we can sell both a PC download and an NES cartridge.

Scramble opcodes in your game, and also the emulator. Maybe give it an iNES header that is invalid, knowingly substituting correct mapper behavior later. Change the addresses used to interact with the PPU. Make it run on a "screwed up NES!"

I find it strange that you feel like this. I think 6502 assembly is really fun to code, it doesn't feel like a chore to me. And I actually like the limited scope that programming for the NES creates... I would probably feel a bit lost if I made a PC game, not being sure how far go with the various aspects of it.


Interesting ideas. You could also mapper-hack your game to a made-up mapper that no emulator supports.

I had a similar idea for a project I did a while back. Though I stripped the emulator down to only be able to support my ROM and XOR encoded all memory (because any kind of strong encryption would be a waste of time, as you'd have to leave the key in the executable anyway), both the ROM and in-use memory. I also considered recompiling parts of the ROM into native code, but I figured the task would then be quite large for relatively little benefit. My ROM relied upon some "system calls" implemented in the emulator anyway, so it'd be rather difficult to extract the ROM and use it anywhere else anyway. I also scrambled the opcodes by modifying the assembler, and I worked on having a different set of scrambled opcodes per instance of the executable as a kind of a watermark. Needless to say, I eventually grew bored and the project now rests in procrastination hell.

What I'm getting at is, my recommendations are pretty much the same: Modify the ROM and emulator to rely on one another. Scramble opcodes. XOR encode all memory.

With that said, the bigger issue here is probably that most well known emulators are released under GPL, which makes all of this effort to obfuscate the ROM and inner workings of the emulator a waste. You'd have to find an emulator with a more permissive license and modify that, which may require reworking the interface of the emulator and adding support for more platforms and input devices. I'm not too familiar with how well the permissive licensed emulators are implemented.

If I was going to do this I'd probably code my own emulator, with really crappy timing accuracy and just the features that the game actually needed. An emulator like that should be fairly quick to code.

If the game will be released on a cartridge, why bother trying to scramble or encrypt the copy bundled with the emulator? You can't stop someone from dumping the cartridge.

While this certainty is true, you don't have to make it so easy to extract that anyone with a hex editor can do it (There are far more people with hex editors than there are people with NES cartridge dumpers). It's a statement: I don't want people to think it's OK to redistribute the ROM, therefore I've put a tiny bit of effort into making it slightly more difficult to do.

In the end, DRM schemes cannot protect content and only hurts paying customers (I can't play this game in an emulator of my choice, on the platform of my choice), but I can see why you'd want to go to a slight effort to protect your own interests. At least in the beginning.

For a game written in a portable language, you could get away with a mediocre emulation of the PPU / VDP / whatever system you targeted, and build the game for the native target architecture.

But writing a basic 6502 emulator/interpreter is easier than coding the game again in another language.

Well, it's pretty clear which aspect of this topic is the most interesting to talk about, heheh.

If all the protection one wanted was making it harder to extract the ROM and use it, you could pretty much just use the existing protection from the VS Unisystem.. add the game's CRC to the emulator so it runs it as such. Or add a new similarly modified PPU into the emulator. It's not just palette differences, but it'd be easy to make it not even run on a normal PPU without some fairly extensive hacking (but still have it simple to change when assembling the ROM).

Something that would work on both your emulated version and a cartridge would just be to make your own unusual mapper. While someone with programming or hardware skills could still get around that, they might be less inclined than others to share/pirate the game to others.