Question on tile animation

[infidelity]

Sorry about that, I added (hex) to my comment.

[Sik]

EDIT: Alright, I was wrong. The instant you touch the warp point, Dragon View copies that crouching position over to BG1. BG1 is apparently empty in that room. It SHOULD be used for the bit of foreground along the bottom with the doorway, but I guess they used sprites for that just in this room so they could abuse BG1.

I'll be blunt, that's pretty overkill for something that could have been managed in software honestly (it's literally just copying entire rows as-is and the sprite is rather tiny). Heck, just split each row into its own sprite and you don't even need to keep the CPU busy during the animation itself (overflow wouldn't be an issue since empty rows would be the ones removed anyway).

Each to their own way of doing it, I guess.

[Khaz]

the effect does look kinda lame...

Seems a bit judgmental for an animation effect they expected to get one use out of per playthrough. I think it looks wonderfully fancy without being ostentatious or a waste of effort.

I'll be blunt, that's pretty overkill for something that could have been managed in software honestly

I would imagine the rationale was "It's just so much easier to use a BG layer and HDMA...". Like, that approach I bet you write one HDMA table and you're done. Doing it the other way is a lot of copying and moving things around manually....

[Sik]

Oh right, I forgot about HDMA >.<; Still, the software option is there if you don't want to waste layers.

[infidelity]

Ok I have another question on vram. The vram has address $0000-$FFFF. I currently have it entirely filled with tile data, as seen in my previous post with a pic. Where do the bg planes store the tile data? Is it within the vram I already have filled? Is there another (ram) section that I don't know about that holds these values?

Also, how do you where the nmi is in a rom? The rom I have is megaman X, that I'm using to test all my stuff you have all seen in this thread. When I hacked the nes, I knew that the nmi had its own address at $FFFA, and that the reset vector had an infinite loop on itself waiting for an nmi to trigger.

So how do I know where to locate the snes nmi address, and does the snes have a reset vector. Cause so far it seems to me, that the reset vector always starts at 00:0000. Thanks again for the info!

[AWJ]

Ok I have another question on vram. The vram has address $0000-$FFFF. I currently have it entirely filled with tile data, as seen in my previous post with a pic. Where do the bg planes store the tile data? Is it within the vram I already have filled? Is there another (ram) section that I don't know about that holds these values?

Also, how do you where the nmi is in a rom? The rom I have is megaman X, that I'm using to test all my stuff you have all seen in this thread. When I hacked the nes, I knew that the nmi had its own address at $FFFA, and that the reset vector had an infinite loop on itself waiting for an nmi to trigger.

So how do I know where to locate the snes nmi address, and does the snes have a reset vector. Cause so far it seems to me, that the reset vector always starts at 00:0000. Thanks again for the info!

BG nametables are in the same VRAM as tile patterns (so you can't completely fill VRAM with tiles if you want to display any BGs). There are PPU registers that control where the nametable for each BG is, and where the tile pattern data for each BG and for the sprites begins (i.e. the VRAM address corresponding to "tile number 0" for that layer)

The 65816 reset vector is at 00:fffc, the same as the 6502. The 65816 has a 24-bit address space, but the vectors are 16-bit and can only reside in, and only point to, the first 64KB of the address space. When the CPU is powered on or reset it is running in 6502 emulation mode, and fetches the NMI vector from 00:fffa and the IRQ and BRK vectors from 00:fffe, exactly like a 6502. When the CPU is running in native mode (i.e. after clc; xce) it fetches NMI from 00:ffea, IRQ from 00:ffee and BRK from 00:ffe6 (the 65816 has a bunch of other vectors as well but you never need to worry about them on the SNES)

Those addresses are CPU addresses; how they translate to ROM offsets depends on the cartridge type. For a mode 20 cartridge, subtract $8000 from the CPU address (this only works for addresses in the first 32KB of the ROM!) So for Megaman X the reset vector is at offset $7ffc in the ROM, and the value in it is $8000, which points to the very beginning of the ROM (as you've noticed). For a mode 21 cartridge don't subtract anything from the CPU address (again, this only applies to addresses in the first bank).

Note that if any of the vectors is less than $8000, then that vector is pointing into RAM rather than ROM, and you'll have to trace the game code to see what it puts in that RAM location to find the actual interrupt handler. Do not get confused by mode 21--a vector value of $1000 is pointing to offset $1000 in RAM, not ROM, regardless of whether it's mode 20 or mode 21 (I made this mistake myself when I started reverse engineering my first SNES game, many years ago. I got very confused because there was valid code at the ROM address the NMI vector appeared to be pointing to, but it wasn't the code that was executing at NMI)

The value of the reset vector will always be between $8000 and $FFFF--it has to point to ROM, because RAM is uninitialized when the SNES is powered on. This is one of the heuristics SNES emulators and flashcarts use to determine the correct mapping for a ROM image.

[tepples]

Ok I have another question on vram. The vram has address $0000-$FFFF.

VRAM addresses on the Super NES is word addressed. For example, $0000 is 16 bits, $0001 is 16 bits, $0002 is 16 bits, etc. This means the 65536 byte VRAM has addresses $0000-$7FFF.

I currently have it entirely filled with tile data, as seen in my previous post with a pic. Where do the bg planes store the tile data? Is it within the vram I already have filled? Is there another (ram) section that I don't know about that holds these values?

Tile data goes in "pattern tables". Each background can address 1,024 different tiles (16 KiB for 4-color, 32 KiB for 16-color, or the whole 64 KiB for 256-color). The VRAM addresses of the pattern tables used by each background are specified in $210B.

Map data goes in "nametables", each 2048 bytes ($400 words) in size, which hold which tile goes at each position in a 32x32 tile grid. The VRAM addresses of the nametables are specified in the background screen base registers ($2107-$210A). A scrolling background usually has two nametables side by side, giving an effective 64x32 tile grid, so that columns of tiles can be uploaded to the nametable before they scroll into view.

One possible VRAM layout for mode 1 might look like this:

$0000-$3FFF: 16-color background tiles 0-1023, used by background 1 and 2
$4000-$5FFF: Sprite tiles 0-511 (sprites are always 16 colors)
$6000-$63FF: Background 1 left nametable
$6400-$67FF: Background 1 right nametable
$6800-$6BFF: Background 2 left nametable
$6C00-$6FFF: Background 2 right nametable
$7000-$73FF: Background 3 nametable (often used for a scoreboard, like the "fix" layer on Neo Geo)
$7400-$7FFF: 4-color background tiles 640-1023, used by background 3

[infidelity]

Thank you AWJ & tepples! All of that information is very helpful! I'll start tonight working on inserting a tile to a BG. And then try to have a functional nmi.

Oh with the nmi, in the nes I forget off the top of my head, of the nes needing a value of $80 sorted to it, in order for the nmi to kick on. Does the snes have a similar register that needs to be written to within the rest vector, for the nmi to be initiated? Thanks again for all of that info!

[93143]

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

Scroll down to the detailed description of NMITIMEN, which is at $4200.