Well, I'd advise you start with VSNES and examine a savestate so you can start finding things out for sure instead of assuming anything. Another thing is the term 'sprite', when talking about the SNES platform, typically refers to tile data used for OAM objects which are handled very differently from those used as the typical background data. You'll want to differentiate between the two when speaking about them and what you're looking for.

With that said, I'm assuming you are looking for background tile data. The palette used by each tile is stored in 3 bits of it's 2 byte attribute or 'tile map' table table which may or may not be the hex data you've given us.

I refer you to Anomie's Register Doc. Read the section entitled 'Tile Maps and Character Maps' to understand what I mean.

In VSNES, you'll also be able to tell if a background is using 16x16 tiles or is really just using 8x8 tiles. You'll also be able to tell where the map is and where the tile data is stored. You can then use a debugger to trace back how that data got into VRAM and ultimately find where it is coming from in the ROM.

You've bitten off a fairly large task for being new to this material, so if you want to be successful, you'll need to break this down to clear, small, objectives that we can better help you with.

Don't think of it in terms of the game, think of it in terms of the hardware. By 'background', I mean just that, one of the four SNES backgrounds. Use ZSNES and press '1','2', '3', and '4'. The BACKGROUND layers will disappear.  If you press '5', the SPRITE layer will disappear.

It's important you determine what it is you're looking for. As I said, they're handled very differently and I can't help you if you can't tell me correctly what it is you are looking for. So, use your emulator and determine if it's background data and if so, which background? (1,2,3, or 4).


In SceneViewer, look at the 'layers' tab and the 'info' tab. That will show you everything you need to know about the backgrounds. Each background will have a tilesize, tilemap location, and a tiledata location. Those 16-bit locations are in VRAM. VRAM only exists in the savestate right now, but we can use the information to find it in the ROM.

So, find the background your data is on (1,2,3, or 4). Then open the 'hex editor' icon at the top. Choose 'VRAM' and now you can go to the address your 'tilemap' is at. You can fiddle with the values to start to understand how they work. You'll see the results in the scene viewer.

VSNES is a great learning tool. You can change VRAM contents and hardware registers and observe the effects immediately (for many hardware features anyway).

You should be able to edit the tilemap in VRAM and see what happens to the tiles. You can get them to use different palettes this way and understand how that works.


They're both right. The most significant bit is not used because it would go out of range for VRAM.

VRAM effective addresses range from 0-0xFFFF
However, the SNES use two chips, therefore when you set the actual address you can only set between 0-0x7FFF.

So, when you set actual VRAM address to 0x000, $2118 goes to 0x0000 and $2119 goes to effective location 0x0001. When you set the actual VRAM address to 0x0001, writing to port $2118 it goes to effective location 0x0002 and $2119 goes to effective location 0x0003.
When you set the actual VRAM address to 0x7FFF, writing to port $2118 it goes to effective location 0xFFFE and $2119 goes to effective location 0xFFFF.

So....

Example:

Tilemap should be at effective VRAM location of 0xF800.

So, the actual VRAM address is 0x7C00.

Now shift by 10... and you get 0001 1111. So you take those 6-bits and use them as the upper 6 bits in $2107.

So, the byte that should be at $2107 is 0x7C.


SO... the reason 7-bits are used in VSNES is because the 8th bit is ignored because it can never used because VRAM can only be addressed from 0-0x7ffff.

Just change the value in VSNES and observe the tilemap address results in the Scene Viewer. You'll get how it works.

I got that, I just think it's confusing to talk about a background when it's (in the game) not a background. A layer sounds more logical to me From ZSNES/vSNES I see "background" 1 is the layer I need.

Okay, so the "tilemap base" is an offset in the VRAM, got it.

Oh wow, that's a cool feature


Okay, I *think* I understand what you're saying here. However, I do not see how to get the ROM address from the VRAM address.
If I understand correctly, when the game is running it writes certain things to register 2117 and it ends up in the VRAM. So can I somehow track where in the rom that data is coming from?



Actually, it looks more like 4 times an 8x8 grid... this is very confusing, the game doesn't load all tiles but somehow makes a selection?

Yes, that's the general idea give or take. I purposely left out how to get the ROM address because that's opening up another can of spam.  I wanted to make sure you understood how things worked first and understand what data you need to change to get the desired effects. With that said, have you been able to change the palette used for the background tiles you're interested in? If you understand what needs to be changed, you'll understand what data you actually need to look for in the ROM and what to do with it.

You should also clarify if you need to change the palette the tile is assigned to using or if you want to modify the actual colors in the palette being used. My assumption thus far as been you want to change the assigned palette. If you want to change the individual colors, you will need to look at the palette data as a whole and get into some CGRAM modification which isn't that hard. The hardest part there is the effects your palette changes may have on the rest of the game. Often you may get undesired effects because palettes are often shared by many things in game.

So you tell me, what have you done so far and what do you want to do next specifically? Finding the tilemap in the ROM for example could be a difficult task if you don't know assembly and the game creates it on the fly. Or it could be simple if the game stores such a map directly in the ROM. The easiest thing you can do is search for the tile map data you see in VRAM in the ROM using any hex editor with byte searching.  You may get lucky and the tilemap is flat out stored in the ROM. Also run a search for just the tile index byte of the map. More often than not, the second byte in the tilemap is generated on the fly when the game determines what palette to use, if any flipping is needed etc. In those cases, it pulls tile indexes from the ROM and assigned the second byte via game code.

