Can NES music be NSF-rip protected?

[oRBIT2002]

I'm just curious. Is there a way of implementing music/sound effects in a .NES-file that makes ripping it to an NSF more difficult?
Or coding the music-player in such a way that it can't be played by the common NSF-players (for example a Winamp plugin)?

[blargg]

- Make the code very timing-dependent, so any changes will disrupt critical APU writes.
- Use VRAM for variables and music data.
- Access the PPU in ways that are hard to follow or remove.
- Require an obscure mapper.
- Rely on unofficial instructions.
- Make code rely on absolute addresses. For example, have the high byte of an address also be executed as an opcode.
- Put some hard-to-find writes to the NSF bank switch registers.

I'm sure others can come up with more off-the-wall ideas.

[Bregalad]

- Don't use NMI interrupts for a timing base but use extrenal IRQs from an obscure mapper, making almost all NSF players running it at wrong speed.
- Rely on open bus when reading APU registers, SRAM, etc...
- Shatter your sound code in small pieces in a big programm and pieces fall into different bankswitched places
- Simply put, read music data from the CHR-ROM (evil)

Why would you want to do that anyway ? To be sure nobody listen the music of your game/demo without purchasing it or something like that ?

[Memblers]

- Put some hard-to-find writes to the NSF bank switch registers.

That's pretty evil.

Doing indirect writes to the sound registers is another little thing that can be annoying.

I don't think any of this will really stop a rip from being made, slow it down probably, or make most give up. The only other unsaid ideas I can come up with involve code-protected microcontrollers (which is also what some yet-unemulated arcade games do).

[tepples]

Doing indirect writes to the sound registers is another little thing that can be annoying.

Something like STA $4003,X is annoying, but not evil. I do just that in Pently so that I can reuse the same pitch code for channels 1, 2, and 3, and the same envelope code for channels 1, 2, and 4. If the program is accessing sound registers through STA ($24),y, data breakpoints can still start to tease those out.

Streaming music data from CHR ROM, now that's evil. This goes double if the CHR gets XOR'd with graphics from another CHR bank before being played.

But some games do one thing that could be considered more evil than that. They generate the music in real time based on what's happening elsewhere in the game engine:

• Super Mario 64 water levels turn strings on and off depending on the player's position.
• Tetris Advance (J) for GBA turns channels on one-by-one depending on which section the player is in, and section 5 sounds almost exactly like the Starman music from the Mario series.
• Lumines for PSP turns channels on and off depending on how many squares got swept in the previous pass.
• Super Mario Galaxy takes Super Mario 64's methods to the next level.

blargg said require an obscure mapper. You could design a sound chip that generates DPCM samples at $FFC0, which the NES can easily stream. Or one that generates raw samples to be played with code like this:

Code: Select all

irq:
  pha
  lda $4111
  sta $4011
  pla
  rti

EDIT (2018-10-28): The audio driver has a name

[Bregalad]

I don't see why sta $4003,X would be either annoying or evil. Almost all sound engines I've ever seen does something like that, I also do that in mine. All channels are considered equal, exept the noise channel for the pitch and the triangle channel for volume who have to be threated spearately from the other channels, because the hardware pretty much require this.

I also made a sound engine doing indirect writes to the registers, because this simplified my code. Technos' sound engines do APU register writes in RAM self-modified code, a nice thing too. Not to consider that Just Breed relies on MMC5 multiplier to be there in it's sound code.

Also, you could rely on uninitialized RAM. I tried to dump music a NSF from Nesnake 2, and I almost suceded but a sound effect always comes up when a new track is started, probably because the memory is set to all $00 and this seems to play SFX 0 for some reason.

[Memblers]

Well "indexed indirect" is what I meant, which is the STA ($23),y type. STA $4003,X I thought would be "indexed absolute". And yeah I suppose a breakpoint would catch those, I thought of it because it's why I didn't rip Golgo-13 or Conflict despite many attempts.

Actually if you attempt to rip some Jeroen Tel soundtracks, you could see pretty well how to make a hard NSF to rip. I did one of them (Alien 3 I think), usually I'd go through and rip everything by the same authors, but I had to quit the first one (though the first one even worked fine).

blargg said require an obscure mapper. You could design a sound chip that generates DPCM samples at $FFC0, which the NES can easily stream. Or one that generates raw samples to be played with code like this:
Code:

Code: Select all

irq:
  pha
  lda $4111
  sta $4011
  pla
  rti

Which is exactly how my Squeedo sound synth was working. I figured it to be emulatable though, either by simulation or actual PIC18F emulation. Enable code protection bits like I mentioned earlier, and it's instantly a black box (Squeedo was to be open though).

Though oRBIT asked about in .NES files, so mapper weirdness is kind of out of the question.

[tepples]

Here's one if you can afford an MMC5: It has 1 KiB of RAM at $5C00-$5FFF. Look what's mapped to the last eight bytes of this in the NSF mapper.


Another one should be obvious to anybody familiar with my posting history on Pocket Heaven.


Five words: Big Bird. Still not ripped.

Trace the game's speech playback code and compare it against the currently deployed NSF spec to see why. The current version of NSF has no well-defined way to stream PCM to $4011 like Joshua, Skate or Die 2, Battletoads, Bayou Billy, SCAT, Big Bird's Hide and Speak, and Sesame Street Countdown do. A proposed spec (topic 1, topic 2) clarifies how to handle PCM streaming, but few if any NSF players implement it.


oRBIT: You're trying to implement Digital Restrictions Management. In the end, all DRM is broken.

[blargg]

Five words: Big Bird. Still not ripped.

That brings up another method to eliminate rips:
- Make the music/audio content not worth the time to rip.

[Zepper]

I'm just curious. Is there a way of implementing music/sound effects in a .NES-file that makes ripping it to an NSF more difficult?
Or coding the music-player in such a way that it can't be played by the common NSF-players (for example a Winamp plugin)?

Was Battletoads ripped with RAW drums, without the "watch dog" thing?

[Drag]

The more unrippable you try to make it, the more you're asking for someone to rip it~