Implementing Original Music for Nintendo & Sega Game Dev

Hi! I'm Alex. I'm a music composer for video games and movies (as well as an animator, writer, etc.).

FOR NES​
I have used FamiTracker (a music tracker designed to perfectly emulate the 2A03 audio chip of the NES/Famicom) for many years and I've always been fascinated by the fact that whatever music made in that program can be played on original hardware. That had me thinking about homebrew and ROM hack development, looking to improve my freelance music composition repertoire by expanding into the homebrew and ROM hack scene. I then found this site which deals specifically with retro game dev and so I figure that I would be able to get clear and more follow-able answers here.

FamiTracker is able to export NSF, .NES, PRG, BIN, ASM, and tracker text formats. Here are my questions:

• What steps can I take to make sure that the music is more usable for the programmer(s) to implement into their development?
  Are there size limits to individual tracks? I know that FamiTracker allows for limitless frames, but how much space can be used on a NES game to be used for audio?
• How do I sort out sound effects? Should they be separate songs in FamiTracker or in one song? Is there something I can do in FamiTracker that would allow for the sound effect to return back to the background music after the sound effect is finished playing?
• Are there specific Song Settings I should use (e.g. Speed, Tempo, Rows, Frames)? I understand that the NES does not build its tempo on BPM like the SNES does but on some kind of "clock" timer. Would changing the Speed or Tempo in the settings affect how the game performs? This includes the Fxy function which I use for ritardando and accelerando.
• Expansion audio (e.g. VRC6, FDS, Namco 163) can only be used on Famicom hardware with the physical chip on the game cartridge (and on NES emulators, of course). Would a Famicom Everdrive/flash cart remove that problem?
• If the ROM of a game with expansion audio implemented were to be played on the 2A03-only NES, would the expansion audio simply not play or would that lead to complications?
• How should I export the music data to the programmer?
• Will FamiTracker's "New Style" of vibrato (modulating the pitch up and down instead of the "Old Style" where it is just down) cause problems? Will having a very effect-heavy and musically busy soundtrack cause errors?

According to HertzDevil on the FamiTracker forum, he said this.

"Do not use FamiTracker BIN export, especially if there are going to be sound effects at all. FamiTracker's own NSF driver is never designed to allow fast playback; instead, leverage existing drivers like Shiru's FamiTone2 or Gradualore's sound driver, or create an intermediate format yourself, either with the text exporter output or with the (not very usable) CFamiTrackerDocInterface class. You are on your own when designing sound drivers that are compact yet sufficiently expressive."​

After looking into it, FamiTone2 by Shiru allows for converting FamiTracker (v 0.3.6 and higher) music —
including DPCM — into NESASM, CA65, and ASM6 formats. Gradualore's GGSound was used in Super Bat Puncher (which is an outstanding game with outstanding music) and in Star Keeper (which I haven't played yet). I am not interested in developing my own program to convert FamiTracker data into usable code AND the actual implementation of that code into the game as my knowledge in these fields are very limited. If necessary, I will look into those things further.

Unlike the SNES where the RAM for the audio and the RAM for the rest of the game are separate, the NES shares it. The largest official games for the NES were Kirby's Adventure at 6 megabits and Uncharted Waters at 5 megabits and most other games were at around 4 megabits. The largest Famicom game was Metal Slader Glory at 1 megabyte (or 8 megabits). I know they are capable of more, though it requires additional hardware for the cart (apparently the Nintendo 64 can handle a 4-GB cart! Resident Evil 2 was the largest game released at 64 megabytes). At any rate, I'm wondering how much of the RAM on the cartridge can be used for audio and read by NES and Famicom hardware? How much can be used for an NES emulator?

I also found some neat things like this NES programming tutorial.

FOR SNES​
In addition to NES music, I'm also interested in learning how to create SNES music so that it can be implemented into a SNES homebrew/ROM hack. I did a great deal of research into how the SNES handles audio in order to accurately create fakebit SNES music from scratch.

The audio chip of the 16-bit Super NES/Super Famicom (Sony SPC700 via 65816 RAM(?)) has 8 adaptive differential pulse-code modulation (ADPCM) channels for bitrate reduction- (BRR) compressed samples. All the samples had to be compressed with ADPCM/BRR formats at a ratio of around 3.5:1 (32:9?) to less than 64 Kilobytes to fit on the discrete audio chip’s RAM. This means that for every 32 bytes of 16-bit PCM there are 9 bytes of BRR. The size of the samples should in total not exceed more than 150 kilobytes. The raw samples of the instruments are tweaked for downsampling, then downsampled to 8 to 22 kHz, and cut into small loops that are then truncated to 8 bits. Equalizing to retain brightness can occur before or after downsampling. Samples are often no larger than 2 kilobytes, having 16 samples to be looped.

The DSP also allowed for echo effects. Impressively enough, the SNES is capable of Dolby Surround Sound, albeit it was pseudo-surround sound using stereo Q-Sound.​

I later learned that Shiru made a SNES music tracker that does all that busy work for me (except for the chorus effect). The tracker is more basic and less intuitive than FamiTracker, but it gets the job done. I don't know how I would go about exporting that data to be used for SNES development.

