nesdev.org

An "obvious" way to make something that's not trivially pirateable is to make it not an NES game at all ... add an extra CPU (using the NES's own 6502 as a coprocessor that only handles uploading attribute data, starts OAM DMA, manages register I/O, does some raster effects), and extra RAM to transparently feed the PPU the correct tile data. If you don't care about famiclones, you can even get 8×1 attribute zones (instead of 16×16) and arbitrarily large tilemaps instead of the NES's 64×30 or 32×60.

All of this is completely doable from the cartridge edge.

That said, difficulty of cloning isn't a good reason to do it this way, as opposed to making a NES-like library that adds the relevant restrictions to your high level language of choice and just making a game on a modern machine.

Wide Boy, RetroVision, and Super Game Boy implement exactly that technique, and with modern ARM CPUs, it might just be workable. Still, it's probably overkill as copy protection.

In August 2012, the U.S. FBI expanded the Anti-Piracy Warning seal program to all copyright owners. This means you can scare pirates by displaying the seal and authorized warning language while performing various checks on the hardware. For bonus points, display the game's serial number below the box, and use that serial number as the random seed for shuffling so that you can compare the leaked ROM to each sold copy in order to find the copy with the smallest Hamming distance.

tepples wrote:Wide Boy, RetroVision, and Super Game Boy implement exactly that technique, and with modern ARM CPUs, it might just be workable. Still, it's probably overkill as copy protection.

This was something i also considered, having an extra cpu do some or all the work and passing some neccessary data to the NES.
But this would be pretty costly, providing an extra cpu to every single cart.

SNgamer wrote:But this would be pretty costly, providing an extra cpu to every single cart.

"Goddammit, damn dammit, damn damn"
-- Fox McCloud, Star Fox

At least by the Super NES era, the cost of including a CPU on a cart had dropped to the point where the Super FX and SA1 coprocessors were cost-effective. And now that field-programmable microcontrollers are widespread, I wonder how much it'd actually cost to put a PIC or AVR microcontroller on every cart. Memblers has been toying with the idea with the "Squeedo" cart. I wonder how much of the game logic can fit on the ATMEGA popularized by Arduino kits.

They're certainly easier to program with a "real" C compiler, although I'm not certain what kinds of division of labor makes sense.

A 3D rasterizer and some (fake) two-port RAM would allow something like Star Fox, although shading isn't an option given the NES's limited palette. And attribute clash...
Maybe decompression or converting from a serial ROM to the NES's parallel interface...
Some kind of math coprocessor that's less awkward than the MMC5... probably needs to do more math at once.

tepples wrote:

SNgamer wrote:But this would be pretty costly, providing an extra cpu to every single cart.

"Goddammit, damn dammit, damn damn"
-- Fox McCloud, Star Fox

At least by the Super NES era, the cost of including a CPU on a cart had dropped to the point where the Super FX and SA-1 coprocessors were cost-effective. And now that field-programmable microcontrollers are widespread, I wonder how much it'd actually cost to put a PIC or AVR microcontroller on every cart. Memblers has been toying with the idea with the "Squeedo" cart. I wonder how much of the game logic can fit on the ATMEGA popularized by Arduino kits.

Whoops... for a moment when typimg i forgot about the existence of cheap avr mC. Using one of these might just be the solution for anti-piracy. And with some more coding it could serve as new mapper, with extra features.
I might want to build the game together with the power of an avr that has some nice features to add to the game.

Are we talking about using an AVR as ROM here? Or just other stuff?

I was under the impression that such microcontrollers were too slow to be used as ROM. I vaguely remember some thread where someone wanted to make a homebrew game genie but it wasn't going to be possible with a microcontroller. Though, in that situation the micro would be doing more than getting an address and spitting out a byte.

If you can use an AVR/arduino as a ROM then I've got work to do.

Not really. A PIC or an AVR (but very unlikely with the Arduino overhead) is fast enough to feed bytes to the NES as it needs them, but not fast enough to have it be a function of the address fetched.

So it's only good enough for bootstrapping a cartridge that has no parallel ROM: it could feed a little tiny stub code that would copy the actual 6502 code into RAM. (If there's then an additional serial ROM, that code could then copy data from the serial ROM into RAM, kinda like the FDS or any of the CD-based consoles.

Yes, you can run an entire game on an AVR MCU: see the Uzebox. If you can make a "Wide Boy" style circuit where the AVR responds to the PPU's (predictable) video memory fetch pattern, you've successfully protected your game from dumping through normal methods.

You can get some ludicrously powerful MCUs for under $10 these days. I suppose I could admit that I have my eyes on the new PIC32MZ (and my hands on some samples ). The PIC MCUs (most of them) have a parallel port, which NES can use like a normal memory (uses /CE,/RD,/WR inputs). I've used that on PIC18 with the old Squeedo board. Later PICs have a 4-byte buffer (and optionally, A0,A1 address inputs) and also a DMA function. I haven't tried it, but in theory it may be possible for the NES to execute (non-branching) code directly from it. It certainly could do slower LDA reads from it, or JSR to a single instruction + RTS (fits in 4 bytes). There are lots of nice 16 and 32-bit MCUs under $4 also.

hehe tepples, that quote, and I always thought Falco was saying "dammit wing dammit".

As for the cost, I always figured it's something the user buys once, and the games could be separate. Like a modern version of the Aladdin Deck Enhancer [link]. Game releases could be ROM, memory card, or why not a case and/or label? There is the initial high cost of the cartridge, but ideally, the freely available software for it would make it worth it.

I've already been doing work in this direction, minus the copy protection. You should check out Blargg's work with the serial cable, as well. In discussions on IRC with people on #nesdev, we've pretty much eliminated the need for any DP SRAMs or the like, although a CPLD may be desirable to emulate this with fast SRAMs as well as provide mapper functions.

The key to my strategy is to have a PRG-RAM/CHR-RAM cart and either a small bootloader ROM or preload the SRAM outside of the NES using batteries and tristate bus. The MCU I'm thinking of using is not able of working as fast as say, a '161, but it is plenty fast to transfer using a 2-way parallel-port-like interface and implement bank select.

The copy protection would be useless unless it resists decapping and protocol analysis, for say a game that uses a MCU for graphics calculations.