nesdev.com

Sounds great! There is the case of the M50805 and the Jaleco ADPCM sample chip carts for SFX one-hits in the NSF to have expansion bits; and other known expansion audio pirate carts like City Fighter.

The sample data will need to be held within the meta-data at the end of the NSF2. It would also be good to consider a way for a hardware player to access this information from ROM or have it loaded into RAM.

Stuff that can't function without a sample chunk does not need to allocate an expansion bit. The presence of that sample chunk (also marked mandatory by the NSF2 byte bit 7) is enough by itself. I'm trying to avoid redundant/unnecessary allocations.

As far as hardware players go, I don't see any real impediments to that in this file format. I don't know if a PowerPak or Everdrive FPGA has enough internal RAM to handle this stuff, and probably don't have access to an extra piece of dedicated RAM, so they might never be simulate those sample playback chips. A new design certainly could do it, though, IMO.

PowerPak's FPGA has only 3KiB of internal RAM, much less than the 12 KiB in the µPD7755, (edit:) let alone the 32 KiB of the µPD7756.

A smart-assed design could probably stuff it into CHR and piggyback on PPU fetches, however. (It would have to pre-load fetches during vertical blanking, and stall the first fetches after playback starts until vertical blanking ends)

Everdrive N8's FPGA has 13 KiB.

Players are allowed to use at least the upper area of the stack page ($01F0-$01FF). From the spec:

The precise position of the stack on INIT or PLAY is not guaranteed, as the NSF player may need to use the top area of the stack for its own internal purpose. Make sure the tune does not attempt to modify $01F0-01FF directly. (Armed Dragon Villigust did, and was relocated to 2xx for its NSF.)

All of those Jaleco with the ADPCM use different registers for sample playback. Is there a need to have them use all the different registers or can we just rip them to use one that doesn't interfere with other chips?

Well, format wise I think it would only amount to an extra byte or two in the sample chunk to designate how it's wired. Not really a problem for emulators, at least... Since they don't need to take up a (precious?) remaining expansion bit anyway, I don't think there's too much issue here encoding that info.