FOR GAME BOY​
I have only been able to find a few ways to create Game Boy (and Game Boy Color) music: mGB (a hardware mod that allows for MIDI signals from a MIDI controller, effectively making the Game Boy a basic polyphonic synthesizer), Little Sound DJ (a music tracker cartridge for the Game Boy itself), and Deflemask (a tracker that emulates the Game Boy audio chip as well as the YM2612, YM2515, 2A03, MOS 8651 and 8580, and more). To my knowledge, only Deflemask allows me to create Game Boy music from the computer instead of from the Game Boy itself and in such a streamlined way. However, I don't know if it is able to export the tracker data to be used in Game Boy dev. It is able to export VGM format.

FOR SEGA GENESIS / MEGA DRIVE​
The same for the Game Boy goes for the Genesis. I am aware of VGM Maker, a Genesis music tracker, but it is nowhere as clean looking and as streamlined as Deflemask. It is also able to export VGM format. I'll keep the rest of this topic in the Sega dev forum.

This forum post was also posted to AssemblerGames.com

I never figured out how to make Deflemask work, to be honest (it keeps refusing to let me touch the track or load files from outside its directory?).

Honestly I should make a tracker for Echo (which then would be guaranteed to be usable for games since Echo is a sound engine, not a player), but emulating the YM2612 is hard, and the existing emulators are either bad (I know composers will consistently run against problems with the Gens core) or have licensing issues (in particular, anything based off the MAME core has a "non-commercial use" limitation, which hits hard with homebrew in case something ever ends up in a cartridge).

MAME has been moving toward a free software license, and only a handful of non-free drivers remain. I wonder if there's a way to exclude them at compile time.

Note that FamiTone supports only a limited set of features from FamiTracker, so it's a good idea to familiarize yourself with the limitations, and to test early and often with the music actually running in FamiTone.


Are you sure about that? I always thought miau rolled his own playback routines for SBP, but I could be mistaken.

NES restriction questions are sort of impossible to answer. For graphics. For code size. For scanline effects. There are so many configurations because of extensions being allowed in the cart. And that affects a lot more than just music.

NES has 2KB of RAM. Cartridges can give 8 more kilobytes. or 32 more kilobytes. Or whatever. But even if that's true, that doesn't necessarily mean any extra is allocated to the music. As you already know, there's different music extensions. You can't use them on a project that doesn't have them, obviously.

How much space is too much for the music is similarly impossible to answer generally. How to give data to a developer... You'll have to ask all of these questions every time you approach a developer. (If they approach you, they'll likely tell you the limitations.) I mean... I know it's no fun, but it really is different every time. Especially with hacks of existing games. Homebrew developers might use existing libraries, and then they might say, "I use famitone2" and you read what it can do. And then you don't do what it can't do. They might say, "I need you to type up every single note/rest in a file in this format." And then you have to do it if that's how their game works and you want to make music for it. Or write your own program to make that easier for yourself. Or make them write a program to make it easier for you.

Different engines/converters might make the same song wildly different filesizes, so there's no answer to how big the song could/should be.

All of the RAM on the cartridge could be used for audio. It depends on the design of the individual game. An NES emulator could give you an effectively limitless amount of RAM, but you could do something similar on the console itself by building your own cartridge. But if all you're doing is composing, you don't have to worry about that at all. If you don't use the things the engine doesn't support, and the engine is written well, it doesn't matter what you do you'll be fine on RAM. A bigger worry is actually CPU speed. If you make a really CPU intensive song, you could cause the game to start playing slower. And even what will make a song CPU intensive varies engine to engine.

I know you're looking for some general metric, but there really isn't one. Actually there's one: You should never even expect to get to use any kind of expansion audio.

Still, learning to compose music under Famitone2 is probably your best bet for practice. Its rules are in its readme. If there's some part of them that's tough to understand, that's an easier thing to help with than a general what can I do.

Edit: These answers are mostly true for all the platforms you're looking at. There's X that the console can do. Y is the subset of that that the music engine for game Z can do. You need to know Y before writing music for Z. X practically doesn't matter.

A reply from the point of view of a music engine developer:


By "make them write a program", are you trying to imply that developers of music engines that operate by translating a textual input format ought to make and include tools for converting music sequences ("every single note/rest") from formats used by more popular GUI composing tools (IT, S3M, XM, MOD, FTM, MIDI)?


How critical is it that a music engine developer include a guide to estimating file sizes in the music engine's manual? And how critical is it that a music engine include configuration options to enable or disable particular engine features at assembly time in order to push the engine's size even smaller?


For example, the Sunsoft FME-7 has been shown to allow selection among up to sixteen 8192-byte banks of WRAM at $6000, for a total of 130 KiB (128 KiB on the cartridge and 2 KiB in the console).


X matters to the extent that Z's developer feels a need to add often-requested features to Y in order for his hard work not to be ignored.

Hey AlexE,

We have a "Music" subforum here too. Some regularly usually check that one first who are more musically inclined and attented.

Perhaps this discussion should be moved over there as well.

~~~~~~~~~~~~~~

Regarding the additional SPC700 effects for SNES there is an IT converter program developed by Augustus Blackheart and KungFuFurby located: http://www.morganleahrecords.com/august ... loads.html Source code is available.

