NSF player "cheats"?

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

Moderator: Moderators

Rahsennor
Posts: 479
Joined: Thu Aug 20, 2015 3:09 am

Re: NSF player "cheats"?

Post by Rahsennor »

rainwarrior wrote:My click removal is to detect if $4011 is ever written; if so, I maintain an inverse signal that is mixed on top to cancel it out (i.e. the result of the $4011 write steps up the waveform +35, then my "inverse" jumps down -35). Over time I allow the inverted signal to slowly and noiselessly drain out back to 0 (which is important because clicks are often in 1 direction only, and could eventually cause integer overflow).
How do you detect $4011 PCM, like the drums in Battletoads?

Or if you're just muting all $4011 writes, wouldn't it be easier to ignore the writes in the first place and let the DMC saturation take care of it?
B00daW wrote:I didn't say the fixes were spectacular but may aid to some minor annoyances.

Every suggestion I said was for art. Regarding those glitches possibly to be fixed I've used them to create forms of art already.

All other suggestions are also purely art related. :) If you don't see a point, you may just not share a similar perspective. It seems that your perspective is to get cleaner sounds out of commercial music and games. Myself and many other people use older hardware and consoles to create art for expression.
I don't mean to soud rude, but did you even read the thread subject? It's about NSF players, and half of your suggestions had nothing whatsoever to do with NSFs.

Yes, my question was mostly centered around fixing the audible glitches found in commercial game rips. I'm not opposed to implementing other features in my player, but the only thing it does is play NSFs. Art and perspective are not the issue here - the things you posted are simply not relevant to this particular tool.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF player "cheats"?

Post by rainwarrior »

Rahsennor wrote:How do you detect $4011 PCM, like the drums in Battletoads?

Or if you're just muting all $4011 writes, wouldn't it be easier to ignore the writes in the first place and let the DMC saturation take care of it?
1. It should always be an option, because it's no appropriate in all cases. PCM playback is such a case. (FWIW there is no compliant NSF for Battletoads that has PCM yet, but there are PCM NSFs around.)

2. An option to just ignore $4011 writes is another way to do it, but this has undesirable effects on the nonlinear mixing of the triangle + noise + DMC, i.e. anything that's trying to use it for limited volume control of the triangle (e.g. Super Mario Bros, Startropics) will lose the intended effect.

Personally I would support both these options.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NSF player "cheats"?

Post by tepples »

rainwarrior wrote:My click removal is to detect if $4011 is ever written; if so, I maintain an inverse signal that is mixed on top to cancel it out (i.e. the result of the $4011 write steps up the waveform +35, then my "inverse" jumps down -35). Over time I allow the inverted signal to slowly and noiselessly drain out back to 0 (which is important because clicks are often in 1 direction only, and could eventually cause integer overflow).
I think the "heuristic" part was about distinguishing this from intentional $4011 pops used as a crude kick drum. There's a page on the wiki describing what could be done about that: Enhancement#Pop reduction
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NSF player "cheats"?

Post by B00daW »

Rahsennor wrote:I don't mean to soud rude, but did you even read the thread subject? It's about NSF players, and half of your suggestions had nothing whatsoever to do with NSFs.