If you turn up empty handed on those searches, it's going to be more difficult because you'll need to get an SNES debugger learn to trace some code and figure out how that data got to VRAM so you know where it came from. That could be difficult without prior knowledge of assembly and/or debuggers. It's often a big obstacles for newcomers to get over so be prepared to spend some time on it.

Yes, here too. But it works

I can't believe I missed that :X yes, it's a 16-tile wide grid.

Yes, I have

Changing the colors was nice practice to better understand how the tiles are stored, but that's not my ultimate goal. I want to make a level viewer (or background viewer, if you wish)

Okay, what I've done so far:
I know where the palette is stored in the ROM and know how to extract/show it.
I know where the 8x8 tiles are stored in the ROM and how to show them.
I'm not entirely sure where to go from here, I guess finding out how the tile map is constructed in the VRAM is the next logical step. The tiles in the ROM and in the VRAM don't match up, so something is going on there. For example, one tile is 740 in vSNES, but it's the 776th in the ROM. Another one is 70 in vSNES but the 670th in the ROM.

I've done some assembly in the past, but that's over 8 years ago...
Nope, unfortunately the tilemap data can not be found in the ROM. Not flat out, and not by searching for just the tile-index-byte

Alright, so what debugger can you guys recommend? And where would I start? (Aside from brushing up on my ASM skills)

Yes, Geiger's is the best available despite being old and outdated. SNES debugger development overall stalled out several years ago.

You'll want to read up on DMA transfers in Anomie's register document. Most all SNES games (there are a few black sheep though) will use a DMA transfer to transfer tiled ata and tile mapsto VRAM. This is because you can only write to VRAM (as well as most PPU/video related registers) on the SNES during the blanking (v-blank or h-blank) period. DMA is the fastest way to transfer the data which is important since you only have a limited amount of time you can do it.

Personally, I like to have a trace file open showing much of the code to help give a bigger picture when I'm either stepping through or just toying with break points trying to find out where data came from. To make a trace file, just click 'CPU' under 'Logging'. Go back to the game and  wait a second, then click the box off to end the trace. There are a few CPU trace options. The most notable is 'Trace Once'. This will trace each instruction one time. Therefore if a routine is used more than once or there is a loop, only the first iteration is printed. Sometimes this is desirable to keep trace size small, however sometimes you'll want to nothing left out and you want a full trace. Note that a full trace can be many MB in size for even a second or two of tracing. So, try not trace more than you have to. Limit it to one or two seconds which should be sufficient for most tasks.

Breakpoints will be your other best friend. You can set the debugger to break on read, write, or execute of any SNES address. This includes ROM, RAM, and even registers. This is how you find things out. You want to know when a value from RAM is written to, you set a breakpoint. Want to know when a value from ROM is read, set a break point. This is how you start to figure out where things came from and how they get to where they're going. I use breakpoints to find code locations and then like to reference my trace file to see the full routine.

The other thing you need to know is DMA tracing. Under 'Special Tracing', you can check DMA, then you'll see all DMA transfers happening. Here's where you'll see source address and destination. It also shows VRAM address in the event it's a transfer to $2118 (more often than not it is). Again, limit your trace to a second or two, or you'll have hundreds of DMA transfers you won't be able to sort through.


OK.. So, in a nutshell, you'll want to do some DMA tracing and see when data is copied to VRAM around the location you know the tile map is in. You'll see where that data came from. It's most likely some location in RAM. Then you can do a few write breakpoints to see when and how the data got to the RAM locations and work backwards.


I've said plenty, I'm sure you'll have a rough time digesting it all. So, go dive in.


P.S. There is a 'Show Hex' button as well. You can view contents of ROM, RAM, and VRAM there similar to VSNES.

Right, it's now 6 weeks later so let me tell you what I've been up to...

I've tried debugging for a while, but I just didn't get the hang of it. So the project got halted.
A few days ago I couldn't take it anymore. I just had to do this! I tried a different approach though: corrupting. I started corrupting in large chunks and wrote down what happened. In case of a crash, I went to smaller chunks to see what happened then.
Using this method I found out:
- where the titlescreen graphics are stored
- where the logo is stored
- the title screen uses a different palette than the actual game
- some other graphics
- where the songs are stored (lots of SPC700 stalls in this area)
- I corrupted the "physics" (the unicycles kept bouncing up and down, or the saddle kept sticking to the floor, or the cycle would keep rotating in a funny way)
- the tile graphics are not related to their collision
- I think I did something with either collision testing or changing the collision of the tiles
- and I got a lot of crashes.

I'm now to the point that I broke down most crashes to 1024 bytes or less, but nowhere did I find out where the level data is. Since there are around 45 levels, I highly doubt that it will fit in 1024 bytes, even with RLE.
I really don't know what to do, but I have one idea that I can use your help on:

Is it possible to track which offsets the game is taking data from?

So for example, on the titlescreen it will take data needed for the background, the text etc. from offset xxx. Now if you start a level, it will take data for the graphics at offset yyy, the palette at offset zzz and level data from offset aaa. When you start a different level it will read yyy, zzz and bbb!

If this is possible, please explain how to do! Thanks in advance for any help.