Since this is now available, what is the consensus of how it should be allowed to enter into battle versus standard?

- SuperNSF is 2a03 plus up to 4 PCM channels.
- SuperNSF+ is currently 2a03 and VRC6 plus up to 4 PCM channels.

Basically anyone that can track IT can create a SuperNSF.

First off, it's not a hack. "SuperNSFs" are playable on hardware. So, this really doesn't compare to dual POKEY...

My thoughts:

I say we let SuperNSF in standard NSF battles and SuperNSF+ into NSF+ battles and let those who vote use their own discretion on how they feel with vote points.

And the rest of you wonderful peoples' thoughts are...?

I believe it should be permissible unless the rules disallow it, though I guess that for a stock NSF compo it may have to be restricted. But NSF+ totally calls for it.

+ means expanded. SuperNSF is unexpanded.

http://kkfos.aspekt.fi/projects/nes/tools/pornotracker/ <-- you talking about this?

If so, it's not supported by the .NSF playback format. :(

If you are talking about soft-mixing supported by .NSF it's worth considering!

PornoTracker is great, but I'm talking about SuperNSF.

http://lmao.rotfl.at/upload/B00daW/supernsf.zip This is the brainchild of mukunda and tumult of #mod_shrine. All documentation is included and NSF export is supported.

Wait, has a tool for creating PCM NSFs been released to the masses? In any case, this came up somewhat suddenly.

I agree with B00daW's idea 110%. Even though PCM NSFs are becoming more of a gimmick, it's still a slap in the face for compo participants who are composing via traditional and more challenging methods. Imagine, soon our NSF and NSF+ OHCs will be filled with these bitchslaps just because everyone will be worried about their competitive edge!

If you're going to go all unorthodox with yer NSFs by being #mod_shrin ppl, plz take it in another format plz! =DDDD

EDIT: My idea for the icons: Keep them the same as NSF/NSFPlus, but palette swap them with the colors of the GIANTO MUSHROOM.

WTF is a "GIANTO MUSHROOM"?

I just wasted 7 minutes in g00g0l time. xP

Haha.  I meant to type "Giganto Mushroom". I was too lazy to look the actual term up, but I meant the . Maybe the NSF/SuperNSF icons would be too alike using those colors?

Still, I don't think it should be a different format unless the majority says so after many battles.

/me think it should be a different format or at least there should be a "traditional nsf"format with no supermodelling aloowed in the same way there's a milion different module formats here for different tastes (and i hatez supernsfbutt)

There are 2 options I'd like:

one: separate formats, so one with SuperNSF allowed, and one without
or
two: just have hosts state whether it's allowed in that compo.

hmm...

I could add an NSF/PCM format. The + or VRC6nesh of it should be declared by the host.

But there are a few things I need clarified. What is the quality of the PCM format? Is this a software mix to the DPCM?

I'd like to keep pure o|d5kul3 2a03 the way it is.

The quality is better than DPCM in terms of not mangling your samples. It's worse in that it's a lower samplerate. It's pretty much done by writing to the DPCM position register IIRC.

Personally, I <3 SuperNSF. It's so nice! Especially because it sounds like shit :DDD

Also, who has tested to see if a SuperNSF works on hardware?

Oh, it will work on hardware perfectly fine. I might hook up my CopyNES and PowerPak just to prove it in a bit.

null1024: You're right. It uses the first 7 bits of the $4011

register. tabled PCM data is streamed into the register at a specified rate versus clock speed of 1.79 MHz (NTSC); also counting the cycles of code already running.

"Heim this!" by madbrain, included within the SuperNSF package, demonstrates that the noise channel is used at a low volume in order to "fill in the gaps" of the "sounding like shit" audio in order to "trick the ears." ":D" In fact Strobe uses this technique regularly whenever he can't make his DPCM perfect enough. ;D/

Btw... SuperNSF needs all PCM samples as 8-bit. It's also not really an advantage in battle unless you already have a comfortable SuperNSF and tracker environment set up already.

...Not to mention control over the 2a03 noise channel is total shit and FamiTracker is superior in its manipulation among other things.

I have a very comfortable SuperNSF environment set up, it's almost [or maybe even actually is] nicer than using IT2NSF. PCM samples as 8 bit is to be expected, and generally, I don't expect to use it for much other than more chip-sounding channels [and maybe a voice sample thrown in :D]

my main problem with it is that it sounds completely different, and i think to me botb is about music (sound) more than codewank (ok, yes, technically it is an nsf file)... i suggested a checkbox when begasting an nsf ohc to specify whether supernsf type things are allowed or not;;

omg this is so interesting!

