It is currently Mon Oct 23, 2017 10:18 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 123 posts ]  Go to page 1, 2, 3, 4, 5 ... 9  Next
Author Message
 Post subject: NSFPlay 2.2
PostPosted: Fri Aug 31, 2012 7:46 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5734
Location: Canada
NSFPlay 2.2 has been released! Get it here:

http://nsfplay.googlecode.com/files/nsfplay22.zip

The 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?NSFplay


Project homepage: http://rainwarrior.ca/projects/nsfplay/


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Mon Sep 10, 2012 2:49 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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.. :-)


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Mon Sep 10, 2012 8:58 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 930
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?

_________________
.


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Mon Sep 10, 2012 9:16 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5734
Location: Canada
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.


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Mon Sep 10, 2012 5:19 pm 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3944
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.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Mon Sep 10, 2012 7:19 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5734
Location: Canada
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.


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Sat Sep 15, 2012 4:49 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5734
Location: Canada
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)


Last edited by rainwarrior on Mon Aug 07, 2017 2:48 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Sun Sep 23, 2012 1:10 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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.


Attachments:
nsfe_playlist.png
nsfe_playlist.png [ 15.8 KiB | Viewed 3376 times ]
Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Sun Sep 23, 2012 4:11 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5734
Location: Canada
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.


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Thu Nov 15, 2012 8:33 am 
Online
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
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).

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Thu Nov 15, 2012 11:00 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5734
Location: Canada
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 )


Last edited by rainwarrior on Mon Aug 07, 2017 2:45 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Thu Nov 15, 2012 11:11 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19119
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Thu Nov 15, 2012 11:16 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5734
Location: Canada
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.)


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Thu Nov 15, 2012 11:19 am 
Online
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2963
Location: Tampere, Finland
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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Thu Nov 15, 2012 11:47 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5734
Location: Canada
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 123 posts ]  Go to page 1, 2, 3, 4, 5 ... 9  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group