Yes, my question was mostly centered around fixing the audible glitches found in commercial game rips. I'm not opposed to implementing other features in my player, but the only thing it does is play NSFs. Art and perspective are not the issue here - the things you posted are simply not relevant to this particular tool.
The majority of NSFs available on the internet now these days are not commercial or related to games. The PAPU of the 2a0x has evolved into its own musical instrument and music is a form of art. Even rainwarrior and his modification of the NSFplug/play library has evolved since audio player routines have evolved out of the 25 year old drivers used in videogames into something else. (See Deflemask and its PCM routine used to get around NSF1's lack of IRQ.)

If you want to even reference the realm of commercial music and games see Neil Baldwin of modern and classic 2a0x audio and art (ex: Magician, James Bond Jr., Hero Quest, etc.) Some of his modern music creation software cannot even be replayed with the NSF1 format.

I fail to see your stance that art/music that you find an interest in enough to create a player for a format that's not currently up-to-date is irrelevant. Even kevtris (author of ported format resembling PSID) plays modern art NSFs on his hardware players and has introduced the 90% complete NSF2 format due to some of the issues that are limitations of past and future creations that are capable to be replicated on hardware with ROMs/mappers/expansions.

I don't think you're rude; but I'm confused in your perspective and intentions with your NSF player -- unless you intend to keep it to yourself for personal enjoyment.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NSF player "cheats"?

Post by tepples »

This player could be just the kick in the pants that NSF2 needs to become popular.
Rahsennor
Posts: 479
Joined: Thu Aug 20, 2015 3:09 am

Re: NSF player "cheats"?

Post by Rahsennor »

rainwarrior wrote:FWIW there is no compliant NSF for Battletoads that has PCM yet
I have three of them. Not sure if they count as "compliant" or not, since they use the Nintendulator-style non-returning play, but my player supports that so I need to consider the possibility.
rainwarrior wrote:2. An option to just ignore $4011 writes is another way to do it, but this has undesirable effects on the nonlinear mixing of the triangle + noise + DMC, i.e. anything that's trying to use it for limited volume control of the triangle (e.g. Super Mario Bros, Startropics) will lose the intended effect.
Yeah, I just tried it out on Castlevania 3 and it sounds terrible. Castlevania 2 sounds okay though.

I also tried remembering the last value written to $4011 and ignoring repeated writes of the same value, and found that the Castlevania games actually use multiple different values.
tepples wrote:I think the "heuristic" part was about distinguishing this from intentional $4011 pops used as a crude kick drum. There's a page on the wiki describing what could be done about that: Enhancement#Pop reduction
Looks like I'm going to need another frame counter...
B00daW wrote:The majority of NSFs available on the internet now these days are not commercial or related to games.
I know. That's the reason I started my NSF player in the first place - none of the existing players on Linux would play all the tunes from Famicompo Pico correctly.
B00daW wrote:I fail to see your stance that art/music that you find an interest in enough to create a player for a format that's not currently up-to-date is irrelevant. Even kevtris (author of ported format resembling PSID) plays modern art NSFs on his hardware players and has introduced the 90% complete NSF2 format due to some of the issues that are limitations of past and future creations that are capable to be replicated on hardware with ROMs/mappers/expansions.
Point me at a stable spec for NSF2 and some test files and I'll implement it. That's my only problem here - time, documentation and testing. I'm one person with limited free time and lots of other things I'd like to do with it - and I haven't even seen a single NSF2 file. Why support something that, as far as I am currently aware, doesn't even exist yet?
B00daW wrote:I don't think you're rude; but I'm confused in your perspective and intentions with your NSF player -- unless you intend to keep it to yourself for personal enjoyment.
If I wanted to keep it to myself, I wouldn't have posted it on this forum. Okay, so I stopped updating it with every version bump when I found nobody cared - the latest version had been downloaded exactly once last time I checked - but there hasn't been much progress to update it with anyway.

Just to clear up any confusion, my complaint with your original comment was that you suggested features that would require me to emulate things like an arcade machine or a PPU, both of which are outside the scope of this particular project - I seriously doubt that any NSF-related format would require support for two CPUs or a PPU. That's the realm of a full emulator, and while I could write a full emulator if people wanted me to, there are already plenty of them out there that do a better job than I would.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF player "cheats"?

Post by rainwarrior »

Rahsennor wrote:
rainwarrior wrote:FWIW there is no compliant NSF for Battletoads that has PCM yet
I have three of them. Not sure if they count as "compliant" or not, since they use the Nintendulator-style non-returning play, but my player supports that so I need to consider the possibility.
Non-returning PLAY is not a big problem. That's easy enough for hardware to support, though it may require a reset to be able to change tracks or otherwise interact with the player.

The Battletoads NSFs use a non-returning INIT, which is the real problem. The hack to make this work is to have an (arbitrary length) timeout on the INIT if it takes too long, and the INIT then continues to run as a sample player and PLAY becomes a 60 hz interrupt with the other APU updates in it. This is a bad way to do it, IMHO, and will probably never see compatibility with hardware players.
Rahsennor wrote:I also tried remembering the last value written to $4011 and ignoring repeated writes of the same value, and found that the Castlevania games actually use multiple different values.
Last value written isn't really relevant, only the current counter value is. The DPCM sample pushes it around, obviously, why would it matter where it started?
Rahsennor wrote:
tepples wrote:I think the "heuristic" part was about distinguishing this from intentional $4011 pops used as a crude kick drum. There's a page on the wiki describing what could be done about that: Enhancement#Pop reduction
Looks like I'm going to need another frame counter...
1. Option to play as written.
2. Option to eliminate the effect of $4011 pops in a straightforward way, knowing that this breaks certain kinds of things like PCM.
3. Option to eliminate some $4011 pops only under certain mysterious conditions, which might be good enough for everything you play?

I personally don't like the heuristic approach, because I like options to have a very clear cut behaviour. Options 1 and 2 can be understood intuitively by anybody who knows the NES. The heuristic option can only really be understood by someone who knows the exact (arbitrary) heuristic used; and if we ever find a case that breaks the heuristic, it has to change, too; then we get divergent heuristics, and at the same time people can come up with 100 different heuristics for this same thing (e.g. why "3 frames" specifically?)... it just feels like a mess made to solve a non-problem. :P
Rahsennor wrote:Point me at a stable spec for NSF2 and some test files and I'll implement it. That's my only problem here - time, documentation and testing. I'm one person with limited free time and lots of other things I'd like to do with it - and I haven't even seen a single NSF2 file. Why support something that, as far as I am currently aware, doesn't even exist yet?
There's no NSF2 NSFs.

B00daW says "kevtris did it", but he really didn't as far as I'm concerned, otherwise we'd have a reference implementation. I do believe kevtris implemented some version of NSF2 capabilities in hardware, but that's not of value to anybody at this point. It's not a spec, and it's not anything people can use to make their own implementation.

The NSF2 spec really belongs to the first person who:

1. Publishes a good working implementation of their version of NSF2, along with their version of a spec.
2. Publishes a collection of NSF2 rips and test NSFs (recommended: new rips for Battletoads and Ultimate Stuntman).

If this sounds like your cup of tea, go right ahead. ;) I might do it eventually, but I've got other projects I care a lot more about for the time being.

