It is currently Fri Oct 20, 2017 5:27 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: NSF player "cheats"?
PostPosted: Mon Feb 01, 2016 10:09 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5721
Location: Canada
I still think the best thing to do is append NSFe chunks. The NSFe metadata format already exists, is already implemented by some players, and can do the job perfectly well. Chunks are easy to parse, easy to skip if the player doesn't want to handle a particular chunk type, and easy to extend in the future. I believe NSFe's existing chunks already have all of the proposed metadata goals on the wiki met, aside from an explicitly stated text encoding (it asks for UTF-8).

Encoding is actually an open issue with NSF, since it was never made explicit, and many Japanese composers use Shift-JIS. I think all existing NSFe rips are technically utf-8 compatible, since they were pretty much all done by Disch and should be plain ASCII. We could just make that part of the standard for NSFe text encoding.

...and no I do not dare anyone to make a game. Certainly not just to prove a point. What kind of reason would that be to make a game? The things that motivate others I may never understand...


Top
 Profile  
 
 Post subject: Re: NSF player "cheats"?
PostPosted: Mon Feb 01, 2016 6:34 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 284
This has to be the most epically derailed thread I have ever started. :shock:

B00daW wrote:
Someone who's writing an NSF(2) player just needs to move forward with these two discrepancies to have much desired/needed IRQ supported. Who really wants to write their own hacked routine to rip PCM or IRQ related routines when a proposed format can do it. This would ease in the ripping process and allow for growth into readily-present hardware capability.

I'm all for IRQ support in the standard, but I'm probably not a good person to talk to for working on said standard. Six months ago I wasn't even aware the NES homebrew scene existed. I'm just going to sit tight and wait for more experienced people, such as yourself, to figure out where they want to go from here.

If anyone wants a software implementation, or the opinion of a software implementor, I should be around here somewhere.

B00daW wrote:
Regarding your comment on the hardware emulation requests: Most of those features are already emulated by MESS/MAME; as you say -- and there's no shame in taking readily available code. Even rainwarrior's NSFplay is hardly original.

You're still not getting it - I am writing an NSF player. Not an arcade machine emulator. Adding features outside the scope of a project is the road to feature creep and bloatware. I understand your desire to make music using such hardware and the desire for an emulator of said hardware. This is not that emulator. I don't normally like using analogies, but you're talking to a piano maker about guitar picks.

Sorry if I'm being pedantic here. I get like that sometimes. :oops:

B00daW wrote:
Two things out of the bunch that are not currently emulated are 2a0x audio TEST and Mitsubishi M50805 for "Family Trainer 3: Aerobics Studio"; which is an LPC decoder with factory ROM and hardware modes to allow for input of LPC datastreams. I've created test NSFs that rely on $6000-based expansion registers for this setup. (I should probably just write a test CopyNES driver with the cart in to make something artistic with my Aerobics Studio instead.)

Now these I can help you with. I think I have most of the information I need to emulate the TEST registers. If someone can write a test ROM and confirm the functionality on hardware, I can add them to my player. I'm not sure how useful they would be though.

As for the two remaining expansion audio chips, well, they both appear to play fixed samples. I'd need the relevant data off the chips if you want an emulator implementation. And again, I don't really see how they would be useful for anything other than their original purpose.


Top
 Profile  
 
 Post subject: Re: NSF player "cheats"?
PostPosted: Mon Feb 01, 2016 7:32 pm 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 540
Rahsennor wrote:
You're still not getting it - I am writing an NSF player. Not an arcade machine emulator. Adding features outside the scope of a project is the road to feature creep and bloatware. I understand your desire to make music using such hardware and the desire for an emulator of said hardware. This is not that emulator. I don't normally like using analogies, but you're talking to a piano maker about guitar picks.

Sorry if I'm being pedantic here. I get like that sometimes. :oops:


I'm glad you're writing an NSF player :D. "Family Trainer 3: Aerobics Studio" is a Famicom cartridge and practically everything I've considered writing to you involves the Famicom/NES aside from Donkey Kong 3 arcade. What I meant was regarding Jaleco is the "NEC µPD7756C". This Famicom "expansion" chip is present in many known Famicom cartridges. It provides additional ADPCM playback without 2a0x cycle cost. The hardware within the cartridge simply calls a function that the ADPCM encoder plays out the expansion audio port. The Mitsubishi M50805 is only known within the Famicom cart Family Trainer 3: Aerobics Studio; but again this is an LPC (vocoder) decoder. Both of these would be very interesting when it comes to art production and currently are not supported in emulation or even NSF; even being known Famicom cartridges.

The reason why the reference to the Donkey Kong 3 arcade machine would be relevant to an NSF player is that it involves two 2a03s.


Top
 Profile  
 
 Post subject: Re: NSF player "cheats"?
PostPosted: Mon Feb 01, 2016 7:51 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 284
Yeah, I know what those two chips are - I looked into them back when I first saw there were two chips on the wiki's expansion audio page that did not appear in the NSF specification. But it looks like both of them have an internal ROM for sample storage. Without the contents of those ROMs, and some way of including them in an NSF file, emulation is basically impossible.

For now I think I'll get started on IRQ support. That should make implementing the full NSF2 standard much quicker, once I have something concrete to implement.

B00daW wrote:
The reason why the reference to the Donkey Kong 3 arcade machine would be relevant to an NSF player is that it involves two 2a03s.

So write two NSFs and mix them in postprocess - boom, done. :P


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Yahoo [Bot] and 7 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