Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
With the desire for NSFE support, I believe we should move onto adopting the NSF2 format and project itself. To be very honest, NSF2 is more like NSF2b. It is in an beta state and has a few bugs that need to be worked out and a standard to be set for the information block fields.
To quote the father of NSF and NSF2, kevtris:
[quote=kevtris]
The goals (of NSF2) are:
* IRQ support
* "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
* 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.[/quote]
[i]Originally posted: Wed Dec 22, 2010 8:41 pm[/i]
Since its original post date NSF2 already has been modified to work on Kev's FPGA music synth; as well as his new and rather unspoken-of format SPC2.
-----
To summarize about the highlights of NSF2, IRQ support means the ability to make extremely fast synth instruments for non-gameplay code. An example of what that may sound like is located in [url=http://www.membler-industries.com/squeedo/]Memblers's Squeedo directory. This also means that PCM support is relatively easier and wouldn't need special init code; which is good for ripping PCM NSFs and making PCM sound engines that you wish to export to NSF. For those ripping NSFs, NSF2 would be much easier since init does not ever have to return anymore.
Last but not least, the information block could maintain all possible information fields that anyone would want to have. For example: Album or game name, author, composer, date and copyright, ripper (if applicable), engine author, sound engine name and version, track names, track types (song/jingle/SFX), and misc. notes (just like XM/IT/S3M; which could be used to describe the album, the ripping process, or some interesting information about the tracks.)
I think the above is a pretty solid standard. If any of you think there is anything else we should add, while keeping it simple and space conscious, please recommend something!
-----
Bugs and conflicts. Well, the only bug that I know of right now is the fact that NSF 2.0 as-is does not support EXT APU TST features by Ricoh. NSF2's IRQ registers are among $4018 through $401A; which are the same exact registers as the [url=http://forums.nesdev.com/viewtopic.php?f=6&t=8868]EXT APU TST registers of the 2a0x.
If pin 30 of the 2a0x is pulled high, extended APU functions are added; mainly the ability to control the position of the triangle channel and the ability to mute or suspend volume globally.
They are some neat features, but they may have to be left behind for progress unless another R/W area can be found to replace them. Currently if someone developed code for the EXT APU TST features NSF1 rips would support them perfectly fine.
-----
Well, that's NSF2 in a nutshell. Being that it practically has everything that anyone could want I believe that after it is standardized there will be no need to develop another format or upgrade it further. Let's make it happen.
I thought so too, so far it's only a matter of changing the version number to 2.
But the actual new features are subject for further discussion in my opinion. The only feature I can think of that I've missed from NSF so far is DPCM IRQs, since that can be used for some neat tricks.
What I'd like to know first, is there a software player that supports NSF2 and is there any example files available? (ripped or composed)
Well, the extended data block is optional, and as yet doesn't have any proposed format for extra information.
I'd actually propose to just throw NSFe chunks in there (minus the ones made redundant by the header), since we already have a well defined format for that.
I proposed what it should include in the post. Pretty sure that it's all anyone could need.
At 007d:
- Album or game name
- Composer
- Arranger
- Date and copyright
- Ripper (if applicable)
- Sound engine name and version
- Sound engine author
- Track type and Track names
..
..
..
..
- Misc. Notes (just like XM/S3M/IT has to document the album, ripping process, or interesting notes.)
To give an example about how this should look:
#01hAlbum or game name#02hComposer#03hArranger#04hDate and copyright#05hRipper (if applicable)#06hSound engine name and version#07hEngine author#084DhSong name#094DhSong name#0A4DhSong name#0B4DhSong name#0C4DhSong name#0D4AhJingle name#0E4AhJingle name#0F4AhJingle name#1053hSFX name#1153hSFX name#1253hSFX name#80hMisc. notes (just like XM/IT/S3M; which could be used to describe the album, the ripping process, or some interesting information about the tracks.)#81h
Basically there is a starting byte per information entry. When it get to #08h there is a following byte that denotes track type: M (in hex) for song, J (in hex) for jingle, and S (in hex) for SFX. The name of the track follows. Tracks names can go up to #80h (or as much as ROM space allows) to which the misc. information field starts and ends in a #81h. Code follows.
I think this should do just fine. Do you think any compression is necessary?
I think the ROM data will outweigh any metadata you want to add to the file, so unless you want to compress the ROM too I don't think there's much point. I can't imagine adding more than about 1 or 2k of text/metadata to an NSF, which is a fair bit smaller than a typical NSF ROM.
The reason I liked NSFe's chunk format is because it's easily extensible to include any new chunks of metadata; whatever you need. It's easy to just stick chunks in the extra-data portion of the NSF2.
I also like it because using that format it becomes very easy to support both NSFe and NSF2's metadata.
A third reason is I don't like the idea of adding yet another arbitrary standard to the pile; NSFe's metadata chunks are pretty effective as they are.
The current metadata chunks NSFe already has are:
plst - track order
time - track lengths
fade - track fade times
tlbl - track names
auth - game/artist/copyright/ripper
The only thing I'd add to this is maybe:
text - additional text, any length
We can come up with other data that might be relevant, but really the ability to just add some paragraphs of text on there is probably more useful than a bunch of specialized fields.
NSFPlay happened to have a little text box in the info page where I stuffed all the file details, and I'm probably going to add a little "info" button that will break this text out into a new window panel of its own.
Is it because Nintendulator actually supports NSF2, or because it ignores the things that set NSF2 apart from NSF?
_______________________
Follow me on [url=https://twitter.com/jrlepage2a03]Twitter.
I record (some) NSFs on hardware. Feel free to [url=http://www.famitracker.com/forum/posts.php?id=3633]request a hardware render.
I heard that it is because Nintendulator supports some but not all features of the NSF2 format. It also happens that not only does the music steal its music driver from another game, but it also is the worst NES soundtrack I've ever heard.
Can you attach the NSF or link to it? I can't find it in Gil Galad's archive, or on Zophar, and googling it only leads to your own post about it.
Who ripped it and what does it do that requires NSF2? Are you sure? From watching a video, it does not sound like it would require NSF2. Also seems like a strange choice to be the first NSF2; why not Battletoads or Skate or Die 2 or Ultimate Stuntman, or something else that's frequently discussed as impossible in regular NSF.
Could you link us to your source for this information? As I said, googling has failed me.
My mistake, it's not an NSF2 file, but the NSF uses features of NSF2. Or at least that's what Gil told me a while back.
I attached the NSF file.
If you play Sesame Street Countdown, you'll notice they both use the same music driver and same exact sound effects.
Okay, apparently the current unstable beta version of Nintendulator has some preliminary NSF2 support, though that doesn't appear to be relevant to this NSF. This NSF plays in older versions of Nintendulator as well.
This NSF does not contain any NSF2 header or footer information, nor does it appear to write any proposed NSF2 registers. So, yeah, it's not an NSF2 at all. If it works in Nintendulator, this probably doesn't have anything to do with its NSF2 support, and probably has a lot to do with some sort of workaround that is specific to how Nintendulator implements NSF playback (similar to that Battletoads + PCM NSF that only plays on a few emulators).
I presume what was meant was that this is a hack that will only work in Nintendulator, and proper NSF2 support would make the hack unnecessary.
