Talk:NSF

A NSF tune is perfectly playable in an emulator; in short words, a "normal" NES emulator, not something clipped for exclusive NSF playing and behaviour.

Regarding 4015h, well... it's empirical. My experience says that setting 4015h to 0Fh is required in order to get *a lot of* tunes starting playing. I don't remember of *any* broken tune by setting such value. So, it's recommended *to follow* such thing. --Zepper 14:25, 29 March 2012 (PDT)

Adding NSF support involves a mapper, an executable format, and a piece of shell code to draw the title, artist, and publisher, run the player in a loop, and switch tracks. But you're right that an emulator incapable of playing NSF is incapable of emulating something that runs on an NES, as the PowerPak has an NSF player. --Tepples 20:29, 29 March 2012 (PDT)

Yup, I assigned mapper 256, since iNES cannot assign it. And yes, it's required a player (I wrote my own in asm) and commands to switch tracks, but that's all. Perhaps I wasn't crystal clear... :( --Zepper 14:31, 30 March 2012 (PDT)

NES 2.0 can assign mappers up to $FFF.F. Yes, that's a hexadecimal point, used to separate the mapper number from the variant number. No variants are officially assigned though. --Tepples 15:00, 30 March 2012 (PDT)

I admit that my first statement sounds like "any NSF file can be loaded into any NES emulator", which isn't true. Proper support for NSF is required, as tepples noted. So, the emulator must create a mapper (I assigned 256, since iNES 1.0 cannot assign it), a player (I use 6502 code loaded at $4018-$4FFF) and controls for changing tracks, plus the frame rate control. The NSF header is parsed and then the file is loaded as specified by the document. Sorry for the confusion! --Zepper 10:05, 31 March 2012 (PDT)

$4010 value

The page appears to recommend writing $10 to $4010 but $00 to most other APU registers. However APU DMC says there's nothing mapped at D4 of $4010. Where did this come from? --Tepples 12:55, 31 March 2012 (PDT)

That's an odd one. It's in Kevin Horton's spec. /shrugs Rainwarrior 17:57, 31 March 2012 (PDT)

$4017 register

What about this register? For NSFs, is correct to write $00 to $4017 (frame IRQ enabled) and re-writing the last value on reset?

I don't think there should be any specification about what to do with this register for a couple of reasons. 1. NSF does not support any kind of IRQ; so enabling it is inappropriate. 2. Most software NSF players do not support resetting the frame sequencer by writing to $4017. 3. If your hardware player is NMI driven, you probably want to avoid writing to it so that it does not reset and get out of phase. 4. Alternatively your hardware player may be driven by the frame sequencer interrupt (esp. if there is no PPU), in which case the needs of the player dictate how the register should be used anyway. - Rainwarrior 22:14, 31 March 2012 (PDT)

If anything I think it might be good to forbid the use of $4017 in the NSF spec, but I'm not sure on this. - Rainwarrior 22:17, 31 March 2012 (PDT)

Multi expansion

I like the new section with multi expansion notes. I have a few thoughts about it.

• It's probably worth suggesting to not use mirrored register addresses in general. (I don't think mirrored addresses are widely supported in existing NSF players.)
• Perhaps some recommendations can be made for NSF players as to how to avoid the conflict, i.e. writes to VRC7 registers should not be mirrored to VRC6 as well, etc. This may facilitate the implementaion of multi-expansion players, so that a consistent practice can be maintained.
• Does the 5B actually mirror E000 to E000-FFFF? (...and C000 to C000-DFFF?) I can't find any good documentation on it; the emulators I've checked so far only respond to $C000/$E000. Does the FME-7 mapper page need an update?
• FDS and writable memory needs a clarification; these areas conflict with VRC6, VRC7, and 5B, I think. It seems writing those addresses would corrupt your memory unless you're careful to make sure your code isn't stored there, or perhaps we should suggest that players disallow FDS-RAM writes at these addresses for enabled expansions.

I think a good practice for resolving write conflicts could be done fairly easily by having a standardized order in which to issue writes to the various expansions, like, off the top of my head, maybe N163 VRC7 5B VRC6 MMC5 APU FDS, where each enabled layer is allowed to take ownership of the write or pass it to the next layer in turn. - Rainwarrior 02:28, 1 April 2012 (PDT)