It is currently Tue Nov 20, 2018 11:14 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Mon Aug 27, 2018 2:43 pm 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
Sounds great! There is the case of the M50805 and the Jaleco ADPCM sample chip carts for SFX one-hits in the NSF to have expansion bits; and other known expansion audio pirate carts like City Fighter.

The sample data will need to be held within the meta-data at the end of the NSF2. It would also be good to consider a way for a hardware player to access this information from ROM or have it loaded into RAM.


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 3:07 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
B00daW wrote:
Sounds great! There is the case of the M50805 and the Jaleco ADPCM sample chip carts for SFX one-hits in the NSF to have expansion bits; and other known expansion audio pirate carts like City Fighter.

The sample data will need to be held within the meta-data at the end of the NSF2. It would also be good to consider a way for a hardware player to access this information from ROM or have it loaded into RAM.

Stuff that can't function without a sample chunk does not need to allocate an expansion bit. The presence of that sample chunk (also marked mandatory by the NSF2 byte bit 7) is enough by itself. I'm trying to avoid redundant/unnecessary allocations.

As far as hardware players go, I don't see any real impediments to that in this file format. I don't know if a PowerPak or Everdrive FPGA has enough internal RAM to handle this stuff, and probably don't have access to an extra piece of dedicated RAM, so they might never be simulate those sample playback chips. A new design certainly could do it, though, IMO.


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 3:27 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7722
Location: Seattle
PowerPak's FPGA has only 3KiB of internal RAM, much less than the 12 KiB in the µPD7755, (edit:) let alone the 32 KiB of the µPD7756.

A smart-assed design could probably stuff it into CHR and piggyback on PPU fetches, however. (It would have to pre-load fetches during vertical blanking, and stall the first fetches after playback starts until vertical blanking ends)

Everdrive N8's FPGA has 13 KiB.


Last edited by lidnariq on Mon Aug 27, 2018 3:42 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 3:30 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20788
Location: NE Indiana, USA (NTSC)
Players are allowed to use at least the upper area of the stack page ($01F0-$01FF). From the spec:

The precise position of the stack on INIT or PLAY is not guaranteed, as the NSF player may need to use the top area of the stack for its own internal purpose. Make sure the tune does not attempt to modify $01F0-01FF directly. (Armed Dragon Villigust did, and was relocated to 2xx for its NSF.)


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 6:14 pm 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
All of those Jaleco with the ADPCM use different registers for sample playback. Is there a need to have them use all the different registers or can we just rip them to use one that doesn't interfere with other chips?


Top
 Profile  
 
PostPosted: Mon Aug 27, 2018 6:34 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
Well, format wise I think it would only amount to an extra byte or two in the sample chunk to designate how it's wired. Not really a problem for emulators, at least... Since they don't need to take up a (precious?) remaining expansion bit anyway, I don't think there's too much issue here encoding that info.

