NSF Extensions, NSF2 and NSFe (2018)

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by rainwarrior » Sat Sep 01, 2018 10:45 am

NewRisingSun wrote:It bothers me to reward the TNS makers' non-standard implementation by retroactively standardizing it.
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.

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.
NewRisingSun wrote:... the description of byte $7B bit 1 should definitely be explicitly changed then...
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:...there are now four different YM2413-like chips (YM2413, YMF281, YM2423, VRC7)
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:I have no preferences regarding the addresses at which the chip responds; make it just $9010/$9030, variant-specific addresses, or both.
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
Posts: 1060
Joined: Thu May 19, 2005 11:30 am

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by NewRisingSun » Sun Sep 09, 2018 4:58 am

As promised, here are preliminary rips for your testing purposes.

First, from a OneBus game that uses the second set of APU channels (without PCM), plus a very preliminary, unordered and unoptimized rip of Family Noraebang using the YM2413. I took the liberty of using bit 6 of the NSF header's expansion byte for OneBus. For Family Noraebang, I moved the chip writes from $6000/$6001 to $9010/$9030, but otherwise only set the VRC7 bit, because I don't fully know what that disambiguation chunk would look like.

Edit: Converted Family Noraebang's NSF header to NSF2 and added VRC7 chunk.
Attachments
Family Noraebang (unordered unoptimized).nsf
(720.13 KiB) Downloaded 255 times
Santa Claus (VT03).nsf
(2.17 KiB) Downloaded 257 times
Last edited by NewRisingSun on Fri Sep 14, 2018 12:16 pm, edited 1 time in total.

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by rainwarrior » Sun Sep 09, 2018 11:49 am

Thanks. It will take me a little while to get to implement these (a lot of tasks ahead of it) but I will make use of them.

NewRisingSun
Posts: 1060
Joined: Thu May 19, 2005 11:30 am

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by NewRisingSun » Thu Sep 13, 2018 10:24 pm

Could you please provide a preliminary defintion for the YM2413 disambugation chunk, so I can add preliminary support to NintendulatorNRS?

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by rainwarrior » Thu Sep 13, 2018 10:29 pm

Chunk ID: 'VRC7'
1 byte: chip type (0=VRC7, 1=YM2413, 2-255 reserved)
optional:
128 bytes internal patch set.

If using don't forget to indicate NSF2 and set the mandatory extra data bit.

NewRisingSun
Posts: 1060
Joined: Thu May 19, 2005 11:30 am

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by NewRisingSun » Fri Sep 14, 2018 12:19 pm

I have added support for OneBus NSFs ($7B bit $40s) as well as YM2413 (using the NSF2 VRC7 chunk) and N163 variable volumes (using the mixe chunk) to NintendulatorNRS. Other NSF2 features are not (yet?) supported, beyond the original Nintendulator's support for non-returning play routines.

I have also updated the Family Noraebang NSF in the above post, and added a mixe chunk to the existing King of Kings NSF for testing, attached. Please look at the three NSF(2) files and tell me if I applied the new features correctly, so I can begin releasing rips.
Attachments
King of Kings (NSF2).nsf
(8.15 KiB) Downloaded 251 times

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by rainwarrior » Tue Sep 18, 2018 7:11 am

King of Kings:
- the mixe chunk appears well formed. Sets N163 to 18.00dB.
- I would suggest keeping it as version 1 ($05) and not setting the "mandatory metadata" bit ($7C:7) so that it is allowed to fall back to default mix if that's unsupported.