Where are you getting ought to? Three choices were listed if a hypothetical musician pairs with the developer of a text based format and they both want to work with each other. If the composer is fine with typing the text, that's the first choice. If they're not and can program, making their own program is the second choice. If they're not fine with typing text and can't program, having the developer who wants the music make a program to help is the third. Who else would do it given that situation? If they didn't, they'd have to find a different composer, but even that doesn't mean they should write conversion tools.

File size estimation is not critical at all. I'd say it's unimportant. As far as disabling engine features, it's probably also not that critical. But as everything, it depends on how large the base engine is. Or maybe not even then, if it doesn't need to always be swapped in. Your engine can be 5KB and it'd be fine. NROM people would be out of luck, but there's a million edge cases to everything. I wouldn't care if an engine was 8KB, so long as it tried to be as fast as possible but that specific sentiment may be uncommon.


That's only true if Z's developer also developed Y. (I realize that is you, yes.) I personally wouldn't be adding features to an engine I didn't write for a musician. I'd probably be willing to write stuff to make getting it in the actual format easier if I really liked the music, but that doesn't close the gap from Y to X. There's usually some meet halfway point. It's the way of things.

Because I want my engine to be adopted, while I'm told composers are willing only to work in a tool they already know. A couple months ago, I was almost offered a job as composer for an NES game project, but I was turned down because I wanted to use my engine, and it wasn't quite ready for other composers to use in case other composers needed to make changes to a song. The producer went with FamiTone instead because other composers would be more comfortable in FamiTracker.

HertzDevil's analysis of the 275 NSFs in the original and cover sections of Famicompo Pico '15 bears this out. Over 80 percent of all entries were composed in FamiTracker (71 0CC-FT; 65 FT 0.5.0; 67 FT 0.4.5/0.4.6; 29 FT 0.4.4 or earlier; 232 total). Only 22 used P*MCK, and 10 were converted from IT/S3M.

My engine uses a similar "what you say is what you mean" (WYSIWYM) approach to PPMCK. But I'm told PPMCK isn't popular here in the west, unlike in Japan where the popularity of MSX BASIC exposed people to MML. The other text-based format is LilyPond, which I'm guessing is popular in the classical scene, not so much in the chiptune scene. So I'm guessing that many western chiptune composers are not familiar with text-based WYSIWYM formats, nor can they program. They're more acquainted with the "what you see is what you get" (WYSIWYG) approach, which WYSIWYM fans prefer to deride as "what you see is all you get". It's like the difference between, say, Microsoft Word and LaTeX. Nor is an expert at 6502 assembly language programming necessarily an expert at PC tools programming.

All this means I will likely need to either A. make a program to help convert formats commonly used by western chiptune composers; B. acquaint western chiptune composers with typing in text in some manner, such as by hosting a compo; or C. accept that my work will be ignored.


It's about willingness of a game's producer to pair a musician with a developer. Some programmers want to maximize the pool of composer labor in case they want to sign other composers onto a project in the future. And one way to maximize this pool is by choosing an engine that has the easiest path from the tool that is most popular among composers.

Or am I making too big a deal about it, and are composers willing to learn new tools?

(And is this a thread hijack?)

It's sort of like asking a guitarist to write their next song on a xylophone or something, maybe they could and maybe it's mind-expanding, but it's not the process they're used to. That's quite a different thing from asking them to take a song they wrote on guitar, and arrange it for a xylophone. I'm sure what you would find is composers want to make their song in Famitracker, then they'll be wondering why they should bother to remake the same song with a different interface when it going to come out sounding the same. If you can automate that boring part, and encourage users to then further enhance their songs with special features of your engine, then I think it would stand a chance of getting the usage it deserves. Otherwise, the only good option is to let composers use whatever tools they want, and have someone else convert the song to whatever engine.

I actually did look into that and I wrote out each limitation in FamiTracker in the instrument names. I also looked into RushJet's new DPCM tool creatively called RJDMC. It seems pretty neat from what I've seen.

I'll get to noting the GGSound limitations another day since it's 1 AM currently and I feel like doing that thing that normal people do at 1 AM. What was it called again? Sleep? Never heard of it.


