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)

Forbidding use of the frame IRQ ($4017 D6) is fine, as it confuses IRQ-driven hardware players. To support all rate/period values, a hardware player implementing the NSF mapper will be using its own timer IRQ anyway, insha'411ah. But if you forbid $4017 writes entirely, then you forbid use of the length counter, linear counter, sweep units, and hardware envelopes, as their rate depends on $4017 D7. --Tepples 06:11, 1 April 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, possibly because the NSF spec never mentions them.
• 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. Alternatively, perhaps it should just be suggested that mirrors not be supported by NSF players (which also conveniently avoids conflicts). - Rainwarrior 02:28, 1 April 2012 (PDT)

Another thought: it's not necessarily correct to insist that VRC6-VRC7 should conflict, for instance, since the NSF spec defines a mapper that does not include the mirrored registers. I don't believe there are existing NSF rips that rely on these mirrors, and they aren't really supported by playeres anyway. If you were to attempt a mult-expansion hardware solution (e.g. the TNS-HFE4), it's really up to you as the hardware designer to decide how to resolve these conflicts (or not resolve them, if the solution is too difficult and warn the user). For the most part, the various combinations of hardware seem to work pretty well in NSF players; it doesn't seem necessary to suggest that there should be a conflict. FDS, may be a problem though; I suspect some players have a potential memory corruption problem when using FDS with VRC6/VRC7/5B. - Rainwarrior 02:54, 1 April 2012 (PDT)

I was going from the perspective of soldering all the synths to a circuit board and putting that board in a Famicom's cart slot. Your "how to avoid the conflict" and "practice for resolving conflicts" would be implemented in a decoder circuit. This way, people building these hardware solutions will know what behavior to implement, and people building NSF players will know what behavior to emulate. If you've been making 5B tests, you might want to convert them to .nes format and post them to the BBS so that people who have made gimmicky devcarts can verify these hypotheses. --Tepples 05:42, 1 April 2012 (PDT)

Short suggestion: support for multiple APU instances. :) --Zepper 08:07, 1 April 2012 (PDT)