Sound Chips?

Ne0

New member
Will there Be an update in the future that allows other sound chips to be put into NESmaker Like the Sunsoft 5B or the Namco N163 or even the Konami VRC7?

That would be really awesome to have that in NESmaker!
 

TakuikaNinja

Active member
No. Updates are non-existent at the moment and you'd need to rewrite the entire codebase to change the mapper to one with expansion audio. By that point you should be making a new game from scratch instead.
 

pizle

New member
@Ne0, That would be rad, but would also require those physical chips to be soldered to your game-cartridge's PCB and the game re-coded for it completely (like what TN said).

...and it's not just Dev's being lazy ...you see NESMaker is just a GUI (Graphical User Interface) to help assemble code/resources into "I/O"machine language. The stock hardware on the NES/FC can only read this "I/O" language with limited capability (6502 proc can't multiply, divide, etc). So third-party devs found you could attach EXTRA hardware to a game's physical cartridge and intercept specific instructions, to be executed by those more-capable chips. Clear as mud so far? Good!

Many "stars" would have to align to pull that off (finding/implementing proprietary code, variety of chips, etc). Hope this helps you understand the genuine difficulty of that change, despite how cool it would be to soft-expand the NES's APU.
 

maxoakland

New member
No. Updates are non-existent at the moment and you'd need to rewrite the entire codebase to change the mapper to one with expansion audio. By that point you should be making a new game from scratch instead.
When you say updates are non-existent, do you know why? Is NESMaker development over or is it just slowed/paused?
 

TakuikaNinja

Active member
When you say updates are non-existent, do you know why? Is NESMaker development over or is it just slowed/paused?
Development has slowed down to a snail's pace as far as I know.
I think the NESmaker team only recently realised how much work they signed up for.
In retrospect, I think they should've finished Mystic Searches first.
 

maxoakland

New member
Development has slowed down to a snail's pace as far as I know.
I think the NESmaker team only recently realised how much work they signed up for.
In retrospect, I think they should've finished Mystic Searches first.
That’s too bad. Didn’t they announce SNESMaker last year too?
 

Bucket Mouse

Active member
They felt pressured to announce it because someone else announced THEY were building a SNES Maker. Then that other guy dropped the project. SNES Maker was announced prematurely and probably won't happen for years, unless someone ELSE wants to make one.

And they ARE finishing Mystic Searches first, at least that's what it seems like. Joe seems mostly preoccupied with it over all his other projects.
 

maxoakland

New member
They felt pressured to announce it because someone else announced THEY were building a SNES Maker. Then that other guy dropped the project. SNES Maker was announced prematurely and probably won't happen for years, unless someone ELSE wants to make one.

And they ARE finishing Mystic Searches first, at least that's what it seems like. Joe seems mostly preoccupied with it over all his other projects.
The irony is, I’m pretty sure that guy dropped it because NESMaker announced they were making one too. So that’s actually really annoying because now it means we got nothing

I love your username by the way
 

capacitor

New member
@Ne0, That would be rad, but would also require those physical chips to be soldered to your game-cartridge's PCB and the game re-coded for it completely (like what TN said).

...and it's not just Dev's being lazy ...you see NESMaker is just a GUI (Graphical User Interface) to help assemble code/resources into "I/O"machine language. The stock hardware on the NES/FC can only read this "I/O" language with limited capability (6502 proc can't multiply, divide, etc). So third-party devs found you could attach EXTRA hardware to a game's physical cartridge and intercept specific instructions, to be executed by those more-capable chips. Clear as mud so far? Good!

Many "stars" would have to align to pull that off (finding/implementing proprietary code, variety of chips, etc). Hope this helps you understand the genuine difficulty of that change, despite how cool it would be to soft-expand the NES's APU.
but, for build a room(no chip) the "only" assembly modifications that could be made would be the adresses of the diferent mappers, or not? what moooore would be?
 

TakuikaNinja

Active member
but, for build a room(no chip) the "only" assembly modifications that could be made would be the adresses of the diferent mappers, or not? what moooore would be?

NESmaker uses mapper 30 (UNROM512) by default. It provides 512KB of PRG-ROM divided into 16KB banks, and 4x8KB CHR-RAM banks.
For better or for worse, the software and codebase are built around this mapper. Changing it to use another mapper let alone one with expansion audio would require major changes.

First major change: CHR-RAM -> CHR-ROM
CHR-RAM means that tiles are manually written to the PPU (graphics processor). It allows for graphics to be stored (even compressed) onto PRG-ROM.
CHR-ROM means that tile data is stored into a separate chip on the cartridge, directly connected to the PPU. Most mappers with expansion audio use CHR-ROM banks, so the codebase would have to change to account for it. (The FDS is its own nightmare to code for)

Second major change: PRG-ROM bank size
A few mappers with expansion audio support 512KB of PRG-ROM (exceptions: MMC5 is 1024KB, Sunsoft 5B is 256K), but the size of the banks are usually 32KB, 16KB or 8KB. The codebase & bank structure would have to change to account for this.

Third major change: Register layout
This has already been mentioned by Ne0. Changing mappers always involves changing the codebase to use the correct mapper registers. You could make a system to automagically set them up, but you'd need to be working with a variety of mappers to justify that.

Honorable mention: FC vs NES
Only the original Famicom can play expansion audio without modifications to the console. Enabling expansion audio on the NES involves adding circuitry to the expansion port on the underside of the console. This isn't an issue on emulators, but you may want to consider making the music in such a way that the lack of expansion audio doesn't ruin the compositions on an unmodified NES.

You also need to keep in mind that NESmaker becomes less and less useful with each modification to the codebase. At some point you will realize that it's easier to bypass the software and make/use a different toolchain for NES development. A few members here have become aware of that fact already.
 

maxoakland

New member
Only the original Famicom can play expansion audio without modifications to the console. Enabling expansion audio on the NES involves adding circuitry to the expansion port on the underside of the console. This isn't an issue on emulators, but you may want to consider making the music in such a way that the lack of expansion audio doesn't ruin the compositions on an unmodified NES.
Is there a known reason Nintendo did that? It’s disappointing
 

TakuikaNinja

Active member
Is there a known reason Nintendo did that? It’s disappointing
It's probably related to the strict third party licensing Nintendo of America brought in. Third party mappers were disallowed (notable example: Castlevania III had to be changed from VRC6 to MMC5). Nintendo's MMC5 does have expansion audio capabilities, but barely any Famicom games used it (sound effects/one time samples only).
As already mentioned, expansion audio can be re-enabled by adding circuitry to the expansion port. I suspect this was so Nintendo could sell extra hardware a la the Super Famicom's BSX service. There were also plans to bring the Famicom BASIC accessories (like the keyboard & cassette recorder) over, but I assume it was dropped as soon as the new licensing & marketing strategy was proposed.
 
Last edited:
Top Bottom