So that means that I could essentially write a 20-minute prog rock magnum opus for the 2A03 while adhering technically to the limitations of FamiTone2, GGSound, or whatever format the dev requires for his game and I'll have no problems? Or are you saying that whatever space is left from the more important aspects of the game like graphics and gameplay can be used to fill in with music? If the game is being created with the purpose of being played strictly on emulators, then that would mean I have free reign over the length and complexity — ultimately, the file size of whatever format the dev requires — of each song and SFX while adhering to each format's limitations (FamiTone2: no duty cycle sequence but DPCM supported; GGSound: duty cycle sequence but no DPCM supported; manually: no inherent limitations but complicated). If the game is being developed to be played on original hardware, the music would have to adhere to some size restrictions that would be put in place by the developer himself unless the cartridge uses additional, custom hardware (called mappers(?)) to accommodate for more RAM. (I've heard of the MMC5 being used in The Legend of Zelda: Adventure of Link, a freakin' rad ROM hack of The Legend of Zelda. I tried using it on my Everdrive N8, but it would load because the cartridge hardware didn't have the right "mappers".) I wonder if this additional hardware is easy/cheap to manufacture for homebrews?

I assume that's where the "speed" of FamiTone, GGSound, etc. comes into play, right? I've heard some slick, complex NES jams (particularly music from Tim Follin, who is my new favorite video game composer) in games like Silver Surfer.

:'( That's a shame. I absolutely adore VRC6 and FDS expansions. Is this not even possible (or realistic) on emulation-only homebrew dev?



Thanks, man! I'll check that out.


I haven't heard of PPMCK. I'll check into that as well.


That's what I'm hoping I can get out of this whole situation is a more simple method of converting from FamiTracker to usable code for the programmer. It seems that it is more complicated than that from what I can tell.

There are also my improvements to ppMCK (tail-call optimizations, as well as * and ? commands), which is also possible in case you want to use MML. Also note that ppMCK is really meant for making .NSF rather than for games, although the output could be adapted for such use, I suppose.

And about MAME, I would like to be able all program can be made properly FOSS, although I don't care about the license of the game manifests; I believe external manifests would be a better idea anyways.

If a game has expansion audio and is used on NES, the expansion audio is simply bypassed (it won't play). You can have option in the game to configure such thing if you want to do so.

How much space can be used in the game depend what mapper you are using, as well as on the game, and ROM size, and other stuff. However, there can be different storage formats depending on the playback engine, so compression may also be possible.

If it's able to incorporate FamiTracker effects like vibrato, arpeggio, tempo, etc. to NSF then to game dev, that would be great.


That's good to hear.


I heard that NES data could be compressed from a Reddit post I made asking why there hasn't been a decent ROM hack of Metal Gear yet. There wasn't a lot of info spilt on NES compression, though.

With ppMCK it is possible to do vibrato, arpeggio, and tempo.

I don't know much about the compression used for music (although look at Pently for example), although there is more stuff about compression of other stuff such as map data and text and so on (if they are compressed, it also makes more room for the music; however note also CHR ROM is separate from PRG ROM and many games will have both; CHR ROM is normally used for graphics, although some games may use it for other stuff too (such as compressed map data)).

Yes, if there's enough space. But in practice, a 20-minute composition would probably need to be synchronized with the game action, and that more than likely would mean auto-scrolling and no "go back to save point when you die": either respawn in place or restart the whole thing. Unless, that is, the 20-minute composition itself has restart points.


Also yes. The size of PRG ROM on all but a single-digit number of NES games is a power of two.


If you mean Zelda II: The Adventure of Link, that's nowhere near MMC5. It's a garden-variety MMC1 according to NesCartDB.


Basic mappers allowing more RAM are easy to manufacture: in theory, it's just a 6264 SRAM and a 74HC20 to decode it (meaning to enable it). If you're implementing some common ASIC mapper (such as MMC1) on a CPLD, the equivalent of a 74HC20 can likely fit into unused space on said CPLD. It gets more expensive if you want the data in RAM to persist across a power cycle, as in games with battery save, because you have to add a 3 volt lithium watch battery, a battery clip, and a circuit to control the RAM's voltage during power cycles.


On emulation-only homebrew dev, you can in theory just use MP3 music, which simulates an MP3 player being soldered to a Famicom PCB. Heck, on emulation-only homebrew dev, you can make games at PS2 or higher graphical complexity, as Java, C#, and asm.js programs are "emulated" in a way.

Unlike the Famicom cassette connector, the NES Game Pak connector lacks the pins used for audio; instead, those are routed to the expansion connector at the bottom (for traditional front-loading NES consoles) or nowhere (for the top-loading NES-101). If you're intending to sell copies of the game on cartridge, you'll also have to sell a jumper pack that plugs into the expansion connector in order to make the sound audible. Such a jumper pack exists; it is one of the functions of chykn's ENIO board.


I'm not certain that PPMCK's engine is really optimized for the ROM size or RAM size requirement of coexisting with graphics and game logic code, as zzo38 pointed out. But once you're proficient with the MML input format of PPMCK, you'll have a big head start on learning to use my music engine, called Pently. I made Pently because small size was important to me in NROM-128 projects.


Pently supports both arpeggio envelopes and arpeggio effects. It supports tempo changes down to fractional-BPM precision. It supports sound effects that interrupt music in an intelligent manner. The two things it doesn't support are vibrato and portamento, and that's probably a result of my training on discrete-pitch instruments (piano and trumpet).


It depends on what kind of compression. Some are better suited to the (relatively) small RAM of the NES than others. Methods that involve looking small things up in a static table to get big things, such as byte pair encoding or Huffman coding, work well on NES. So do run-length encoding (RLE), which assumes that the each byte is likely to be the same as the previous byte, and Markov RLE, which uses a table to predict the most common byte that follows each byte. I've used RLE and Markov RLE to compress graphical tile data and map data, and data formats built around Huffman coding or byte pair encoding work well for text. Still other forms of "compression" could be described as clever ways of structuring data to avoid internal fragmentation, such as a music engine whose sequence data combines 5-bit pitch and 3-bit duration of each note into a single byte.

But one popular family of general-purpose compression methods, called LZ77, is based on references to previous decompressed data in a circular buffer. That's not so easy on NES, which has only 2048 bytes of RAM randomly accessible to the CPU unless extra RAM is on the cartridge. LZ77 is easier on the Master System, which has 8K of main RAM; the Game Boy, which also has 8K of main RAM as well as random access to video RAM while rendering is turned off; and on Genesis and Super NES, which have 64K or more of main RAM.

What that means is that it's impossible to answer generally. If you really, really, really want a general metric, whatever song you want after exporting to whatever format should probably be less than 8KB. The problem with this answer is that it's not strictly impossible to have a larger song. And most devs will probably not want a single song to be that large, but I don't have a number in my head of where a better line is. It depends how much the developer values music. The Super Bat Puncher music is very large for just a few songs if I recall correctly.

Note that this 8KB limitation I'm throwing out randomly only deals with a single song. All of the data for all of your songs could be like 256 KB, and that generally wouldn't be a problem for playback specifically, but it would be taking up a lot of space that the dev might want to use for other things.

Which... is again why this sort of thing is impossible to answer generally.

Okay, let me put it like this: You only get "free reign" through an emulator if you know how to program, because if nothing exists that gives you the space/features you need, you have to add it to the emulator yourself. Just like to get "free reign" on the hardware itself, you need to be able to design/build the PCB that will make it possible. As Tepples said, it's possible to get MP3 quality playback but at that level what's the point of going with NES? A lot feel the same about expansion audio. I don't think there's a commercial USA release that uses expansion audio. If there are, they don't make up more than 1% of the overall library.

But the only universal truth is that it's up to the dev. If they both know how to and want to support whatever, you can do whatever. If they can't or don't want to, you can't. So you must ask the dev. Yes. Every time. Unless you are already capable or are willing to learn to build music engines/whatever yourself to help them.

The answer is no. And honestly, I'm not even sure it's well emulated yet. If you care about your stuff being played on real hardware, you should expect not to use any expansion sounds.

Edit: Hmmm... infiniteneslives is at least working on some boards that supported expanded sound. So maybe you can get there at some point.

It's impossible to answer generally. Certain effects (if they're supported), certain instruments might be CPU intensive. The speed of the song itself could matter too, but... impossible to answer generally.

If you only care about emulation, there's still another problem. As far as I know there doesn't really exist good freely available music engines for expansion sound. (Maybe the famitracker driver is one? But that's not particularly good for games.) I could be wrong on this point and there's something that's just as easy to use for them as Famitone2. But if there's not, what this means is that whoever you pair with has to build a thing just to support your music. And this also locks them into whatever mapper the expansion sound is paired with (which affects how programming will go for many things beyond the music.), unless they also want to build a custom thing that supports the music of the expansion sound and also other things they want.

I'd say it's not realistic to expect it for homebrew, no. Maybe for those MMC5 conversion hacks, I don't know enough about them.

There's really no such thing as NES specific compression. NES has a CPU like any other. It's limited by RAM and addressing space, but in theory it can do the same things as a modern computer could. Just very slowly. The issue with compression on NES that whatever you want to compress must be able to fit in RAM decompressed, and be able to be decompressed relatively quickly on the weak CPU.

What the reddit post could mean is that Metal Gear uses a lot a custom compression formats that haven't been reverse engineered yet.

Edit: But ROM hacking (outside of certain graphical things) isn't easy in general. You are editing code you did not write, with no documentation, after it has been assembled. The reason hacks are common for certain games is the hard work has already been done, usually due in part to extreme popularity. Super Mario Bros. has a full disassembly, which is like having documented source code. But... someone had to actually go and figure everything out for that to exist. Same for GUI level editors and things. That's the result of a person spending hours with debuggers trying to figure out what pieces of RAM represented. I would assume no one has done the hard work for Metal Gear yet.

Just as a random aside DPCM is not too much fun to support. Even though, yes, Famitone2 does support it, the data for it has to be in a specific place in memory on NES which makes certain things hard depending on what hardware setup a given game uses. My choice to support it is actually causing a lot of problems in a mini project I'm working on.

Say I gave you a famitone2 test package. You make your song, export it, double click a thing and you'll have a ROM that will play whatever music you gave (or give you errors if you didn't obey the limitations somehow). Is that interesting to you? This could at least give you an idea of how large certain songs would be in Famitone2.

In my opinion, that is a bit silly. I can describe my own opinions about emulation-only homebrew dev, in order to contrast.

One thing about making the .NES format is that you can then use it on many different emulators, including on different devices. Some might not support the mapper in use, although it may also be possible that future versions of that emulator will implement it. Most emulators do support expansion audio as far as I know.

Even if you never intend the game to be use outside of emulator, it should still be design to work on real hardware too. There are advantages of such: working better on future emulators, and that in case someone does want to use it on a real hardware, they can do that too (although if you need to, you can use a complicated mapper, which would make it more difficult to use on a real hardware but still possible). I like to think of it as, the program is written for "Famicom VM", and the different implementations of Famicom VM including software implementations (emulators) and hardware implementations (such as NES and Famicom hardware).

While you can use MP3 music, I do not really suggest it (although there are some work-in-progress specification to allow formats such as Vorbis to be provided as a purely optional alternative to 2A03 music on emulators that can support them; a similar work-in-progress specification exists for graphics too)

However, of course if you do not want to write your game for "Famicom VM", you are not even required to do so, as tepples has mentioned. You can use Java or .NET or whatever if that is what you want your game to be, although then you are not writing a NES/Famicom game.

Except the likes of Bananmos used to always drill in us that the Java or .NET VM will get the job done more easily than the Famicom VM.

Blast from the past: Threat of violence, hopefully in jest

tepples wrote:

AlexE wrote:

So that means that I could essentially write a 20-minute prog rock magnum opus for the 2A03 while adhering technically to the limitations of FamiTone2, GGSound, or whatever format the dev requires for his game and I'll have no problems?

Yes, if there's enough space. But in practice, a 20-minute composition would probably need to be synchronized with the game action, and that more than likely would mean auto-scrolling and no "go back to save point when you die": either respawn in place or restart the whole thing. Unless, that is, the 20-minute composition itself has restart points.

Maybe a 2D sidescrolling Gradius-like game where it is just one very, very long level would work for something like that? That'd be pretty neat.


Nah, I mean the ROM hack Legend of Link! Adventure of Link, Legend of Link, Link's Dink? It's all the same at this point. Legend of Link uses MMC5 because the game is far too huge to use regular hardware. It's a super great game, too. Infidelity, the creator of the hack, had a blog about it.



WHAT. Are you telling me that a modded NES, even in an NES emulator, can play MP3s?? And that a NES emulator can play games that look like PS2 games for the NES emulator??? That's a little unreal.


I feel really out-of-place here because I'm having trouble keeping up with this tech jargon.

What don't you understand?

...Please tell me you at least know what a "byte" is, or "RAM"...

Because of how the Famicom was designed, there is a long tradition of extending its functionality by adding extra hardware in the cartridge.

Whether, as in the Famicom Disk System, that's just to provide a single channel of audio and a magnetic storage medium, or the MMC5 to add all sorts of extra video features.

So, pedantically, you could take an MP3-player-on-a-chip, put it inside the cartridge, and call it good enough. There were a number of Famicom games that are almost exactly this: they added a stored-speech IC to the cart. (And the only real difference here is "how many seconds of recorded audio can you store")

A byte is a unit of data and RAM stands for Random Access Memory (or Random Access Memories if you're a Daft Punk fan).
I understand some of the very basics of computing. I'm more of a musician than I am a programmer.

What lidnariq describes is exactly why it's so difficult to give general answers to your questions. Even if we limit our answers to things that were used in the era, it's still a very wide range of possibilities.

Let's move past what CAN be done...

If you're interested in making 80s style chiptunes, for use on NES (etc), then restrict yourself to the commonly used sounds. Sure, you could Mod a cart to play an MP3, but where's the nostalgia in that? It won't feel like an NES game/song.

tepples and I were talking about this in IRC the other day. I offered him my outsider's opinion, and I'm curious to see what others would think.

I haven't truly delved into famitracker yet, but from what I've seen, the interface doesn't seem particularly musical to me. When I think of laying out music on a computer, I think of something like this:


(I've chosen FLstudio as the example, because I actually like its interface the best for creating music directly on a computer.)

I realize what I'm saying goes against the whole worldwide chiptune scene, but I feel like those who aren't chiptune composers would be more comfortable with a piano roll, and a visual layout to position song segments. Then, any musician who's familiar with a DAW could compose pretty comfortably for your game project.

There's actually a Game Boy music editor called Bleep that's laid out a bit like that. As a contrast to LSDJ, I suppose.

Edit2: I guess while I'm editing I should say that version of bleep is Game Boy, not color.

To me the difference is mainly in the axis. One's vertical, one's horizontal. I think there are more problems than layout moving from a traditional musical background to chiptune. Like... you can't hit three notes at once for a chord on NES. Edit: At least not with the same instrument and without expansion sound.

FamiTracker (and trackers in general) use the computer keyboard to simulate a piano roll pretty analogously, so it comes naturally from a pianist persepctive. The rest of it is using math to place out the rhythms of each note/sample. I also use programs like Reason and MuseScore to make music.

My questions aren't so much as to what technological madness can be done on the NES, it's how to put music ON the NES game. Basically, the answer seems to be "You'll have to figure it out; here's some tools to help you figure it out."

Once you have made the music, the player library will come with a subroutine that you call to start a song, a subroutine that you call to start a sound effect, and a subroutine that you call every frame to update the APU registers. A player library may offer additional subroutines to pause music, register a loop callback, and the like.

So I offered in one of my posts a thing that lets you try out your music using Famitone2's player. Do you want that? I'm not saying figure it out, I'm saying it's on a game by game basis. The questions you're asking simply can't be answered generally. We can help you with Famitone2 specific questions. We can help with GGSound questions. We can't help you make music guaranteed to work for any given game, because that's impossible.

So what is your goal? If you're looking to get your music in a game, you can simply post things you've made without expansion chips so people can decide if they like your sound. You may not get responses, but that's more that there simply aren't that many people doing this.

If you do get a response, whoever wants your music will definitely help you out with what their game needs. It's just hard to help you with general questions, when it's going to vary based on the project that needs the music. It's not like a modern game where you can just send an mp3 over which will work in whatever project.

You wouldn't prefer a piano roll like Reason uses or a staff like MuseScore? Personally, I like to have a visual indication of my notes and their lengths. I think there's a massive difference between the two approaches.

If you look at the screen on a piano roll setup, at a quick glance, even subconsciously, you can see where the notes you've placed would fall on a keyboard. You can see the intervals between the notes immediately. You can see how long any given note is and visually observe any slides. You can read all of this from the screen, for the entire segment of the song on which you are working, in a matter of seconds, if that.

When I look at famitracker, I see code. I see something that I have to interpret to get a meaning from it. I'm not a classically trained musician, and I wouldn't call myself a musician, I suck at it, but I enjoy hitting drums and playing analog synths. (they're so cool!) Anyway, I have to know what an A#3 is, and subtract that from a C-4, to know the interval between notes. Then I have to count the spaces between notes to find the length. Are these notes sustained or staccato? How many of these spaces does it take to make a quarter note? If I want to write a song with a 7/4 verse, a 5/4 chorus, and a 3/4 break, can I get a visual indication of that? What are these effects? They're just numbers; they're not any sort of terms that describe what they are.

If I want to hire a composer for my game, should I expect a musician to take the time to learn to code in famitracker and be able to convert their musical writing style to it, or should I find someone who works exclusively in chiptunes? You can go to the hipster part of your local city and throw a rock and it just hit a musician who needs work.



That's true, but I feel like that's more of a limit of the instrument rather than for the method of conveying information to it. Anyone who's programmed a monophonic synthesizer would immediately understand that.

Set the length of a beat in rows with "Row highlight 1st", and set the length of a measure with "2nd". I forget whether this time signature is global, per FTM, or per song in the FTM. But it's certainly not per pattern, which is what you'd need to for the kind of math rock you describe in your next paragraph.

Pently allows changing time signatures during the song. You can set a time signature for one measure, start some patterns, wait for another measure, change the time signature, and start different patterns.


You could find a musician who can read sheet music and set up a Pently environment. Someone comfortable in MuseScore could export in LilyPond format and then copy-paste the exported sequences into a Pently project. Or you could find someone who has used PPMCK or another MML tool, as much of MML is also valid in Pently.

That might've been more bratty sounding that what I thought it would be. I apologize.
By "figure it out", I mean that each game would be different as you said and that I would have to "figure it out".
I appreciate the help!

Typically in FamiTracker, things are split up into even numbers. I usually go by having every 8 rows being a quarter beat. That would mean that every 4 rows is a eighth beat and every 2 rows would be a sixteenth beat.

When I use FamiTracker, the computer keyboard essentially BECOMES the piano roll. Q on the keyboard is C musically, W is D, E is E, R is F, T is G, and so on. The accidentals are set up in the same manner. The number 3 in "C-3" means that it is C in the third octave (middle C actually, I think). If you want to have a staccato eighth note, for example, you would cut the note's length with the Note Cut tool, essentially a rest, at the second row after the note is played.

FULL EIGHTH NOTE
01 D-3-
02 -----
03 -----
04 CUT

STACCATO EIGHTH NOTE
01 D-3-
02 CUT
03 -----
04 -----

As for different time signatures, that would depend on the amount of rows (1/32 beats) per pattern (measure). 4/4 time will probably have each 1/4th beat having 32 rows totaling 128 rows. If you want 3/4 time, you would place a Dxx effect at the third beat in 4/4 time to cut the measure short (or you could have 96 rows instead of the default 128 rows). You would have to mathematically figure out the number of rows needed for those unusual time signatures (since I don't have FamiTracker with me at the moment).

For effects, there are various effects for changing how a note plays. They're labeled as a number from 1-9 and A-F (instead of 10-16 because trackers use single digit numbers for some reason I DUNNO. If you remember from middle school math class, you'll remember that x and y are variables that can be given these numerical/alphabetical values). I use 4xy, the vibrato effect, for vibrato. It keeps the droning sound of the pulse wave from becoming monotonous. The Axy effect allows for volume sweeps and I personally prefer it to creating a volume envelope because it keeps things more simple, streamlined, and customizable on the fly HOWEVER apparently FamiTone and GSSound doesn't like that.



Analog mono synths are my fuckin' jam, m8.

EDIT: Later, I'll upload a FTM file explaining some fundamentals of FamiTracker.

Before you do that, I want to state that my questions were largely rhetorical. The reason I brought this up is because of the talk about whether or not it's reasonable to expect a composer to learn a new interface for writing chip tunes. I question whether or not the interface for writing chiptunes needs to be something that even requires learning. (besides the use of non-basic features and keyboard shortcuts)

I'd like to ask this question:

Having done both methods and overcome the learning curve of Famitracker, would you see any downside to a piano roll method of composition? I've casually messed with Famitracker for about an hour. I knew the answers to a couple of the questions that I asked but not all of them. My view is that I never opened up a piano roll style program and wondered what to do to create notes. I think seeing this as an outsider is valid, because I'm considering my (hypothetical) choice for chiptune composition software. I feel like if I took the time to learn Famitracker, that switching to a piano roll system would allow me to retain what I learned about creating music for the hardware, and at the same time, wouldn't introduce new hurdles, because the interface would be self-explanatory.

If I was considering getting into chiptunes, and there was an option for composition that had a piano roll, the choice would be a no-brainer for me. I'd go for the piano roll hands down. Am I the only one who feels this way? (It's perfectly fine if not, but I'm curious if my opinion at all correlates to the feelings of the general intended user base for a chiptune composition program)

Having started using trackers and a very early version of Cakewalk (3.0 for win31) at the same time, I'm roughly equally familiar with both UIs. I prefer trackers for electronica, sheet music for live instruments, and piano rolls for visualizations (but not for composing).

In my opinion, there are a few things (both features and constraints) that trackers make explicit:
- Coupling effects and instrument choice into the UI. The piano rolls that I have seen often don't present any information other than duration and pitch.
- Monophonic instruments (impulse/modplug tracker notwithstanding)

I find that piano rolls make duration really clear in a way that I don't find helps me when I'm composing.

Additionally, I find that the tracker UI makes it easier to get an idea of everything that's going on at the same time; I find that reading "F-4 D-4 A-3" is a lot easier to identify (as a first inversion F major chord) than three horizontal lines with specific spacing on a piano roll.

Well, from the opinions that I got, it seems that I'm in the minority on this one. Perhaps a piano roll would be more popular outside of the chiptune community, but nobody that I've talked to who composes chiptunes would be interested in working in a piano roll.

Thinking on this, sure, I know plenty of good musicians, but would their talent translate to creating chiptunes? I'm sure if someone had a lot of experience programming monophonic synths, even synthesizing percussion sounds, that would translate. A modular synth aficionado would probably be well suited for the task, but you're going to have a throw a rock pretty far to hit one of them.

A real wind-blown instrument (flute, clarinet, trumpet, saxophone) is a physical monophonic synth. If you build the instrument definitions, you can have someone else compose sequences using those instruments.

I'd be honored if this were true, and surprised I didn't know because I conversed fairly often with miau back when he was developing that. Haha! I'm amused I'm still referred to as Gradualore. I'm just GradualGames. Where did you hear that it was used in SBP? *edit* StarKeeper is great---not sure if a rom is available, it was a limited release on NA. But it was a fantastic game---definitely an unsung gem in the homebrew community. Great music, too. I'd say I was biased only I didn't realize until much later that he was actually using my sound engine, haha!

I don't know exactly where I read it, but I guess confused "Gradualore" with "GradualGames" because "Grad...." was in the name. It was also probably 2 AM at the time, so I get pretty loopy in the wee hours of the morning.

No, you're quite right, the word "gradual" is intentionally in each iteration of the name. But I've basically dropped the original moniker, in preference of "brand recognition" so far as that has any meaning in this small community, hahah.

Hi, I asked if you'd like a thing. Here's the thing:

It's very simple at the moment. It has no visuals/doesn't support sound effects/DPCM, but I figured I'd get you something to start before I get too deep in another thing and forget. I make no promises I'll update it, but anyone else can feel free to. It's not like anything's sacred in there.

Make a song (or set of songs) in Famitracker using Famitone2's limitations. Go to file, export text in Famitracker. Export "testsong.txt" into the unzipped directory. Double click "makerom.bat".

A file called "main.nes" will be created with your music.

Or, it will tell you why it was not able to create a rom. If "main.nes" doesn't exist in the folder, read what the commandline window said and try to fix it. Or ask us if you don't understand the error.

You can press right to go to the next song, and left to go to the previous song.

Let me know if you have any actual problems with it.

Hey there, let me clear this up real quick!
GGSound was not used for SBP. I rolled my own sound driver that supported most of Famitracker's feature set at the time except for DPCM. I wanted the composer to not have to worry about technical details too much. We did agree to only use certain effects (vibrato, sweeps and some others), so I could purge the rest from the driver and save some RAM.

I also implemented lz77-like compression for the song data, but without using much extra RAM (it used the compressed input as a dictionary). The compressor was some kind of weird bruteforce genetic algorithm thing written in C that would run for 10 minutes to achieve a ~50% compression ratio. Don't even dare to look at it now.

What I did use back then, though, was your (Gradualore's ) text exporter plugin for Famitracker. Thanks a bunch for that! IIRC, I ended up extending it later to be able to export an entire FTM (all songs) in one click.

Hahah! Amusingly, I didn't even write the text exporter plugin (unless you actually used the example sound engine it came with, which was actually a super early version of GGSound). What I did do was create a system for adding a drop-in dll plugin to famitracker. Others, starting with Shiru, created a text exporter plugin using that system. Then, rainwarrior added text export directly into famitracker. Since then I believe nearly everyone is using that, in combination with a converter tool (text to asm) for specific music engines.

Ah, it was probably Shiru's plugin then, sorry! All I know is there's a "TextExporter.dll" lying in a plugin folder somewhere. And the plugin system might be where I remember your name from, then. Some diving into the FamiTracker source had to be done.