nesdev.com
http://forums.nesdev.com/

Smallest chr-rom or ram bank size is 1k? or smaller?
http://forums.nesdev.com/viewtopic.php?f=2&t=16059
Page 1 of 1

Author:  GradualGames [ Sat Jun 10, 2017 7:38 am ]
Post subject:  Smallest chr-rom or ram bank size is 1k? or smaller?

Are there any mappers which have an even smaller chr bank size than 1k? Or is that the smallest?

Author:  Bregalad [ Sat Jun 10, 2017 9:21 am ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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.

Author:  rainwarrior [ Sat Jun 10, 2017 9:26 am ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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!)

Author:  Myask [ Mon Jun 12, 2017 8:54 am ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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.

Author:  rainwarrior [ Mon Jun 12, 2017 12:51 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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).

Author:  lidnariq [ Mon Jun 12, 2017 1:05 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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)

Author:  Myask [ Mon Jun 12, 2017 2:15 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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…]

Author:  lidnariq [ Mon Jun 12, 2017 2:58 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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?

Author:  NovaSquirrel [ Tue Jun 13, 2017 1:02 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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.

Author:  lidnariq [ Tue Jun 13, 2017 1:04 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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?)

Author:  NovaSquirrel [ Tue Jun 13, 2017 2:00 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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.

Author:  rainwarrior [ Tue Jun 13, 2017 2:11 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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?

Author:  lidnariq [ Tue Jun 13, 2017 2:13 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

... 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)

Author:  tepples [ Tue Jun 13, 2017 5:00 pm ]
Post subject:  Re: Smallest chr-rom or ram bank size is 1k? or smaller?

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.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/