By the way, Battletoads and Ultimate Stuntman could both be done with the Deflemask trick, too, so it's not like they even demand an NSF2 spec to exist in practical form.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NSF player "cheats"?

Post by tepples »

rainwarrior wrote:I do believe kevtris implemented some version of NSF2 capabilities in hardware, but that's not of value to anybody at this point. It's not a spec, and it's not anything people can use to make their own implementation.
There's the beginning of a spec in the thread where it was proposed, and I just copied it to the wiki so it can be cleaned up. What remains are
  1. Clean up the wiki page.
  2. Ask kevtris in #nesdev for clarification on any unclear features.
  3. Make a "hello world"-type rip using each feature and have kev try to play it on his hardware player.
  4. Make players that can play the same rips.
  5. Re-rip Battletoads.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF player "cheats"?

Post by rainwarrior »

kevtris doesn't have to verify anything. He's never offered a working player to the world, there's no reason anyone trying to push an NSF2 spec would have to work with whatever arbitrary hardware decisions he made. He can still change his hardware whenever he wants to.

It's probably an important goal for the NSF2 spec to be implementable in hardware, but kevtris isn't the gatekeeper for this. He does have good knowledge/experience, and his advice is worth seeking, but he's not a necessary part of the equation. As long as it's clear that it can be sensibly built, that's all that matters.

A practical, implementable, and testable spec is what's important.