i also just wanna point out that there are already 8 sample-based formats, plus allgear and wildcard, so turning a unique format like NSF into the 11th sample-based format seems a bit >:( to me

supernsf in an nsf compo is basically pitting .it vs .ftm (ok, it2nsf, but that's an .it that has constraints forcing it to sound pretty much identical to ftm) - aside from the technical side of it, there's really no musical similarity between supernsf and a "traditional" nsf. a compo format that goes "you must use 2 pulse channels, 1 triangle, 1 noise and 1 dpcm *OR* pcm samples of whatever you feel like" is a bit odd to me. supernsf is musically completely unrelated to a trad. nsf - none of the same constraints or limitations imposed on the composer and the end result sounds completely different. if amiga used an nsf-like format would we be putting MOD and AHX in the same competition? i'd hope not. i'm not saying "supernsf has no place at botb" but that supernsf and trad. nsf in the same competition is a bit silly.

in the nsf+ compos, however, there's always a bit of arbitrary expansion and people aren't all working within the same limitations, so i have no problem with supernsf/supernsf+ being allowed in the nsf+ compos.

by making chiptunes we are *by definition* arbitrarily shunning advances in technology and doing things "the old way" ... let's carry on in the nsf compo please.

bah, if all else fails, i'll just wait for the novelty to wear off, i suppose.

love you all

xxx

ant1, I love you!

it2nsf and supernsf are exactly the same. Your limitations are IT. FamiTracker allows you more control over the chip with macros, envelopes, and refresh rate; which nobody seemingly other than me uses.

+ indicates expansion. Making SuperNSF only allowed into + would break a fundamental value.

The only way to solve this issue is to continue to have more OHCs and find out what suits the majority.

"it2nsf and supernsf are exactly the same" except that it2nsf you have to use two channels of instruments with pulse, one channel of triangle with no volume control, one channel of noise, etc, whereas supernsf you can have a sampled trumpet, an accordion, an orchestra hit, a rave stab. EXACTLY the same...

"it2nsf and supernsf are exactly the same."

What? ant1 just explained that it's the opposite in his last post! it2nsf only gives others a familiar environment in which to bathe in the chip! It's just another traditional composing tool.

SuperNSF allows people to compose .ITs like .ITs and then play them back on a NES. It doesn't make people compose .ITs like NSFs.

SuperNSF isn't exactly like an IT though. You only get 4 channels to do all your sample madness, and if you use the full compliment of 4, it sounds like shit due to the low frequency playback [unless you're extremely careful].

Using it feels like a far less restrictive expansion [this is a vote to put it in for NSF+ only, if the supernsf checkbox idea doesn't go through].

On the other hand, in a 2a03 only compo, having the ability to pull shit like this off: http://dl.dropbox.com/u/6443934/insidious_sick.nsf is a bit ridiculous [although, that would be downvoted, despite not breaking any rules, yet].

Take note that the PCM bit sounds like shit there -- it doesn't sound exactly the same as the source XM/IT, and you have to work to try to get it to sound good.

What are the resulting file sizes from these? Perhaps a maxfile size for .NSF would help? 24kb anyone?

OK. This is getting beyond ridiculous.

My point is being proven and time and time again no matter whose fingers it comes from. SoiledBargains states that using SuperNSF as a tool, you are able to compose a song with its standard channels and registers to replay on hardware on its respective chip. The + format, denoting expansion, was created to level the playing field from one chip against multiple chips. The standard thus far is even with any and all chip formats. Expansions are common in most hardware platforms. TIA, POKEY, SID, PSG, Beeper, Channel F, AY, and any or all chips can also output encoded samples via their internal hardware or by PCM and/or PWM, but are not standardized. TIA has commercially been capable of being paired with DPC (Pitfall II (2600)) or POKEY (Commando (7800)). This would be TIA+. POKEY can be paired with GTIA. This would be POKEY+; etc and so forth.

Let's get back on topic of the 2a03 and its sample register. Back during the NES/Famicom's commercial life, due to RAM prices and CPU usage, DPCM (1-bit encoded) samples were preferred due to RAM costs and cycle saving for screen animation and other code-intensive processes. Now that RAM is no longer an issue, memory mappers can be made to suit anyone's purpose, and games are no longer the intention of these sound chips, people can take full advantage of their hardware.

So 7-bit PCM sounds a lot better than DPCM, right? And we can have 4 PCM channels, right? (The fact is that even more PCM channels could be made with quality degradation.) With those PCM channels, any sample can be made among the programmable "channels." What an innovation! Sounds like a game-changer to me. No hardware hacking is necessary and more audio is available at our fingertips. Should DPCM be deprecated? Of course not. In fact, there is a developer in NESdev right now who has proposed a 128 megabyte PRG and 128 megabyte CHR mapper. This allows for more space for (D)PCM usage as a whole. Shall we simply stop using the 2a03 chip due to innovation; or because we resist change?

The NSF mapper does not truly limit the size of DPCM that can be used with its memory bankswitching routine and the limits of the 2a03's internal RAM itself. Strobe's Ziberia is an example of this; using no PCM and coming in at a whopping 400+ kilobytes. If finding a way to disallow SuperNSF and/or PCM usage, or finding a workaround to making things more "level", size limits will not fit the bill. The only logical deduction would be to allow the limits of the hardware to define the borders of creative fairplay.

In summary and conclusion, times change, rules change, tools change, genres change, tastes change, people change, and everything will eventually change. These things do not degrade our skills, desires, competency, and enjoyment unless we let them with our own limitations.

Let's not limit creativity due to opinion. Let's make up the difference with our skill, passion, and individualism with all the tools that we are provided within their limits.

Much love, BotB.

- Uncle B00daW

Let me clarify my point. I understand that (D)PCM playback is, without a doubt, a feature of the Famicom. I acknowledge too that some commercially produced games used this feature, whether it be for music (or was that never done?) or higher-quality samples. But the problem is, tools that make music using this feature isn't with the spirit. I thought the reason we made chiptunes for the 2A03 is to relive the 80s (or as it is for many of us, our childhoods) and compose music conventionally like most composers from the Famicom days. This was when PCM hackery was limited to few games for temporary effect, and when DPCM was either not used at all or was used at varying extents. In fact, as you could conclude from B00daW's post, doing PCM output gives you very little available resources in return, which is why this was never used often even in later games.

I know, Strobe breaks this rule with his DPCM whoring all the time. But he's just a guy who can get away with anything around here, somehow. It works, probably because there's a secret to it, and no tool for it, either.

I'm all for pushing a system like the NES to its absolute limits, especially with the possibilities we could have with such a huge mapper (OS on a cart!).

At the very least, I'd support SuperNSF's use in NSFPlus. Just because it's uses the APU's $4011 and sounds like crap doesn't mean it can give an unfair uppercut to others.

But maybe you're right. Maybe I'm not able to accept this change. Maybe I'm not up for most of our NSFs turning into a completely full-fledged, demoscene-like-muscle-pumping format because everyone (save for the very rare participants that are composing masters) would be using it to keep their edge.

"I know, Strobe breaks this rule with his DPCM whoring all the time. But he's just a guy who can get away with anything around here, somehow. It works, probably because there's a secret to it, and no tool for it, either. "

Thats a nice personal attack there! and as usual without anything to back it up!

i still disagree but i'm obviously outnumbered and botb isn't all about me, so i'll leave it and live with it

=)

Im still up for creating a SuperNSF specific format for the major compos.

OK.

Talked to the the guys at #nesdev and found out the best solution for the scenario.

Globally there needs to be a 256K file size limit for all NSFs. PowerPak supports up to a maximum of 512KB of PRG RAM with a minimum of 8K bankswitching. Since the NSF mapper scheme uses 4K bankswitching, and if a 256K NSF is loaded, each 4K bank would be doubled to an 8K bank as a dirty hack to allow for NSF playback; filling the PRG RAM. 8K bankswitching is a hardware limitation for the PowerPak and cannot be fixed with FPGA code or a BIOS revision.

(D)PCM and musicdata together are limited for PowerPak hardware playback to 256K NSFs; until other hardware solutions are designed.

I'm gonna look at this from BotB's perspective. If I ever write a file header check, these SuperNSF's won't register as anything exceptional unless they use expansion. Byte 007b_h declares which expansion is in use with each bit as a flag.

There will be no new format.

If you have issues with this, vote accordingly. BotBrs who want to try it should be advised there are nostalgic purists in their midst. Plus, a super NSF article could be helpful in the lyceum.

Strobe, I'm sorry! I didn't mean it that way! I meant to just say your unique DPCM technique is an exception to many and myself!

B00daW, I mustn't be understanding something. I have been able to play PCM NSFs in upwards of 400KB in size on my PowerPak with the latest mappers without a problem.

Anyway, looks like puke7 has settled the matter, which is nice! :D

[10:44:41] <B00daW> in theory, no NSFs >256K with latest hardware, boot ROM, and NSF mappers should function correctly, right?
[10:45:19] <retrousb> right, because of the rom wiring >256KB will never correctly load
[10:45:29] <retrousb> because of ram wiring

From the horse's mouth.

Most likely if something loads, it will partially load and then the 4KB banks will double to 8KB and either entirely break things or allow for partial functionality.

I have the latest mappers, save boot ROM (a cosmetic fix only), and cannot load any NSF >256KB on my PowerPak. :P If one loads for you, good! But you cannot expect full functionality or functionality itself. :)