Which hurdles have to be taken when releasing an NES game?

I am in process of programming my own homebrew game, which I might want to release as a cartridge and sell it (much like sivak did with his Battlekid games on Retrousb).
What do I have to consider? Any issues with patents when I for example use graphics or music from other (licensed) commercial games?
If anyone has already experience or does know where I can aquire good information on this topic, i would really appreciate it.

I don't believe there are any significant remaining patent issues.

However, you should not use music, graphics, code, or other content from other games. That's a copyright violation. Copyright lasts much, much longer than patents.

good to know, that copyrighted material actually must not be used. So my ideas of cameos in the game will be dropped....

Now, if i changed my mind and were to release it as free homebrew, is there also any issues using copyrighted material?

If you want to use someone else's copyrighted material in your own work without buying a license, ask a lawyer first about what does and does not qualify under "fair use" rules.

Copyright law does not care whether something is "for profit" or "freely redistributed". However, some corporations may elect to not care if you're not making a profit.

Also, bitmap fonts (i.e. letters, numbers, punctuation) are deemed not copyrightable in the US, so you could probably get away with borrowing that portion of something else ... not that finding or drawing a font is much effort.

Ok, well, it seems like it might not be worth going through the hassle and stress of getting some copyrighted material into my work.

Another question:
Is there a way of securing rom data from being pirated?
I know i could implement a new custom mapper of which only i know how it operates. But for someone motivated enough, it would be no problem to "crack" the mapper.
Does anyone have an idea on how to secure rom data (and possibly chr) from being accessed by anything other than the nes? This would be pretty interestening.

You can make it a royal pain to deal with ... but crackers tend to like puzzles.

That's a curious request coming from someone who was JUST NOW considering using music and art from existing games!

Anyway, there's very little you can do to protect your data. Even if you find a way to heavily encrypt everything, at some point it will be decrypted (it doesn't matter if by software or hardware) to be delivered to the NES, and it can be easily intercepted by crackers then.

Every time this subject is brought up in these boards, the consensus is that the best you can do is digitally sign each ROM (something more complex than a string at a fixed memory location, please), so you'll at least know WHO to blame in case it does get distributed. Letting people know about this might discourage them from distributing their copies.

If you know it's signed, all you need are two different copies and you will know where the signature is. From there it should be straightforward to obliterate. I think this method is more likely to catch someone if they are unaware it's signed. i.e. it's better for punishing someone after they've already leaked it, than as a deterrent.

Honestly, there's no good way to do it, and even if there was you wouldn't want to speak of it here in the open.


BUUUUUT

The vastly harder task is to actually make a game worth stealing. You need to do that first, and you haven't even started on that one have you?

Not if they're shuffled differently. I made a preprocessor that shuffles the order of instructions, subroutines, and variables in a source code file. Factorial growth means that even for a simple little NROM game, there are more possible ROMs than atoms in the observable universe squared. See also old discussion about keeping prototypes secret.


I don't see how given that each copy has its variables and subroutines in a different order. An IPS from one version to the other would end up covering virtually all of the PRG ROM. To make a shuffled ROM untraceable world require at least as much effort as doppelganger expended making the disassembly of Super Mario Bros.


In any case, the shuffle methodology would probably provide strong enough evidence to identify and go all Capitol v. Thomas on the offender.

Ah, sure, a complex reordering of the game code could do it. Still, all you have accomplished is naming your leak. If your game is worth putting in enough peoples' hands, it will be leaked by one of them, and then everyone who wants it will have it. You can try to sue the leak at that point, but you haven't stopped the piracy. All that effort was just to take revenge on a single person.

Personally, I'd be too afraid to do something that drastic. Software never works entirely as expected, and you're going to have bugs that manifest differently or not at all depending which build it was. To me, that's a maintenance/stability/testing nightmare. Some people are willing to take this kind of risk in the name of anti-piracy though.


If it's just to protect a prototype, I could see how it would be effective enough. Given only to a pool of people small enough to be intimidated, and bugs are expected in unfinished software, so maybe that part isn't an issue either.

I can't imagine ever wanting to try this method, myself, but good luck to you with it.

I have come up with a method that, in theory, would allow for encryption of specific banks within the PRG-ROM. Code running from a different area of memory would be unable to read valid data from it. And almost any external cart readers would be stopped from reading it.

It was fun to think it up, but who knows if I'll actually want to implement it.

I'm moving this thread, lets keep any homebrew-related posts out of the repro forum.

Yeah, as i said, i had the idea for some cameo appearances which of course would have needed those licensed graphics and sprites, but i dropped it in favor of not wanting to go through a lot of hassle and stress to include these.


Actually, i have started with it, but of course you are right on making it worth stealing

to the ideas posted:
if the game would be cracked and distributed, i would not think of taking any legal action. so being able to identify who the leaked the game is not neccessary, thus its not neccessary to sign every single copy in order to do so.
i thought more of making it just very hard to get a dump of the rom, so it would be secured at least for some time, if not forever if it was too hard


But I should probably focus on getting some work on the game done before even thinking of security measurements.

Look up tapedump and realize you not only need to design a new mapper (not that tapedump supports every one, but it can be modified to support known ones), but also need globtops. Can't just do one or the other. Without a custom mapper, I figure out what mapper you're using and write software to dump it. Without globtops, I desolder and read your eproms and then have to do a little work to figure out your bank switching. (This is probably the one to choose if you're only going to do one, though.)

Even with both, someone will do it. Especially if the game is worth dumping.



Indeed.

Even without chip-on-board packaging ("globtops"), putting some of the bank switching logic and possibly even game logic in a tamper-evident microcontroller (or MCU) was a common method of protecting arcade games. Bootleg arcade machine makers had to program a high-level emulation of what the MCU was doing in their own bootleg versions. This is why the arcade version of Bubble Bobble was emulated wrong until 2006 when its MCU was decapped: the HLE got the EXTEND randomization and the "monster pecking order" behavior (where only the first monster near the player follows the player) wrong.

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.

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.

"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.

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.