I'm not trying to "reward" anybody. I'm trying to avoid creating new incompatibility in the world. The TNS cart is a real NSF player with a practical way to offer a YM2413, and many of these devices were actually produced. This also conveniently already has NSFs, it's not just theoretical. I want to reuse this existing implementation instead of throwing it away with another arbitrary standard. I don't care whether it's how I would have done it or not; it's here and it works. It wasn't really just the TNS either. Multiple people have been doing experiments exchanging YM2413 for VRC7 for years, but TNS actually made a production of NSF player carts for it. I also think it makes for a succinct and practical implementation.NewRisingSun wrote:It bothers me to reward the TNS makers' non-standard implementation by retroactively standardizing it.
Similar reason why even though nobody ever used it, I want to keep almost all of kevtris' original NSF2 spec. ...or why I think it's better to keep deprecated submappers and use new numbers rather than reassign them. (As for the opposition to 7-bit MMC3 PRG in iNES mapper 4, I've never really understood that, but I don't really care to argue about it. All I cared about was oversize BNROM. ;P)
FWIW those NSFs do have to be patched with a new VRC7 disambiguation chunk, version 2, and the "mandatory chunks" bit to get it, just the code portion wouldn't need patching.
I'm not referring to the old NSF 1 specification. This is a new proposal, there is no written definition at this point.NewRisingSun wrote:... the description of byte $7B bit 1 should definitely be explicitly changed then...
Well, those could get an enumeration in that same disambiguation byte as well if someone wants to use them for NSF. Right now plgDavid seems to be experimenting with them, that's fine, but it doesn't need to be part of NSF yet. The spec can change when it needs to.NewRisingSun wrote:...there are now four different YM2413-like chips (YM2413, YMF281, YM2423, VRC7)
Well, it was just the Family Noraebang Karaoke that would potentially move for this, and really my whole justification for that is that we can perfectly accommodate it this way without adding more encumbrance to the specs/implementation.NewRisingSun wrote:I have no preferences regarding the addresses at which the chip responds; make it just $9010/$9030, variant-specific addresses, or both.