NewRisingSun wrote:
rainwarrior wrote:
There will be an NSFe chunk to specify "VRC7 is actually a YM2413" to support NSFs for the TNS cart that has this.
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.
No, it's a mandatory chunk that extends and disambiguates the VRC7 bit in header. Not metadata.
NewRisingSun wrote:
If anything needs patching, it's the TNS homebrew cart
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.