Implementing Original Music for Nintendo & Sega Game Dev

Discuss NSF files, FamiTracker, MML tools, or anything else related to NES music.

Moderator: Moderators

User avatar
AlexE
Posts: 46
Joined: Fri Jan 29, 2016 3:16 pm
Location: York, PA
Contact:

Implementing Original Music for Nintendo & Sega Game Dev

Post by AlexE »

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
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by Sik »

AlexE wrote: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.
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).
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by tepples »

Sik wrote:anything based off the MAME core has a "non-commercial use" limitation
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.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by thefox »

AlexE wrote: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.
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.
Gradualore's GGSound was used in Super Bat Puncher (which is an outstanding game with outstanding music)
Are you sure about that? I always thought miau rolled his own playback routines for SBP, but I could be mistaken.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by Kasumi »

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.
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?
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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by tepples »

A reply from the point of view of a music engine developer:
Kasumi wrote: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.
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)?
Different engines/converters might make the same song wildly different filesizes, so there's no answer to how big the song could/should be.
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?
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.
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).
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.
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.
User avatar
B00daW
Posts: 586
Joined: Thu Jan 03, 2008 1:48 pm

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by B00daW »

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.
User avatar
Kasumi
Posts: 1293
Joined: Wed Apr 02, 2008 2:09 pm

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by Kasumi »

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)?
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.
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?
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.
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.
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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by tepples »

Kasumi wrote:Where are you getting ought to?
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.
Kasumi wrote: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.
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?)
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by Memblers »

tepples wrote: Or am I making too big a deal about it, and are composers willing to learn new tools?
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.
User avatar
AlexE
Posts: 46
Joined: Fri Jan 29, 2016 3:16 pm
Location: York, PA
Contact:

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by AlexE »

thefox wrote: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.
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.
FamiTone2 Template (with limitation notes).ftm
(7.65 KiB) Downloaded 394 times
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.
Kasumi wrote:How much space is too much for the music is similarly impossible to answer generally.
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?
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 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.
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.
:'( That's a shame. I absolutely adore VRC6 and FDS expansions. Is this not even possible (or realistic) on emulation-only homebrew dev?
B00daW wrote: 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.
Thanks, man! I'll check that out.
tepples wrote: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.
I haven't heard of PPMCK. I'll check into that as well.
Memblers wrote:Otherwise, the only good option is to let composers use whatever tools they want, and have someone else convert the song to whatever engine.
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. :shock:
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by zzo38 »

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.
(Free Hero Mesh - FOSS puzzle game engine)
User avatar
AlexE
Posts: 46
Joined: Fri Jan 29, 2016 3:16 pm
Location: York, PA
Contact:

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by AlexE »

zzo38 wrote: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.
If it's able to incorporate FamiTracker effects like vibrato, arpeggio, tempo, etc. to NSF then to game dev, that would be great.
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.
That's good to hear.
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.
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.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by zzo38 »

AlexE wrote:If it's able to incorporate FamiTracker effects like vibrato, arpeggio, tempo, etc. to NSF then to game dev, that would be great.
With ppMCK it is possible to do vibrato, arpeggio, and tempo.
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.
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)).
(Free Hero Mesh - FOSS puzzle game engine)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Implementing Original Music for Nintendo & Sega Game Dev

Post by tepples »

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.
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?
Also yes. The size of PRG ROM on all but a single-digit number of NES games is a power of two.
(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".)
If you mean Zelda II: The Adventure of Link, that's nowhere near MMC5. It's a garden-variety MMC1 according to NesCartDB.
I wonder if this additional hardware is easy/cheap to manufacture for homebrews?
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.
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.
:'( That's a shame. I absolutely adore VRC6 and FDS expansions. Is this not even possible (or realistic) on emulation-only homebrew dev?
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.
tepples wrote: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 ... [It and] LilyPond [use] text-based WYSIWYM formats
I haven't heard of PPMCK. I'll check into that as well.
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.
AlexE wrote:FamiTracker effects like vibrato, arpeggio, tempo, etc.
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).
AlexE wrote: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.
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.
Post Reply