Like VRC6 chose the most notable game as the standard, and the rest had to be flipped in the rip. (Actually... maybe an NSFe chunk to specify VRC6 swapping would be nice. There have been several times when I've wanted to test VRC6 NSF stuff but on the other board type.)

Though modifying stuff for a rip isn't as big a deal in .NSF as it is in .NES since these are deterministic programs with no user input. It's easy to ensure you got everything, and that there's no unexpected behaviour.

So, I dunno, I'd lean toward adding the extra desgination just because I like the idea of rips that are closer to natural. I don't really mind either way. If you're making the rips I'd say it's up to you. (Also even if it could be specified in the chunk, you could still rip them all at one address if you later decided that worked better anyway.)

...though, by the same token the Karaoke cart could be ripped to use VRC7 registers instead of requiring its own expansion bit, too. I guess that'd be not hugely different than the existing VRC6 situation (just now a mandatory chunk to indicate YM2413, which I need anyway for the TNS stuff that does this.) Maybe that would actually be better, since the NSF would be nicely compatible with the TNS thing, and also not need to take up a new expansion bit.

Checking my partial implementation in NSFPlay, I actually did have N163's 'mixe' fully implemented, I think. So technically this already works in NSFPlay 2.4b5, at least for N163.

Going to fill out the rest of the 'mixe' chunk defaults soon though, writing the necessary tests today.

Pretty sure the Karaoke cart uses "rhythm mode". VRC7 doesn't support this. Also not certain if there are channel discrepancies, since the YM2413 has more channels. Best just to support it fully. Also we should try to flesh out the K-663A differences from the YM2413. I know that some bootleg arcade machines use the K-663A as well. krzsysiobal said that there is buzz or hum on it.

When I said VRC7 registers I mean the memory addresses. There will be an NSFe chunk to specify "VRC7 is actually a YM2413" to support NSFs for the TNS cart that has this.

Was suggesting that patching the write addresses in the karaoke NSF would make it completely compatible with this, and not require yet another expansion (analogous to the way we patched 2/3 of the VRC6 games to run on the other VRC6 configuration for NSF).

An extra chunk indicating that a header bit doesn't mean what it's supposed to mean? Please not, that's the epitome of a hackish solution.

If anything needs patching, it's the TNS homebrew cart using a hackish way to achieve something that the NSF spec did not actually support. I still advocate using another expansion bit for YM2413 instead of using an extra chunk to redefine the VRC7 into an YM2413 (as if the YM2413 were a "kind of VRC7"). It's cleaner that way, we've got enough extra bits left in the header (two in $7B, and $7C still has four reserved bits even in NSF2), and it would also allow using YM2413 alongside a VRC7.

I agree with that.

No, it's a mandatory chunk that extends and disambiguates the VRC7 bit in header. Not metadata.


You can't patch the cart, it's hardware. It's a real NSF player cart that already implements this, and they've been making it for a while now. NSFs are already out there for it. I'm not going to create some alternative NSF spec that's incompatible with what it already is, that would defeat the point of adding support for it.

If you're complaining about whether a rip of the Karaoke cart should be remapped to this... that's a different matter entirely. A rip can be patched. Family Noraebang is not an NSF player, and doesn't relate with the NSF spec in the same way.

NSF is not like iNES at all. iNES is trying to take a pristine ROM dump and give enough information to run it. NSF has always been about modifying the dump to just play the music. Because NSF programs are deterministic this is very practical, and relatively easy to verify that the modifications were done correctly. Completely different situation. The Karaoke rip can be remapped to this with zero difference in output.

So the bottom line is: I'm implementing the VRC7 disambiguation chunk to support the TNS player method of replacing VRC7. It already works, and it's just a continuation of it. Whether or not we think the Karaoke cart deserves an entirely new expansion... maybe up for debate, but I think there's a lot of advantage to reuse this one that we've already got practical implementations of. The rip could run today on existing player hardware. Even for prospective emulators, it's less code to maintain, have bugs with, etc.

As for whether every conceivable expansion has to be made possible as a multichip, I don't agree with that. If it's convenient, fine. If it's not, I think other concerns are more important. The fact that the original 6 expansions were (eventually) made mutually compatible was more of a lucky accident than anything else. We don't have a separate expansion bit for VRC6a and VRC6b, kevtris just remapped that. Much more practical. You could build hardware that lets you stack 6 VRC6es if you want, but I'm not really going to add constraints to my plans to ensure that this is a future possibility. Show me someone actually making multichip music with Family Noraebang and maybe I'd think differently about how important this is.

That may be the case, but accurate emulation of the expansion sound hardware is why we have such vibrant chip music communities. Might as well shove the YM2413 (K-663A) in NSFPlay and quit whining, bro. Also, I think there's some rhythm mode in the Noraebang songs so VRC7 wouldn't work.

That said, my personal opinion is that I'd really like to stop the conflation of the YM2413 and the VRC7 ... and per plgDavid's video I didn't even know there were apparently three different versions of the OPLL, all varying just by baked-in patch set: YM2413, YMF281 ("P"), YM2423 ("X").

... it's also not clear that the defined binary interface to talk to the simulated IC has anything to do with preventing this conflation.

Read what I wrote. I'm not saying to play it back as VRC7, I'm saying to add a disambiguation byte that says which chip goes at those register locations. Basically exactly what the TNS cart that already supports YM2413 does. If you specify YM2413 you get a YM2413. YM2413 has rhythm mode.


It's not conflating them, it's just using the same MMIO location to drive either one. The actual chip to use will be specified.

I meant and should have written "NSF files written for the TNS cart should be patched". It bothers me to reward the TNS makers' non-standard implementation by retroactively standardizing it. It is similar to some people's opposition to supporting MMC3 ROM hacks, as well as Chinese MMC3-clone RPGs, with more than 512 KiB of PRG-ROM as Mapper 4.

But lidnariq's comment has changed my mind: if there are now four different YM2413-like chips (YM2413, YMF281, YM2423, VRC7), each with a different set of default instruments, then I would support renaming NSF header byte $7B bit 1 to from "if set, this song uses VRC7 audio" to "if set, this song uses YM2413-like audio", with the VRC7 variant being the default variant, and a mandatory chunk after the main NSF data indicating YM2413 variants other than the VRC7. This would of course accomodate files for the TNS cart as well. This is basically your plan, but the description of byte $7B bit 1 should definitely be explicitly changed then, otherwise people will start thinking that the YM2413 is a kind of VRC7, when the reverse is the case.

I have no preferences regarding the addresses at which the chip responds; make it just $9010/$9030, variant-specific addresses, or both.