NSFPlay 2.3

NSFPlay version 2.3 is released.

Download: nsfplay23.zip
Project information: http://rainwarrior.ca/projects/nsfplay/index.html

Changes:

NSFPlay 2.3 - 7/19/2013
Emulation:
- All illegal 6502 opcodes are now emulated.
- Audio emulation is now driven by CPU clock cycles, increases timing accuracy.
- FDS emulation completely rewritten for better accuracy.
- N163 emulation completely rewritten for better accuracy.
- APU frame sequencer now correctly driven by $4017, supports 4 and 5 step modes, immediate reset, and IRQ flag.
- MMC5 frame sequencer now independant of APU frame sequencer.
- Time dilation now slows frame sequencer along with CPU rate.
- Replaced PREFER_PAL setting with REGION, containing more options including Dendy support.
- Swapped duty option for APU1.
- More effective implementation of DMC anti-click option.
- Removed useless "frequency limiter" APU option.
- Added optional mute for ultrasonic triangle.
- Fixed broken oversampling filter.
- Adjusted device volumes to match more careful measurements, all centred at 128 now.
Other:
- Better small icon.
- Thinner DPCM address display, does not get truncated.
- Using # instead of + for note names.
- Cosmetic fixes in settings dialog.
- Keyboard frequency display correction for APU/MMC5/VRC6 (were off by 1).
- Keyboard envelope display now shows L for loop.
- N163 waveform display now hides waveform when track is muted with a wave length >= 128.
- Expanded infobox info for NSFe.
- Fixed improper loading of UI DLL, prevents crash in same folder as Famitracker.
- UI DLL now reports version, preventing potential problems if mismatched.
- LOG_CPU option for dumping register writes to file.
- Fixed song wrap where NSFs do not start on song 1.
- Source code cleanup: removing unrelated Z80 emulation code.

Just aquick question. I notice that almost all of the presets now have chip volumes all at volume=128, except the default, where the vrc7 is lower, volume=96. Is there a reason for this? Also, I remember in beta3, the n163 had different volumes for some of the presets, but now doesn't. Also, has consensus been reached as to relative volumes of expansions to each other and to the internal appu?

I clearly see this in in_yansf.ini that comes with 2.3:

The 2nd line onward are all part of PRESETxxxx sections, while the first line is part of the NSFplug section. The 2nd line is part of PRESET0000, which is also known as "Default". You'll need to go through the ini yourself by hand to see what I'm talking about. I tend to use the "NES" preset, but the point here is that each of the sections can have a different adjustable volume (for example the ones with 167 are "Bad Analog Circuit" and "TV Speaker").

There are other threads here on this forum rainwarrior is taking part in to try and figure out what the "ideal" default volume is for some chips, particularly the N163. Stuff like this takes time and lots of feedback from folks who have the time/interest/equipment. Please be patient.

VRC7 should not be default to 96 anymore. That was a mistake that I missed while editing the presets by hand. I'll fix it in the zip.

I have rewritten the balance for every chip in this version, so at the same time I made the default balance in the options "128" so it's easy to see as the default.

Also, this version marks the first time I have written tests and measured the output for all chips. Before this the balances used were done "by ear" from available recordings of existing soundtracks. Now they are based on the output of test programs instead. In some cases I've gathered a small consensus from people who have responded to my requests for recordings, but some of it is only measurements made by me on my Famicom. So far I have only had responses from original AV-modded famicoms, including my own, but where I do have multiple points of data they have been pretty consistent, so I have a moderate amount of confidence in it.

I'm sure different models of Famicom like the Twin or the AV Famicom have different tendencies, which is what the preset system is supposed to address, but the presets are really just leftover from the previous maintainer. I did not create any of them myself, and do not know if they are accurate at all.

@koitsu: Thanks for that. Yeah, I was aware of the differences in the bad analog and tv presets, but wasn't including those as I see them as more toy presets, although tv speaker could be useful I guess. As for figuring out volumes between chips, I'll gladly wait as long as it takes to be as accurate as possible, but was just wondering if things were pretty much decided now or if work's still being done.

@Rainwarrior: I suspected this was the case re, different balance of vrc7 in default preset vs everything else. I do find for a lot of older nsf's written with vrc7, that I end up turning it down, because to my ears, it sounds better. of course given that only one actual game ever used the vrc7 as far as we know... enough said.

Lagrange Point has the 2A03 attenuated a lot compared to the VRC7, and appropriately in its music the VRC7 channels are not playing at full volume. The VRC7 has logarithmic volume control, so it's actually very dynamic, so it can go quite loud relative to 2A03. The problem is that a lot of people who write NSFs just leave the VRC7 at full volume in their music instead of using a more appropriate lower setting.

Similarly, 5B can be very loud. N163 is also extremely loud if you put it in 1-channel mode, which I was surprised to see several people doing this year in Famicompo.

