Bankswitched CHR-RAM?
Moderator: Moderators
Bankswitched CHR-RAM?
I've got this idea recently to somehow combine the benefits of using CHR-ROM and CHR-RAM. For the sake of a simple explanation, let's assume we have 32k of RAM. Of course the PPU would only ever be able to use $0000-$1FFF of the RAM chip by default. However, with discrete logic the game can control A13 and A14 of the RAM chip to switch the 8k of CHR-RAM window of the PPU. So you fill the 32k of RAM with different animation frames, keeping copies of whatever you don't want to animate (Sprite tiles could just be the same set copied 4 times, to $0000-$0FFF,$2000-$2FFF,$4000-$4FFF,$6000-$6FFF of the RAM chip)
Then, during gameplay, all you have to do is keep cycling through these CHR-RAM banks to have everything animated.
Pros:
+ You get to compress your tiles, like with regular CHR-RAM
+ You can easily animate a large number of tiles like with CHR-ROM bankswitching, without having to waste space or resort to updating only a few tiles in NMI.
+ Possible to implement using discrete logic only (While still using other bits of the CPU data bus to select PRG-ROM banks)
Cons:
- Takes a lot of time to fill the whole RAM (do it in forced blank)
- Makes loading new sprite tiles more difficult (unless you could select CHR-RAM banks for sprites and background separately)
Then, during gameplay, all you have to do is keep cycling through these CHR-RAM banks to have everything animated.
Pros:
+ You get to compress your tiles, like with regular CHR-RAM
+ You can easily animate a large number of tiles like with CHR-ROM bankswitching, without having to waste space or resort to updating only a few tiles in NMI.
+ Possible to implement using discrete logic only (While still using other bits of the CPU data bus to select PRG-ROM banks)
Cons:
- Takes a lot of time to fill the whole RAM (do it in forced blank)
- Makes loading new sprite tiles more difficult (unless you could select CHR-RAM banks for sprites and background separately)
Re: Bankswitched CHR-RAM?
I've made a few boards that use bankswitched CHR-RAM: Squeedo (2004 version), 8TROM, and GTROM. Only Squeedo and GTROM were ever produced in quantity, and the latter is available now. Both of those only switch 8kB pages, have 32kB of CHR-RAM, and use part of that memory for 4 nametables. In GTROM's case you only get 2 8kB pages of tiles though, the other half of the memory is used for nametable paging. I've never been able to resist hooking the nametables up to the CHR-RAM.
There's only so much animation you can get out of flipping between 2 pages, but if it's combined with sprite tile and nametable updates, then at least it does increase the number of tiles available for display. I've noticed 128kB SRAMs have finally been approaching the nice $1 mark where 32kB ones used to be, so I'd expect to see those used more. You're right that filling a large amount of CHR-RAM does take a noticeable amount of time though, especially if the decompression is non-trivial. One good thing that can still do during forced blanking is play music, so it doesn't have to completely disrupt the flow.
Another advantage of CHR-RAM paging, and still applies to having 2 pages, is that you can do double-buffering. So if you have an animation that takes longer than one vblank to render, you can do partial updates while displaying the previous frame. The result is that you can update a large part of the screen at once, with no visual 'waving' or 'tearing' side-effects.
There's only so much animation you can get out of flipping between 2 pages, but if it's combined with sprite tile and nametable updates, then at least it does increase the number of tiles available for display. I've noticed 128kB SRAMs have finally been approaching the nice $1 mark where 32kB ones used to be, so I'd expect to see those used more. You're right that filling a large amount of CHR-RAM does take a noticeable amount of time though, especially if the decompression is non-trivial. One good thing that can still do during forced blanking is play music, so it doesn't have to completely disrupt the flow.
Another advantage of CHR-RAM paging, and still applies to having 2 pages, is that you can do double-buffering. So if you have an animation that takes longer than one vblank to render, you can do partial updates while displaying the previous frame. The result is that you can update a large part of the screen at once, with no visual 'waving' or 'tearing' side-effects.
Re: Bankswitched CHR-RAM?
What about single screen mirroring and using the internal CHR RAM as the first 64 tiles?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Bankswitched CHR-RAM?
That's what Napoleon Senki does, and it is indeed a very elegant use of the NES hardware. Such a magnificent mapper for such a shitty game, what a waste.Dwedit wrote:What about single screen mirroring and using the internal CHR RAM as the first 64 tiles?
Re: Bankswitched CHR-RAM?
I thought the Napoleon Senki mapper (#77 VOTE FOR PEDRO) used CHR ROM (one 2K switchable window) and 8K of CHR RAM to make four-screen:
- $0000-$07FF: One 2K bank of CHR ROM
- $0800-$17FF: CHR RAM, used for 6K of pattern tables
- $2000-$27FF (first two nametables) in four-screen
- $2800-$2FFF (last two nametables): Internal video memory
Re: Bankswitched CHR-RAM?
Essentially all mapper hardware capable of bankswitching CHR ROM is also capable of bankswitching CHR RAM. Even in MMC1/3 boards with a 6264 (8Kx8 SRAM) or equivalent 8 KiB CHR RAM, the upper address bits of the CHR RAM were run through the mapper as opposed to being directly connected to the PPU address bits. This includes SGROM, SNROM, SOROM, SUROM, SXROM (Japan only), TGROM, TKSROM (Japan only), and TNROM (Japan only).
The limit in some people's minds is whether Nintendo ever produced such a board with more than 8 KiB. This wasn't common in the pre-1997 era for cost reasons, as a 62256 (32Kx8 SRAM) was more expensive than a 6264. But memory is cheaper nowadays. And any emulator that understands the NES 2.0 header should support GNROM (#66), Color Dreams (#11), MMC1 (#1), or MMC3 (#4) with a 32 KiB CHR RAM.
The limit in some people's minds is whether Nintendo ever produced such a board with more than 8 KiB. This wasn't common in the pre-1997 era for cost reasons, as a 62256 (32Kx8 SRAM) was more expensive than a 6264. But memory is cheaper nowadays. And any emulator that understands the NES 2.0 header should support GNROM (#66), Color Dreams (#11), MMC1 (#1), or MMC3 (#4) with a 32 KiB CHR RAM.
Re: Bankswitched CHR-RAM?
I recall there being a debate over whether it was meaningful to say which boards could be modded to accept CHR-RAM, since that depends on how much you mod them, but not where nor when.
UNROM-512, at least, is a mapper/board that RetroUSB makes(made?) and is therefore available(?) as non-donor carts for homebrew to use that does "vanilla" >8kiB bankswitched CHR-RAM.
Also, discussing the games that did use it seems fruitful for this topic, but I don't know much about them and their innards.
UNROM-512, at least, is a mapper/board that RetroUSB makes(made?) and is therefore available(?) as non-donor carts for homebrew to use that does "vanilla" >8kiB bankswitched CHR-RAM.
Also, discussing the games that did use it seems fruitful for this topic, but I don't know much about them and their innards.
Re: Bankswitched CHR-RAM?
I'm using CHR-RAM bankswitching, and I'd be willing to bet that a lot of other devs are too. I'm pretty sure (though might be wrong) that the original Battle Kid bankswitches CHR-RAM because the modern UNROM512 supports it, and there are good reasons to have it.
As Tepples said, anything that can bankswitch CHR-ROM should (in theory) be able to bankswitch CHR-RAM.
As Tepples said, anything that can bankswitch CHR-ROM should (in theory) be able to bankswitch CHR-RAM.
- rainwarrior
- Posts: 8735
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Bankswitched CHR-RAM?
Nope. The original Battle Kid was designed for plain UNROM (256k), and Battle Kid 2 only relied on the extension to 512k, and not any of the other extended features. The extra features were made prospectively by RetroUSB; they might be used in one of the 8-bit christmas carts?thenewguy wrote:I'm pretty sure (though might be wrong) that the original Battle Kid bankswitches CHR-RAM because the modern UNROM512 supports it.
Re: Bankswitched CHR-RAM?
Study Hall uses at least some of the extended features.