Smallest chr-rom or ram bank size is 1k? or smaller?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
GradualGames
Posts: 1106
Joined: Sun Nov 09, 2008 9:18 pm
Location: Pennsylvania, USA
Contact:

Smallest chr-rom or ram bank size is 1k? or smaller?

Post by GradualGames »

Are there any mappers which have an even smaller chr bank size than 1k? Or is that the smallest?
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by Bregalad »

There's no technical limit, however I am not aware of a mapper that swaps smaller amounts than 1k. The same is valable for PRG-ROM, there is no technical limit but I do not know any mapper swapping banks smaller than 8k.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by rainwarrior »

Bregalad wrote:I do not know any mapper swapping banks smaller than 8k.
Mapper 31 does 4k PRG banking, and it's based on NSF which requires it.

That's also why the PowerPak can't play NSFs over ~256k. Its PRG address control only goes down to 8k so it had to be worked around. Everdrive N8 can do it, though... but it doesn't have an NSF player. (You can't win!)
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by Myask »

NovaSquirrel was desiring such a 512B CHR-banking mapper…but, as no other mapper had, the PowerPak doesn't interpose that address line, and can't do it.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by rainwarrior »

Myask wrote:NovaSquirrel was desiring such a 512B CHR-banking mapper…but, as no other mapper had, the PowerPak doesn't interpose that address line, and can't do it.
Does it only fail to output that line to the CHR, or does it fail to receive it as input to the FPGA too? The NSF doubling trick could work otherwise (but cuts total CHR size in half to 256k).
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by lidnariq »

PowerPak connects PPU A9 to CHR A9.

It does connect all lines from the cart connector to the FPGA.

(Must generate/relay: CHR A0,1,2,10,11,12,13,14,15,16,17,18)
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by Myask »

Yeah, I meant it couldn't "properly" do it by banking over CHR_A9, because it's teed-in to that line, rather than (as for the lines lidnariq mentioned) having separate pins for the cart-edge and the [actually-RAM] ROMchip, which is what I meant by "interposing" [between them]. It's a bad habit f mine to use three words when a paragraph would do.

Don't you need to double the data on the chip to do that? [a custom loader could cause this to occur without inflating the ROM image, and hey, loader's part of the mapper file on PowerPak…]
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by lidnariq »

Myask wrote:Don't you need to double the data on the chip to do that? [a custom loader could cause this to occur without inflating the ROM image, and hey, loader's part of the mapper file on PowerPak…]
Yes... On the other hand, 256x512B = 128KiB anyway, so maybe that's ok?
User avatar
NovaSquirrel
Posts: 483
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by NovaSquirrel »

rainwarrior wrote:Does it only fail to output that line to the CHR, or does it fail to receive it as input to the FPGA too? The NSF doubling trick could work otherwise (but cuts total CHR size in half to 256k).
I wanted to use CHR RAM, which complicated things a lot, since you'd have to either do things where 512 byte banks can only be in even or odd slots, or where you'd have to write the RAM twice. I guess it could be a virtual CHR RAM+CHR ROM thing, where the small banks come from "ROM" but the 1KB or bigger banks come from RAM.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by lidnariq »

Depending on timing properties of the RAM used in the powerpak, you might be able to get away with changing the address in the middle of the write to split a single PPU write (which should take ≈186ns) into two (90ns each?)
User avatar
NovaSquirrel
Posts: 483
Joined: Fri Feb 27, 2009 2:35 pm
Location: Fort Wayne, Indiana
Contact:

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by NovaSquirrel »

lidnariq wrote:you might be able to get away with changing the address in the middle of the write to split a single PPU write
If you write to the first half of a 1KB bank, even if you change the bank mid-write, I don't think the FPGA can assert that it wants to write to the second half of that other 1KB bank.

The reason I wanted 512 byte banks in the first place was doing an enhanced version of the 1KB "1 player bank, 3 sprite banks" strategy where each of the bank slots provides access to the tiles for a particular animation frame of one of the entities on the screen, where instead of 3 independent entities you'd be able to have 6. There's probably other ways to approach that that'd be even better and get you more entities.
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by rainwarrior »

NovaSquirrel wrote:The reason I wanted 512 byte banks in the first place was doing an enhanced version of the 1KB "1 player bank, 3 sprite banks" strategy where each of the bank slots provides access to the tiles for a particular animation frame of one of the entities on the screen, where instead of 3 independent entities you'd be able to have 6. There's probably other ways to approach that that'd be even better and get you more entities.
Considering that it's CHR-RAM, if each character had 8 x 512 byte sprite pages, you could fit 6 characters into 3 x 1k banked regions just by loading all the permutations of pairs. 8 x 8 combinations is only 64k. 6 characters in pairs like that would only take 192k.

Kind of a trade of constraints on how many source pages you need vs. how many independent characters you want. If some of the characters use the same pages, you could reuse the same 1k pages in different 1k bank slots too?
Last edited by rainwarrior on Tue Jun 13, 2017 2:13 pm, edited 1 time in total.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by lidnariq »

... Right, without the FPGA being able to drive CHR A9 we can't make the data appear in both the lower and upper 512B half.

(the FPGA can change one of the addresses it does control in response to a divided copy of the 21MHz clock, not just in response to PPU A0..A13)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Smallest chr-rom or ram bank size is 1k? or smaller?

Post by tepples »

rainwarrior wrote:Considering that it's CHR-RAM, if each character had 8 x 512 byte sprite pages, you could fit 6 characters into 3 x 1k banked regions just by loading all the permutations of pairs. 8 x 8 combinations is only 64k. 6 characters in pairs like that would only take 192k.

Kind of a trade of constraints on how many source pages you need vs. how many independent characters you want. If some of the characters use the same pages, you could reuse the same 1k pages in different 1k bank slots too?
In The Curse of Possum Hollow, we ran into a problem with permutations of characters. The game uses MMC3 with 32 KiB CHR RAM, where the player sprite uses banks 16-23 in window 2 ($1000-$13FF), commonly used objects such as powerups and particles use bank 31 in window 5 ($1C00-$1FFF), and enemies can use banks 24-30 in window 3 ($1400-$17FF) or window 4 ($1800-$1BFF). If a particular sprite sheet is 1K or smaller, multiple actors using it can share a window. (Only players and bosses have a larger sprite sheet.) But if both window 3 and window 4 are in use, and the enemy does not share a sprite sheet with the enemies in window 3 or the enemies in window 4, it enters a queue where it waits to pop into existence until window 3 or window 4 is no longer in use. (This behavior can be seen in the pattern table viewer when the game is run in a debugging emulator.)

In order to have more than two types of enemy on screen at once, we had to combine enemies that commonly occur next to each other and have less than 1K of tile data (thirty-two 8x16-pixel tiles) between them into the same sprite sheet so that they can share a window. The initial plan was to do this combining at build time, assuming that these pairs of enemies that take up parts of the same 1K sprite sheet would always occur together. But later on, the level designer felt frustration in not being able to freely vary enemy placement due to window conflicts. At that point, it was too late to change the fact that combination is done at build time, not runtime, without unduly delaying the game's release for a revamp of the sprite system. So I made a tool that would read the enemy placement data from the source code, find places where too many enemies or enemies from too many different sprite sheets are placed near one another, and write the level filenames and coordinates of the places most likely to be painful. Some were false positives, such as enemies that enter and quickly leave the screen or "decoration" enemies that can wait to pop in until other enemies leave or are destroyed.
Post Reply