Can SNES Vram be expanded?

Hello! I am fairly new to SNES programing (and programing in general, for that matter) and I was wondering if it were possible to expand the SNES's Vram size via an expansion chip (kind of like the MMC5 for the NES) or something like that. If so, could you add additional bits for selecting more sprite and background character data? Sorry if this question seems ridiculous. It's just that I have not seen any documentation on the matter.

NES and Neo Geo are the only consoles I know of that can use extra video memory in the cartridge. Super NES video memory cannot be expanded through the cartridge connector. If you're running out of space for background or sprite tiles, you can always blast in some more with DMA during vblank, replacing tiles that aren't used anymore. This philosophy (although without the DMA) was used to animate the player character as early as Battletoads for NES: some tiles in CHR RAM were reserved for the current animation frame for each player character, and heavily unrolled code would copy it to CHR RAM.

Oh, well, that's depressing... I had known about many games using dma every frame for tile data (mostly main characters as nothing usually shares tile data with them), but I had wanted to make a 64x64 explosion sprite with about 15 frames of animation. Because I will have multiple explosions on screen, changing the tile map would not be feasible. I seriously do not understand as to why the SNES would even have an option for 64x64 sprites, as it does not have nearly enough Vram to back it up. Oh, and out of shear desperation, can it expanded from the expansion port on the bottom of the system?

No, the expansion port on the bottom of the system just allows for an extra device to be added to the SNES's "B" bus.

I don't know what your explosions look like, but you might be able to make one 32x32 quadrant of a 64x64 explosion and mirror it as four 32x32 sprites.

I know what you mean. All the explosions in contra III seem to be mirrored, but I think it looks extremely awkward. I will probably just have to use 32x32 sized sprites.

Do this for every dynamically animated object.

- Check if there is enough DMA time.
- If not, don't update animation frame
- If so, continue
- Clear object's vram slot (area it takes up in VRAM) from the vram slot table
- Find new vram slot, using the vram slot table
- If slots are different, update animation frame
- If slots are the same, compare new and old animation frames
- If animation frames are the same, don't update animation frame
- If animation frames are different, update animation frame

That's a lot more complexity than just statically allocating a VRAM slot to each actor the way I do in my white paper about the technique on GBA. Obviously it has to be slightly modified because you can rewrite only about a third of the sprite cels during one NTSC vblank, but averaging 20 fps across all sprites on screen still isn't half bad.

Well, my method is a little more flexible with sprite sizes.

True, you can and should allocate different amounts of VRAM for different sizes of actor. But you have to allocate the largest amount of memory that each actor can use. Otherwise, you get problems when all actors happen to switch to a larger cel at once.

...and actors wider than 64 pixels, should have tiles rearranged to fill up complete rows of 128 pixels.

Random thought, but wouldn't this problem be similar to heaps in everyday memory management? (this also means you have to be careful about fragmentation)

If it happens that you need more than 16kB a frame, you could do mid-screen bank switching, and divide actors between top half, bottom half, and both halves, and move them from one bank to another when they move from one region to the next.