Like VRC6 chose the most notable game as the standard, and the rest had to be flipped in the rip. (Actually... maybe an NSFe chunk to specify VRC6 swapping would be nice. There have been several times when I've wanted to test VRC6 NSF stuff but on the other board type.)

Though modifying stuff for a rip isn't as big a deal in .NSF as it is in .NES since these are deterministic programs with no user input. It's easy to ensure you got everything, and that there's no unexpected behaviour.

So, I dunno, I'd lean toward adding the extra desgination just because I like the idea of rips that are closer to natural. I don't really mind either way. If you're making the rips I'd say it's up to you. (Also even if it could be specified in the chunk, you could still rip them all at one address if you later decided that worked better anyway.)

...though, by the same token the Karaoke cart could be ripped to use VRC7 registers instead of requiring its own expansion bit, too. I guess that'd be not hugely different than the existing VRC6 situation (just now a mandatory chunk to indicate YM2413, which I need anyway for the TNS stuff that does this.) Maybe that would actually be better, since the NSF would be nicely compatible with the TNS thing, and also not need to take up a new expansion bit.


Top
 Profile  
 
PostPosted: Wed Aug 29, 2018 12:42 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
rainwarrior wrote:
The 'mixe' chunk is mostly specified already, I need to write a few test NSFs/ROMs to fill in some of the implementation details in NSFPlay (though it does already parse that chunk, it just doesn't have reference volumes for a few expansions, including N163 yet... next beta I'll finish it soon.) Yes with the merging of metadata this becomes a solution under NSF2 as well.

Checking my partial implementation in NSFPlay, I actually did have N163's 'mixe' fully implemented, I think. So technically this already works in NSFPlay 2.4b5, at least for N163.

Going to fill out the rest of the 'mixe' chunk defaults soon though, writing the necessary tests today.


Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 11:35 am 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
rainwarrior wrote:
...though, by the same token the Karaoke cart could be ripped to use VRC7 registers instead of requiring its own expansion bit, too. I guess that'd be not hugely different than the existing VRC6 situation (just now a mandatory chunk to indicate YM2413, which I need anyway for the TNS stuff that does this.) Maybe that would actually be better, since the NSF would be nicely compatible with the TNS thing, and also not need to take up a new expansion bit.

Pretty sure the Karaoke cart uses "rhythm mode". VRC7 doesn't support this. Also not certain if there are channel discrepancies, since the YM2413 has more channels. Best just to support it fully. Also we should try to flesh out the K-663A differences from the YM2413. I know that some bootleg arcade machines use the K-663A as well. krzsysiobal said that there is buzz or hum on it.


Top
 Profile  
 
PostPosted: Thu Aug 30, 2018 11:47 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
B00daW wrote:
rainwarrior wrote:
...though, by the same token the Karaoke cart could be ripped to use VRC7 registers instead of requiring its own expansion bit, too. I guess that'd be not hugely different than the existing VRC6 situation (just now a mandatory chunk to indicate YM2413, which I need anyway for the TNS stuff that does this.) Maybe that would actually be better, since the NSF would be nicely compatible with the TNS thing, and also not need to take up a new expansion bit.

Pretty sure the Karaoke cart uses "rhythm mode". VRC7 doesn't support this. Also not certain if there are channel discrepancies, since the YM2413 has more channels. Best just to support it fully. Also we should try to flesh out the K-663A differences from the YM2413. I know that some bootleg arcade machines use the K-663A as well. krzsysiobal said that there is buzz or hum on it.

When I said VRC7 registers I mean the memory addresses. There will be an NSFe chunk to specify "VRC7 is actually a YM2413" to support NSFs for the TNS cart that has this.

Was suggesting that patching the write addresses in the karaoke NSF would make it completely compatible with this, and not require yet another expansion (analogous to the way we patched 2/3 of the VRC6 games to run on the other VRC6 configuration for NSF).


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 2:05 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 695
rainwarrior wrote:
There will be an NSFe chunk to specify "VRC7 is actually a YM2413" to support NSFs for the TNS cart that has this.
An extra chunk indicating that a header bit doesn't mean what it's supposed to mean? Please not, that's the epitome of a hackish solution.

If anything needs patching, it's the TNS homebrew cart using a hackish way to achieve something that the NSF spec did not actually support. I still advocate using another expansion bit for YM2413 instead of using an extra chunk to redefine the VRC7 into an YM2413 (as if the YM2413 were a "kind of VRC7"). It's cleaner that way, we've got enough extra bits left in the header (two in $7B, and $7C still has four reserved bits even in NSF2), and it would also allow using YM2413 alongside a VRC7.

rainwarrior wrote:
Stuff that can't function without a sample chunk does not need to allocate an expansion bit. The presence of that sample chunk (also marked mandatory by the NSF2 byte bit 7) is enough by itself.
I agree with that.


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 11:18 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
NewRisingSun wrote:
rainwarrior wrote:
There will be an NSFe chunk to specify "VRC7 is actually a YM2413" to support NSFs for the TNS cart that has this.
An extra chunk indicating that a header bit doesn't mean what it's supposed to mean? Please not, that's the epitome of a hackish solution.

No, it's a mandatory chunk that extends and disambiguates the VRC7 bit in header. Not metadata.

NewRisingSun wrote:
If anything needs patching, it's the TNS homebrew cart

You can't patch the cart, it's hardware. It's a real NSF player cart that already implements this, and they've been making it for a while now. NSFs are already out there for it. I'm not going to create some alternative NSF spec that's incompatible with what it already is, that would defeat the point of adding support for it.

If you're complaining about whether a rip of the Karaoke cart should be remapped to this... that's a different matter entirely. A rip can be patched. Family Noraebang is not an NSF player, and doesn't relate with the NSF spec in the same way.

NSF is not like iNES at all. iNES is trying to take a pristine ROM dump and give enough information to run it. NSF has always been about modifying the dump to just play the music. Because NSF programs are deterministic this is very practical, and relatively easy to verify that the modifications were done correctly. Completely different situation. The Karaoke rip can be remapped to this with zero difference in output.

So the bottom line is: I'm implementing the VRC7 disambiguation chunk to support the TNS player method of replacing VRC7. It already works, and it's just a continuation of it. Whether or not we think the Karaoke cart deserves an entirely new expansion... maybe up for debate, but I think there's a lot of advantage to reuse this one that we've already got practical implementations of. The rip could run today on existing player hardware. Even for prospective emulators, it's less code to maintain, have bugs with, etc.

As for whether every conceivable expansion has to be made possible as a multichip, I don't agree with that. If it's convenient, fine. If it's not, I think other concerns are more important. The fact that the original 6 expansions were (eventually) made mutually compatible was more of a lucky accident than anything else. We don't have a separate expansion bit for VRC6a and VRC6b, kevtris just remapped that. Much more practical. You could build hardware that lets you stack 6 VRC6es if you want, but I'm not really going to add constraints to my plans to ensure that this is a future possibility. Show me someone actually making multichip music with Family Noraebang and maybe I'd think differently about how important this is.


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 9:30 pm 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
That may be the case, but accurate emulation of the expansion sound hardware is why we have such vibrant chip music communities. Might as well shove the YM2413 (K-663A) in NSFPlay and quit whining, bro. :) Also, I think there's some rhythm mode in the Noraebang songs so VRC7 wouldn't work.


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 9:31 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7722
Location: Seattle
B00daW wrote:
Also, I think there's some rhythm mode in the Noraebang songs so VRC7 wouldn't work.
rainwarrior wrote:
When I said VRC7 registers I mean the memory addresses. There will be an NSFe chunk to specify "VRC7 is actually a YM2413" to support NSFs for the TNS cart that has this.