I still think it's a better idea just to re-rip Battletoads with the Deflemask trick. :P Even though it rubs against the NSF spec's advice not to interfere with IRQs, it's proven quite practical. Honestly I don't think the NSF2 spec is really needed for any game rips, just for more modern experiements.
Rahsennor
Posts: 479
Joined: Thu Aug 20, 2015 3:09 am

Re: NSF player "cheats"?

Post by Rahsennor »

rainwarrior wrote:Non-returning PLAY is not a big problem. That's easy enough for hardware to support, though it may require a reset to be able to change tracks or otherwise interact with the player.

The Battletoads NSFs use a non-returning INIT, which is the real problem. The hack to make this work is to have an (arbitrary length) timeout on the INIT if it takes too long, and the INIT then continues to run as a sample player and PLAY becomes a 60 hz interrupt with the other APU updates in it. This is a bad way to do it, IMHO, and will probably never see compatibility with hardware players.
Whoops, I meant to say INIT. My player (hopefully) supports both, and I agree that non-returning INIT is harder to implement, even in software.
rainwarrior wrote:Last value written isn't really relevant, only the current counter value is. The DPCM sample pushes it around, obviously, why would it matter where it started?
The idea was that pops would be caused by the same value being written every time, but volume changes (in games that don't use the DPCM) would be different. So ignoring only repeat values would ignore drum pops but still allow volume changes.

Of course, since drums don't write the same value to $4011 each time, that doesn't work.
rainwarrior wrote:1. Option to play as written.
2. Option to eliminate the effect of $4011 pops in a straightforward way, knowing that this breaks certain kinds of things like PCM.
3. Option to eliminate some $4011 pops only under certain mysterious conditions, which might be good enough for everything you play?

I personally don't like the heuristic approach, because I like options to have a very clear cut behaviour. Options 1 and 2 can be understood intuitively by anybody who knows the NES. The heuristic option can only really be understood by someone who knows the exact (arbitrary) heuristic used; and if we ever find a case that breaks the heuristic, it has to change, too; then we get divergent heuristics, and at the same time people can come up with 100 different heuristics for this same thing (e.g. why "3 frames" specifically?)... it just feels like a mess made to solve a non-problem. :P
Yeah, I think I'm just going to ignore the issue. It's not like the pops in Castlevania 2/3 even sound bad - when I first heard them I thought the clicks were all there was to the drums, and that it was a pretty clever trick!

I was hoping for a fairly simple heuristic that would save the user from digging into a menu for each different NSF played, especially if they're in a queue or something. But it's a complicated issue so that's kind of a lost cause.
rainwarrior wrote:I still think it's a better idea just to re-rip Battletoads with the Deflemask trick. :P Even though it rubs against the NSF spec's advice not to interfere with IRQs, it's proven quite practical.
I can get behind this. Maybe relax the NSF standard slightly, to indicate that this (or something like it) is permissible?
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF player "cheats"?

Post by rainwarrior »

I thought it was already mentioned on the wiki, but apparently not, so I've now added a note about this: http://wiki.nesdev.com/w/index.php/NSF# ... RQ_Variant

On further consideration, perhaps we should consider promoting it to an official part of the spec, though? The complaint was that it uses SEI to mask hardware interrupts, which interferes with hardware that might rely on them, but because it is a non-returning play I think it might be a non-issue. If it was supposed to drive PLAY with interrupts, SEI is actually appropriate in a non-returning PLAY.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: NSF player "cheats"?

Post by zzo38 »

rainwarrior wrote:I thought it was already mentioned on the wiki, but apparently not, so I've now added a note about this: http://wiki.nesdev.com/w/index.php/NSF# ... RQ_Variant

On further consideration, perhaps we should consider promoting it to an official part of the spec, though? The complaint was that it uses SEI to mask hardware interrupts, which interferes with hardware that might rely on them, but because it is a non-returning play I think it might be a non-issue. If it was supposed to drive PLAY with interrupts, SEI is actually appropriate in a non-returning PLAY.
That is what I thought too when I looked at it; yes since it is a non-returning PLAY, it should be safe to do so (although some hardware implementations might then make it impossible to stop the music or select a different track without resetting the console, but I do not consider this to be a significant problem).
(Free Hero Mesh - FOSS puzzle game engine)
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF player "cheats"?

Post by rainwarrior »

I've revised the wiki to explain that it's as valid as any non-returning PLAY technique, though it still comes with all the cautions of the non-returning PLAY, and a note that many players lack support for it.
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NSF player "cheats"?

Post by B00daW »

Rahsennor wrote:Point me at a stable spec for NSF2 and some test files and I'll implement it. That's my only problem here - time, documentation and testing. I'm one person with limited free time and lots of other things I'd like to do with it - and I haven't even seen a single NSF2 file. Why support something that, as far as I am currently aware, doesn't even exist yet?

Just to clear up any confusion, my complaint with your original comment was that you suggested features that would require me to emulate things like an arcade machine or a PPU, both of which are outside the scope of this particular project - I seriously doubt that any NSF-related format would require support for two CPUs or a PPU. That's the realm of a full emulator, and while I could write a full emulator if people wanted me to, there are already plenty of them out there that do a better job than I would.
I could make a NSF2 file with original music easily but unless people have the interest to create an emulated player my art dreams don't fly. You also mention Famicompo Pico. That is run by a colleague of mine (and fellow administrator) in Battle of the Bits We've been known to host competitions to test FamiTracker betas before they were released and we distributed SuperNSF source after Famicompo from mukunda and #mod_shrine.

Where I have more expertise in creative and "out of the box" thinking my expertise in high-level programming is not the greatest. I understand assembly code and hardware fairly well.

My position is advocacy for a community who does not understand potentiality of IRQ support for the 2a0x chip for music/art production. Let's consider Memblers's Squeedo cart with MIDI in and custom driver/"patches" (a cart relying on IRQ and cycle counting to produce additional timbres)... I doubt any hacking of LOAD/INIT/PLAY routines could get code to play on modern NSF players or hardware players.

I never said NSF2 was complete. It's about 90% done. I believe I remember that kev has made NSF2 rips and has played a few on his hardware player; but he and we know that the format lacks a few things and has a conflict:

1.) Nobody has agreed on where the Title/Author/Track/etc documentation header/footer is.
2.) The NSF IRQ "registers" are located overtop of the 2a0x audio TEST registers and need to be moved elsewhere. Just in case these are used.

