NSF 2.0 Featureset - NESdev BBS

NSF 2.0 Featureset
by kevtris on 2010-12-22 (#71794)

ack. it ate my formatting! edited.

Code:

Well, I was talking with gil_ on IRC and we were discussing how a potential NSF 2.0 would be approached.

The goals are:

* IRQ supprt
* "no return" init addresses
* information block


For IRQ support, I figured allowing the use of frame IRQs and DPCM IRQs just like on the NES, and then a 16 bit IRQ timer which would be connected to the CPU in the usual way (via its IRQ input).

This would allow a real NES to play 2.0 NSFs using say a powerpak or similar.

So my proposal for IRQ hardware:

* a 16 bit IRQ timer that sits at 0x4018-0x401a
    * 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.  
        * bit 0 - 0 = timer off, reset.  1 = timer is running
    * all registers are readable and writable.  on a real NES, these
       addresses are fully readable/writable to the cartridge.

* allowing the use of DPCM and frame IRQs.  
    * these will work like on a real NES. you MUST write to 0x4017
       to enable the external (timer) IRQ, and to reset the frame IRQ,
      just like a regular NES.

* IRQ vector.
    * write the vector to FFFE and FFFF.  These two locations hold the 
       IRQ vector like usual, but are writable.  When read by  the CPU,
       these two locations must return the two bytes written there.
    * when written, you DO NOT write to the underlying NSF data bank.
    * in effect, FFFE/FFFF become two bytes of RAM which are separate
      from the rest of NSF space.

And the proposal for no return on the init address:

    * Allow for the init address to never return. 

    this basically means:
    * init becomes the reset vector 
    * play becomes the NMI vector
    * and IRQ has its vector at FFFE/FFFF





Proposed header changes:


0005    1   BYTE    Version number (currently 01h)

this will be bumped to 02h for version 2.0


007c    4   ----    4 extra bytes for expansion (must be 00h)

these will be used as follows:

007c    1  BYTE   NSF 2.0 feature enables
       bit:
       0    - when set, enables the IRQ features. when clear, disables them
       1    - when set, allows for a non-returning init address.
       2    - when set, allows play calling to be disabled
       3-6 - maintain 0
       7    - an extended info block follows nsf data. (see below)

007d    3  WORD  length of NSF data block, in bytes.  LSB first (little endian)


Extended data block:

   * an extended block of data that is optional to include.
   * it has the following features:
       * stores a unicode? title up to N characters long
       * stores the same for copyright, author, and ripper
       * allow for separate author/copyright/title on each track?
       * lengths of tracks
       * any other possible ancillary data?
   * the reason for placing it at the end, is so that 1.0 players can still
      use these NSFs.  they will append the extra data into NSF space, and 
      it should not affect the playback if it doesn't use any of the other
      features (IRQs, non-return init addresses)
    * You MUST still populate the original author/copyright/title strings
       in the original header for backwards compatibility.


So that's basically it.  I think it adds all the features that can be added and still function properly on an NES with a powerpak or similar player cartridge.

I'm open to suggestions or feedback on it.  If people like it, I will formalize it and update the existing NSF document, and modify my FPGA synth to conform to the document for testing.

Re: NSF 2.0 Featureset
by Hamtaro126 on 2010-12-23 (#71805)

kevtris wrote:

Well, I was talking with gil_ on IRC and we were discussing how a potential NSF 2.0 would be approached.

For IRQ support, I figured allowing the use of frame IRQs and DPCM IRQs just like on the NES, and then a 16 bit IRQ timer which would be connected to the CPU in the usual way (via its IRQ input).

This would allow a real NES to play 2.0 NSFs using say a powerpak or similar.

I think it adds all the features that can be added and still function properly on an NES with a powerpak or similar player cartridge.

I'm open to suggestions or feedback on it. If people like it, I will formalize it and update the existing NSF document, and modify my FPGA synth to conform to the document for testing.

Good idea, I approve of this, Just wait for more to approve,

EDIT: Fixed my formatting too,
EDIT2: What do I say about my post level - It's Over 300!!!

Re: NSF 2.0 Featureset
by lidnariq on 2010-12-23 (#71818)

kevtris wrote:

* a 16 bit IRQ timer that sits at 0x4018-0x401a

Clocked by the standard 1.8MHz (1.6MHz on pal) cpu instruction clock, I assume?

Re: NSF 2.0 Featureset
by kevtris on 2010-12-23 (#71823)

lidnariq wrote:

kevtris wrote:

* a 16 bit IRQ timer that sits at 0x4018-0x401a

Clocked by the standard 1.8MHz (1.6MHz on pal) cpu instruction clock, I assume?

That's correct. It would decrement at the CPU clock rate, whether it be NTSC or PAL rate (so 1.79MHz or 1.66MHz or so).

The counter is a modulus N counter and has the following behaviour:

When the counter is off (whenever 401a bit 0 is clear) it is constantly being reloaded with the values in 4018/4019, and the counter IRQ flag is cleared.

When the counter is on (401a bit 0 is set), it will decrement once per CPU cycle. When it hits 0, it is reloaded from 4018/4019, the IRQ flag is set and an IRQ is asserted.

This means an IRQ will be generated every N+1 clock cycles, where N is the value loaded into the counter. (it is N+1 because 0 is counted too).

To clear the IRQ flag, you read 401a. I should probably put the IRQ flag at bit 7 (read only) to allow easy testing of IRQ source.

Thusly, your code would look something like this to use the IRQ timer:

Code:

timervalue:  .equ 01fffh       ;desired # of cpu cycles minus 1

starttimer: LDA #000h
               STA 0401ah         ;reset and shut off timer in case it was on

               LDA #<irqvector
               STA 0fffeh           ;store interrupt vector low of our handler
               LDA #>irqvector
               STA 0ffffh            ;store interrupt vector high

               LDA #<timervalue
               STA 04018h         ;low byte of timer value
               LDA #>timervalue
               STA 04019h         ;high byte of timer value

               LDA #0c0h
               STA 04017h         ;turn off frame IRQs
               LDA 04015h         ;ack any pending DPCM IRQ if, it exists
               CLI                     ;enable IRQs

               LDA #01h
               STA 0401ah         ;turn the timer on
               RTS

stoptimer: SEI                    ;turn off IRQs
                LDA #000h
                STA 0401ah        ;turn timer off
                RTS

irqvector:  <perform our interrupt code here>
                ....
                ....
                
                LDA 0401ah        ;reading 401a resets IRQ flag
                RTI                    ;return from interrupt


alternatively, if you wish to determine WHAT caused the IRQ (if you're using more than one source) you'd do something like this...

irqvector:   BIT 0401ah        ;bit 7 indicates we have a timer IRQ waiting
                 BPL +
                 JSR timer           ;if bit 7 was set, call timer subroutine
               + BIT 04015h
                 BPL +
                 PHP                   ;save flags if we have DPCM int.
                 JSR dpcm           ;if bit 7 was set, call DPCM sub
                 PLP
               + BVC +
                 JSR frame          ;bit 6 of 4015 = frame IRQ
               + RTI                    ;exit interrupt

timer:        <do stuff here>
                 RTS

dpcm:        <do stuff here>
                 RTS

frame:        <do stuff here>
                  RTS

There's a lot of ways to skin this cat, but this is one particular method.  The idea is to read the status regs to figure out which source caused the interrupt, then run code to service it, then go back and check the other sources just in case one of them also needs servicing.

by Lord Nightmare on 2010-12-23 (#71827)

Technicality: does it reload when it HITS 0 (on 1->0 transition, so 0 is only in timer for an irerelevantly small time period before reload) or does it reload on underflow FROM 0 (0->"-1" transition)?

LN

by kevtris on 2010-12-23 (#71828)

Lord Nightmare wrote:
Technicality: does it reload when it HITS 0 (on 1->0 transition, so 0 is only in timer for an irerelevantly small time period before reload) or does it reload on underflow FROM 0 (0->"-1" transition)?

LN

when it hits 0, the NEXT clock performs a reload. so, the counter would count like so:

if the reload is 10h...

(reset)
10
10
10
(counter enabled)
0f
0e
0d
0c
...
02
01
00
10
0f
0e
0d
0c

when the counter is reloaded, the IRQ flag would be set also.

02 0
01 0
00 0
10 1

the second number being the IRQ flag.

by Memblers on 2010-12-23 (#71832)

Actually what would be nice in the info field is to follow what MML format does, by having title, composer, and programer (sic) fields for each track.

by Dwedit on 2010-12-23 (#71834)

I'd like to see individual track information saved into the file, including an indication of whether a track is a song, jingle or sound effect. Then with your magical NSF player plugin for winamp, you can enqueue only songs and not sound effects.

Also, maybe an "Initial ram image and sound registers" feature, so you don't need to make your own 6502 code. It would make it more like SPC files.

by B00daW on 2010-12-23 (#71842)

Dwedit is onto something...

Some standardization n the optional info block for players somewhat in the lines of markup language would be pretty useful. Of course we would want to conserve as much space as possible for hardware players.

Take for example Track info:

(Open by < and close by >)

<AUzan-zan-zawa-veia>AU<CPzan-zan-zawa-veia 2010>CP<TR3dirt hole:145Table jump:505Tfour word:430T>TR

This would decode as the author being "zan-zan-zawa-veia", the copyright being "zan-zan-zawa-veia 2010", and there being 3 tracks, named "dirt hole," "able jump," "four word," and their respective times, last two characters being seconds, and two preceding being minutes. (I doubt that many tracks would be more than an 59 minutes and 59 seconds, right? Even so, someone may do it just to see if they can. A byte for hours might be desirable. It wouldn't be impossible for someone to create a nine hour long 2a0x track with the slowest possible time and refresh, but then they are just sadistic. Just thinking ahead...) At the end of the track length info would be the type of track: T for track, J for jingle, X for effect, D for stand-alone DPCM data with pointer, and P for stand-alone PCM data with pointer.

<RS(RAM/REG state dump here)>RS

The above information tries to make an attempt at conserving space and allowing for the standard desirable categorization of information. Moving forward, the markup code for the info block shouldn't need more than 2 characters per attribute.

As for some additional information, it might be nice to know what sound engine is being used in the NSF. For example: FamiTracker vXXX, PornoTracker vXXX, NerdTracker vXXX, SuperNSF vXXX, it2nsf vXXX, etc...

<SEFamiTracker vXXX>SE

... I believe this can be expanded to infinity ...and beyond.

by tepples on 2010-12-24 (#71862)

Interesting. First I thought "How would you escape : and > characters in titles?" and then I realized that one might choose JSON instead of an ad hoc markup language, and lengths in seconds instead of minutes and seconds. This is more verbose, but at least less so than XML, and it's self-describing and probably already has a parser in your favorite language.
Code:
{
"title":"didder","engine":"FamiTracker vXXX",
"author":"zan-zan-zawa-veia","copr":"zan-zan-zawa-veia 2010",
"tracks":[
{"n":"dirt hole","t":105,"d":"bgm"},
{"n":"able jump","t":305,"d":"bgm"},
{"n":"four word","t":270,"d":"bgm"}
]}

by kevtris on 2010-12-24 (#71894)

tepples wrote:
Interesting. First I thought "How would you escape : and > characters in titles?" and then I realized that one might choose JSON instead of an ad hoc markup language, and lengths in seconds instead of minutes and seconds. This is more verbose, but at least less so than XML, and it's self-describing and probably already has a parser in your favorite language.
Code:
{
"title":"didder","engine":"FamiTracker vXXX",
"author":"zan-zan-zawa-veia","copr":"zan-zan-zawa-veia 2010",
"tracks":[
{"n":"dirt hole","t":105,"d":"bgm"},
{"n":"able jump","t":305,"d":"bgm"},
{"n":"four word","t":270,"d":"bgm"}
]}

I was thinking something a lot simpler- this should ideally be readable on an NES and parsing some kind of higher level thing would be a pain to do I think.

my approach would be to have records that contain track # and then information fields... something like this:

record:

offset, # of bytes, type, description
----------------------------------------
0 1 BYTE record type
1 2 WORD record length
3 1 BYTE track #
4 N --- record data

Records would be one after another, and a record of 4 00h bytes would signify the end of the data.

the type would be something like:

0 - last record
1 - title
2 - composer
3 - copyright

etc.

Track # 0ffh could be reserved, and used as a wildcard indicator,
allowing for things like this:

composer, track 0ffh, jimbob
title, track 0, my first song
title, track 1, my second song
title, track 2, a song by someone else
composer, track 2, billy
title, track 3, another song

this would populate all the "composer" entries on the tracks which do not have a specific composer (i.e. everything but track 2 in the above example).

This would allow removal of most duplicated material and allow for individual track fields to be populated with different info if required.

Also, it'd be pretty trivial to process this type of data on a real NES or other hardware player.

Possible fields could be (with tentative ID's):

01 Title followed by ASCII or unicode? data. A max length should be specified.
02 Composer (Same as above)
03 Copyright (Same as above)
04 Ripper (Same as above)
05 length (in seconds? milliseconds? NMI counts?)
06 type (maybe? i.e. SFX, BGM, title tune, etc)
07 ancillary data (i.e. compo entry #? "this is a cover of xyz")

Any other fields that would be useful? As usual, all fields are optional, and you only use the ones you need/want.

This would make it pretty easy to read via a real NES, vs. some feel-good text format. As such, it'd probably be a decent idea to only allow ASCII in the fields since an NES cannot read unicode too easily. (Also, a simple converter could be written to "compile" a desired text format into the binary format for stuffing onto the end of the NSF.)

As for a pure text format, I ran into this issue with .SAP files. I had to write a somewhat annoying complicated parser for these files, because they have a human-generated header with the binary data just appended on. Because of this, you have to account for all sorts of weird cases; tabs, spaces, CRLF, LF only, etc.

It's kind of a nightmare to handle in 6502 asm.

by B00daW on 2010-12-24 (#71898)

The Ripper field could be interchangeable for Engine. Since it's unlikely that the engine will be known if it is ripped from a commercial game. The engine information would be useful for modern composed NSFs.

kevtris wrote:
01 Title followed by ASCII or unicode? data. A max length should be specified.
02 Composer (Same as above)
03 Copyright (Same as above)
04 Ripper (Same as above)
05 length (in seconds? milliseconds? NMI counts?)
06 type (maybe? i.e. SFX, BGM, title tune, etc)
07 ancillary data (i.e. compo entry #? "this is a cover of xyz")

by tepples on 2010-12-24 (#71905)

If you want the header readable on the NES, then how are you going to handle Unicode UTF-8 character encoding? A player running on an NES would have to include a font covering the whole Unicode BMP including CJK, a layout engine including stacked accents, bidirectional reordering, and contextual glyph replacements, just in case an NSF has Arabic song titles.

"Engine" is known for any game whose music data format has been described on romhacking.net. For example, a lot of Capcom games use substantially the same engine.

by clueless on 2010-12-24 (#71907)

Kevtris, your approach seems very similar to how a TIFF image encodes image meta-data in "tiff tags". I like the idea that the info is easily extracted with 6502/NES software.

by thefox on 2010-12-24 (#71909)

kevtris wrote:
As such, it'd probably be a decent idea to only allow ASCII in the fields since an NES cannot read unicode too easily. (Also, a simple converter could be written to "compile" a desired text format into the binary format for stuffing onto the end of the NSF.)

Standardizing it as UTF-8 is probably the best choice, since it's backwards compatible with ASCII.

tepples wrote:
If you want the header readable on the NES, then how are you going to handle Unicode UTF-8 character encoding? A player running on an NES would have to include a font covering the whole Unicode BMP including CJK, a layout engine including stacked accents, bidirectional reordering, and contextual glyph replacements, just in case an NSF has Arabic song titles.

Yeah if you really need to nitpick. Most players would be fine with displaying only ASCII characters though and maybe display a message if non-ASCII characters are detected.

I would also go with a binary format for the meta-data.

by Memblers on 2010-12-25 (#71959)

It would help to have the Programmer field for the track list. For situations where one person composed the song, another made the NES version, and the copyright isn't the either of their names. So without a Programmer/Arranger/Whatever field, with no other place to go, this kind of stuff will probably end up in the ripper field or somewhere else that doesn't make any sense.

by B00daW on 2011-02-23 (#74470)

Let's aim for ease, compatibility, and simplicity for the tags.

Would it be prudent to possibly compress the tag footer with LZSS? Tokumaru has its code here > http://membler-industries.com/tokumaru/ ... u_lzss.zip

Game rip NSF2s will want to be rather thorough to separate jingles and SFX from music and allow categorization via players.

The LZSS might come in handy if a modern artist would like to comment on his/her work and to display it in either a CPU or hardware player; as long as it was limited to say 2K.

Let's try to push this forward! I know we'd all like to possibly see some Squeedo cart works emulated and ripped as NSF. ;P

by B00daW on 2011-07-02 (#81004)

What's a good way for hardware NSF players to detect the footer and its information? Should there be a header WORD to tell the player the location of the footer?

...

In other news, a group of us are working on a site to archive complete, original NSF works. We may or may not include game releases. The site will be PHP based and have a lot of scripts to convert NSF 1.0 to the accepted 2.0 and also database which 2.0 NSFs are not backward compatible by reading the NSF 2.0 feature byte. Hopefully the site will provide a smooth transition between 1.0 and 2.0.

There is no rate but 411ah
by tepples on 2011-07-02 (#81006)

While looking over this copy of the NSF spec for a good place to stash the length of the music program, I discovered something: "There is no rate but 411ah, and NTSC is the video system of 411ah."

The official NSF spec recommends playing NTSC tunes at $411A = 16666 µs per update. This is accurate for those few (about two if I remember correctly) games that use the APU Frame IRQ to time their music code.

NTSC subcarrier rate = 315/88 MHz by definition
NTSC NES CPU rate = 1/2 subcarrier rate = 315/176 MHz
Cycles per APU Frame IRQ = 29830
Thus 176/315*29830 = 16667 µs per update.

But the PPU runs closer to 60.1 Hz than 60.0 Hz. By my calculation, $40FF = 16639 µs would be more accurate to the hardware for the vast majority of games, which time their music code with vertical blanking.

NTSC NES PPU pixel rate = 3/2 subcarrier rate = 945/176 MHz
Pixels per screen = 341 * 262 - 0.5 = 89341.5
Thus 176/945*89341.5 = 16639 µs per update.

by rainwarrior on 2012-03-28 (#91937)

I'm interested in supporting NSF 2 for NSFPlay and I have a few questions:

1. If init is not expected to return, when should we begin to execute play? Do we wait for the NMI flag to be set via $2000?

2. Is a non returning init allowed to generate sound if we never get signaled to start the play routine?

3. Is the format ready for a formal draft? Have we settled on a track name/length format? Can it be put on the Wiki, or somewhere else?

4. Are there any NSF 2 files available for testing?

by Dwedit on 2012-03-28 (#91938)

I really don't understand NSF2 at all. I could understand perfectly a modified NES format where you stick the song number into A, and run it from there, but NSF2 sounds confusing.

by klarthailerion on 2012-03-28 (#91942)

rainwarrior wrote:
4. Are there any NSF 2 files available for testing?
I don't think so... I don't think the spec was finalized yet.

by B00daW on 2012-08-02 (#97394)

Big ol' necrobump.

I see an issue with the IRQ registers. They are in the same mapping points as the EXT TST APU registers.

If someone were to write code for the EXT TST registers and make a NSF rip, it would work for NSF 1.0 but would not for NSF 2.0.

Re: NSF 2.0 Featureset
by rainwarrior on 2012-08-04 (#97602)

I'm still planning to try to implement NSF2 in NSFPlay sometime in the near future. There are a few things I propose:

1. If init does not return, it should signal when playback is supposed to begin; the current solution GME and other players use, waiting some arbitrary number of seconds, is not ideal. Perhaps the first write (any value) to $401A could trigger the beginning of playback, or maybe add a new bit to $401A that signals the system to begin calling PLAY at the specified interval. This should automatically be triggered if init returns.

2. Use the NSFe format for the extra data appended to the format; i.e. just stick a properly formed NSFe file on there. You should omit the 'INFO'/'DATA'/'BANK' chunks, obviously, since they're already built into the NSF header and ROM sections, but all the rest of it works quite well in my opinion. (Even the 'auth' chunk can be used to override the 32 byte strings in the header if you need to exceed the length limit, or want a ripper name in there.) New metadata can easily be added as new chunk types. It also has the advantage that unimportant data unknown/unspported by the player can easily be ignored. This also will make it much easier for software that wants to support both NSFe and NSF2.

For quick reference, metadata already supported by NSFe:
plst - track order
time - track lengths
fade - track fade times
tlbl - track names
auth - game/artist/copyright/ripper (strings of any length)

3. Add an optional 'text' chunk to the NSFe format that's just a null terminated string of any length, letting the ripper describe the file any way he chooses. This is probably more useful and easier for a player to display than trying to add additional optional information fields.

4. B00daW is suggesting we move the register addresses somewhere that doesn't conflict with the newly discovered test registers. Perhaps move them to $401C-$401F?

Re: NSF 2.0 Featureset
by zzo38 on 2012-08-07 (#97752)

Yes, a time limit (perhaps in video frames?) may be useful if you want to use a playlist instead of having the song loop from the loop point.

Re: NSF 2.0 Featureset
by tepples on 2015-03-22 (#143548)

This bubbled up again in #nesdev recently.

So now we need to define what goes in the footer. One thing I know we'll need is balance for Namco 163 vs. 2A03.

Re:
by koitsu on 2015-03-22 (#143559)

Dwedit wrote:
I'd like to see individual track information saved into the file, including an indication of whether a track is a song, jingle or sound effect. Then with your magical NSF player plugin for winamp, you can enqueue only songs and not sound effects.

This. A thousand times this. Nothing infuriates me more than NSFs that contain sound effects and jingles (I'm a little more flexible on the jingles). And in some cases (just due to either the ripping or the original source data format) sound effects are interspersed with actual songs.

Having this would allow for NSF players to provide the ability to play only tracks of a certain type, e.g. only songs, only jingles, songs + jingles, etc..

I'd suggest using 2 bits somewhere in the file format to define the "track type":

%00 = Song
%01 = Sound effect
%10 = Jingle
%11 = ???

And maybe 2 bits isn't enough room. Maybe folks would want more granularity, so possibly extending that to 4 bits (16 choices) would be ideal. Or for starters, allocating 4 bits but labelling the top 2 bits "reserved for future expansion use". Gotta think ahead.

Re: NSF 2.0 Featureset
by tepples on 2015-03-22 (#143563)

What's the difference between a "song" and a "jingle", especially in a game like WarioWare where each level is 3 seconds long and followed by 1.5-second win/lose jingle and a 1.5-second next level jingle?

Re: NSF 2.0 Featureset
by rainwarrior on 2015-03-22 (#143567)

New metadata ideas are easy to add to an extensible format like NSFe. (This is part of why I suggested we just embed NSFe chunks at the end of an NSF2, rather than create yet another metadata format.)

Of course, adding something to the format doesn't by itself do anything. Someone has to care about producing that metadata. Only about about 350 NSFe tagged NSFs exist that I know about, and even at this point very few players support NSFe.

Many NSFe files were made with the playlist containing only the music tracks, and the full NSF embedded underneath having all the sound effects too. NSFPlay lets you disable the playlist in the options to get at the full track list (though it's not terribly convenient; better playlist control is on my to-do list). So... there is a partial form of what you're requesting already.

Anyhow, if you do want that feature, I'd recommend implementing it as NSFe for the time being (rather than waiting for NSF2 support), and get to work tagging some files! (I guess you'll need to modify NotSoFatso, NSFPlay, or some other player to verify...) NSFe files would be easy to auto-convert into NSF2 metadata, I'm sure, whatever form it might take.

I guess there's never really been a central authority for NSF files, just many independently maintained collections scattered around, so trying to get people to tag things consistently is a problem. It seems nobody has really wanted to take up that responsibility the way, say, VGMrips has for VGM.

Re: NSF 2.0 Featureset
by koitsu on 2015-03-22 (#143577)

tepples wrote:
What's the difference between a "song" and a "jingle", especially in a game like WarioWare where each level is 3 seconds long and followed by 1.5-second win/lose jingle and a 1.5-second next level jingle?

There is universal standard or definition, if that's what you're looking for. It's going to vary per game.

A "jingle" would be something like game over music, or a special tune that gets played when you find an item/achieve something, rather than actual in-game background music. That's the delineation, in my mind anyway. Konami games are filled with these.

Regardless, there definitely needs to be a delineation between sound effects and songs.

Re: NSF 2.0 Featureset
by B00daW on 2015-03-22 (#143578)

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.

Re: NSF 2.0 Featureset
by rainwarrior on 2015-03-22 (#143579)

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.

Re: NSF 2.0 Featureset
by B00daW on 2015-03-23 (#143598)

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?

Re: NSF 2.0 Featureset
by tepples on 2016-02-01 (#163651)

I've tried to clean up the spec: http://wiki.nesdev.com/w/index.php/NSF2

Re: NSF 2.0 Featureset
by B00daW on 2016-02-01 (#163668)

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.

Re: NSF 2.0 Featureset
by B00daW on 2016-02-03 (#163793)

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?

Re: NSF 2.0 Featureset
by tepples on 2016-02-03 (#163795)

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.

Re: NSF 2.0 Featureset
by rainwarrior on 2016-02-03 (#163796)

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.

Re: NSF 2.0 Featureset
by tepples on 2016-02-03 (#163797)

Kev's proposal can replace composer and publisher for individual tracks, unlike NSFe's auth which is global and tlbl which holds only titles.

Re: NSF 2.0 Featureset
by rainwarrior on 2016-02-03 (#163798)

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.

Re: NSF 2.0 Featureset
by B00daW on 2016-02-04 (#163819)

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.