Famicom expansion hardware recordings

[rainwarrior]

I now have an A/V modded Famicom and I have begun to make reference recordings of the expansion cartridges I have. If you have any to share, let me know.

1. FDS
- [none]

2. MMC5
- http://rainwarrior.ca/projects/nes/just_breed_ref.zip Just Breed six random tracks.

3. VRC6
- http://rainwarrior.ca/projects/nes/espe ... _2_ref.zip Esper Dream 2 six random tracks.
- http://www.mediafire.com/?8aijas3l2yoli1t Akumajou Densetsu recorded by jrlepage.

4. VRC7
- http://rainwarrior.ca/projects/nes/lagr ... nt_ref.zip Lagrange Point complete Sound Check.

5. Sunsoft 5B
- http://rainwarrior.ca/projects/nes/gimmick_ref.zip Gimmick! complete Music Sampler.

6. Namco 163
- http://rainwarrior.ca/projects/nes/roll ... er_ref.zip Rolling Thunder title screen and first level (4 channel N163).
- http://www.mediafire.com/?lwdf8bfaoguy7e3 Final Lap (4 channel N163) recorded by jrlepage.
- http://www.mediafire.com/?vby5zhhbhh3hmaq Megami Tensei II (4 channel N163) recorded by jrlepage.
- http://rainwarrior.ca/projects/nes/erik ... en_ref.zip Erika to Satoru no Yumebouken ten random tracks (8 channel N163).
- http://www.mediafire.com/?ec47t4jajbb6ywl King of Kings (8 channel N163) recorded by jrlepage.

7. PAL NES
- [none]

8. Level comparisons between different carts:
- http://rainwarrior.ca/projects/nes/fami ... rison.flac
- Order: SMB, Ninja Gaiden, Uchuu Keibitai SDF, Just Breed, Rolling Thunder, Erika to Satoru no Yumebouken, Esper Dream 2, Lagrange Point, Gimmick!

Edit: More recently I have been hosting hotswap test ROMs on github, including a suite of standardized mixing tests:
https://github.com/bbbradsmith/nes-audio-tests


Older news:

On a related note, I am currently doing tests by running code from RAM and hotswapping to answer the other questions I've had. So far I have verified the following things:
- 5B has the noise and envelope features of the YM2149F, and they are at the speed I expected (i.e. NSFPlay is correct).
- MMC5 square has envelope feature identical to APU.
- MMC5 square has length counter, same as APU except twice as fast.
- MMC5 $5017 does not appear to affect envelope/length counter like $4017 for APU (appears to be fixed at 240hz).
- MMC5 square does not have sweep, as was known.
- MMC5 square and PCM are reverse polarity vs APU.
- MMC5 squares do reset phase like the APU.
- MMC5 does not silence squares with frequency registers < 8, unlike the APU.
- MMC5 does not silence squares with a high frequency that would be silenced by the sweep unit, unlike the APU.
- MMC5 PCM functions as expected in both read and write modes.
- VRC7 requires delay between register writes.

Source and recordings for some of these tests is currently available here:
http://rainwarrior.ca/projects/nes/swap_tests.zip

A more updated and complete collection of swap test ROMs and sources is available here:
http://rainwarrior.ca/projects/nes/fami ... _tests.zip


I've begun this project because I've been working on NSFPlay/NSFPlug, which I've always liked as an NSF player. I'm trying to make it as accurate as I can, while improving it in other ways as well. My current version of this player is available here:
http://rainwarrior.ca/projects/nsfplay/index.html

[lidnariq]

Additionally if anyone has modified a Gimmick cart and tested the unused AY hardware features on the 5B (e.g. envelopes), that would be helpful.

http://nesdev.com/bbs/viewtopic.php?t=8483
http://nesdev.com/bbs/viewtopic.php?t=5979
http://nesdev.com/bbs/viewtopic.php?t=3480 (stale links)

Anything kevtris says about the hardware I would trust at face value.

[rainwarrior]

Thanks for the links, though all of the relevant recordings in them are actually 404 now.

I've seen jrlepage's NSF test, and he's explained that the envelopes play at a different speed on VirtuaNSF and NSFPlug, but I have no point of reference for which (if either) is the correct behaviour. (Also it would be nice to have a test that isolates specific features, like the envelope.)

NSFPlug uses Mitsutaka Okazaki's emu2149.c, which I'm inclined to trust since it's used elsewhere. VirtuaNES's 5B emulation seems to be custom written. Does anyone know if there's a repository for Mitsutaka Okazaki's code somewhere, so I can make sure the version with NSFPlug isn't modified? It would be great to verify though.