First, thank you for the fantastic NSF plugin. Much appreciated.

Now, possible bug. I just discovered NSFe files. Unfortunately, when I play them in NSFPlay/NSFPlug the track titles are often mismatched to the tunes.

For example, I download the Mega Man IV NSFe from http://slickproductions.org/nsfe.php. I play it and Winamp/NSFPlay reports that the first song is Bright Man, when it's clearly something else (probably the intro). The second is mislabeled Toad Man, and so on.

Also tried that site's Milon's Secret Castle NSFe. The first two tracks are labeled correctly, but it diverges from then on.

I have tried updating from Winamp 5.63 -> 5.65, NSFPlug 2.2 -> 2.3, and also using a fresh Winamp install with no other plugins. The mislabeling persists, and also occurs in NSFPlay 2.3.

Any thoughts? It would be pretty rotten luck if I just happened to download two badly ripped NSFes in a row.

Further testing from http://slickproductions.org/nsfe.php:
DuckTales seems fine.
Double Dragon II is a mess.
Castlevania II seems fine.
Batman is wrong.
Ninja Gaiden II is a mess.

I am wondering if the quality control at http://slickproductions.org/nsfe.php is just really bad. But the bottom of the page suggests that they have high standards, so I dunno what to think.

Yes, you're correct. The track title display was not using the NSFe playlist. This will be fixed in 2.4, thanks for the report.

For now, if you disable the nsfe paylist in the options, the track titles will match (but it will not use the playlist order). The track length and fade times should be correct either way, though.

Aha, I see. No problem, and thanks for the speedy reply.

Bug report: The N163 channels sound incorrect in xaimus' dendrite.

Apparently between 2.3 beta 3 and 2.3 final there was some sort of change to N163 output that causes it to fail on this particular track. To my knowledge this track is not susceptible to the ppMCK output bug described here. I believe were that bug the culprit all versions back to 2.0 would be affected. Taking a look at the Google Code changelog, I'd guess revision r96 introduced the behavior change.

I have attached the NSF in question. The original may be obtained from Famicompo Mini vol.6, Original set, entry 21. SHA-1: 22F0628C3895918638715F5C0306E8BD784C337D

Additionally, I have uploaded two videos demonstrating the difference:

NSFPlay 2.3 beta 3 Synthesia

NSFPlay 2.3 (final)

The N163 has 3 registers per channel that can be written to set the channel's 24-bit phase counter. Very few N163 emulations implement this behaviour, but it is how the hardware performs. The only other emulator that I know of which implements this correctly is NEZPlug++.

Dendrite writes all 8 bytes of each channel each frame, which unfortunately causes the phase to be reset at a rate of 60Hz. I'm not sure what engine is uses for playback, but it is broken in this regard, and will only run "correctly" on emulators which ignore this behaviour of the hardware.

Hmm, after looking at it in a debugger, unfortunately it's not a trivial patch, like the other problem which could be solved by changing a single ORA mask. This engine attempts to write all 8 bytes consecutively by using the N163's address increment on write, something which is very appropriate for uploading waveform data, but as you can hear, doesn't work out well for the channel updates.

Thanks for the prompt reply and detailed explanation.

Edit: I didn't see your 3rd paragraph when replying. Knowing that the fault lie in the NSF and not in NSFPlay 2.3 final, I am satisfied with using 2.3 beta 3 for dendrite playback. Seeing how the core is in active development and optimization has not yet been performed, a dendrite-specific patch likely isn't the best use of your time, especially since I haven't come across other NSFs with this behavior. If I do, I will post them here for reference. Cheers.

Edit2: Ah, you probably meant patching the file, not the player.

Here, I patched it.

Dendrite is actually one of my all time Famicompo favourites, so I am happy to fix it.

For reference, here is how I fixed it:

1. I found some empty non-bankswitched space at $A912, and placed the following two subroutines there:


2. Then I used these subroutines to patch the offending writes out of the player code:

Excellent. Sounds fantastic, thank you very much!

That reminds me -- there are some Famicompo tracks I've heard which sound like bad N163 emulation but can't really discern what the heck is going on, plus I don't have a point of reference/comparison. Ones to check out, if interested:

FCM8_Entries/Cover/Entry41.nsf
FCM9_Entries/Cover/Entry39.nsf

And I have not the slightest idea what's wrong with these (I'm guessing some actual sequencer/engine problem and probably not NSFPlay-related):

FCM10_Entries/Cover/Entry009.nsf
FCM10_Entries/Cover/Entry017.nsf
FCM10_Entries/Cover/Entry035.nsf (starts at about 00:11)
FCM10_Entries/Cover/Entry148.nsf

