- 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
NSFPlay 2.2
Moderator: Moderators
Re: NSFPlay 2.2
Some option they seem not to have, I suggest to have:
(Free Hero Mesh - FOSS puzzle game engine)
-
rainwarrior
- Posts: 8740
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSFPlay 2.2
[*]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.
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
[*]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.
Last edited by rainwarrior on Mon Jan 21, 2013 12:00 pm, edited 2 times in total.
Re: NSFPlay 2.2
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.I don't know what this means.Expansion register mirroring on/off
Good deal.I do plan to introduce an NSF diagnostic which can test an NSF and give warnings for this kind of thing.
-
rainwarrior
- Posts: 8740
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSFPlay 2.2
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.
Re: NSFPlay 2.2
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.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.
You can access hidden tracks, perhaps?[*]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.
Yes, diagnostic warning is good enough.[*]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, it is what I meant.[*]Triangle phase reset (at initialization) on/off
This could be randomized like noise.
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.)[*]FDS write conflicts on/off
Why?
Yes, I mean diagnostic mode.[*]Warning/errors display
What warnings and errors? (Though this may fall under the diagnostic logging option I mentioned above.)
Yes, I mean such as yansf.ini options.[*]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.
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.[*]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.
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.[*]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.
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![*]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.
(Free Hero Mesh - FOSS puzzle game engine)
Re: NSFPlay 2.2
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.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.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
-
rainwarrior
- Posts: 8740
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSFPlay 2.2
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.
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.
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 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.
Re: NSFPlay 2.2
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?
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?
Re: NSFPlay 2.2
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.
Re: NSFPlay 2.2
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.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.
Re: NSFPlay 2.2
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.)
(Free Hero Mesh - FOSS puzzle game engine)
-
rainwarrior
- Posts: 8740
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSFPlay 2.2
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.
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.
Re: NSFPlay 2.2
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).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.
(Free Hero Mesh - FOSS puzzle game engine)
Re: NSFPlay 2.2
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
arfy
-
rainwarrior
- Posts: 8740
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NSFPlay 2.2
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.
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.