[Memblers]

http://nesdev.com/bbs/viewtopic.php?t=8352
The video in that thread has part of the answer. There are hardware recordings from a crapload of different Famicom board revisions, and IMHO it seems to prove definitively that there never was an "accurate" expansion sound, at least in cases where games use the NES internal channels at the same time (so it's especially notable on FDS stuff since it doesn't stand alone very much). The balance differences are really huge.

[rainwarrior]

Yeah, I did realize that different models have different sound. Even revisions of the NES have some variation (not to mention whether you take the sound from the AV out or are demodulating the RF signal, or even just resistor variation between the same model). I was hoping to at least get to a sensible set of default sound levels (people seem to complain that expansions are too loud in NSFPlug); though maybe that's doable via some consensus. The levels are easy to configure though; not a huge problem overall.

More important is actual simulation errors. Is there anything that NSFPlug is getting demonstrably wrong at this point? Effective hardware recordings can show this kind of error really well.

[ionustron]

there may be another issue: shameless cross post I put over at famitracker forums...

I don't really use trackers nor do I post here much, but I was talking to chibitech last night and there may be some things to watch out for with N163 emulation in the long run...

It's possible that an authentic interpolation or resolution method may need to be implemented in the future depending on the number of active channels. It's still very much up in the air, but the idea is that songs that activate more channels start to have sample interpolation issues. Well that concept along isn't up in the air, it's just that I thought all currant players were taking this into account, though it may not be the case.

I had become concerned this past famicompo when I heard a recording of my submission taken through a variant of Nezplug - nezplug++ - apparently it's considered accurate by some folks in the eastern side of things, least with N163 emulation. However, it's emulating really bad banding in various ranges depending on samples and many channels activated. Even commercial games that use all 8 channels (King of Kings, Erika to Satoru no Yumebouken, others,) have a very annoying high pitch hiss the entire time! Chibi thought that perhaps this hiss is filtered out when the signal runs through RF; but perhaps if your famicom had an AV out setup, you might get the hiss. Powerpak as well as most currant players may not emulate the banding.

The issue was brought up to the author of the Nezplay variant, that certain N163 enabled songs (such as xaimus's dendrite) have the painful hiss (not to mention another issue, later,) to which the author responded that that is the way it's supposed to sound. Take that as you will I guess.

We may ask Robokabuto in the future to confirm this since I guess he has a TNS-HFE4 set-up, but it's very likely that it's just as accurate as whatever famicom you're running off of, just like that video posted of FDS Zelda title screen audio recorded on something like 30+ different famicom & famiclone models; if it's an AV cable model, perhaps you'll have problems if it can even run expansion mappers, but again, this is all up in the air right now.

Also, I don't know if it was reported but apparently in said emulator, Chibi said the currant famitracker beta ported nsfs had a nasty buzz on the 163 channels, apparently the same as NSFs created using it2nsf with N163 enabled played on real hardware. It may be a unnecessary constant register write every single frame.

Again, sorry as this is all very vague, and sounding like it's developing for one emulator (that I don't even care for that much!) Hopefully we'll get some more solid information later.

Perhaps the nsf player author has a really crappy famicom? Who knows...

[rainwarrior]

Yeah, there's all sorts of things that can go wrong on just one person's unit. I had a used genesis where the electrolytic capacitor on a power supply filter had dried out, and I could basically hear the CPU loudly through the audio output, until I figured it out and replaced it.

Also, I added PAL support to NSFPlay; see OP for link.

[B00daW]

Thanks for taking it upon yourself to really do this! So far the player passes a lot of tests and curveballs I throw at it. Because I love it, I'm guaranteed to nitpick it, so be prepared...

First off the biggest downside I see is that Strobe's NSFs he made with a custom FamiTracker export plugin that glues FTMs together for "unlimited" bankswitched DPCM (within NSF file specs) crash and burn. Do not try them on PowerPak's NSF player since it has a 256KB NSF limit due to hardware limitations. Kev says that they work on his FPGA player and they are legal in spec.

http://lmao.rotfl.at/upload/Str0be/stro ... e_blip.nsf
http://lmao.rotfl.at/upload/Str0be/strobe-ziberia.nsf

So far it's passing most other PCM NSF tests, N163 tests, and multichip tests just fine!

On to the nitpicks and feature requests:

* I see you are concurrent with terms such as N163 and Sunsoft 5B. These could be reflected in the player. Also, the "DPCM" channel could be called "(D)PCM" since it's more than just a DPCM channel.

