This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

The merits of a fixed bank


by on (#45899)
In this post, tokumaru wrote:
Mappers that "fix" a bank of memory to the end of the addressing space do it so that the programmer can have a place to safely store all the bankswitching logic and the interrupt vectors.

If that were the main reason, then it would have been cheaper to use 32 KiB bankswitching (like B*ROM/A*ROM) and put a stub for trampolines and vectors into the last 256 bytes of all banks than to add the 74HC32 on the cartridge's circuit board. As I understand it, the real reasons that U*ROM fixes the upper 16 KiB are so that
  • one piece of code running in $C000-$FFFF can read CHR data, map data, music sequence data, etc. from multiple banks, and
  • data accessed by background DMA processes (on the NES, that's only DPCM samples) remains mapped in no matter what the main code is doing.

by on (#45915)
I thought the hardwired bank was so programmers had a safe place to put the bankswitch initting code, for the mappers whose settings are unpredictable on boot. :P

by on (#45917)
Drag wrote:
I thought the hardwired bank was so programmers had a safe place to put the bankswitch initting code, for the mappers whose settings are unpredictable on boot. :P


Yes, but that's pretty easy to work around (fit the reset/init code at $FFF0-$FFF9 in every bank). The better advantage is what tepples said.

Quote:
one piece of code running in $C000-$FFFF can read CHR data, map data, music sequence data, etc. from multiple banks


Actually many, if not all of the UNROM NSFs I've ripped keep the sound code and data in the same lower 16kB bank.

by on (#45923)
Memblers wrote:
Actually many, if not all of the UNROM NSFs I've ripped keep the sound code and data in the same lower 16kB bank.

This is a very logical choice, because music can take a considerable amount of space, and it would be very wasteful to have that mapped at all times when it's used only once per frame.

by on (#45929)
tokumaru wrote:
Memblers wrote:
Actually many, if not all of the UNROM NSFs I've ripped keep the sound code and data in the same lower 16kB bank.

This is a very logical choice, because music can take a considerable amount of space, and it would be very wasteful to have that mapped at all times when it's used only once per frame.


The catch is though, you can't use more than 16kB (minus code size) for sound data while the code is in that same bank. Many Capcom games were like that, it's an impressive amount of music for the size.

by on (#45930)
tokumaru wrote:
Memblers wrote:
Actually many, if not all of the UNROM NSFs I've ripped keep the sound code and data in the same lower 16kB bank.

This is a very logical choice, because music can take a considerable amount of space, and it would be very wasteful to have that mapped at all times when it's used only once per frame.

Are you talking about music code or music data? As of April 2009, my sound engine's CODE segments occupy less than 768 bytes (reported by ld65 for music.o + sound.o + samples.o, not counting RODATA), but then I don't yet have all the effects in. Once the music code+data exceeds a bank, which might happen in some 256 KiB games using UOROM or SNROM, you have to duplicate the code, or you have to put at least some of the code in a fixed bank, or you might have to put instruments and sound effects with their code in one bank and order tables and patterns with their code in another bank. It happens even more quickly for MMC3 games, whose $A000 bank is only 8 KiB; a lot of them reserve the other switchable bank for DPCM.

To put it more concisely and closer to the topic: Fixed banks are good for any code that needs to access data spread across multiple banks. Some sound engines are big enough to need that; others aren't.

by on (#45934)
I don't see the problem here, have your music engine in bank #n, and music/SFX data in others banks. When calling the music engine you switch bank #n in, and from there if you need to fetch music/SFX bytes, call a routine stored in the hard bank that will switch the desired bank, fetch the data, switch bank #n instead and return the data. Maybe a little slow if all channels starts new notes at the same frame, but I don't see the problem.

For 32kb switching games, if 32kb is not enough to store all the music+SFX+sound code, that fetching routine will have to be copied to RAM, but again that's no real issue.

Quote:
It happens even more quickly for MMC3 games, whose $A000 bank is only 8 KiB; a lot of them reserve the other switchable bank for DPCM.

I don't know why you keep saying that again and again when it's not true, as far I've checked the very vast majority of MMC3 games arround uses $8000-$bfff switchable and $c000-$ffff fixed, SMB3 is the only one I know which doesn't do that (gimmick does but it's not MMC3). If you really use that much DPCM I'd just suggest using $4011 instead because DMA mode sounds horrible in my opinion.

by on (#45941)
Bregalad wrote:
I don't see the problem here, have your music engine in bank #n, and music/SFX data in others banks. When calling the music engine you switch bank #n in, and from there if you need to fetch music/SFX bytes, call a routine stored in the hard bank that will switch the desired bank, fetch the data, switch bank #n instead and return the data. Maybe a little slow if all channels starts new notes at the same frame, but I don't see the problem.

You could run the entire game on top of peekFromOtherBank and end up with less than 1 KiB of the 16 KiB fixed bank used. Ultimately, it's an engineering decision.

Quote:
Quote:
It happens even more quickly for MMC3 games, whose $A000 bank is only 8 KiB; a lot of them reserve the other switchable bank for DPCM.

I don't know why you keep saying that again and again when it's not true, as far I've checked the very vast majority of MMC3 games arround uses $8000-$bfff switchable and $c000-$ffff fixed, SMB3 is the only one I know which doesn't do that

Can anyone who regularly builds emulators from source gather some stats on that?

Quote:
If you really use that much DPCM I'd just suggest using $4011 instead because DMA mode sounds horrible in my opinion.

That's fine if you want to pause the action while the sample plays. The most complicated animations I've seen behind $4011 sample playback are scrolling the screen (Rick Rolled demo), mouth flaps (Big Bird's Hide and Speak), and palette updates (Skate or Die 2 title).

by on (#45943)
Sometimes I feel like we enjoy having the same discussions over and over again... Too little of the content in this thread is actually new, most of it we have discussed before.

by on (#45944)
tokumaru wrote:
Sometimes I feel like we enjoy having the same discussions over and over again... Too little of the content in this thread is actually new, most of it we have discussed before.


I guess we're getting older? :P

by on (#45948)
...and that don't create any good homebrew releases.

by on (#45973)
Memblers wrote:
tokumaru wrote:
Memblers wrote:
Actually many, if not all of the UNROM NSFs I've ripped keep the sound code and data in the same lower 16kB bank.

This is a very logical choice, because music can take a considerable amount of space, and it would be very wasteful to have that mapped at all times when it's used only once per frame.


The catch is though, you can't use more than 16kB (minus code size) for sound data while the code is in that same bank. Many Capcom games were like that, it's an impressive amount of music for the size.


Bomberman Pocket for Gameboy had a duplicate of its music engine in each bank that had music in it. It works, but I can see where some programmers would frown on it. *shrug*

by on (#45979)
tokumaru wrote:
Sometimes I feel like we enjoy having the same discussions over and over again... Too little of the content in this thread is actually new, most of it we have discussed before.


well it's 'new to me' lol but hey, you can't expect to have much in the way of new content for a 40 year old technology

by on (#45989)
frantik wrote:
well it's 'new to me' lol but hey, you can't expect to have much in the way of new content for a 40 year old technology

Sure, but it's one thing to discuss about the same subjects, and it's another thing to hear the exact same arguments and the same replies over and over. =)