Family Noraebang:
- Usage appears correct to me. (i.e. version 2 + mandatory bit implies it's not appropriate to use VRC7)
- VRC7 chunk appears well formed.

Santa Claus:
- Using bit 6 for onebus seems OK to me.
- Keeping version 1 ($05) also seems fine to me, since there is no extra data in $7C.

In general, version 2+ should indicate that $7C should be interpreted, version 1 that it should be ignored (though it should also be $00 for version 1). The rest is backward compatible with version 1, including new use of these last 2 expansion bits.

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by rainwarrior » Wed Sep 19, 2018 10:52 am

Some questions:

1. The OneBus system is not a Famicom expansion, but a whole clone system where the extra audio hardware is inside the system, not the cartridge?

2. The OneBus has swapped duty on both of its APUs?

3. Aside from the swapped duty, does it differ from the NES APU in other ways? Length counter table? DPCM frequency? Noise frequency? Periodic noise mode? Sweep? Nonlinear mixing? Have any of these things been tested for it? (e.g. not even the MMC5 is a complete APU copy for its square channels, I can't really take any of these for granted.)

4. Does anyone know how to get either the Family Noraebang cartridge, or the OneBus system? Ebay doesn't seem to have any listings for these. I don't know where to look. Alternatively, would someone be willing to lend me these things temporarily?

NewRisingSun
Posts: 1060
Joined: Thu May 19, 2005 11:30 am

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by NewRisingSun » Wed Sep 19, 2018 12:39 pm

rainwarrior wrote:The OneBus system is not a Famicom expansion, but a whole clone system where the extra audio hardware is inside the system, not the cartridge?
That's right.
rainwarrior wrote:The OneBus has swapped duty on both of its APUs?
The VT02 and VT03 certainly have. It's possible that later ones don't: most of the later ones are used in handhelds with a built-in speaker and no Line Out, so that the sound samples heard in YouTube videos showing them are inconclusive. The development kit for the OneBus famiclones includes the EmuVT emulator however, which does not reverse the duty cycles. I emulate it without swapped duty cycles.
rainwarrior wrote:Aside from the swapped duty, does it differ from the NES APU in other ways? Length counter table? DPCM frequency? Noise frequency? Periodic noise mode? Sweep? Nonlinear mixing?
Attached data sheet has tables with the length counters and DPCM frequencies (page 33ff). (Annoyingly, the data sheet calls the square wave channels "rhythm".) They sound identical to a normal NES, except for the duty cycles of course, but I have not compared each value. With two output pins, one for each APU, I don't think there is nonlinear mixing.

I have no Family Noraebang cartridge unfortunately, and only one OneBus famiclone (Samuri Star Angel) which I would like to keep, as it is a plug-and play system made of of entirely original games with no cartridge slot. But there are many cheap famiclones using the VTxx chips, so maybe somebody else could spare one.
Attachments
VT02 Data Sheet RevisionA5_ENG__1.pdf
(619.07 KiB) Downloaded 244 times

lidnariq
Posts: 8777
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by lidnariq » Wed Sep 19, 2018 12:42 pm

Do we know if any of those cheap ones that run off SPI memory (like this one) have the dual APU ?

NewRisingSun
Posts: 1060
Joined: Thu May 19, 2005 11:30 am

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by NewRisingSun » Wed Sep 19, 2018 12:48 pm

The VT36x model is poorly understood, as there is no data sheet publicly available for it, but I have seen no evidence that V.R.T. removed the second APU.

(Edit) I suppose there is no danger in trying out the 101-in-1 (AT-103) multicart ROM on it, which uses the second APU for its menu music. It's likely that the screen will remain black, however, because of the lack of display-specific initialization code. If anybody writes his own test ROM, note that the second APU must be enabled first by setting the correct bit in register $4030.

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by rainwarrior » Sat Mar 02, 2019 1:36 am

Alright, the full proposed NSF2 I outlined in the OP is now implemented in NSFPlay 2.4 beta 9, available here:
https://github.com/bbbradsmith/nsfplay/releases

I made 3 test NSFs to demonstrate the features:
https://github.com/bbbradsmith/nes-audio-tests

One thing that I think I forgot to state in OP is that because "non-returning INIT" implies that PLAY will come from an NMI wrapper, this means that PLAY will implicitly have the I flag set when being used with non-returning INIT. This has consequences if trying to use the IRQ and non-returning INIT features at the same time (though probably easy to understand as long as you're aware that this will happen). This also means that the vector overlay for IRQ should actually extend down to $FFFA so that the player can also control the NMI. (Only $FFFE needs to be writable by the user/NSF though.)

I'll write this up on the Wiki very soon.

NewRisingSun
Posts: 1060
Joined: Thu May 19, 2005 11:30 am

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by NewRisingSun » Sat Mar 02, 2019 9:43 am

I love your plugin. :) Thanks for all your work on it. Three comments, if I may:
  1. The Family Noraebang NSF is still not loaded, with the error message being "Not an NSF file". Is that as it should be?
  2. I am having the problem with the WinAmp plugin that the settings are not saved to in_yansf.ini, even though both the folder and the file are write-enabled and have all security settings set to allow non-administrator access. What might I be doing wrong? I had to edit the file by hand to change settings, and had to resort to trial-and-error to find out which one of the APU1_OPTIONx and APU2_OPTIONx corresponded to disabling non-linear mixing.
  3. Also, I would like to request a high-quality N163 mode. Right now, it offers serial multiplex mixing (as on the original chip), which is disabled by default. But the "disabled" setting still sounds rather grungy, like serial mixing but just with an additional low-pass filter on top. In NintendulatorNRS, I offer "better-than-original" mixing using the following code:

Code: Select all

uint8_t ChipRAM[128];
uint8_t CurrentChannel;	// Current channel being serviced
uint8_t	PhaseMSB[8];	// Eight more bits of phase position per channel for "clean" rendering.

int	GenerateWaveClean (int Cycles, int ChannelOffset, int ChannelNum) {
	int Channels = (ChipRAM[0x7F] >>4)+1;
	int Phase    = (PhaseMSB[ChannelNum] <<24) | (ChipRAM[ChannelOffset +5] <<16) | (ChipRAM[ChannelOffset+3] <<8) | ChipRAM[ChannelOffset+1];
	int Freq     = ((ChipRAM[ChannelOffset +4] &3) <<16) | (ChipRAM[ChannelOffset+2] <<8) | (ChipRAM[ChannelOffset+0]);
	int Length   = 256 -(ChipRAM[ChannelOffset +4] &0xFC);
	int Offset   = ChipRAM[ChannelOffset +6];
	int Volume   = ChipRAM[ChannelOffset +7] &0xF;
	
	while (Cycles--)
		Phase =(Phase +Freq) % (Length *(65536 *15 *Channels));

	int sample=(Phase /(65536 *15 *Channels) + Offset) &0xFF;
	int output= (ChipRAM[sample >>1] >>((sample&1)<<2)) &0x0F;
	
	// update Phase
	PhaseMSB[ChannelNum      ] =(Phase >>24) &0xFF;
	ChipRAM [ChannelOffset +5] =(Phase >>16) &0xFF;
	ChipRAM [ChannelOffset +3] =(Phase >> 8) &0xFF;
	ChipRAM [ChannelOffset +1] =(Phase >> 0) &0xFF;
	return (output -8) *Volume;
}

int	MAPINT	GetClean (int Cycles) {
	int out =0;
	for (int Cycle =0; Cycle <Cycles; Cycle++)
		for (CurrentChannel =(~ChipRAM[0x7F] >>4) &7; CurrentChannel <=7; CurrentChannel++)
			out += GenerateWaveClean(1, CurrentChannel*8 +0x40, CurrentChannel);
	return out *128 /Cycles / ((ChipRAM[0x7F] >>4)+1);
}
... with "GetClean" being the routine that is called for sound generation, and "Cycles" meaning 1.78 MHz CPU M2 cycles. As you can see, high-quality generation requires more bits of the phase position, which has to be stored outside the N163's normal chip RAM.
Last edited by NewRisingSun on Sun Mar 03, 2019 8:48 am, edited 1 time in total.

User avatar
rainwarrior
Posts: 7669
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by rainwarrior » Sat Mar 02, 2019 12:46 pm

NewRisingSun wrote:The Family Noraebang NSF is still not loaded, with the error message being "Not an NSF file". Is that as it should be?
I have not implemented the VRC7 chunk, so it is (correctly) unable to play the file. It's on my to-do list, but YM2413 support is behind a larger task of rewriting the VRC7 emulation. I'm still in the research phase of this.
NewRisingSun wrote:I am having the problem with the WinAmp plugin that the settings are not saved to in_yansf.ini, even though both the folder and the file are write-enabled and have all security settings set to allow non-administrator access. What might I be doing wrong? I had to edit the file by hand to change settings, and had to resort to trial-and-error to find out which one of the APU1_OPTIONx and APU2_OPTIONx corresponded to disabling non-linear mixing.
Hm, I do see this problem happening with Winamp installed to Program Files. I am unable to duplicate the problem with a portable version of Winamp though, or the stand-alone NSFPlay (which is also portable), where it seems to work correctly. I would assume this is a matter of administrator access not being granted to the DLL to write to Program Files, but you have claimed that it should have the right. Where is your plugin located?

I suspect the real solution here would be to save it to appdata. This was just how it was done in the original version of NSFPlay and has never changed over the years. I think I'd still want a portable app to save it next to the application though. I'll try to figure out an appropriate way to make it handle both methods gracefully if I can.
NewRisingSun wrote:Also, I would like to request a high-quality N163 mode.
Actually already on my to-do list. Funnily enough the original N163 implementation in NSFPlay had accidentally run it at 3x the real samplerate, just due to lack of knowledge about the chip. Several years ago when a lot of the specific details about the chip were finally researched, I corrected this with a new implementation that uses its authentic samplerate, but I do miss the "enhanced" sound it used to have.
NewRisingSun wrote:had to resort to trial-and-error to find out which one of the APU1_OPTIONx and APU2_OPTIONx corresponded to
Yeah, I never liked the way that was structured, though I don't think I will change this until NSFPlay 3.0, which will be a fundamental rewrite. I want to "finish" NSFPlay 2 with a rewrite of 5B and VRC7, and a few other things that seem reasonable to fit in along with it (NSF2 was a long held goal) but the code is more than 15 years old and has a lot of architectural resistance to a lot of things I'd like to do (e.g. cross platform support). So... config overhaul is something I want to do, but proobably not in NSFPlay 2.

NewRisingSun
Posts: 1060
Joined: Thu May 19, 2005 11:30 am

Re: NSF Extensions, NSF2 and NSFe (2018)

Post by NewRisingSun » Sat Mar 02, 2019 1:12 pm

rainwarrior wrote:I have not implemented the VRC7 chunk, so it is (correctly) unable to play the file.
It seemed to me that it's complaining because of the version number in the header though, not because of the VRC7 chunk. I base on this on the observation that changing the version number byte to 0x01 loads the file, just plays it incorrectly with VRC7 instead of YM2413, which is what I had expected.
rainwarrior wrote:Hm, I do see this problem happening with Winamp installed to Program Files.
I do have installed it into Program Files, though I have set all the NTFS permissions of the plugins subfolder to allow my normal user account full r/w access, so I thought that would be enough. But yes, AppData probably seems to be the safer choice, given that WinAmp itself puts its configuration there.

Post Reply