nesdev.org

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).nsf
http://akumunsf.good-evil.net/B/Bio%20Miracle%20Bokutte%20UPA%20(FDS).nsf

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