NSF 2.0 Featureset

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

Moderator: Moderators

User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NSF 2.0 Featureset

Post by B00daW »

Another thing to consider with the footer or the header is sample-load addresses for the LPC/PARCOR and ADPCM chips; ex: Mitsubishi M50805 and NEC µPD7756C. We could rip/dump the samples in proper format and stick them in ROM space somewhere where the header addresses them or pack them onto footer space where the header expects them to be when it is told which chips are used. Packing them into footer would probably be cleaner since sticking them into ROM space is more or less a hack. Footer space would take more code for the player.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF 2.0 Featureset

Post by rainwarrior »

B00daW wrote:Footer space would take more code for the player.
I don't think either way would really result in more code in any significant way.
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NSF 2.0 Featureset

Post by B00daW »

Well either way would we have to designate areas for LPC/PARCOR and ADPCM sample RAM? Even considering if both expansion chips are used at the same time with a custom NSF?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NSF 2.0 Featureset

Post by tepples »

I've tried to clean up the spec: http://wiki.nesdev.com/w/index.php/NSF2
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NSF 2.0 Featureset

Post by B00daW »

tepples wrote:I've tried to clean up the spec: http://wiki.nesdev.com/w/index.php/NSF2
The interval timer has three readable and writable ports:

$4018: Lower 8 bits of the 16-bit timer reload value
$4019: Upper 8 bits of the 16-bit timer reload value
$401A: Control register. Clearing bit 0 stops the timer and holds it in reset; setting it to 1 starts it.
Can we change these to $401B-$401D to resolve the 2a0x TEST conflict? Also did the decap show that this area are unused lines?

Edit: Well since we know that $401B-$401D are disconnected I went ahead and edited the wiki to resolve this conflict.
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NSF 2.0 Featureset

Post by B00daW »

WikiSpec wrote:$07C 1 BYTE NSF 2.0 feature enables (was $00)
bit 0: if set, enable IRQ features
bit 1: if set, allow a non-returning init address
bit 2: if set, allow play calling to be disabled
bit 3-6: still 0
bit 7: if set, a metadata block follows the NSF data
bit 5 should denote if NEC µPD7756C (Jaleco) ADPCM sample data is loaded/referenced after NSF data; possibly starting with a 16-bit value which gives sample length.

bit 6 should denote if Mitsubishi M50805 (Bandai) LPC sample data is loaded/referenced after NSF data; possibly starting with a 16-bit value which gives sample length.

if bit 7 is enabled then it should verify/calculate its location given one/both expansion(s) enabled.

Any issues?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NSF 2.0 Featureset

Post by tepples »

Would it be wrong to make a metadata chunk type for the ADPCM or LPC sample data? Metadata chunks can be up to 65535 bytes long. But then that'd require the ability to make actual dumps of the data, not just analog-reconverted recordings.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF 2.0 Featureset

Post by rainwarrior »

I, too, think metadata chunks are a good place for it.

I said elsewhere but I forgot if I said in this thread, but I think it should just be NSFe metadata chunks; merge the two formats. The metadata goals seem to completely overlap, and I don't see the point of having an arbitrarily different "chunk" format when we've got a perfectly good one already implemented and ready to use.

In NSFe terms, the samples chunk would be a "required" chunk (i.e. allcaps FOURCC) so any player that doesn't recognize the chunk type would know it's not going to be able to play correctly.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NSF 2.0 Featureset

Post by tepples »

Kev's proposal can replace composer and publisher for individual tracks, unlike NSFe's auth which is global and tlbl which holds only titles.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NSF 2.0 Featureset

Post by rainwarrior »

So what? You can just add another chunk type. Super easy. "taut" or something with a list of authors, etc.

You don't need a whole new format for that. NSFe is easy to extend.
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: NSF 2.0 Featureset

Post by B00daW »

Metadata chunks sound fine. There are NEC µPD7756C dumps available in MAME/MESS games but not from the actual Famicom games. In place they could be used to test emulated and hardware support until the actual samples are dumped. I'm not sure any equivalent for the LPC samples are dumped yet.
Post Reply