NSFPlay 2.3

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

NSFPlay 2.3

Post by rainwarrior »

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.
Last edited by rainwarrior on Sun Sep 11, 2016 10:11 am, edited 1 time in total.
arfy
Posts: 22
Joined: Mon Apr 29, 2013 4:37 am

Re: NSFPlay 2.3

Post by arfy »

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?
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: NSFPlay 2.3

Post by koitsu »

arfy wrote: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:

Code: Select all

C:\Program Files\Winamp\Plugins>grep VRC7_VOLUME in_yansf.ini
VRC7_VOLUME=128
VRC7_VOLUME=96
VRC7_VOLUME=128
VRC7_VOLUME=128
VRC7_VOLUME=128
VRC7_VOLUME=128
VRC7_VOLUME=167
VRC7_VOLUME=128
VRC7_VOLUME=167
VRC7_VOLUME=128
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.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSFPlay 2.3

Post by rainwarrior »

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.
arfy
Posts: 22
Joined: Mon Apr 29, 2013 4:37 am

Re: NSFPlay 2.3

Post by arfy »

@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. :)
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSFPlay 2.3

Post by rainwarrior »

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.
seasprite
Posts: 3
Joined: Thu Aug 08, 2013 11:33 am

Re: NSFPlay 2.3

Post by seasprite »

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.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSFPlay 2.3

Post by rainwarrior »

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.
seasprite
Posts: 3
Joined: Thu Aug 08, 2013 11:33 am

Re: NSFPlay 2.3

Post by seasprite »

Aha, I see. No problem, and thanks for the speedy reply.
Whelkman
Posts: 11
Joined: Sat May 03, 2014 6:28 pm

Re: NSFPlay 2.3

Post by Whelkman »

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)
Attachments
entry021.nsf
(160.12 KiB) Downloaded 385 times
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSFPlay 2.3

Post by rainwarrior »

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.
Last edited by rainwarrior on Sat May 03, 2014 8:03 pm, edited 1 time in total.
Whelkman
Posts: 11
Joined: Sat May 03, 2014 6:28 pm

Re: NSFPlay 2.3

Post by Whelkman »

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.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSFPlay 2.3

Post by rainwarrior »

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:

Code: Select all

a912: ; store N163 write address, replaces: sta $F800
    sta $F800
    sta $600 ; $600 is a RAM location that happened to be unused
    rts
a919: ; increment N163 write address without writing, replaces: sta/stx/sty $4800
    pha
    tya
    pha
    txa
    pha
    inc $600
    inc $600
    lda $600
    sta $F800
    pla
    tax  
    pla
    tay
    pla
    rts
2. Then I used these subroutines to patch the offending writes out of the player code:

Code: Select all

; 9192
    ; sta $f800
    jsr $a912 ; patch
    jsr $93ea
    ldy #$3c
    sty $0004
    asl
    rol $0003
    asl
    rol $0003
    rol $0004
    asl
    rol $0003
    rol $0004
    sta $4800
    ; sta $4800
    jsr $a919 ; patch
    ldy $0003
    lda $0004
    sty $4800
    ; sty $4800
    jsr $a919 ; patch
    sta $4800
    ; sta $4800
    jsr $a919 ; patch
    ldy $002d
    sty $4800
    lda $002b
    ora #$70
    sta $4800
    rts
Attachments
entry021_fixed.nsf
Famicompo 6 entry 21: Dendrite, patched for correct hardware behaviour
(160.12 KiB) Downloaded 483 times
Whelkman
Posts: 11
Joined: Sat May 03, 2014 6:28 pm

Re: NSFPlay 2.3

Post by Whelkman »

Excellent. Sounds fantastic, thank you very much!
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: NSFPlay 2.3

Post by koitsu »

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
Post Reply