• FCM8_Entries/Cover/Entry41.nsf same issue as with dendrite
• FCM9_Entries/Cover/Entry39.nsf I don't see anything wrong with this one? This is Don't Tarry? see below for patch
• FCM10_Entries/Cover/Entry009.nsf troll PCM entry, not worth any time to troubleshoot
• FCM10_Entries/Cover/Entry017.nsf turn on "write protect" in NSFPlay FDS options
• FCM10_Entries/Cover/Entry035.nsf (starts at about 00:11) requires banskwitching but does not specify so, put 00 01 02 03 04 05 06 07 in bank section of header not sure, possible troll?
• FCM10_Entries/Cover/Entry148.nsf turn on "write protect" in NSFPlay FDS options

The write protect problem is that multi-expansion doesn't make allowances for FDS RAM and there are write conflicts from the other chips' interfaces. I made an option to write-protect it in NSFPlay 2.3, but in the next version I will default it to write protect whenever multi-expansion is used (with an option to disable).

FCM9_Entries/Cover/Entry39.nsf

Sorry, there pack is mislabeled and there were two entry 39s in the pack. Back when FCM9 happened I actually patched this one. (I believe I also notified the author of the engine used and it's been subsequently fixed)

Thanks for the patch for FCM9_Entries/Cover/Entry39.nsf. I spent time looking for this previously but came up empty.


This one's new to me. I attempted to follow the instructions but now the NSF doesn't play. According to Kevin Horton's NSF documentation, the bank section starts at 0x0070 and runs for eight bytes. Indeed, at that location there is an 8-byte string of zeros but when entering 00 01 02 03 04 05 06 07, the file no longer plays. Must another modification be made or is this not the correct location?

Thanks much for all the insights! Woot!

I didn't even know about the write-protect option 'til now. I always wondered how all the multi-expansion NSFs managed to actually avoid such conflicts -- sounds like they can't, so the programmer/composer actually has to ensure compatibility if possible. Whee...

Er, sorry, I misidentified that one. It does not require bankswitching.

I don't know what's wrong with it. Possibly it's a troll entry, actually, given the size. It doesn't actually hit any bad opcodes or anything.

Thanks. I always assumed it was a troll entry but from the song description.

For some reason, the NSF for Ai Senshi Nicol doesn't play correctly. It works fine on FCEUX and Nintendulator.

Works for me in both 2.3 and SVN (2.4 beta 1).

Ai Senshi Nicol.nsf
CRC-32: 66ecc9d6
MD4: 14ad63f377bb4c7b2a32c5bca726af7b
MD5: 24c0f5a6ffbe490c3771c9726c03614f
SHA-1: e74c715d2ad16aa265b1d4a992d8315dcbdab7d7
SHA-256: 38e0bb12285ee80d53efe596b51b0298f3d67440f312165cb5f52e0f35731645

There's an older rip of that game that relies on impossible FDS RAM mirroring. Try this one instead:
https://dl.dropboxusercontent.com/u/883356/NSF_rips/Ai Senshi Nicol (FDS)(1987)(Konam) a.nsf

More info here: http://forums.nesdev.com/viewtopic.php?f=6&t=9224&p=98299#p98299

Looks like merely changing the header bytes at 0x76 from 00 00 to 03 04 was enough to fix it. Thanks!
edit: not quite fixed, doing that still puts a bunch of noise and crap in song #4.

Are the clicks at the beginning of track 1 in this NSF supposed to be there? Or is the NSF bad? The clicks aren't present in VirtuaNSF 1062, but I don't know if that means anything. I'm using NSFPlay revision 130 (2.4 beta 1). The clicks are present for the first four seconds and sound similar to artifacts in Napster era MP3s when CD drives and ripping software lacked stable digital audio extraction and error correction. The NSF came from Zophar Domain's collection and has a stamp of February 23, 2014.

Yes, the clicks should be there. Here's proof recorded from my NES just now.

The NSF is strange. It sets both squares and the triangle to frequency 7 for a brief time before silencing, so you get a high frequency chirp. It also suffers from a non-returning PLAY function, which is kind of unusual for a ripped NSF. I would guess that in-game nothing is changing onscreen while this first track plays?

Thanks for the investigation. I found gameplay footage and you're correct: image is static while the music plays.

https://www.youtube.com/watch?v=ApiMiIPj3VU

Just FYI I created a Winamp plugin for straight-up .FTM playing. I'd been posting about it in response to this request.

It's not perfect yet, but it at least works.

For those of us [or just me?] that don't want to have to export FTMs to NSFs to listen to their playlists in Winamp.

Just a minor problem with the Winamp plugin.
In Windows 10, when you mouse over the taskbar entry for Winamp, you get a set of playback controls. Play, Pause, Stop work fine, but the Previous and Next controls do not work correctly, and instead restart the currently playing track. This is weird because the buttons in Winamp work fine, hotkeys and global hotkeys work fine, and media keys on the keyboard work fine as well.

Is that a bug report about NSFPlay's Winamp plugin, or about cpow's FTM plugin?

I don't have Win10 but in Win7 when I mouse over the taskbar icon I can use the prev/next buttons in the preview OK with the FTM Winamp Plugin. Strangely my media keys do not work.

It's about NSFPlay, not the FTM thing.

You say that like it's bad.

Anyhow, I can duplicate this. I've been wanting to adjust the winamp plugin to break the NSF out into a playlist instead of doing that weird all-in-one-track thing, but it's been low priority for a while. I'm sure I can fix the problem whenever I work on that area of things. Thanks for the report.

Yeah. Sorry about that slight hijack.

Poppin' back in. Noticed today that NSFs crash Winamp on startup if encountered in the saved playlist from last session. It seems that is addressed in the updated plugin's readme:

So yay. I see 2.4 betas mentioned here and elsewhere but can't find a compiled download. Are there builds anywhere, perhaps automated?

Ah, great. That'd be much-improved functionality. I hope it will also be possible to specify / play specific NSFE tracks in playlists / via command line.

Thanks for your continued development efforts!

No automated build, and it's not in open beta, but if you've got a bug or something you'd like to test feel free to contact me.

I have a really dumb question...
I'm using the Winamp plugin, how do I make it louder? I know you can make anything louder by using the EQ settings, but nes music is too quiet relative to other songs.

There are several places for volume, depending on what you want:

1. Windows' mixer volume (duh)
2. If Vista or newer: the per-application mixer volume (duh)
3. Main Winamp volume slider (duh)

And in the NSFplug (Winamp plugin) window:

4. View -> Device Mixer (alternately you can use Options -> Easy Setup to control the master volume)
5. View -> Channel Mixer

To get to the aforementioned window, just double-click on the song title/track name (or press Alt+3) (this is a Winamp thing)

Settings are saved to an .ini file in your_Winamp_installation_directory\Plugins\in_yansf.ini

Do you have plans to keep Winamp plugin after you go cross-platform? Because it would be hard to make improvements of I can't compile the whole thing.

I noticed a lot of DC in the waveform, and that interferes with volume controls. The lowpass settings do nothing to get rid of the DC. The DC goes way up when using DMC and expansion sound (Gimmick!), it even clips sometimes without increasing any volume controls.

Yes, but the Winamp plugin will be separated from the rest of the code, merely using it as a library. It should not be in conflict with an code that it cross platform. (Individual plugins for Winamp, Foobar, etc. will all be separate and only for their target platforms.)


I've not seen that happen before, could you PM me with a copy of your settings (inyansf.ini) and link to an NSF that can demonstrate?

If you disable the lowpass highpass filter (i.e. set it to "0") there should be an evident DC bias, but it shouldn't beoing "way up" or have anything to do with expansion sound... possibly you've triggered a bug I haven't seen in the experimental "anti-click" option?

Er, what? Do you mean "highpass" filter? Because a lowpass filter would always let a DC bias pass through it, and a highpass would block it, whatever the corner frequency.

Yes, I meant highpass, though hopefully Dwedit also meant highpass. ??

You're right and I'm an idiot.
Setting highpass to one above 0 eliminated the DC.

Hey how can I force specific region via C++? All NSFs I open are played in NTSC but I want PAL or Dendy.

In the UI the "Region" setting is a dropdown list near the bottom of the "General" tab.

In the .ini file the setting is called "REGION", consult nsfplay.txt for a list of values.

OK, thanks.

How can I make the infinite playtime?

I don't think there's a setting for "infinite", but you can set the play time very high, which is practically the same thing?

Edit: The UI seems to give it a limit of 32767 seconds (about 9 hours). Is that "infinite" enough?

If the time is set to 0, does it not play at all? ;P That could be infinite looping.

A time of 0 is treated as such.

za909's extremely small 390 byte NSF based on pseudo-random patterns does not work with NSFPlay, but works in other players.

1. What does "other players" mean?
2. Does it run on a PowerPak?
3. Why does it enable NMI by writing $80 to $2000 during INIT?
4. Is there source code?

Hrm... Works on NSFLive and FCE Ultra. Does not work on VirtuaNSF or Nintendulator either.

I NOP'd the NMI with $2000 code and it still doesn't work in NSFPlay, but continues to work in the above two.

viewtopic.php?f=6&t=16061

This is the bank setup:
Bank :[00][00][00][00][00][00][00][f9]

F9 should be a 00. The contents of bank F9 are "undefined" since the file has no such bank.

Fixing that will get it to run, but it should also get rid of the STA $2000 since NMI will almost certainly cause PowerPak and any player with a PPU to fail in some way.

OK; wow. Yeah, that was easy. Thanks.