* Since the Sunsoft 5B is a clone of the AY with extra memory mapping functions, it would be nice for NSFPlay/NSFPlug to support the AY volume register "buzzer" for when FamiTracker supports Sunsoft 5B compositions!

* MMC5 PCM support would also be nice... I don't think it would be very hard to port SuperNSF to MMC5 just for proof of concepts at first.

* DPCM and PCM logging/dumping would be a very handy feature. NSF Live! by jsr is still used quite frequently to rip DPCM samples. I see PCM logging and dumping to be kind of difficult if someone is using direct $4011 writes to affect noise or triangle volume.

* N163 waveform logging to MML format. This way waveforms could be logged and copy/pasted into FamiTracker or *MCK.

* NSF2 support. If you support it, you will have the first player in the world to use it; aside from Kev's FPGA player. NSF2 is the next frontier in NES/Fami music composition!

Even NSF2 aside, having all noted features above would make NSFPlay/NSFPlug the only fully-featured NSF player in the world; then we can really focus on more accuracy to make it the most fully-featured and accurate player in the world. That way people could just stop arguing about which player is the best and only use one; this one.

Edit:

I'm also very pleased that NSFPlay works great under WINE too.

[rainwarrior]

1. I was planning to adjust the names. No, I'm not going to put parentheses around the D. That looks silly and nobody calls it that. I was considering just calling it DMC though, since that's the actual name of the channel and not just the sample format.

2. Can you possibly get me Strobe's source code and FTMs for those NSFs you think should work but don't? It's will take a lot more time to try to debug it if I have to do it by reverse engineering.

3. What is the AY volume register buzzing, and is this something that you know NSFPlay is missing, or have you tested it? (If you do have a test for it, send it to me.)

4. I don't agree that MMC5 PCM support would be "nice", as it's an utterly useless hardware feature, but support for it is on my to-do list. Does there even exist a game that used it for musical purposes and not just game-halting sound effects? I had to hand write my own NSF just to test it.

5. If you want to rip DPCM samples, try my NSF Importer for Famitracker. http://rainwarrior.ca/projects/nsfimport.html PCMs you can rip very easily just by opening the ROM as raw data in an audio editor. I don't really intend to facilitate DPCM or PCM ripping with NSFPlay (I don't think there's a good way to generalize PCM ripping anyway), but I will probably need to implement a trace/debugging feature.

Actually, now that I think about it, if you just mute everything but the DMC and record the output that's as good as any "PCM logging" feature would do. Why don't you just do that?

6. Again, not really planning to facilitate sample dumping with this program, but my NSF Importer project is all about this kind of thing, so... there will be a solution.

7. Ha ha, NSF2. Only when I get everything else worked out.

[tepples]

Actually, now that I think about it, if you just mute everything but the DMC and record the output that's as good as any "PCM logging" feature would do. Why don't you just do that?

That depends on how well the output sample rate lines up with the APU sample rate., along with whether the output nonlinearity can be switched on or off.

[rainwarrior]

The nonlinearity can already be switched off in NSFPlug.

I don't see why the output samplerate would be a factor. The standard 44.1kHz is more than enough to capture every sample (in any practical example); you can figure out the true samplerate and resample without losing anything.

I think the options currently go to 96kHz if you really need it, but if the NES can even go that fast (not sure what the exact limit is) why would you bother storing a PCM sample that plays at an inaudibly high frequencies?

[tepples]

The standard 44.1kHz is more than enough to capture every sample (in any practical example); you can figure out the true samplerate and resample without losing anything.

How hard it is to undo the upsampling of a 33.5 kHz DPCM kick drum sample to 44.1 kHz depends on what sort of filtering the player uses.

[rainwarrior]

All the filtering as well as the nonlinearity can be turned off in NSFPlug.

At any rate less than your output samplerate you can resample without losing anything (as long as your resampler is point sampling).

Still, for PCM ripping it's far easier just to open the ROM as raw data in an audio editor. For DPCM ripping just use NSF Importer.

[tepples]

Still, for PCM ripping it's far easier just to open the ROM as raw data in an audio editor.

Have you ever tried doing that for Big Bird's Hide and Speak?

[rainwarrior]

Doesn't work for that one. Obviously there's going to be examples where they don't store them raw. Do you have a burning desire to rip the samples from this game?

Also, and I forgot about this earlier, playing raw PCM in an NSF is a really touchy operation anyway. This is why there are very few NSF rips that include PCM samples. (This big bird game might be tough to rewrite the for NSF compliance.)

So... yet another reason why PCM ripping for an NSF player isn't really in the cards. It only applies to modern music engines written specifically for NSF, and for that you can probably just ask the author for the samples.