That said, my personal opinion is that I'd really like to stop the conflation of the YM2413 and the VRC7 ... and per plgDavid's video I didn't even know there were apparently three different versions of the OPLL, all varying just by baked-in patch set: YM2413, YMF281 ("P"), YM2423 ("X").

... it's also not clear that the defined binary interface to talk to the simulated IC has anything to do with preventing this conflation.


Top
 Profile  
 
PostPosted: Fri Aug 31, 2018 9:53 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6959
Location: Canada
B00daW wrote:
That may be the case, but accurate emulation of the expansion sound hardware is why we have such vibrant chip music communities. Might as well shove the YM2413 (K-663A) in NSFPlay and quit whining, bro. :) Also, I think there's some rhythm mode in the Noraebang songs so VRC7 wouldn't work.

Read what I wrote. I'm not saying to play it back as VRC7, I'm saying to add a disambiguation byte that says which chip goes at those register locations. Basically exactly what the TNS cart that already supports YM2413 does. If you specify YM2413 you get a YM2413. YM2413 has rhythm mode.

lidnariq wrote:
That said, my personal opinion is that I'd really like to stop the conflation of the YM2413 and the VRC7

It's not conflating them, it's just using the same MMIO location to drive either one. The actual chip to use will be specified.


Top
 Profile  
 
PostPosted: Sat Sep 01, 2018 3:12 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 695
rainwarrior wrote:
You can't patch the cart, it's hardware.
I meant and should have written "NSF files written for the TNS cart should be patched". It bothers me to reward the TNS makers' non-standard implementation by retroactively standardizing it. It is similar to some people's opposition to supporting MMC3 ROM hacks, as well as Chinese MMC3-clone RPGs, with more than 512 KiB of PRG-ROM as Mapper 4.

But lidnariq's comment has changed my mind: if there are now four different YM2413-like chips (YM2413, YMF281, YM2423, VRC7), each with a different set of default instruments, then I would support renaming NSF header byte $7B bit 1 to from "if set, this song uses VRC7 audio" to "if set, this song uses YM2413-like audio", with the VRC7 variant being the default variant, and a mandatory chunk after the main NSF data indicating YM2413 variants other than the VRC7. This would of course accomodate files for the TNS cart as well. This is basically your plan, but the description of byte $7B bit 1 should definitely be explicitly changed then, otherwise people will start thinking that the YM2413 is a kind of VRC7, when the reverse is the case.

I have no preferences regarding the addresses at which the chip responds; make it just $9010/$9030, variant-specific addresses, or both.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group