Custom NES music replacement.

Custom NES music replacement.
by Guest on 2005-12-07 (#7256)

I've created a topic on my forum regarding my plans to implement a music-enhancement system for NES games. If anyone would like to comment, please do so, here or there, as I read both forums regularly.

http://mednafen.com/forum/index.php?t=msg&goto=111

by Disch on 2005-12-07 (#7258)

This reminds me of an idea someone on ZMD had to allow tiles for full PNGs to be blitted to the screen in place of typical pixel rendering.

I must say I'm strongly opposed to both ideas. An emulator's job is to emulate the hardware. It's hard enough to do the real job properly.. even without having to worry with all this "made-up" functionality.

I mean if you're just going to bypass all the NES hardware limitations and use modern PC media... why are you even bothering with the NES at all? Why not work on PC games?

by Guest on 2005-12-07 (#7260)

Disch wrote:
I must say I'm strongly opposed to both ideas. An emulator's job is to emulate the hardware. It's hard enough to do the real job properly.. even without having to worry with all this "made-up" functionality.

I mean if you're just going to bypass all the NES hardware limitations and use modern PC media... why are you even bothering with the NES at all? Why not work on PC games?

My emulator will do what *I* want it to do. I want it to enhance games so that they're more enjoyable, without rewriting them. Why are you so bitchy about it, you don't have to add it to your "emulator".

by Disch on 2005-12-07 (#7261)

I didn't mean to sound bitchy. You wanted feedback and I gave my two cents, that's all. Sorry if you took it the wrong way.

Power to ya if you want to do it... but I still don't like the idea.

by Guest on 2005-12-07 (#7262)

Well.....I kind of wanted feedback and comments on the design and implementation, rather than whether or not it was a good idea in general. :b

by Disch on 2005-12-07 (#7263)

Whoops. Communication error. ^^

by Guest on 2005-12-07 (#7264)

Ok. Now we can be happy together and drink mead and sing songs again!
*lalalala*

by Disch on 2005-12-07 (#7265)

*gives you a beer*

Anyway, since it seems like you're triggering this through read/writes... just be sure to designate an unused area so it doesn't conflict with mapper register writes or NES system registers. Unfortunately, mappers are known to occupy most of the available space (N106 takes all of $4800-FFFF)

I think your best best would be around $46xx... I don't think anything uses that area, and it doesn't mirror to anything either.

by Guest on 2005-12-07 (#7268)

It will be programmable, and I'm hoping that most games will work with the system unpatched, just by watching RAM writes.

by tepples on 2005-12-07 (#7270)

Disch wrote:
This reminds me of an idea someone on ZMD had to allow tiles for full PNGs to be blitted to the screen in place of typical pixel rendering.

I must say I'm strongly opposed to both ideas. An emulator's job is to emulate the hardware. It's hard enough to do the real job properly.. even without having to worry with all this "made-up" functionality.

Four words: Super Mario All-Stars.

Besides, most emulators emulate a PlayChoice, not an NES. Emulating a real NES would involve generating an NTSC signal, filtering it (0-2.7 MHz for luma and 2.7-4.5 MHz for chroma), and doing NTSC decoding on the result.

Quote:
I mean if you're just going to bypass all the NES hardware limitations and use modern PC media... why are you even bothering with the NES at all? Why not work on PC games?

Because many of them would be making ROM hacks for proprietary NES games without having the original games' commented source code, which would be required for a proper PC port. Besides, some people develop NES games, Super NES games, or GBA games because they prefer limited-color 2D graphics to the truecolor 3D graphics that are expected of most PC games. If I want to make a 2D game, critics like to tell me to develop only for a platform that doesn't support 3D so that my work will be more appreciated.

For graphics:
Let's see... If you're working on upgrading an NES game to a more PC level, I'd suggest making tiles 16x16 pixels and 16 colors, with color 0 as transparent (as before). Then, given that each of the 8 palettes in the NES is 3 colors, and each color is 6 bits, associate these 18 bits with a 16-color palette using a hash table.

It won't easily work with U*ROM games or A*ROM games or SNROM games or any other game with VRAM unless you hash the tile data itself, and that can get slow.

For sound:
CPU$3000-$3FFF might be a good place to put emulator-specific registers. This would act "normally" (that is, as a mirror of $2000-$2007) until the program unlocks it by writing a sequence of bytes to $3000 with the "slave PPU" bit set (which no commercial games use).

But in more of the spirit of emulating hardware that could actually be implemented, this could be designed as a Famicom sound chip, which would occupy a 256-byte area outside what other mappers use. Games would need to be trained (e.g. IPS) to use the extra sounds, and it would need a separate sample bank (.wav, .ogg, etc) which could be included in a zipfile (MAME style) or in a folder or even as a new chunk type in UNIF or iNES+UNIF.

$43x0 write: Control (enable, looping)
$43x1 read: Status (finished, stopped, etc)
$43x2-3 write: Sample number to play when this sample finishes
$43x4-5 Playback rate
$43x6 Left channel volume
$43x7 Right channel volume
$43x8-$43xF Reserved

by Disch on 2005-12-07 (#7272)

tepples wrote:
Four words: Super Mario All-Stars.

Yes... a SNES game which fit within the boundaries of the SNES. I fail to see the point you were trying to make.

Quote:
Besides, most emulators emulate a PlayChoice, not an NES. Emulating a real NES would involve generating an NTSC signal, filtering it (0-2.7 MHz for luma and 2.7-4.5 MHz for chroma), and doing NTSC decoding on the result.

Naw... they emulate the NES/Famicom. Just because video rendering isn't 100% accurate doesn't mean it isn't an NES emu.

Quote:
Because many of them would be making ROM hacks for proprietary NES games without having the original games' commented source code, which would be required for a proper PC port.

I guess. That just seems so lame though.

Quote:
Besides, some people develop NES games, Super NES games, or GBA games because they prefer limited-color 2D graphics to the truecolor 3D graphics that are expected of most PC games. If I want to make a 2D game, critics like to tell me to develop only for a platform that doesn't support 3D so that my work will be more appreciated.

So you intentionally choose a system that has more restraints... but then do a hack-job to remove the restraints? What? Why did you pick the NES/SNES/whatever in the first place if you're just going to look for ways to get around the limits of the system?

I dunno... the way I see it, is if you're working with the NES... you should be working with the NES. I mean any halfass hacker can come along and make his own super-powered mapper that will only work in X emu (but won't work on the real thing because the mapper is fictional)... but that defeats the whole idea behind emulation.

I mean I guess it's something this guy wants to do... and it's something he'll use, so I shouldn't be all negative like this. But just the idea of this really makes me cringe.

by tepples on 2005-12-07 (#7273)

Disch wrote:
tepples wrote:
Four words: Super Mario All-Stars.

Yes... a SNES game which fit within the boundaries of the SNES. I fail to see the point you were trying to make.

Point is that the desired facelift that such an emulator would perform on NES games would resemble that of Super Mario All-Stars, where the game logic is pretty much the same (and even runs off the same code), the graphics are actually laid out in the ROM in the same fashion as they are in the NES games (open up SMAS in Tile Molester and look), and only those changes needed to get the game working and saving on the Super NES were made.

Quote:
Naw... [NES emulators that don't take into account NTSC chroma distortion] emulate the NES/Famicom. Just because video rendering isn't 100% accurate doesn't mean it isn't an NES emu.

Likewise, just because video rendering on Nesticle isn't 100% accurate doesn't mean that it isn't an NES emu. As different people draw the line of minimum acceptability at different levels of fidelity, it's useful to state upper and lower practical bounds for this line.

Quote:
Quote:
Because many of them would be making ROM hacks for proprietary NES games without having the original games' commented source code, which would be required for a proper PC port.

I guess. That just seems so lame though.

But sometimes lame is good.

Quote:
So you intentionally choose a system that has more restraints... but then do a hack-job to remove the restraints? What? Why did you pick the NES/SNES/whatever in the first place if you're just going to look for ways to get around the limits of the system?

Why did Nintendo design the MMC5 if not to get around the limitations of the NES? But actually, that comment about restraints and the expectation of 3D on a PC was to address Bananmos's repeated comment that if one tests code primarily to exclusively in emulators, one might as well develop for DirectX.

Quote:
I dunno... the way I see it, is if you're working with the NES... you should be working with the NES.

Did you mean "NROM"?

Quote:
I mean any halfass hacker can come along and make his own super-powered mapper that will only work in X emu (but won't work on the real thing because the mapper is fictional)

Except such a sound enhancing mapper has precedent: the sound chip on the Japanese version of Bases Loaded.

by Disch on 2005-12-07 (#7275)

--delete--

I shouldn't be giving this guy such a hard time. Rather than going back and forth about why I don't like the idea, I'll just drop this so that other people can give some helpful feedback.

Sorry, Guy (whoever the original poster was).

by blargg on 2005-12-08 (#7281)

Quote:
It won't easily work with U*ROM games or A*ROM games or SNROM games or any other game with VRAM unless you hash the tile data itself, and that can get slow.

Based on my experience with the CHR caching optimization I described a while back, replacing tiles at run-time would not be a performance problem at all. The CHR caching routine does a fair amount of transformation on the tile data, and uses less than 1% of emulation time. Replacing it with a simple hash and selection of replacement tile data would probably make it faster.

by Memblers on 2005-12-08 (#7290)

Sounds like it'd work fine, one way would be with a cart like Squeedo that has a serial port you could send init/play signals to the PC and have the actual PC do the sound stuff there. I thought about that before. It would possibly work with a controller port to RS232 adapter also, but controller reads can mess it up (from toggling the strobe output shared by both ports).

If you want the sound coming out of the actual NES, then of course that's something else (and the system would need to be modified). I'm not sure what you have in mind as far as what hardware would generate the sound.

by tepples on 2005-12-08 (#7292)

blargg wrote:
Based on my experience with the CHR caching optimization I described a while back, replacing tiles at run-time would not be a performance problem at all. The CHR caching routine does a fair amount of transformation on the tile data, and uses less than 1% of emulation time. Replacing it with a simple hash and selection of replacement tile data would probably make it faster.

Then what happens when you get CHR RAM games that dynamically compute the tile data? Qix, Videomation, and the map in one of the Final Fantasy games come to mind. For these, you're probably better off just using regular rendering and then letting hq2x sort it out. And what about games such as Rad Racer that use raster effect on every scanline to tilt the background?

Memblers wrote:
[With a custom music chip,] If you want the sound coming out of the actual NES, then of course that's something else (and the system would need to be modified). I'm not sure what you have in mind as far as what hardware would generate the sound.

Which is why many popular NES emulators aren't NES emulators at all; they're Famicom emulators. They don't emulate the lockout chip in a frontloading NES, and they do emulate the sound path going through the Game Pak's PCB. For authentic emulation, they should ignore mapper-generated sound when run in PAL mode.

by Mednafen on 2005-12-08 (#7295)

tepples:

My method would be more difficult to implement in hardware, but it would be completely transparent to the game, requiring no ROM patches.