NSFPlay 2.2 has been released! Get it here:
http://nsfplay.googlecode.com/files/nsfplay22.zipThe most significant update is NSFe support, but there's a bunch of other minor changes.
NSFPlay 2.2 - 8/31/2012
Audio Emulation:
- Unmute on reset now sets $4015 to $0F instead of $1F.
- PAL noise frequency $1 now 8 instead of incorrectly 7.
- New VRC7 patch set, option to select alternative patch sets via VRC7_PATCH.
- 5B polarity inverted, envelope adjusted, volume tweak.
- MMC5 polarity inverted, length counter runs at double speed, highest 8 frequencies are not muted.
- VRC6 $9003 register implemented (controls halt and frequency multiplier)
- VRC6 polarity inverted, phase reset now functions properly.
- FDS now uses NSF header $76/$77 to set up $6000-7FFF memory range.
- FDS $4087 bit 7 now mutes modulator.
- Enable periodic noise option fixed. (Forced perodic noise by accident.)
Other:
- Fixed improper $4015 read implementation (should return length counter status), also DPCM IRQ was not initialized.
- Default focus in keyboard window now the track list (to prevent accidental mouse scroll time expansion).
- Fixed Winamp visualizer timing inaccuracy, changed default keyboard delay/freq.
- Inverted VRC7 volume display in keyboard view.
- NSFe support.
- Added NSFe extension block 'text', contains null terminated string of any length (NSF text).
- Removed broken ENABLE_DCF config option. HPF=256 now correctly disables HPF.
- Rewrote LPF and HPF, should have a more usable range of options now.
- Removed XXX_FR/XXX_FC options, now XXX_FILTER works like LPF for each device.
- Memory R/W access is now exclusive to the first device that accepts it; prevents FDS multi-expansion write conflicts.
- Title string will automatically remove whitespace at its beginning or end.
- Fixed single instance bug, was failing to open new NSF file when chosen from explorer.
- Fixed conflicts between keyboard commands and other dialogs.
- Removed tag menu from info page. Does not appear to apply to NSFs.
- Fixed incorrect PAL pitch when QUALITY=0.
NSFPlay 2.1 - 3/27/2012
Audio Output:
- Fixed race condition in audio buffering; stand alone NSFPlay would occasionally get stuck stuttering.
- Produces stereo output, channel mixer dialog for panning and per-channel volume control.
- Fixed PCM playback speed; CPU execution was counting requested clocks, not clocks executed.
- Fixed accuracy of seek times.
- Loop detection now accounts for all audio registers, not just a subset of 2A03 and N163.
- N163 wavelength is actually 6-bit, not 3. Now allows sample length up to 256.
- Fixed FDS volume/sweep envelope caps. (Direct register writes can make them louder.)
- Fixed FDS modulation bias calculation and wrapping.
- Set default volume for VRC7 and FDS a little lower (to match expected levels).
- MMC5 PCM support (for both read and write mode).
- Added phase reset option to MMC5.
- MMC5 was missing length counter and audio register reads; rewrote to conform with APU.
- Adjusted phases for APU/MMC5 square channels to match NesDev's description.
- APU/DMC/MMC5 rewrite of envelope/length/sweep behaviour to use a frame sequencer instead of independent timers.
Options:
- Option to randomize noise on reset (on by default).
- Options cleanup, removed unused/deprecated options from .ini file.
- Using global LPF by default instead of on each device (saves CPU, same result).
- Keyboard view channel colour is now customizable in .ini file (CHANNEL_XX_COL).
Keyboard view:
- Fixed crash due to keyboard OnTimer being allowed before Reset() is executed by the PlayThread.
- Double buffering keyboard view to remove flicker.
- Different colours for different expansions in keyboard view.
- Fixed sound lag after seek.
- FME-7 now named 5B, N106 now named N163.
- DPCM now named DMC in keyboard view.
- Fixed 5B volume display (E now correctly indicates envelope, volume is now correct value).
- 5B now displays envelope and noise.
- VRC6 saw volume now displays accumulator register.
- Corrected VRC6 saw pitch in keyboard view.
- Fixed trailing lines on N163 waveform display.
- DMC volume display no longer flipped (is now $4011 register value).
- DMC now shows sample frequency rather than byte frequency.
- Triangle and noise were not showing muting due to length counter of 0.
- Noise now has frequency display (either rate of random samples, or tonal frequency for periodic noise).
- Removed feature that extends the life of key dots beyond the frame the channel is active (frequency can change when key is silent, esp. VRC6 squares, which visibly jump to the wrong pitch)
Other:
- Save WAV button on NSFPlay.
- Command line WAV output for batch processing.
- Added extra NSF header information to "misc" text box, initial banks, load/init/play addresses, etc.
- Fixed thread-safety issue for configuration (was accessed liberally from many threads).
- Removed legacy code for windows versions older than XP.
NSFPlay 2.0 - 2/22/2012
- Restructured sln/vcproj files, and rebuilt for VS9.
- All intermediate files go into common Debug/Release directories.
- Renamed wa2nsf project to in_yansf to match name of the plugin.
- Fixed improperly set WAVEFORMATEX header in libemuwa2 (allows execution on windows Vista/7).
- Corrected pitch of noise channel.
- Updated VRC7 default patch set.
- Added PAL support and pal flags indicator (PREFER_PAL=1 to prefer PAL for dual mode).
- Added about box for determining build version.
- Fixed some menu items in English dialogs.
- Fixed some initial config settings.
- Fixed crash when using playlist menu options with no loaded NSF.
NSFPlay - 12/09/2006
- Written by Brezza >
http://www.pokipoki.org/dsa/index.php?NSFplayProject homepage:
http://rainwarrior.ca/projects/nsfplay/
Something I should have mentioned during NSFPlay 2.1 and so on -- it completely escaped me, and I apologise for that. Referring to the Winamp plugin portion only. Two bugs or oddities, and both apply only when playing a **single NSF file** (e.g. the playlist consists of only one NSF file).
When playing a single NSF file, the Forward and Back buttons in Winamp are supposed to move forward/back indices within a song (meaning like the >> and << buttons inside of the NSFPlug UI natively). And for the most part they do that. Except...
1. Load Predator NSF; first song that plays is song #8 (of 9 total). In the Winamp UI, clicking the forward button; the next song played is song #9. Press the forward button again and the song goes to #8 again.
Compare that to the NSFplug UI, where once you're at the final song, clicking >> stays at the last song.
I think what's going on is that inside of the Winamp UI, when pressing forward when the last track is played, the plugin chooses to start the entire NSF over (in other words, per the NSF header, start playing again from song #8).
Now the other oddity, which is almost certainly similar or related:
2. Load the Predator NSF; song #8 will play automatically. Click Back in the Winamp UI until you get to, say, song #3. Now press Forward in the Winamp UI. The song played is song #8.
Compare this to the NSFplug UI (within Winamp), where the >> and << buttons do what's intuitive (go forwards or backwards a song until song #1 or {last song #} and stay there).
And now for something sorta related, but pertains to when **multiple** NSF files are in the playlist:
3. Load two NSFs into the playlist and start one. Click forward in the Winamp UI. It picks the next NSF file and starts playing from there. Click forward again and it goes to the next song within that NSF. Click back and it goes back to the previous NSF file in the playlist.
So, basically what I'm saying is that the Winamp UI forward/back button behaviour is very... unintuitive... depending on if you have a single NSF selected or multiple NSFs selected.
The behaviour, in my opinion, should be this:
1) If only a single NSF is in the playlist, the forward/back buttons in the Winamp UI should behave exactly like the forward/back buttons in the NSFplug UI.
2) If multiple NSFs are in the playlist, the forward/back buttons in the Winamp UI should control which NSF is being played and not control which song is being played (meaning the user will need to double-click and bring up the NSFplug UI to control songs).
I'm pretty sure I went through this ordeal (or something similar to it) with Disch with NotsoFatso long ago. Winamp's UI for multi-song-within-a-single-file makes things a little tricky depending on what the user wants. I think NotsoFatso had an actual checkbox setting to adjust the behaviour of Item (2) above.
As usual, I'm happy to test improvements/behaviour/alpha-beta-gamma builds/etc.. :-)
I don't know of Winamp much, but I do have one possible idea: If playing using Winamp, put each track in the playlist separately. Perhaps this can avoid the problems they have?
zzo38: there's actually support for M3U playlists which break it down to one track per playlist entry (see nsfplay.txt), and if you just want to generate a default playlist with all tracks, there's a menu option:
File > Winamp Playlist > New
Koitsu, thanks for the example with the Predator NSF. I had sort of noticed that problem before but it always seemed to go away; I guess I hadn't been trying the right NSFs. I'll try and get that to a more intuitive state.
Can we get the playlist generation to trigger automatically as soon as a file is loaded or added to the playlist? This is a feature I've always wanted to see in an NSF player.
That's an interesting idea. That might solve all the problems pretty simply.
I actually haven't spent very much time learning how the Winamp API and the part of NSFPlug that interacts with it works, yet. It's mostly the same as it was in the older version when I picked it up.
This is an early beta of the next version, just to support the Deflemask IRQ hack:
nsfplay23b0.zip (dropbox link removed, latest release version of NSFPlay supports Deflemask)
Also something I found (super easy to fix): the text dialog area used for the "Use NFSe Playlist" checkbox in the NSFplug GUI is too long (horizontally) and cuts into the border region. It looks to me it needs to be shortened by about 8-9 pixels. Screenshot attached showing the issue.
Hmm, interestingly the VS 2008 form designer snaps it to the frame which puts it precisely 2 pixel too far over. How odd, why would you want to snap to that? Anyhow, fixed in the source now.
Just an FYI, the STREEMERZ NSF doesn't work (
viewtopic.php?p=102982#p102982).
Also I'm not sure how the "Prefer PAL for DUAL mode NSFs" setting works, but I think you should by default prefer whatever mode is set in the NSF (since the dual mode is indicated by a separate bit).
Well, I actually spent some though on that idea before, but at the time I decided it wasn't worth it.
The primary purpose of having a dual-mode NSF is so that the preferred mode can be selected by the user (and that's what the setting does in NSFPlay). The other bit is mostly irrelevant; if it supports both the choice is up to the user, not the author of the NSF. In many situations only one of the two options is available, so the choice is automatically made. In this software situation, both are supported. That's really what the dual-mode is for. I consider the extra bit in the dual mode situation as just a consequence of using a binary system to represent 3 options, but being left over yes it COULD be interpreted as a preference bit. I think this is in the same boat as multi-expansions as something that wasn't really intended, but doesn't seem to break the spec so why not.
The alternative is to give the user three options: use NTSC, use PAL, use based on the 0 bit. At the time I implemented it as a checkbox I didn't think a third option was a good idea for two main reasons: 1. There were zero dual-mode NSFs that set that bit anyway, so it would have been a purely academic exercise at that time giving the user an option that does noting (I hate having UI that does nothing). 2. There are zero NSF players that treat it that way, and it actually causes problems for some NSF players if that bit is set in dual mode (I can't remember which, maybe NotSoFatso), so as an NSF author it's not a good thing to do if your goal is reliable playback.
So... now that you've actually created the first NSF that can do dual mode but really does prefer PAL, I'll consider doing it again.
As for the emulation problems... I'm not really looking forward to supporting that (but I will try). I haven't actually had to touch NSFPlay's 6502 emulation code yet. This is another first (NSF that relies on an illegal opcode). Is there any thorough documentation of the illegal opcodes somewhere that you can recommend?
Another thing that isn't supported in NSFPlay 2.2 is the full use of the frame sequencer ($4017). This was another thing that there were no NSFs to test against, so I guess it had never been implemented. Deflemask finally found an unusual technique that exposed it (preventing the IRQ but polling the interrupt flag to insert 60hz timed playback into a PCM stream). If you've got tests you'd like to throw at it, here's a build of my latest code that should support everything the frame sequencer is supposed to do:
( nsfplay23b1.zip dropbox link removed )
rainwarrior wrote:
Is there any thorough documentation of the illegal opcodes somewhere that you can recommend?
Our own wiki has pages on
what the unofficial opcodes are and
how to use them, and those pages link to other useful references.
I'm aware of both of those two pages, but honestly neither of them seems a thorough reference. Good enough for an assembly programmer trying to use them, not really specific enough for an emulator programmer. This is why I asked for a recommendation if there's a better doc out there.
(I'm sure they're good enough to support whatever TheFox did specifically, but I'd rather not have to revisit this later if someone uses some other opcode I neglected.)
rainwarrior wrote:
Well, I actually spent some though on that idea before, but at the time I decided it wasn't worth it.
...
Yeah I wouldn't hold it against you if you didn't support that, it just would make sense IMO, even though spec doesn't really say anything about it. I'm surprised to hear that some players barf if both the PAL and Dual bit are set, though.
Quote:
As for the emulation problems... I'm not really looking forward to supporting that (but I will try). I haven't actually had to touch NSFPlay's 6502 emulation code yet. This is another first (NSF that relies on an illegal opcode). Is there any thorough documentation of the illegal opcodes somewhere that you can recommend?
For a quick reference
http://www.oxyron.de/html/opcodes02.html (that's also where CA65 gets its mnemonics, and I think
http://www.cc65.org/snapshot-doc/ca65-4.html#ss4.3 is probably a good reference on what opcodes may be worth implementing).
As for HOW to implement them, honestly, Nintendulator source is probably the easiest source.
Unfortunately for you, I guess, the NSF does use blargg's sweep trick to set the high byte of period, so it does somewhat depend on the frame sequencer too.
thefox wrote:
Unfortunately for you, I guess, the NSF does use blargg's sweep trick to set the high byte of period, so it does somewhat depend on the frame sequencer too.
That's actually fortunate! That's something that should actually work with the latest code, so it'll be a good test.
Here is 3 files:
http://www.fileden.com/files/2012/4/10/ ... silius.rar1) Journey to Silius NTSC NSF ("Original")
2) Original with $6E-$6F Patched
3) Original with PAL-flag in NSF header:
Code:
offset # of bytes Function
-----------------------------------------------------------------------------------
007a 1 BYTE PAL/NTSC bits:
bit 0: if clear, this is an NTSC tune
bit 0: if set, this is a PAL tune
bit 1: if set, this is a dual PAL/NTSC tune
bits 2-7: not used. they *must* be 0
-----------------------------------------------------------------------------------
- PAL-flag patch has incorrect DPCM-pitch on 50 FPS.
- $6E-$6F patch is OK.
Rainwarrior, can you add "$6E-$6F patch" to NSFplay please?
It allows to play standard NTSC NSFs on 50Hz with correct pitch (dendy-style).
However the real Dendy has a little lower pitch than NTSC NES, since it CPU clock are 1.7734475 MHz (NTSC has 1.7897727 MHz). But you can neglect this fact.
A dendy mode is on my to-do list.
I have seen a thread about incorrect duties on the square channel. Is this a thing that dendy hardware does, or related clones? What happens exactly?
Quote:
Is this a thing that dendy hardware does, or related clones?
"Dendy" is only a brand. Chips were different (1990-1997).
UA6527P and
HA6527P chips have this bug. 25% and 50% duty cycles are swapped (on both square channels).
You can listen it on
puNES 0.69WIP
Here is a test program and recordings (8MB) that were made with 6 different chips.
Some pure-NTSC clones also has this bug: UA6527 (without "P") is the 2A03 NTSC clone.
DWEdit wrote:
00 = 12.5% on both
01 = 25% (or 50% on buggy clones)
10 = 50% (or 25% on buggy clones)
11 = 75% on both
TA6527P (aka TA-03NP1) and NOACs, like
UM6561 doesn't have this bug.
Most of famiclones that were assembled after 1992-1993 doesn't have this bug.
Okay, thanks for the info. I plan to add to settings:
1. Option to force Dendy mode (changes CPU speed, forces 50hz play)
2. Option to flip duties.
I have one more question though, what about duty mode 3?
* duty 0 (12.5%) -> same
* duty 1 (25.0%) -> now 50%
* duty 2 (50.0%) -> now 25%
* duty 3 (75.0%) -> now 50% ? reverse 50% ?
Same, 75%. Have you listen chip recordings on test rom?
NSFPlay 2.3 beta 2: -- removed link --
This should now support all stable illegal opcodes, and handles the "sweep trick" just fine, I think, so streemerz.nsf is now functional. Lemme know if you spot any other problems with it.
Some UI behaviour I found that's strange (at least for the Winamp plugin bit) -- this probably has existed for a while and isn't specific to 2.3 beta 2, just FYI:
1. Open Winamp, open an NSF
2. Double-click the song title area in the main Winamp window (to bring up the NSFplug UI)
3. Select a different song index number (e.g. song 3, song 6, whatever)
4. Double-click on the song title area in the main Winamp window again
5. Song index slider in NSFplug UI immediately jumps to song 1
The problem from what I can tell is that whenever the code for bringing up the UI window is run (whether the window is open or not), it always sets the song index slider position to 1. This one shouldn't be too hard to fix... I hope... :-)
Thanks. Added to my to-do list.
I gave this a try, expecting to be unimpressed with audio (only because most retro audio emulation doesn't impress me). But it sounds good through headphones with some demanding tunes. It also worked without a hitch in Wine on Linux. Lots of options for altering soud too. Only thing that stood out is that it used around 15% CPU on a 1.8 GHz Core 2 Duo (where 100% is both cores fully occupied).
Thanks!
Yes, the default settings go for quality over performance, though you can change this in the options (each audio unit has a separate performance slider; I intend to replace this with a single control eventually). Aside from the noise channel, most things sound OK at lower performance (just with a bit stronger aliasing, generally).
I do plan to do a performance optimization pass eventually, especially on how oversampling is done, but it's been less of a priority. I'm more interested in getting correct emulation first, but also as I said you can sacrifice accuracy for performance in the options.
Also, right now the FDS specifically is currently in the middle of a complete rewrite, and the state it's in for this beta is a lot more performance intensive that it should be (will be fixed by the time 2.3 is ready for release).
Correctness over performance, music to my ears! It runs real-time on any machine made in the last 8 years or so. Sorry, I still need to work on being overly concerned with performance when it's already sufficient.
blargg wrote:
Correctness over performance, music to my ears! It runs real-time on any machine made in the last 8 years or so. Sorry, I still need to work on being overly concerned with performance when it's already sufficient.
Any machine, or specifically any PC? Just as severe compromises were needed to run emulators on the GBA and DS, some compromise is needed nowadays for Android devices. But I agree that pursuing correctness first allows better results once it comes time to trim down the design for handhelds, just as PocketNES benefited from having been based on LoopyNES and not its competitors at the time (iNES and Nesticle). Besides, even on a PC, a music player is expected to use single digit percent of the CPU because the user expects to have cycles left to do other things while it is running in the background.
tepples wrote:
Any machine, or specifically any PC?
It works fine (somewhere around 50% CPU) on my still-being-used Athlon-1333 desktop with a single expansion audio. Multi-expansion of course is too demanding.
The actual problem for a port to Android is battery, not cpu speed.
Android's battery life isn't dependent on CPU usage of what's running? Does Android just not have any music players for any format?
Sorry, I stated that badly. What I meant was: The problem is not the CPU speed in an Android device (although it may be), but rather that a CPU-intensive process is going to suck the battery dry very quickly
Loop count does not seem to work for me in winamp. I have set it to 8 and all tunes still seem to fade after 2 loops. This happens on 2.2 and the 2.3b
EDIT: 2.3b seems to have it work on Bubble Bobble 2 NSF, time is not right in the playlist but the song continues to play after end has reached (and timer goes into positive, when winamp has countdown display mode).
Power Blade 2 is completely messed up on 2.3b, I am häppy that my amp wos not turned up any higher... haha
.....aaaand i have been loading playlist files in winamp all this time.... PowerBlade2 is still completely messed up
Can you paste a nonworking playlist entry for me? The way the loop logic works is kinda weird, I'm wondering if there's a bug or I just need to document it better. It should work like this:
filename::NSF,[song],[title],[time],[loop],[fade],[loopcount]
[time] = length of intro + one complete loop
[loop] = length of loop (or if it ends with a -, start time of loop. if using - the [time] parameter must be filled)
[loopcount] = number of times to loop
Note the if your [time] and [loop] aren't set to match the song the loopcount isn't going to help. (I personally find it easier to leave loop and loopcount as default and just set the time for the length I want.)
Can you attach or link to the Power Blade 2 NSF that isn't working for you? I can find 3 rips of it and they all work fine (though one of them has VRC6 and VRC7 enabled for some reason).
Messed up sound :
http://www.tmeeco.eu/BitShit/Power%20Blade%202%20%5BCaptain%20Saver%5D%20(1992-09-29)(Natsume)(Taito).nsfPlays (but sounds like something is missing, maybe JP is like that...?)
http://www.tmeeco.eu/BitShit/Power%20Blade%202%20JP%20%5BCaptain%20Saver%5D%20(1992-09-29)(Natsume)(Taito).nsfThe time setting seems to take priority when I play NSF directly, I got a nice 10 minute playtime and it is good enough for me.
Hmm, both of those are playing fine for me in NSFPlay 2.3 beta 2. Can anyone else duplicate the problem?
This is what I am getting in Winamp (~1MB file)
http://www.tmeeco.eu/BitShit/Power%20Blade%202.wavThe standalone player has no problems though.
Could Winamp version make a difference ? I got 5.35 installed.
Hmm, I've got 5.63... the version shouldn't make a difference (in theory), since the plugin is a Winamp 2 plugin.
That's pretty weird though. I'm not having any problem playing that file in Winamp with NSFPlug. I'm not sure what to suggest.
TmEE wrote:
Both NSFs play fine for me using Winamp 5.63 on Windows XP + NSFPlay 2.3b2. I don't experience what you do
here. If you want me to make a video of what I experience just let me know.
Have you tried deleting your in_yansf.ini from your Plugins directory and using the one included with 2.3b2? This might explain your looping oddities/behaviour/etc. too, but I'm not sure.
If you roll back to a previous NSFPlay release (and if so which one), does the problem go away?
The sound difference you hear between the two versions is that the strong bass/drum line is missing in the "JP" version. To me, that would indicate whoever did the ripping probably didn't do the right thing (some APU registers not being initialised correctly, etc.); AFAIK the two versions have the exact same music.
Edit: With regards to the sound difference between the two NSFs -- it's related to the DMC channel (which is used for the drum/bass line). Someone either ripped the NSF wrong or is initialising some APU registers wrong.
Found another bug pertaining to the visualiser/vu metres/etc., rainwarrior. Try using a sample rate that's lower than 44100Hz (try 8000Hz) under Playback / Sample Rate -- the metres are "ahead" of the actual audio playback by quite a lot. The buffer/delta gets smaller and smaller the closer to 44kHz you get.
I just tried 2.2 and it plays nicely, no problems.
And now I copied over 2.3 in its entirety and seems there is no problem anymore.
I cannot remember if I overwrote the settings file last time or not... maybe not then ?
Bottomline is things work now ^^
koitsu wrote:
Found another bug pertaining to the visualiser/vu metres/etc., rainwarrior. Try using a sample rate that's lower than 44100Hz (try 8000Hz) under Playback / Sample Rate -- the metres are "ahead" of the actual audio playback by quite a lot. The buffer/delta gets smaller and smaller the closer to 44kHz you get.
Hmm, well the delay for the keyboard view is configurable (click the "Settings..." button). I've tried to tune the default for 44.1kHz on my own setup, but I am not confident that audio latency will be consistent from user to user even if they use the same samplerate as me. I could try to make the delay setting proportional to samplerate, though that might make it confusing (what unit would I use? right now it says ms, which I think is clear), so I'm not sure it would be worthwhile to do that.
rainwarrior wrote:
koitsu wrote:
Found another bug pertaining to the visualiser/vu metres/etc., rainwarrior. Try using a sample rate that's lower than 44100Hz (try 8000Hz) under Playback / Sample Rate -- the metres are "ahead" of the actual audio playback by quite a lot. The buffer/delta gets smaller and smaller the closer to 44kHz you get.
Hmm, well the delay for the keyboard view is configurable (click the "Settings..." button). I've tried to tune the default for 44.1kHz on my own setup, but I am not confident that audio latency will be consistent from user to user even if they use the same samplerate as me. I could try to make the delay setting proportional to samplerate, though that might make it confusing (what unit would I use? right now it says ms, which I think is clear), so I'm not sure it would be worthwhile to do that.
Hm, maybe I wasn't clear in my explanation -- by visualiser/vu metres I'm referring to Winamp's. It's labelled "spectrum analyser". We had a conversation about this problem before, where the issue turned out to be due to the sample size being fed to Winamp was too big so it resulted in a delay between the spectrum analyser results and what you actually hear. What I'm saying is that this problem (the effect itself) happens if you use a sample rate in NSFPlug that's lower than 44kHz.
Question: why is there an intentional delay (referring to the Delay setting under Keyboard) of any sort to begin with? What purpose does this have?
I guess it's sort of a cheap audio-video manual syncing facility.
Yeah, it compensates for the audio latency. Ideally I would use something like waveOutGetPosition and synchronize, but since it's a winamp plugin, the plugin doesn't have any direct access to the audio system (it just fills a buffer on demand).
As for Winamp's visualizer being out of synch at other samplerates, I have no idea what to do about that. The last time the fix was to make sure the buffer length was 576 samples, which Winamp likes best for historical reasons or something. I dunno what to do if it isn't synched at other samplerates...
Found another bug in NSFPlay 2.3 I believe... If you download the newest Famicompo archive, there is a song that is all DPCM in the originals section. NSFPlay doesn't detect it playing anything and fades out after only a few seconds. Since I'm at work, I remember it being about a man saying "I'm hungry..." and him eating various things.
That's not really a bug, there is a setting that stops a track after 3 seconds of silence. You can turn it off, or adjust the silence length, or use a playlist.
If it was set to stop after say 20 seconds of silence, would that cause 20 seconds of audible silence at the end of tracks, or can NSFPlay run ahead internally, notice the long silence, and stop the track only a couple of seconds of actual played silence?
Eh, I don't think that kind of look-ahead is really worth implementing. I don't want to get too fiddly over a fairly innocuous edge case. This is a problem that affects a very small number of NSFs, and there's already a number of solutions available.
1. Turn off the feature.
2. Make the silence length long enough to cover this track.
3. Make an NSFe version with track times.
4. Make an M3U playlist via winamp. (Eventually I want to implement playlist support in the NSFPlay standalone as well.)
I could set the default to 5 seconds, which would immediately eliminate probably 90% of cases where this is happening.
What kind of buffering strategy is used ? It does not take a lot to cause lot of gaps in the sound on my laptop with a 1.6GHz single core Athlon. Scrolling windows and loading web pages usually causes some hiccuping, sometimes a lot.
On my 3GHz P4 desktop these hiccups happen less often.
If you run it in Winamp it'll be buffered by however winamp is set up, and you can customize winamp's buffering, I believe.
I guess the stand alone version never had any options, though I believe it's relatively deep. Lemme check... looks like 32 blocks of 4096 bytes, so... I guess that's about 3/4 second under normal circumstances? I haven't adjusted it since I took over the project, I'm not sure if it needs to be any longer.
The bigger problem is probably CPU usage. If you're getting a lot of skipping, your computer just isn't keeping up with the audio generation. A deeper buffer probably won't help, it'll just take slightly longer to kick in. I'd actually recommend going to the chip settings pages and turning down the quality on each of them from the maximum to one under the maximum, and see if that helps instead. Alternatively you can bump the thread priority in the task manager so it gets a bigger time slice.
Another option is to use the program to render MP3s, maybe, since they're a bit less CPU-demanding to play back. This is a bit inconvenient, and trades space for size, obviously.
Also, turning off stereo sound will double the buffer length (timewise), so you can try that too.
I would also suggest trying setting the priority class in Winamp from Normal to High, just to see if that gives the timeslice sharing algorithm in the OS enough of a bump that it keeps the buffer from maxing out.
If your single-core 1.6GHz Athlon is backed by a video chip that has little-to-no hardware acceleration, then rendering and scrolling web pages, etc. is going to heavily CPU-bound. There's also the audio chip aspect too, where it's highly possible mixing is done CPU-side (i.e. in the driver, with no hardware offloading). And all this begins to hurt even more if you're using something like Windows 7.
Honestly what you (TmEE) should be doing is busting out something like perfmon and trying to figure out what is truly taking up all of your CPU time during these types of situations. Or if there's a way to profile NSFPlay/NSFPlug that would be even more ideal. But let's be at least somewhat reasonable here -- things like the Athlon 2650E just aren't going to get attention. 512KB L2 cache, 15W TDP? The intended goal of that CPU is purely something like a palmtop or bare-bones netbook (e.g. today's mobile phones have more capability than this). I'm not saying optimising things for lower-class CPUs should be ignored -- far from it! -- but someone with that hardware will need to step up to the plate to figure out where all the time is going.
Or just turn down the quality settings!
Lowering the settings did help but not too much. Same problems happen on the standalone player too.
Old NSFplug never had problems (but I guess it was not so accurate either).
As for CPU use, Winamp seems to use up some 10% and overall CPU use rarely maxes out. But seems increasing priority fixed the hiccups. Last time I had to adjust priority was when I was still on a Pentium1... haha
Hmm, that's unfortunate. Well, other than the currently sorta-broken state the FDS is in for the beta 2.3 (I am currently rewriting it), performance shouldn't be significantly worse than older NSFPlay versions. As I said though, I am definitely planning a performance pass eventually, just not a priority until I have done more work on accuracy.
How does the detect loop feature work?
I can see the player updating the times for subsongs while playing, but it doesn't seem to be saving that even with the 'Save the playtime when detected' option enabled.
Would it be possible to use this for an auto-timing tool? Something similar to gsfopt tool I've been using as a helper with timing GBS files for portable music history.
I'd love to start console music history site as well, and timing 1500+ NSF sets by hand is not something I'm looking forward to very much.
It can't save times back to the NSF because the NSF doesn't have anywhere to put times. I -think- it might save times back to a winamp playlist if you're using one, but I haven't really looked into what the save playtimes features does in detail yet. (Eventually I want NSFPlay to have its own playlist window, but that'll be a future improvement.)
The loop detector basically works by keeping a log of registers written each frame. When it finds a sequence of frames that matches a previous sequence, it thinks that's a loop. I think it needs a little tweaking still, but it won't get that much better than it already is. There is also a silence detector which stops the track when a specified amount of silence is found.
As you may have noticed, there are occasional false positives. A section of music that repeats verbatim will be considered a loop if new material doesn't follow soon enough after. A section of silence too long will be considered the end of track by the silence detector. False negatives also occur frequently enough.
I don't think the loop detector is good enough to use it for automated conversion anyway. You'll have way too many tracks you need to go back and fix the length on. If you want to do it properly you really do need to verify this by hand.
When I eventually get around to creating a playlist tool for NSFPlay, it should be able to save that playlist with the NSF as an NSFe. I will not be working on this for a while though. Currently I think only NotSoFatso has an NSFe playlist editor.
When I wrote a loop detector, I found some music that used fractional frame timing, so that on successive loops the writes might be one frame earlier or later than the previous loop, due to rounding. E.g. if it updated every 1.5 frames, you'd have 1-23-45-67..., and on second loop you might have 12-34-56-7...
If you want a test case of what blargg is talking about,
this NSF uses fractional frame timing. Tempos are specified in rows per minute, and the NTSC replayer assumes 3606 frames per minute because I'm anal.
Yep, I've seen that too, it's one of the cases that I file under false negatives. The output may be extremely similar, and probably is conceptually a "loop" to its engine at a high level, but I don't think I'd want to automatically detect such a thing as a loop. I think false positives are a worse problem than false negatives, so I'd rather be a little more restrictive about it.
There's so many edge cases to loop detection. There's also things like, say a channel is muted the first time through, and then the first "loop" it gets turned on with $4015, after that one write the rest of the data will look like an exact loop. Even just patterns that are very subtly different, like one note at the beginning of a phrase of slow music that makes all the difference (but it otherwise identical data), especially for things like VRC7 where the engine doesn't tend to touch the registers every frame.
I think the right idea for dealing with loop detection problems is to put track lengths in the data (e.g. make NSFe files). From my perspective the problem isn't the loop detector, it's the lack of widespread support for NSFe and good tools for making them.
Edit: tepples, yeah I don't really need a test case. It's not a problem I intend to solve.
More NSFPlay GUI stuff (at least in the Winamp config bits):
The up/down arrows under Options/Settings for adjusting default number of loops, stop song after X seconds of silence, and playtime detection size, are inverted in operation -- clicking Up decrements the number, while clicking Down increments it.
Some option they seem not to have, I suggest to have:
- Character encoding for NSF titles (auto-detect, Latin-1 single-bytes, UTF-8, Japanese, etc)
- For each expansion, set polarity inverted on/off
- RAM address for song stop detect
- MMC5 emulation of 2A03 features on/off
- Playback rate in header use on/off (actually, I think it might already have this)
- Set value of A, X, Y register to any number 0-255
- VRC7 delay between register write
- Expansion register mirroring on/off
- Unofficial opcodes on/off
- NSFe chunk for VRC7 patch
- Triangle phase reset (at initialization) on/off
- APU test mode on/off
- Wasted clock cycles to call play routine
- FDS write conflicts on/off
- Direct register view
- Reverb
- Switch zero-based/one-based track numbers display
- Switch track number display decimal/hexadecimal
- Trim spaces on/off
- Fast-forward until value at specified RAM address changes
- Initial delay setting
- Make command-line mode (convert to WAV and so on) to be cross-platform instead of Windows only
- Warning/errors display
- Time units switch between seconds/milliseconds/frames
- Make command-line options to be named options
- Preset to switch filter to RF Famicom or AV Famicom (does it already have this?)
- Override the header, to play NTSC or PAL regardless of what is available
- Override blank titles and "<?>" titles on/off
- Command-line option to output to Csound score files
- Command-line option display various information: ROM used, RAM used, NSF header texts, expansions used, possible conflicts with NSF specification, loop detection, etc
[*]Character encoding for NSF titles (auto-detect, Latin-1 single-bytes, UTF-8, Japanese, etc)
I don't know how to do this with the current UI. Eventually I think I will replace the entire UI so that I can build a cross-platform NSFPlay, but until then this is not something I plan to look into.
[*]For each expansion, set polarity inverted on/off
Planned per-channel invert / stereo-invert for the next version, not yet implemented.
[*]RAM address for song stop detect
This would be an expansion to the NSF format, and is entirely unnecessary. NSFe has track lengths. NSF2 will have track lengths. There is no need for this, just use the newer formats.
[*]MMC5 emulation of 2A03 features on/off
I think the MMC5 already has all the relevant options that the 2A03 does, i.e. phase reset, nonlinear mix. What is missing?
[*]Playback rate in header use on/off (actually, I think it might already have this)
Already an option.
[*]Set value of A, X, Y register to any number 0-255
I don't understand the purpose of this. Why would you want it? Even so it's trivial to insert code into an NSF to set up these registers, or just use a debugger like FCEUX. NSFPlay is not and will never be a debugger.
[*]VRC7 delay between register write
This is not particularly useful to try to emulate. The actual behaviour of the registers when updated too soon is extremely complicated and unpredictable, and totally unknown at this point. As far as I'm concerned, just performing the write anyway is as good a substitute for this unknown resulting state as any. For the few people that play on hardware, this is a known issue, and the major NSF engines that support VRC7 already have a proper delay (FamiTracker, PPMCK/MML, Lagrange Point). I would be willing to add a diagnostic warning about it, however (see unofficial opcodes below).
[*]Expansion register mirroring on/off
I don't know what this means. At the moment I don't want to implement this. There are actually no NSFs I know of that use the mirrors (I don't know of any NSF players that implement them), and it opens up irreconcilable problems for multi-expansion NSFs. I may add a diagnostic for unusual address writes though.
[*]Unofficial opcodes on/off
I see no reason to turn them off, but I do plan to introduce an NSF diagnostic which can test an NSF and give warnings for this kind of thing.
[*]NSFe chunk for VRC7 patch
No, this is not a feature of the VRC7 and implementing this would diminish the compatibility of NSFe files across players and hardware. Use an adlib tracker if you want custom patches. If you want 2A03 + Adlib, you can already do this with the VGM format.
[*]Triangle phase reset (at initialization) on/off
This could be randomized like noise.
[*]APU test mode on/off
Planned, not yet implemented.
[*]Wasted clock cycles to call play routine
You can do this in a debugger like FCEUX pretty easily. I don't plan to implement very many debugging features in NSFPlay.
[*]FDS write conflicts on/off
Why?
[*]Direct register view
This already mostly exists in the keyboard view.
[*]Reverb
No, this will not be part of NSFPlay. However, Winamp has DSP plugins you can use if you want this.
[*]Switch zero-based/one-based track numbers display
I don't think this is needed, and would rather not spend time on it.
[*]Switch track number display decimal/hexadecimal
Same as above.
[*]Trim spaces on/off
What problem would this solve?
[*]Fast-forward until value at specified RAM address changes
You should use a debugger like FCEUX to do this. It's already very capable and can do much more complicated debugging tasks. NSFPlay is never going to be a debugger.
[*]Initial delay setting
What does this mean?
[*]Make command-line mode (convert to WAV and so on) to be cross-platform instead of Windows only
I would like to make the whole program cross-platform eventually. This is not a priority, however.
[*]Warning/errors display
What warnings and errors? (Though this may fall under the diagnostic logging option I mentioned above.)
[*]Time units switch between seconds/milliseconds/frames
I'm not sure why this is needed. Frames are really only relevant if you're debugging, and there are other tools to deal with this already.
[*]Make command-line options to be named options
I don't know what this means, but as part of the WAV export command line I would like to implement the ability to temporarily set yansf.ini options for that render.
[*]Preset to switch filter to RF Famicom or AV Famicom (does it already have this?)
There are presets, and there are settings for the lowpass filter.
[*]Override the header, to play NTSC or PAL regardless of what is available
Implemented already for the next version.
[*]Override blank titles and "<?>" titles on/off
This is the NSF spec. I don't see any reason to change it. Just edit the NSF if you don't like the default title indicator.
[*]Command-line option to output to Csound score files
That's a rather strange request. I will not do that, but I have already implemented a register-write logger that you could write a program to translate into whatever you want, I suppose. This will be available in the next version.
[*]Command-line option display various information: ROM used, RAM used, NSF header texts, expansions used, possible conflicts with NSF specification, loop detection, etc
A windowed MFC program can't properly give any feedback to the command line (there are hacks to attempt it but they do not work well). ROM and RAM used are something debuggers with code/data logging can already tell you, use those. The entire NSF header information is viewable in the info window in NSFPlay if you're looking for that. The planned diagnostic log feature will try to pick up bad NSF behaviour if it can. I'm not sure what information you want about loop detection.
Quote:
Quote:
Expansion register mirroring on/off
I don't know what this means.
A lot of Famicom mappers that include a synthesizer incompletely decode the memory-mapped I/O ports connected to the synthesizer. For example, on Namco 163, writes to $4801-$4FFF will all have the same effect as writes to $4800. If more than one such mapper is connected, a single write might affect more than one synthesizer. You may want to emit a diagnostic if an NSF writes to any address other than the lowest address of a given port. See
NSF#Multi-chip tunes and
Talk:NSF#Multi expansion on the wiki.
Quote:
I do plan to introduce an NSF diagnostic which can test an NSF and give warnings for this kind of thing.
Good deal.
Oh right, I don't know how I forgot what that means, given that I've had conversations about it in the past. Yeah, I don't really want to offer a way to turn that on and off, but yes it would be a worthwhile diagnostic.
rainwarrior wrote:
[*]RAM address for song stop detect
This would be an expansion to the NSF format, and is entirely unnecessary. NSFe has track lengths. NSF2 will have track lengths. There is no need for this, just use the newer formats.
I don't mean an expansion; I mean to make the record to WAV or whatever to tell it to stop in such way in batch processing.
Quote:
[*]Set value of A, X, Y register to any number 0-255
I don't understand the purpose of this. Why would you want it? Even so it's trivial to insert code into an NSF to set up these registers, or just use a debugger like FCEUX. NSFPlay is not and will never be a debugger.
You can access hidden tracks, perhaps?
Quote:
[*]VRC7 delay between register write
This is not particularly useful to try to emulate. The actual behaviour of the registers when updated too soon is extremely complicated and unpredictable, and totally unknown at this point. As far as I'm concerned, just performing the write anyway is as good a substitute for this unknown resulting state as any. For the few people that play on hardware, this is a known issue, and the major NSF engines that support VRC7 already have a proper delay (FamiTracker, PPMCK/MML, Lagrange Point). I would be willing to add a diagnostic warning about it, however (see unofficial opcodes below).
Yes, diagnostic warning is good enough.
Quote:
[*]Triangle phase reset (at initialization) on/off
This could be randomized like noise.
Yes, it is what I meant.
Quote:
[*]FDS write conflicts on/off
Why?
It is possible some NSF might depend on this feature to be one way or the other, it can also be used to test for compatibility, and could also be diagnostics. (Write conflicts should probably be off by default though, since the program that uses these multiple expansions probably won't use FDS RAM; such as ppMCK doesn't use FDS RAM so it should be off by default.)
Quote:
[*]Warning/errors display
What warnings and errors? (Though this may fall under the diagnostic logging option I mentioned above.)
Yes, I mean diagnostic mode.
Quote:
[*]Make command-line options to be named options
I don't know what this means, but as part of the WAV export command line I would like to implement the ability to temporarily set yansf.ini options for that render.
Yes, I mean such as yansf.ini options.
Quote:
[*]Override blank titles and "<?>" titles on/off
This is the NSF spec. I don't see any reason to change it. Just edit the NSF if you don't like the default title indicator.
I mean that when listing the titles, you can turn on/off the option to make it replace "<?>" by the filename or whatever. But perhaps it is not needed if you will change the NSF instead.
Quote:
[*]Command-line option to output to Csound score files
That's a rather strange request. I will not do that, but I have already implemented a register-write logger that you could write a program to translate into whatever you want, I suppose. This will be available in the next version.
Yes, it doesn't have to be Csound format; since I can write another program to convert from that format into Csound format if it is needed.
Quote:
[*]Command-line option display various information: ROM used, RAM used, NSF header texts, expansions used, possible conflicts with NSF specification, loop detection, etc
A windowed MFC program can't properly give any feedback to the command line (there are hacks to attempt it but they do not work well). ROM and RAM used are something debuggers with code/data logging can already tell you, use those. The entire NSF header information is viewable in the info window in NSFPlay if you're looking for that. The planned diagnostic log feature will try to pick up bad NSF behaviour if it can. I'm not sure what information you want about loop detection.
If most of the program is in the DLL, then you can have the separate EXE file for command-line version (on UNIX you can use the same executable for both). OK debugger can tell you, but it should be a debugger which play NSF files good quality!
rainwarrior wrote:
A windowed MFC program can't properly give any feedback to the command line (there are hacks to attempt it but they do not work well). ROM and RAM used are something debuggers with code/data logging can already tell you, use those. The entire NSF header information is viewable in the info window in NSFPlay if you're looking for that. The planned diagnostic log feature will try to pick up bad NSF behaviour if it can. I'm not sure what information you want about loop detection.
Briefly checked this out, apparently a Win32 app can make a new console and interact with that, but can't output to the console that started the app.
Actually you
can get a handle to the console that opened it and printf to it, but the way text comes through is in a really ugly/unusuable way. Like, it won't work with > and dumps it into the next command line, or something to that effect (I don't remember exactly, it's been a little while).
Anyhow, a command line tool might be interesting to try later on, but this would probably come at the same time as a total UI rebuild for cross platform compatibility. Not anytime soon.
Quote:
I don't mean an expansion; I mean to make the record to WAV or whatever to tell it to stop in such way in batch processing.
Currently the best way to batch process is not to use the command line tool. Temporary config overrides from the command line will eventually allow track lengths to be specified, but there is a way to do it right now. Use Winamp, and make an m3u playlist (directions are in the readme). You can then use the diskwriter plugin and just play the whole playlist to disk.
I think I've found an nsf that might show some long-standing bugs in emulation. then again, I might be running off inaccurate data so who knows.
the nsf in question is damian_yerrick_-_covers_volume1.nsf, from the 2a03.org collection. if you can get this into a real nes and compare it, especially songs 6 and 16, I think you'll be surprised. Song 6, listen to the frequencies, especially as they near the top limit of the pulse channels. in most emulators, they flatten out, but I have a feeling they should stay in tune with the scale as it goes up. the old nezplug 0.9.48 got this one right.
in track 16, I have an idea it might show the difference between emulated and real periodic noise. in the old emulator SMYNES, which I can't get to run anymore, the periodic noise was in tune with the little melody that was played on the pulse channel. in *every* other emulation I've herd, it's just a mismatched set of notes.
So, any ideas?
Don't trust subtleties of anything I made before I got my PowerPak in the fourth quarter of 2008, especially Covers vol. 1. It
relies on long-standing emulator bugs.
- Track 6 ("Korobeiniki Slow") uses pitches up to 1760 Hz, and these will sound flat on an NES or an accurate emulator. The version of NerdTracker II against which Covers vol. 1 was compiled had a bug: the frequency table doesn't compensate for the t + 1 behavior of the square and triangle timers. My NSFs since mid-2005 use a corrected period table.
- Track 16 ("Looped Noise Test") is in tune on NESten and completely wrong on an NES.
tepples wrote:
Don't trust subtleties of anything I made before I got my PowerPak in the fourth quarter of 2008, especially Covers vol. 1. It
relies on long-standing emulator bugs.
- Track 6 ("Korobeiniki Slow") uses pitches up to 1760 Hz, and these will sound flat on an NES or an accurate emulator. The version of NerdTracker II against which Covers vol. 1 was compiled had a bug: the frequency table doesn't compensate for the t + 1 behavior of the square and triangle timers.
- Track 16 ("Looped Noise Test") is in tune on NESten completely wrong on an NES.
ok thanks! I did wonder if this was the case, because it was in the early days of nes sound emulation, so was wondering which was accurate. good to know.
Can there be log to VGM added? (To log the chips which are not supported in VGM, look at "vgm_unofficial.txt" in the VGMCK distribution; once VGM offically supports these chips, then you should change it to the official codes of these chips instead.)
No, there are no plans for log to VGM, but there is already some logging in the beta (which will be properly exposed to the user in the next release).
However, the logs are of a form where each line is a command, such as WRITE(4011,22), and it should be relatively straightforward to use a macro assembler like ca65, or other suitable program to build VGM (or other binary logs) from it easily.
rainwarrior wrote:
No, there are no plans for log to VGM, but there is already some logging in the beta (which will be properly exposed to the user in the next release).
However, the logs are of a form where each line is a command, such as WRITE(4011,22), and it should be relatively straightforward to use a macro assembler like ca65, or other suitable program to build VGM (or other binary logs) from it easily.
I would think VGM would be a good format to use for logs of commands send to sound chip, but, you can use the text format if you want to, and I can then make the program to convert the text format into VGM; it is not really a lot of problem. But the log feature is really good; thanks for adding such logs feature (myself and/or others can write the converter if wanted).
Just a quick thread bump, and status check. I assume nsfplay will/is still being worked on? haven't seen any updates here or from the svn repository in quite a while. No problem if life/priorities are taking over as they often do, just curious for any updates.
arfy
Yes, I'm still working on it.
I need to rewrite the FDS emulation before the next release (its old state does not work well with some changes I made to the way it executes, and there are many questions I need to verify). I will probably also rewrite N163. The reason I haven't yet is that I need to do some testing. There has been a series of setbacks on that front. My FDS disk drive is kaputt, and efforts to repair it have failed. I got an FDSLOADR cable, but the first three parallel port devices I tried to use did not work. I still haven't bothered setting up the fourth one I bought, though I suspect it would actually work if I did. I also tried to make a device to split the writes to a second cartridge to do tests that way, but one of the cartridge pinout diagrams on the wiki was backwards so I totally botched that.
Anyhow, these problems aren't really what's preventing me from doing it. I can still hotswap at the very least (that's how I've been testing other hardware) but it's just that the last several times I've been motivated to work on it, the route I chose ended up failing.
I won't bother laying out my personal life here, but I will say that I do have some free time to spend on it in the next few months, and I should be able to get the next release out this summer.
Ah, awesome. Glad to know development is still happening, as for your technical issues, gotta love those... not! Looking forward to the next release, for sure. what will rewriting the n163 emulation do, give it the aliasing effect as on the real chip?
Give it the
option for authentic aliasing, yes.
There are a few other things I need to test and measure about its behaviour too.
Before I begin, I just wanna say great job with this program, rainwarrior. It's slowly becoming my fav tool for NSF listenings and recordings.
However I have a big problem - when I load NSFE files, the track names are completely out of order and had to manually rename the songs after recording.
Also, would you consider writing an NSFPlay plugin for Foobar? That'd be amazing.
If the NSFe has a playlist, it will use that playlist order by default. There is an option to ignore the NSFe playlist in the options, if you'd rather it just play all the tracks in their original order.
A foobar plugin is something I'd like to support in the future, but it's not a priority right now (still need to get through an accuracy pass on all expansions, then a performance pass). I'd also like to add a playlist editor, so you can make and edit NSFe or M3U playlists easily, but this has similar priority.
I did a complete rewrite of the FDS emulation after doing a bunch of hardware tests. Here is a new beta, which includes a bunch of other updates (mentioned in nsfplay.txt).
-- removed link --
I hope to rewrite N163 emulation, and finish a few more cosmetic things (UI, documentation, minor bugs) in the next few days, and then hopefully I can release NSFPlay 2.3 in time for Famicompo 10 listening.
Note: for folks using the Winamp plugin of nsfplay23b3.zip -- this change will require you to either nuke your in_yansf.ini (this is the easiest choice) or compare your in_yansf.ini to the one included with nsfplay23b3.
There are some options which got added or renamed (APU1_OPTION4=0, REGION=0, LOG_CPU=0, LOG_CPU_FILE=nsf_write.log), some removed or renamed (FDS_OPTION1, PREFER_PAL, INI_FILE), and some syntax/functional changes (FDS_OPTION0=2000).
With 2.3b3 I played track 2 of Bio Miracle Bokutte UPA (FDS).nsf and thought I was going crazy. "Are those random pitchbends I'm hearing, along with some off-key notes?!?" (the game does have some intentional off-key notes but not like this :-) ).
Here are the things you'll probably need to troubleshoot: MP3 of 2.3b2 playback, MP3 of 2.3b3 playback, and the NSF itself. The MP3s were recorded using Winamp itself, with stock/default in_yansf.ini settings (i.e. what comes in the .zip) with no adjustments. I can set LOG_CPU=1 and provide nsf_write.log if you need it too.
http://jdc.koitsu.org/lj/nsfplay23b3/I'm thinking this is a bad NSF rip (I don't hear this behaviour in any of the other FDS NSFs I've tried) -- the one I put up there is from Zophar's Archive -- but I find the same oddity in these:
http://gilgalad.arc-nova.org/NSF-Archive/b/Bio%20Miracle%20Bokutte%20Upa%20(FDS)(1988)(Konami).nsfhttp://akumunsf.good-evil.net/B/Bio%20Miracle%20Bokutte%20UPA%20(FDS).nsfI went through the archives
listed here to no avail.
I wouldn't spend too much time on this (it's a single NSF and all that), but if you're interested in spending some time on it, have a blast.
In general, when taking a new version of NSFPlay, the in_yansf.ini should not be carried forward from the last version, though I do try to keep changes that would break things to a minimum. Unfortunately FDS_OPTION0 does break FDS playback with the old value, due to the complete rewrite and the removal of the 2 options that were originally there. It's now a lowpass filter cutoff, and its default value is 2000.
The Bio Miracle thing is interesting. I can't find any non-emulated videos on YouTube or Nico Nico to compare against, unfortunately. I dunno what it is, though. A mod-table halt condition that didn't show up in my tests? Maybe I can fit a playback log of it into a hotswap test. (NSFPlay now has a logging feature via LOG_CPU, by the way, though I haven't made a UI or documentation for it yet, which I will do before 2.3 is released.)
Yep, same here, I couldn't find any examples of the FDS version anywhere, just the
cart version (which, duh, isn't the same). I at least wanted to make you aware of it, in the case that it turns out to be an oddity in the emulation rather than the rip; if you're taking notes of NSFs/titles which need further investigation, I'd say add that one to your list. I have an FDS, but the likelihood of me being able to get my hands on a Bio Miracle Bokutte Upa FDS disk is slim-to-none. :/
Edit: I can't even think of a way of getting an .FDS image onto my FDS/Famicom, for that matter. Can't use my PowerPak (even if I made a 72-to-60-pin adapter) because the entire Famicom cart slot is taken up by the FDS with no pass-through, and I have no idea if there is hardware out there which lets you make/reproduce FDS disks (as in the physical thing).
A feature I might think would be sometimes useful is a option to tell it that the duration of the music is infinite.
koitsu: I can't get my FDS drive to read any disks at all (I changed the belt, and tried many times to realign), which is part of why it's taken me so long to get around to testing this stuff. I have an FDSLoadr cable, but so far the complications of acquiring a parallel port and DOS to run it on have prevented me. Maybe I'll try to get it going today.
I don't immediately suspect the NSF to be a bad rip, though that does happen from time to time, obviously. I've noticed that most emulators seem to reset mod-table phase on $4085 writes, which I was not able to duplicate in my testing. Possibly $4085 does reset if the mod-table is halted? I've got some more tests to do. If I emulate it this way (phase reset if halted) it eliminates some of the weirdness, but not those sliding tones around 17s.
zzo38: just turn off the "automatic playtime detection" option, and the "stop the song automatically" after silence option.
If it's of any help, I could mail you my FDS (fully working condition, has AC cord too), especially if it'd help you out. Let me know; I ship stuff up to Canada (Quebec) fairly often.
I had one previously which had a bad belt, but even after replacing the belt + realigning as best I could it still didn't work (I gave that one to Matt Conte, not sure if he was able to fix it or not).
Ah, thanks for the offer, but I don't think I'd need that. The part of the FDS that I care about (the RAM adapter with the audio hardware in it) works fine. If you have a way to play Bio Miracle on it I'd like to hear what it sounds like, but I don't think I would get much benefit from it if I had it. (I can't write disks either, so it wouldn't help me run arbitrary code or anything.)
The FDSLoadr stuff is... well... let's just
we've been down this road before, and I completely sympathise/side with Bregalad. I won't go into that, but the parallel requirement is complete nonsense, it just happens to be a "convenient legacy way" of strobing 11 individual pins that go to the FDS RAM cart. It all becomes more clear when you look at
this and
this. And it gets hilarious when you look at
this and realise how much of a hack it is in the first place.
I can't get FDSLOADR to do anything. I've got FreeDOS running, and the DOS drivers that came with my PCIe parallel port drivers claim they are working with LPT1 mapped to 0378h. I dunno what else I need to do for this, but the program always goes into "Disk Drive hardware present" mode (which seems to be the default).
Rebooting my computer seems to cause the FDS to get a disk-inserted signal, which is at least some minor sign of life...
I can't tell if the FDSLOADR program is really communicating with the port at all. It does the same thing whether or not I run the drivers, whether or not the cable is connected to anything, so... graaaaaah. Maybe I can find another way. This has been a frustrating couple of hours.
I'm going to try and use the RAM adapter via CopyNES...
Eh, 8-bit legacy interface that dates to the original XT? No more of a hack than anything else in computing. Just a different flavor.
Anyway, if he doesn't want to sell the hardware, the parallel port is still the least awful.
Or one could just release the software only for the RasPi. <shrug> Then it becomes everyone else's problem, just like now with the parallel port.
Alright, so now after attaching my FDS to my NES front loader and writing some logging code for NSFPlay and a log player for CopyNES, I've been able to play register logs of that track on my FDS and it really is doing a bunch of weird slides and stuff like that.
So... I guess it might be a bad NSF rip, or the game might be like that? I dunno. I still mean to figure out what exactly is different about my emulator from others that is allowing it.
Edit 1: Also finally found a hardware video, and it appears the actual game does not have this problem.
https://www.youtube.com/watch?v=Hgn4J9RkTxkEdit 2: Also the emulation difference appears to be about whether $4085 writes should reset the phase of the mod table. Specifically, this NSF is writing $4085 while the mod-table is running, and the table looks like [+4,+4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,-4,-4,-4,-4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,+4,+4]. When $4085 occurs in the middle of the table ratehr than the start, the vibrato will be unbalanced, if on a run of zeroes it'll be +8/-8.
In all my tests, writing $4085 does NOT reset the mod table phase while it's running. I will investigate today whether it can reset its phase while its halted (resetting while halted is not this NSF's problem, though-- it writes the entire table every time it halts, which effectively resets phase anyway). I'll also try to take a look via FCEUX and see if the actual game does this or not.
Unless my FDS is special in regard to $4085 and phase reset, I suspect the NSF is busted. Maybe the mod-table reloading routine isn't getting called on some frames where it should? I dunno. Disch's doc claims that $4085 resets phase, and other emulators do this. In my experience so far, writing the whole table is the only way to "reset" phase (by cycling the first value you wrote back to the current position).
Edit 3: Have tested $4085, I haven't found any way to get it to reset phase on my FDS. Info here if anyone wants to try a hotswap test:
http://forums.nesdev.com/viewtopic.php?f=3&t=10233#p114793
After spending some time poring over trace logs, I think the NSF is okay. It seems to match my logs from the .FDS version pretty well.
What happens is:
$4085 > 0
$4087 > halt
$4088 > write 32x
$4085 > 0 (redundant?)
$4087 > resume
$4085 > 0 redundant, but problem causing!
When the last $4085 occurs, it is very close after the resume, but if it takes longer than the mod unit takes to tick before it happens, the first +4 gets nullified by the $4085 write, biasing the pitch downward. At the same time the game is playing a mod strength macro that fades out from 32, so this becomes a slowly rising pitch.
On the register logs I was playing through my CopyNES, the problem was even worse sounding, probably because increased lag between writes, since they're coming through the CopyNES interface.
I have a new theory that $4088 resets the accumulator that clocks the mod table, so in the brief time between the resume and the spurious $4085, it usually doesn't get a chance to clock the unit. Can't think of a good way to test this on the hardware, but it does prevent most (but not all) of the weird sounds in the track if I implement it this way. It's also inconsistent somehow, if I let the NSF play, it's kinda random which loops it does it on. (I also notice the occasional bend in the youtube video I linked when I listen closely, but it seems to be happening less often.)
This is my first release candidate beta for NSFPlay 2.3:
-- removed link --
Please try it out and let me know if you find any bugs/problems.
Changes since 2.2:
NSFPlay 2.3 BETA 4 - 7/16/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.
Looking (and sounding) good, rainwarrior. Few things I found, albeit minor:
- Main NSFplug UI has a window title of "NSFplug" (lowercase "p"), while rest of the program uses "NSFPlug" (capital "p")
- Configuration area with General/APU1/APU2/etc. tabs has a window title of "NSFPlug"; I'd strongly suggest "NSFPlug - Settings"
- Some pixel adjustments need to be made to the UI configuration tabs' "Options" sections, to keep them looking consistent. Boxes, spacing of the text/checkboxes, etc. are different between APU2 vs. FDS vs. APU1, etc.
- "Default number of Loops" lets you decrease the number all the way to 0 (which used to be permitted), but now trying to use a value of 0 throws an error dialog insisting the value must be between 1 and 256. If 0 isn't supported any more, no problem -- make the spinner (up/down arrows) stop at 0
If you upload the source somewhere I can fix these up/provide a diff, particularly for the layout/UI ones.
Source code is always available at
http://code.google.com/p/nsfplay/However, let me start by saying that I intend to rewrite the entire UI in the next version. This version is still focused on emulation accuracy, but at this point the accuracy notes I have left are few enough that I should be more or less "finished" in that regard by the next version, so a UI rewrite will finally become priority. (I will be getting rid of all MFC, and structuring the code better for cross-platform support-- I wanna see this program make it to Linux, and eventually Mac.)
As such, I don't really care too much about UI nitpicks, unless it affects functionality. The only one of those notes I think is worth addressing is the default number of loops (which has actually been that way since before I started working on NSFPlay). I don't know if a 0 is allowed in that field, but I will check, and fix the range test if it is.
It's intentional that everything except the main window says NSFPlug, as all of this stuff is part of the plugin DLL, and the plugin was historically called "NSFPlug". The stand-alone player was always referred to as "NSFPlay" by Brezza, though before my time the UI did say NSFPlug. When I de-MFC everything, I will also restructure things so that the core audio library can be integrated into the player program without being a DLL anymore, so I might just do away with the name "NSFPlug" altogether at that point, and just call the plugin "NSFPlay" (nobody seems to call it anything besides NSFPlay these days anyway).
The alignment of the options panes I don't really care about. Whether the config window says "settings" on it I think is unimportant. I'd rather leave these alone in the interest of making as few changes possible between beta and release.
There are a few issues that did bother me (infobox assumes song 1 instead of current song on opening, winamp playlist prev/next behaviour sucks with multiple NSFs, etc.) that I made an attempt to fix for this version, but gave up after being unable to solve the problem in a short enough period of time, since these things will be erased by the UI/restructure anyway.
Re: UI bits not being a focus right now: gotcha. :-) Guess it might be worth adding a TODO list somewhere so that you don't forget 'em all.
Re: zero in the loop field: my old in_yansf.ini used to have 0 in that field and it used to work how I expected -- with loop detection enabled (default), a single melody/song would play once only. I'm under the impression that a value of 1 means loop once, i.e. the melody plays twice, while a value of 0 means/meant the melody plays once. I could have this wrong though.
rainwarrior wrote:
I will be getting rid of all MFC, and structuring the code better for cross-platform support
There are rumors on IRC that cpow is working on a wrapper to run MFC programs largely unmodified in Qt.
Quote:
so I might just do away with the name "NSFPlug" altogether at that point, and just call the plugin "NSFPlay" (nobody seems to call it anything besides NSFPlay these days anyway).
In other words, NSFplug becomes "NSFPlay for Winamp".
I'm not interested in an MFC wrapper. That will just make a bigger mess. I despise MFC and want it out of the program entirely.
The number of loops thing will go to 0 in the release version or next beta.
I do have a to-do list in the /distribute folder in the source repository, and there's lots of stuff on it.
Also, for the record I don't mind the nitpicks, I just don't want to fix them for this release if they're not functionally important.
By the way, every English UI page has a corresponding Japanese UI page that has to be separately maintained, so they may also require similar tweaks (but I get much less feedback from Japanese users). Also, because of the way MFC does region selection, testing it requires Windows 7 Ultimate to be able to change regions, which was an annoying purchase to have to make. This is another motivation to dump MFC. (I dislike the UI and the UI code for this application in general, so a total rewrite is in the cards anyway, and getting rid of MFC at the same time is kind of a bonus.)
Hrm, I guess I'm wrong about the loop 0 thing. I thought this was a regression between 2.3b4 and 2.3b3, but I just tried it on 2.3b3 and the situation is the same. I'd recommend ignoring my complaint about that for now -- I need to fiddle around to see how exactly I ended up with LOOP_NUM=0 in previous .ini files to begin with, and I need to sit down and actually figure out what the behaviour is WRT that setting.
The spinner/arrows, of course, should still stop at 1 and 256 though, but that's something separate than what I was complaining about.
Footnote: two thumbs up with regards to the desire to remove all the MFC nonsense.
Wow! This is sounding amazing! Just one, seemingly minour point, and a compatibility problem with XmPlay.
1. Would it be possible to have an option for the n163 that makes it behave like older emulators, where only 3 bits of the waveform are read, and not the full 6? This would be useful for older nsf's that rely on this behaviour. Personally, I'd rather patch the nsf's so that they play properly on the real hardware, but I think having the option in the player would be useful as a stopgap measure. Speaking of patching, could someone remind me, or point me to the entry where someone mentioned how to patch older n163 nsf files to sound right?
2. Right now in XmPlay, I'm finding that switching songs, especially after a few switches leads to XmPlay crashing, or at least becoming unresponsive and causing windows 7, either 32 or 64-bits, to bring up it's this program is not responding... dialog. I can't seem to track down a consistent pattern to the behaviour, but when the dialogs do come up, what info should I get to try track down the bug? I haven't got winamp installed right now to test to see if it's XmPlay specific, or if it's something else causing the weirdness.
thanks
1. I have considered this, but no, sorry, I do not want to support faulty emulator behaviour like that. It drags the state of emulation back. No N163 NSF that has been tested on hardware suffers from this problem. It is really only a problem for a small handful of homebrew NSFs, and I would prefer that you fix the offending NSF files.
Almost all of them have already been patched by somebody (jrlepage did a lot of them), and also I posted how to do it for PPMCK when I first made the change in NSFPlay 2.1:
http://forums.nesdev.com/viewtopic.php?p=91958#p91958If you're not willing to fix the NSFs yourself, all previous versions of NSFPlay are still available, and this incorrect behaviour was present in NSFPlay <= 2.0.
2. I've not tried it with XMPlay before. I can't seem to switch tracks at all in this. How do I change tracks, and how do I open the NSFPlug info page in XMPlay? It seems to play the first track of an NSF fine, at least.
Ok, thanks for the quick reply.
1. That's perfectly fine, and I agree. adding hacks like that reminds me of all the options that used to exist in sid players. I assume this means the reset phase on $4085 option for fds will go away too, once more tests are done?
2. To switch subsongs, right-click the previous/next track buttons. also by default, shift-left/right arrow do the trick. For plugin info, I went into the shortcuts section of options, and assigned alt-3 to current track - plugin info.
hth.
The $4085 reset option does not require more tests, it requires some really tight CPU/FDS timing synch which will not be trivial to implement. Ideally it will go away when I can do that. I don't particularly like having it in, but I didn't feel I had a better alternative at the moment.
For now, it seems to only be needed for that one track in Bio Miracle in which its sloppy coding (the mod bias shouldn't be redundantly reset outside the mod-table write loop) exposes the problem by using extremely high modulator frequencies. The other tracks have the same code, but the mod frequency never goes high enough to matter, so the mod unit doesn't tick before the bias is reset.
Thanks for instructions how to use XMPlay with this. So far seems to be working fine on my end (XMPlay 3.6.0.1). I dunno, if you can find a consistent way to crash it, let me know.
Well, turns out the XmPlay crashing is related to the screen reader I'm using. Yep, I'm a blind computer user, and it seems the particular program I was using is causing the lockups. but only with nsfplay, and only with that particular package. switching to my other choice of screen reader makes the crashes go away. So there is something in the nsfplay causing an issue, but don't bother too much about it. I'll look into the issue with the devs of the screen reader instead. As always, keep up the good work! Oh before I forget, was there an archive of the patch n163 nsf's posted somewhere?
Eugene.S wrote:
Can't reproduce this on my XP SP3 system; all pulldowns show their proper contents.
I have this problem both on
Windows XP x64 SP2 eng with Server 2003 MUI (OS version 5.2.3790)
and Windows XP SP3 rus (OS version 5.1.2600)
I've switched to Win9x-like windows classic theme, but problem still here.
That's really odd Eugene.S, the style of the combo box is supposed to have "integral height" that automatically sizes the drop down to the list. I can't duplicate the problem, myself, but I tried increasing the height value on the box (even though it's not supposed to be used). Redownload this and tell me if the problem persists:
-- removed link --
arfy, I'll see what I can dig up, re: patched NSFs.
Edit: jrlepage fixed all of robokabuto's old N163 NSFs:
https://dl.dropboxusercontent.com/u/34026765/robokabuto.rarI don't know what other N163 NSFs are out there from the period before we learned that error. If you find some you can let me know, I might just write a python script to fix them quickly if there's more than a few. (Possibly there are others that aren't PPMCK, which will require some debugging to fix.)
https://dl.dropboxusercontent.com/u/883 ... ay23b4.zipYes, new build works fine now.
Old build work fine also, when i've updated old nsfplug_ui.dll to new from 17.07.2013
Good! Yeah, the only thing that changed was the ui DLL, so that's why you can transplant it.
I think the DMC pop reducer of NSFplay need to be more soften.
I've recorded DMC from Batman - first level.
Nestopia, puNES and NotSoFatso pop-reducers work more soften,
but NSFPlay still have clicky sound.
nestopiaNotSoFatsonsfplay
@rainwarrior. Thanks for the link to the fixed n163 nsf's. some nice goodies in there I'd almost forgotten about, especially Ligaya! Genuine nsf trance, probably the first example of such. Anyway, unless there's other common n163 drivers other than ppmck and famitracker in use today, then I suspect the only other n163 nsf's are from namco themselves. I was also thinking of writing a general n163 patcher, probably in either PureBasic or python. Now if only someone was doing for the gameboy what your doing for the nes, then I'd be very happy.
Eugene.S pop reduction is an option, it is not something that happens by default.
The option "Enable $4011 register", on by default. If you uncheck this all pops caused by $4011 writes will disappear.
There is another option called "Eliminate clicking noise", which does not disable the $4011 register, but removes its sound while preserving the nonlinear mix it normally causes.
Toggling either of these options will remove the DMC clicks.
Thank you, eliminate clicking noise works very good.
But it have some problem, when enabled:
Look at
2:41 and
2:05 please.
Here is my in_yansf.ini (wait 10 second to download)
Agh, it looks like the counter-offset I'm using to suppress the $4011 pops eventually overflows if the DPCM direction goes opposite the $4011 too many times. I'll try to see if I can think of a way to fix it. If it's a DPCM heavy track you might just used the disable $4011 option instead, because the nonlinear mix won't be an issue.
How
leaky is your counter-offset?
It doesn't leak at all, that's why it eventually overflows. I'm going around it a different way now, though.
Okay, I was going to try to inject the counter-pop into the highpass filter and let it gracefully remove the offset, but this solution was becoming too much to change for the release.
So, for now I just put in a very, very simple linear fade to prevent overflow. Not ideal, but it seems good enough for the time being.
Eugene.S please verify that it no longer overflows:
-- removed link --
rainwarrior wrote:
Hmm, this build still buzz.
Can you reproduce this problem on your machine?
ps: this build labeled as "beta 4"
whoops, download again, I copied the wrong files.