It is currently Wed Dec 13, 2017 9:22 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Sat Oct 17, 2015 1:17 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Sun Oct 18, 2015 11:13 am 
Offline

Joined: Sun May 03, 2015 8:19 pm
Posts: 92
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.


Top
 Profile  
 
PostPosted: Sun Oct 18, 2015 11:48 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
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...).


Top
 Profile  
 
PostPosted: Sun Oct 18, 2015 11:52 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19342
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Oct 18, 2015 3:42 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1311
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!"


Top
 Profile  
 
PostPosted: Sun Oct 18, 2015 3:47 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Bregalad wrote:
programming in 6502 assembly is so annoying for so little benefit

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.

mikejmoffitt wrote:
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!"

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


Top
 Profile  
 
PostPosted: Mon Oct 19, 2015 9:39 am 
Offline

Joined: Sun May 03, 2015 2:57 am
Posts: 10
mikejmoffitt wrote:
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 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.


Top
 Profile  
 
PostPosted: Mon Oct 19, 2015 10:06 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Oct 19, 2015 12:41 pm 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
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.


Top
 Profile  
 
PostPosted: Tue Oct 20, 2015 11:27 am 
Offline

Joined: Sun May 03, 2015 2:57 am
Posts: 10
Joe wrote:
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.


Top
 Profile  
 
PostPosted: Tue Oct 20, 2015 2:29 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1311
tokumaru wrote:
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.


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.


Top
 Profile  
 
PostPosted: Tue Oct 20, 2015 3:57 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
But writing a basic 6502 emulator/interpreter is easier than coding the game again in another language.


Top
 Profile  
 
PostPosted: Tue Oct 20, 2015 7:27 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3487
Location: Indianapolis
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).


Top
 Profile  
 
PostPosted: Sat Oct 24, 2015 11:49 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2806
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group