Someone who's writing an NSF(2) player just needs to move forward with these two discrepancies to have much desired/needed IRQ supported. Who really wants to write their own hacked routine to rip PCM or IRQ related routines when a proposed format can do it. This would ease in the ripping process and allow for growth into readily-present hardware capability.

Regarding your comment on the hardware emulation requests: Most of those features are already emulated by MESS/MAME; as you say -- and there's no shame in taking readily available code. Even rainwarrior's NSFplay is hardly original. Two things out of the bunch that are not currently emulated are 2a0x audio TEST and Mitsubishi M50805 for "Family Trainer 3: Aerobics Studio"; which is an LPC decoder with factory ROM and hardware modes to allow for input of LPC datastreams. I've created test NSFs that rely on $6000-based expansion registers for this setup. (I should probably just write a test CopyNES driver with the cart in to make something artistic with my Aerobics Studio instead.)

Nobody's making you have an interest in anything because that's impossible. Interest is sprouted from within. Let me know if you want to make some music and come by Battle of the Bits for some fun.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NSF player "cheats"?

Post by tepples »

rainwarrior wrote:Honestly I don't think the NSF2 spec is really needed for any game rips, just for more modern experiements.
In other words: "I dare you to make a game with NES-Saw music."
B00daW wrote:Nobody has agreed on where the Title/Author/Track/etc documentation header/footer is.
Judging from only kev's posts, I think it's fairly clear that the first chunk starts at offset 128 + NSF[125] + 256*NSF[126] + 65536*NSF[127].

Really what I'm mostly looking for in NSF2 are track titles and lengths.
Post Reply