It is currently Wed Dec 13, 2017 12:25 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 123 posts ]  Go to page Previous  1 ... 4, 5, 6, 7, 8, 9  Next
Author Message
 Post subject: Re: NSFPlay 2.2
PostPosted: Sun Jul 07, 2013 12:53 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6513
Location: Seattle
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.


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Mon Jul 08, 2013 2:29 am 
Offline
User avatar

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

Edit 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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Mon Jul 08, 2013 1:46 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 12:19 am 
Offline
User avatar

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


Last edited by rainwarrior on Fri Jul 19, 2013 4:17 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 7:19 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 9:11 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 9:21 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 9:36 am 
Offline

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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 9:50 am 
Offline
User avatar

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


Last edited by rainwarrior on Tue Jul 16, 2013 10:47 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 10:46 am 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 10:04 pm 
Offline

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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 10:31 pm 
Offline
User avatar

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

If 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.


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 10:59 pm 
Offline

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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Tue Jul 16, 2013 11:24 pm 
Offline
User avatar

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


Top
 Profile  
 
 Post subject: Re: NSFPlay 2.2
PostPosted: Wed Jul 17, 2013 1:09 am 
Offline

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


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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