Question on tile animation

[infidelity]

I'm trying to gather as much information as I can, on how the snes works, in preparation for the next updated release of bsnes-plus's debugger.

In my nes rom hacking days, I've never messed with chr animation within a chr-ram game. I've always converted my projects to chr-rom,so so I can swap the desired amount of tiles with other tiles, to give the appearance of animation. My question is, are there any snes games that utilize chr-rom, or is it universally chr-ram? And if it's the latter, how would one go about creating a chr animation routine within the snes?

[lidnariq]

The NES and Neo-Geo are the only home video game machines with CHR-ROM, both because of their conceptual origins in arcades.

As you pointed out, CHR-ROM is simpler but less flexible, which is why most consoles use internal RAM. Additionally, putting this RAM inside the console reduces reproduction costs later on.

(I think a few random other non-arcade machines can draw tiles from physically-external ROM. The C64 is one, although I don't know if any cartridge-based games used it.)

[93143]

In case that wasn't clear, the SNES doesn't use anything resembling CHR-ROM or CHR-RAM on the NES. The PPU has no cartridge slot access, so if you want to display tile data, you have to put it in VRAM.

[infidelity]

Right, I had a feeling it was vram, and not dependant on a mapped to swap pages.

I've just never delt with vram with animation routines. Chr animation is one of my favorite things to do, and I want to make sure I do it correctly. I guess what I should do, is when bsnes-plus gets its update, is to load up super Mario world, and find that the asm routine that deals with tile swapping for the ? Blocks.

Is there a specific limit, to how many tiles you can load up that you want swapped, without slowdown or glitches occurring?

[Drew Sebastino]

Is there a specific limit, to how many tiles you can load up that you want swapped, without slowdown or glitches occurring?

Unfortunately, yes. You can only upload 6 KB of data, which is equivalent to 3 64x64 sized sprites, but updating oam and other stuff also counts, so it's more of something like 2 and 1/2 64x64 sized sprites. That's easily the biggest problem with this setup. Also, if you try to update more, I think I've heard that the top of the screen gets clipped by a black bar, and the more you're updating, the further down the screen the bar will go. It only lasts for the frame after though.

[infidelity]

Oh wow. I'll definitely have to be careful to not go overboard in what id like swapped for animations. I appreciate all the info everyone thank you! Looking forward to starting my venture to snes rom hacking soon.

Edit: Another question.

When writing a tile to the screen, how does the snes differentiate that the tile being drawn is 2bpp, 4bpp, 8bpp? And is the reasoning behind compresses gfx, due to size issues back in the 90's, cost, etc? Like, can I get away with a romhack, using uncompressed gfx?

[93143]

There isn't really a hard limit on tile animation. It depends on what you're trying to do, and how much else is going on.

You have 64 kB of VRAM to work with. Tilemaps are 2 kB (32x32) and can be doubled in the X and/or Y direction(s) for up to 8 kB per BG layer. Each tilemap can address up to 1024 tiles arranged linearly in VRAM, with each BG layer having a separate starting address. BG tiles can be either 8x8 or 16x16, selected separately for each layer. Sprite tiles are stored in 8 kB (16x16-tile) OBJ blocks similar to the NES, with two relocatable OBJ blocks in VRAM that can be accessed simultaneously; you can relocate these blocks (not the data, but where the PPU thinks the data is) not only between frames but also between scanlines (based on a simple experiment I did a bit ago).

The 6 kB limit Espozo is talking about is the approximate limit on DMA bandwidth per frame, so it only applies if the data you want to switch to is not already in VRAM. The SNES was designed to eliminate the overscan that wasted VBlank time on the NES, so unless you specifically set it to overscan mode, each frame is 224 scanlines, leaving you 38 blank ones at 165.5 bytes per line. (Mind you, this also generally includes OAM and CGRAM updates, so that's about a kilobyte gone if you need to fully update both.) You can also use force blank to turn the screen off early and/or turn it on late, allowing more time to transfer data. I'm trying to port a vertical shmup to the SNES, and my current design has only 206 active scanlines, leaving me roughly 9 kB of bandwidth per frame (I need it all...).

PAL systems have 312 scanlines per frame and no other relevant differences, so DMA bandwidth is huge; this dovetails nicely with the fact that the demoscene is bigger in Europe...

When writing a tile to the screen, how does the snes differentiate that the tile being drawn is 2bpp, 4bpp, 8bpp?

It has to do with the PPU mode. The SNES has up to 4 separate BG planes, rather than just one as on the NES (and they can be independently scrolled, greatly attenuating a major source of tile animation requirements). Each plane has a separately designated tilemap and tile data range. The bit depth is fixed for a given BG layer in a given mode; for instance, in Mode 1, BG1 and BG2 are 4bpp, BG3 is 2bpp, and BG4 is unavailable.

The odd man out is Mode 7, which doesn't use bitplanes at all and is fixed to starting at $0000 and using the bottom half of VRAM. Each word is interpreted as an 8-bit tilemap entry followed by an 8-bit pixel. The result is a huge 128x128-tile map restricted to 256 tiles with no tile flipping, useful for allowing you to zoom out on a relatively expansive swath of terrain without eating all of VRAM. You can stick other data in the Mode 7 area as long as you can guarantee that the player will never see that part of the tilemap...

Sprites are locked to 4bpp.

And is the reasoning behind compresses gfx, due to size issues back in the 90's, cost, etc? Like, can I get away with a romhack, using uncompressed gfx?

Compression was purely to save ROM space. If ROM space isn't an issue (and you don't have an S-DD1 or something like that), compression just wastes CPU time.

[psycopathicteen]

Oh wow. I'll definitely have to be careful to not go overboard in what id like swapped for animations. I appreciate all the info everyone thank you! Looking forward to starting my venture to snes rom hacking soon.

Edit: Another question.

When writing a tile to the screen, how does the snes differentiate that the tile being drawn is 2bpp, 4bpp, 8bpp? And is the reasoning behind compresses gfx, due to size issues back in the 90's, cost, etc? Like, can I get away with a romhack, using uncompressed gfx?

This article can explains how to get around the DMA limit.

http://wiki.superfamicom.org/snes/show/ ... ffectively

[infidelity]

Oh awesome info 93143! Thank you very much for that!

And thank you for that link, psycopathicteen! I'll check it out now.

[93143]

I had originally explained the Mode 7 tile format backwards. I have corrected it. I figured you should be aware of this, since you seem to have been reading my post as I was editing it...

[infidelity]

Thanks for that heads up! I'll re-read that now.

[thefox]

The SNES was designed to eliminate the overdraw that wasted VBlank time on the NES, so unless you specifically set it to overdraw mode, each frame is 224 scanlines, leaving you 38 blank ones at 165.5 bytes per line.

I think you mean overscan, not overdraw.

[infidelity]

I have a question on palette values.

I'm loading a 200 byte table, I have X & Y set as 16-bits. Anyway I was successful in loading 200 bytes into CGRAM. I wanted to perform a test, where I have a 200 byte table with each 2 bytes representing a color for each palette slot.

I have a table such as 00,00 01,00 02,00 03,00 etc etc.

When I reach the point of my table where I have 80,00 81,00, etc, it looks the same as the previous stored colors. So are palette colors only 00-7F?

Thanks everyone!

[AWJ]

I have a question on palette values.

I'm loading a 200 byte table, I have X & Y set as 16-bits. Anyway I was successful in loading 200 bytes into CGRAM. I wanted to perform a test, where I have a 200 byte table with each 2 bytes representing a color for each palette slot.

I have a table such as 00,00 01,00 02,00 03,00 etc etc.

When I reach the point of my table where I have 80,00 81,00, etc, it looks the same as the previous stored colors. So are palette colors only 00-7F?

Thanks everyone!

SNES CGRAM entries are 15-bit: five bits of red, five bits of green and five bits of blue:

xBBBBBGG GGGRRRRR

However, when you write to CGRAM or read it back, the first read or write accesses the low 8 bits (the ones containing red) and the second one accesses the high 7 bits (the ones containing blue). In other words CGRAM access is little-endian, just like everything else on the SNES (and NES).

Don't think of CGRAM as an array of bytes, but as an array of 15-bit words. When you write a byte to $2122, it only gets stored in a temporary buffer. You have to write twice before the two bytes get combined into a word and actually written to CGRAM. The important things you have to remember are that the address you write to $2121 is the index of the first color you want to change, a word address (don't multiply it by 2 even though you're writing 2 bytes per color), and that you always have to transfer an even number of bytes.

The most significant bit in the high byte of a CGRAM word is like the top two bits of NES CGRAM: it simply doesn't exist; you can't even read back what you wrote to it.

One more thing: you can't write an entire word at once to CGRAM by using a 16-bit register. If you do rep #$20; sta $2122 then the low byte of A will be written to $2122 (which is what you want) but the high byte will be written to $2123, a completely different register (one of the clip window registers). I strongly recommend you learn how SNES DMA works and get used to using it for all data transfers to the PPU (OAM, VRAM, CGRAM); it's much more efficient and is what all commercial games do.

[infidelity]

Ahh thank you, that explains the left most bit not being recognized. That's why it's 00-7F I can only see.

I've been messing around all day with my asm. I've been able to load up a value and have it stored within the VRAM. It's not using DMA, but I will try to start reading up on it. I'm not trying to create anything now, I'm just trying to get my feet wet, in seeing if Im able to code in asm, to get things inserted. So far I'm able to adjust the snes screens brightness, I'm able to insert any color into any palette slot, and I've just been able to insert a value within the VRAM. pretty good day for me.

From my tests, it appears that for proper tile appearance of 2bpp, is to have the first byte filled, but the second byte blank, (since I know the vram uses 16-bits) so I was able to have a proper 8x8 tile appear correctly in vram that is meant for 2bpp.

I hope by tonight, to draw to one of the BG's.