NSF PCM technique (via Deflemask)

From the new NSF export available in Deflemask, it looks like Delek found a very interesting technique for doing PCM in NSF. I hope he doesn't mind me sharing. It's not open source, but it's pretty easy to deduce from a debugger:

During INIT:
1. SEI
2. Write $00 to $4017

Non returning PLAY:
1. SEI
2. PCM playback loop with a poll of $4015 after every loop.
3. If $4015 bit 6 is set, do your regular music update, then return to loop.


I was surprised to find that many NSF players, including the PowerPak, support this. There are a number of players, however, which do not really support this feature of the frame counter (NSFPlay included, though I've been meaning to rewrite its frame counter).

Anyhow, this is pretty interesting. It seems a lot more viable than the non-returning INIT hack supported by foo_gep. Obviously it's got a few support problems (use of SEI is bit of a red flag to me), but I thought it was pretty cool that it works with a lot of NSF player implementations. Also, from what I remember reading, $4015 will fail to clear bit 6 if you read on the same cycle it's set? Maybe you'll get a double frame now and then.

This is surprisingly simple, but would be completely pointless in an actual game unless you freeze all action.

Most people making NSFs don't care about actual games...

I understand their viewpoint, but to me it's a little weird. Why limit yourself to a NSF if you're not going to use them in games or tech demoes or any sort ?
They could just use a tracker which does lack the NES' limitation and use chiptune-like instruments to get the same result, but with correctly pitched high triangle note, no channel limit, all the PCM they want (and they could use GOOD sounding drums instead of horribly noisy DPCM), etc...

Again I myself did several nsf without the intention of using them in any game nor demoes, mostly cover of othre video game music, and the main purpose was to play with the chip extensions (FDS, VRC6, ...) to see what they are able to do. VRC6 is my favourite, it sounds amazing. Way better than VRC7 and even N106 for some reason.

It's like one day I remembed I found a nsf (cover music from a more modern video game), which used something like 4 of the 6 sound extensions possible AT THE SAME TIME. The guy who made this definitely didn't care about actual game/demoes, and doesn't even care about limiting himself to something possible on hardware, because it's not possible to have more than one mapper at a time. I'm already seeing teepple's answer : "You could build a new mapper with more than one sound chip". yes you could, but that's not how it was supposed to work.

The MMC3 multicarts already have two mappers at once: one for the game to use and one to select a game. In the case of mappers with Famicom expansion sound, you're correct that only one mapper can control the PRG ROM address lines, but multiple mappers can listen for writes. In fact, several Jaleco games have sampled sound as a separate chip from the mapper. Along the same lines, I remember reading about a project where someone rigged up an MP3 player that plays through the Famicom audio path, at which point chip games can use essentially CD music.

As far as I know, the SuperNSF engine is the undisputed king of using PCM in an NSF file. It's a multichannel PCM mixer/mod player.

Multi sound expansion hardware is possible and has actually been done. Unfortunately, the company that built them only ships to Japan.

SuperNSF and MUSE use the technique of non-returning play and carefully timed code. It's supported by most players, but it's harder to maintain the code.

Here's a clip of multi-expansion being done live on hardware:

Part 1
Part 2

The DJ in the video is actually Robokabuto himself. What's more, he used a YMZ-294 instead of a Sunsoft 5B. :p

But that's besides the point here. As tokumaru pointed out, basically I treat the NES/Famicom as I would any other synthesizer, really. I don't really care about using my NSFs in games or tech demos; all I'm interested in is making music that pushes a system to its very limit. In my opinion, PCM falls under that description, regardless of whether it's feasible in a game context or not. I think this 'hack' Delek found would be pretty neat, if not for the fact that it's incompatible with most NSF players (including NSFPlay). I haven't tested it on my TNS-HFC3 yet, but I'd wager that it doesn't work, despite reports that it does the Power Pak.

If the TNS-HFC3 player is based on NMI, then it should be okay, actually.

Interesting, but... you know the famicom has an audio_in pin, therefore it does not have any limit. You could just make any music, and make it play on a famicom somehow. Not the most interesting challenge, huh ?

When it comes to the NES, it's only limit is that PCM is restricted to 7-bit DAC via $4011. I guess you could just make any music, make a mapper that computes it in a 7-bit value, and have some program doing a lda $wathever sta $4011 loop forever. This is not quite limitating either.

Somehow I suspect you're being a prick on purpose. I suppose I'll go back to lurking if this is how this community reacts to free speech.

Don't worry... Bregalad sometimes has a hard time seeing things from a perspective other than his own (if people do things differently from him it takes him some time to understand that, well, people are different and have different opinions and tastes), but he's not a bad person and would not be a jerk just to piss people off.

I get him though... for us, who like to make games for the NES, it may sound weird that for other people it's just a musical instrument. But this is a fact, so we just have to deal with it. I assure you that this community has nothing against free speech! =)

I'm just bored with people getting on their high horses, telling me that I do what I love to do for the wrong reasons. I'm not talking about Bregalad specifically here; this isn't a personal attack in any way, just an observation that I've made over the 5-6 years that I've been doing this. For example, there isn't a FamiCompo event where a select few complain about tunes that use expansion chips (sometimes more than one OMGOMGOMG*gasp*) because it's "not meant to be that way", "that's not what the NES sounded like" and whatnot, and I'm supposed to adhere to those people's view of what my pasttime and passion should be about (or else they'll downvote my tune that I put the same care, passion and effort in as they did their own!). So yes, I get a little pissed off when I respect other people's hobbies and opinions, but I don't get the same treatment in return.

Bregalad is 100% entitled to his view that NES or NSF coding should be made with actual programs in mind. I see where he's coming from. But I'll tell you this: the NES system is older than I am; I didn't grow up in that generation of video gaming system. For this reason, the NES holds very little nostalgic significance for me, and I don't get that feeling of "impurity" when I or someone else makes something (a demo, a piece of music or anything along those lines) for it that doesn't reflect the machine's past - that isn't "what the machine was designed to do" - au contraire, I find it brilliant thay they're effectively thinking outside the box, and doing things that weren't intended by design.
That's also why I don't find it "weird" to treat the 2A03 (and the Famicom's expansion sound hardware) in much the same way that I would any synthesizer. But in spite of that, I like the idea of sticking to the console's basic limitations, and dislike working in a non-genuine environment like a generic XM/IT tracker with faux-8bit samples. I like the authentic sound of the 2A03 (and the expansion audio). Heck, I like it so much I spent hundreds of dollars to get myself a NTSC NES, a PAL NES, two Famicoms, a Power Pak, a TNS-HFC3 and one copy of every expansion chip to ensure I get as authentic a sound as possible when I play my tunes back. Big deal, you'll say - but that's just to show how passionate I am about Famicom music. And I'm supposed to be doing this for the wrong reasons? What I'm doing is weird, somehow?

Look at it this way: NESDev is a community that essentially consists of people who program on a console that's older than I am. Yet I'm the weird one because I use the same machine in different ways by making music for it for the sake of the music itself?

Lastly, the thing that got to me is the attitude conveyed by this sentence:

This strikes me as both arrogant and pedantic, and that's what grinded my gears in the first place.

Besides - if we're going to go down that slippery slope - could one not say that programming for the NES isn't an interesting challenge due to the fact it has an expansion port that you could wire a modern CPU and GPU to and run a modern program? That doesn't really hold water, does it.

What I'm trying to say is, I admire and respect every one of you who makes wonderful things with the console; all I ask is a bit of that same respect in return.

Bregalad, si tu parles français, je t'invite à exprimer ton opinion en la langue de Molière si cela peut te permettre de mieux transmettre tes idées sans la barrière de langues.

Anyway try Deflemask it's cool~~

I think the fundamental question comes down to what are we really writing a synthesizer for? Is the NES? The Famicom? Or the NSF format? It seems that using multi-expansion audio or 7-bit sample playback are targeting the NSF format, and not targeting either of the first two. And that's ok. But the people who are still thinking of these things as music for NES games are upset by it because it's not music for NES games. Which ties directly into the followup question of "if you're not keeping faithful to the constraints of what could have fit in a Famicom game, why aren't you using a more capable synth?" (To put it another way: Are you allowed to use the 2MHz 6502 as another instrument, or is this really about the sound generating hardware? Logged formats like .GYM can't have this question.)

Tangenting: the ability to set callbacks to a rate other than 50 or 60 Hz is also not exactly all that faithful, but I don't think we gave Neil Baldwin any crap for PR8.

Bregalad has freedom of speech too, you know.

Personally I prefer listening to plain old 2A03 tunes, because that's what I'm most familiar with, and it's easier for me to compare things that way ("oh wow, wouldn't have expected 2A03 to sound this good" vs "I have no idea if this is an achievement on 2A03+whatever expansion chip(s)"). But like you said, this is just a hobby for people, so everybody can, and SHOULD do whatever they get enjoyment out of.


How is using 7-bit sample playback not targeting NES/Famicom? That's a perfectly usable technique in games/demos, even if it's only in title screens, cut scenes etc.

I apologise to sound arrogant and to have driven you to tears, and yes I would never get in the way of a music compositor for dumb reasons.

However, what I was saying is that using more than one expansion chip makes few sense. Don't get me wrong, I am facinated by expansion chips too, and as I said above, I made several songs for them in PPMCK just for the sake of trying expansion chips, without any intent to use this in a game or demo ! I perfectly see where the fascination for expantion chips come. In fact the Famicom is probably the only video game console to ever had something such as expansion sound chip (if you don't count SNES's Super GameBoy).

The point is, the fact the .nsf format allows multiple expansion chips at the same time was, technically, purely accidental. Some guy decided some day that the .nsf format was like this, that every existent expansion chip would get a bit, but this guy could have decided instead that 0 = no expansion, 1 = MMC5, 2 = FDS, 3 = Sunsoft 5B, etc... and this way nobody could have ever thought of using more than one emulated expansion chip at the same time.

I can understand why people would compose in the .nsf format instead of a more sophisticated trackers using "artificial" square/triangle/saw wave samples, but I don't get people that compose specifically for the .nsf format something that could not be made in a famicom cartridge.

Also using the NSF format allows to use more than one expansion chip at a time, but it does not allow to use another expansion chip that wasn't ever put in a Famicom cartridge, which would be very possible. Imagine a SPC-700 in a NES cart

Oh and should just point out that I, too, am younger than the NES, and I too didn't grow up with one, I grew up with the Playstation 1


Sounds cool - would you mind how do you replay NSFs with the FDS RAM adapter ? I'd be interested, because rewriting FDS discs just happen to be almost impossible alas Simulting the FDS disc drive and attaching the RAM datpter to such a simulator doesn't sound much more feasible either


True, but you'd have to consider that CPU time and ROM size are limited, which really reduce the usefulness of 7-bit PCM unfortunately.


It's possible to update faster than 50 or 60 Hz, it would just require a mapper with cycle counter IRQ, such as the FDS-RAM adapter or FME-7.
The problem is the limited CPU, something that updates at 500Hz (like Super Mario World's sound engine) would definitely be a no-no.

So am I. Perhaps the problem is a difference in what one perceives as counting as the "entertainment" in Nintendo Entertainment System.


Changing the APU parameters mid-frame with a timer IRQ is no less faithful than changing the scrolling mid-frame with the same IRQ.


Or, how I express it when NovaYoshi plays some NSFs on his audio-modded NES: "What chip does this use?"


Or the Sega CD. Or the TurboGrafx-CD. Or the Nintendo Play Station (which was canceled here but apparently did see release in the Potterverse). I think the Game Boy Color had something called "Pocket Music" that would work only on a Game Boy Color because the Game Boy Advance lacked the analog audio path. The GBA needed its own version that worked with the GBA's PCM channels.


The NSF format specifies that the NSF mapper, not the expansion sound mappers, controls the PRG ROM's upper address lines. With that in place, multiple mappers can be on the board, watching the CPU bus for writes to their particular synths. Some mappers have overlapping address spaces, but those can be worked around. For example, don't put code at mapper port addresses if you're also using FDS, and make sure the Sunsoft 5B's port address is at $0E or $0F while writing to the N163. In such a case, I see no reason why multiple synth chips can't be soldered to one board and mixed by the cartridge before sending the signal to the Famicom.


Desolder the FDS mapper chip and put it on a custom board.


True, CPU time is limited, but in #nesdev, kevtris reminded me that 4 MB flash chips are cheap. I've implemented a 4-bit ADPCM codec that plays back at 8000 Hz, and at that rate, one could fill 3/4 of the ROM with 13 minutes of audio and still have space left for a game.


Are you talking about the original SNES version by Nintendo or Hummer Team's port to the Famicom?

But let's look at it: Imagine DMC set at the slowest rate ($0). This would tick once every 428 cycles (4182 Hz) and fetch a byte every 3424 cycles (522 Hz). Now imagine using the DMC to play a 1-byte $00 sample with an IRQ at completion. A music engine that doesn't use DMC for audio would end up not making an update most of the time the IRQ handler calls it, so still only a few percent.

Even the Atari 2600 had expansion sound in Pitfall II, which is impressive considering that the extremely limited cartridge connector barely has enough lines to access a ROM chip (+5V, 2 GNDs, 8 data lines and 13 address lines for a total of 24 lines), and the cart can't even tell if the CPU is trying to read or write (carts with extra RAM usually used a memory range for reading and another for writing, so that address lines could be used to tell reads and writes apart). Anyway, apparently the sound chip in Pitfall II directly controls the internal sound registers to produce richer audio than would be possible through software.

Actually, I'm afraid what I said isn't entirely true: I haven't got a Disk System unit (yet). I think Terra Network Systems (the company behind the TNS-HFC3) actually had plans for an adapter that would let you connect the FDS RAM cart to the HFC3 in order to let you play FDS NSFs. I don't know whether they actually went through with that project or if it's still under development though.

I haven't got a 5B cart either, but jarhmander (aka ~J-@D!~) ordered a bunch of YMZ284 chips, and we have already planned to meet up in order to create a custom circuit that would let me use one of these on my HFC3.



Hooking up an OPL3 or similarly powerful chip to a Famicom and writing music for it is a fantasy of mine actually. Not that I'd ever have the know-how to actually go ahead and do it, but it'd be interesting. 2A03+SPC700 would definitely be interesting as well, so would 2A03+SID (I know quite a few people who agree on this one as well, haha).

I think that'd be pushing it though. Might as well make an NSF and a SID separately and mix them in post-production, I think...

Currently, DotFami does not allow audio expansions that were never put in a Famicom cartridge either, with the exception of an extra 2A03 audio (no CPU) unit. If you are interested in it, we could add such commands to DotFami for OPL3, SPC700, SID, or whatever you are interested in.

If you are connecting these audio chips you would have to figure out how the addressing will be connected!

If you want to mix the NSF/SID in post-production, then another possibility would be to use some kind of preprocessor to convert one .MML file into two separate ones for .NSF and .SID output, or to make a program which compiles a single .MML file into different notes for .NSF and .SID. If you are converting MIDI or tracker formats, we could have a program to take only some channels and omit the others, some channel for .NSF and some channel for .SID.

If I remember well, OPL-3 was this chip used in old PCs as a (terrible) MIDI synth. I used to make a lot of music with it (without knowing it) back when I was a kid, but now I hate it's sound - brings back bad memories of having such a lame lowcost soundcard on my PC. Now thank to BASSMIDI and soundfonts I can have high quality sound fonts without even needing a dedicated sound card.

Back on topic - I think the VRC7 sounds quite similar to the OPL-3, but I think it's even worse as it lacks drums, has only 6 channels, and only a single customizable channel. Well again, I like PSG and PCM, but FM modulation is not my cup of tea, probably because of what I just said above.

I agree NSF + SID would be cool, in fact this probably would have happened if Nintendo didn't remove the possibility of sound expansion in their westen cartridges. While the SID was extremely popular in western countries, it was probably unknown in Japan.


There is quite a few chips in the RAM adapter, they are somewhat undocumented. It would be easy to see which one is responsible for the extra audio channel by looking at the PCB layout, but it probably has some other functionalities too.


I forgot about the XXX-CD consoles because they weren't released in Europe and they are almost like new consoles in themselves, like the FDS is almost a different console than the NES (at least GameFaqs separates them in different "consoles").
I never heard about the Pocker Music, and other than that I don't think any GB carts ever used the extra audio pin, which is so much a shame. But I can understand why companies would choose to place a good sound chip in consoles rather than assuming the extra costs of having an additional sound chip in many manufactured cartridges.


I was talking about the SNES Super Mario World, whose music's engine updates at 500 Hz (as does most of Nintendo's SNES games). Of course it would be possible on the NES, but your music engine would have to be extremely fast since it will be called 10 times per PAL frame. Updating 2 or 3 times per frame sounds like a better compromise to me, if meant to be used in a game of course.

I just throught : You'd be better composing music for the GBA which has hardware (real !) PSGs + arbitrary PCM.
Unfortunately the PCM is 8-bit, the Nintendo DS solves this where it has 16-bit arbitrary sound channel similar to SNES' and can still do native PSG on those channels.
This also avoids the problem to have to buy so many rare Japanese cartridges just for their expansion chip.