Firstly, are you sure this is the beginning of map data both in the rom and on the screen you show?

Secondly, from some Zelda gbc games I got to know that those compressions can be tiresome to say the least. Make sure you get a good debugger and start debugging the hell out of it. The gbc Zelda for instance placed blocks everywhere until the map was full and could fill spaces and crap. Really didn't save much with all the control codes, but then again...

Anyway, debug. It's as simple as that... or not

cYa,

Tauwasser

No guide that I know of. I'm not even sure what would be in said guide. You pretty much use intuition and cunning to figure out whatever it is you need to figure out as quickly as you can. If you know the location of the map data in the rom you can set a read breakpoint on a location that is in range. Keep in mind that you might have to convert a rom address to a CPU address in order to set the breakpoint. If you get a hit on that breakpoint when the room loads you know you've hit the code that handles that data.

Thanks for the advice both of you. Yes I understand about having to understand myself, otherwise I won't be able to do anything unless someone teaches me every new function step by step.

My biggest problem is that I don't really know much about the snes hardware or how a debugger works. I have some idea what CPU address is but no idea how to convert it, although I would probably be able to find such a thing out pretty easy looking into the documents here.

The debugger I'm trying now is "Geiger's Snes9x Debugger" and there are a lot of options, like when I'm going to trace what should I trace, when should I start tracing, what happens when a breakpoint finally occurs, should I use Next Op, Step Into or anything else so I will easier find the function.

I will start reading some documents about hardware right away like the one you posted.

And yes I will try to ask polite, as much for my own sake as others, so I can read my own posts without having to get annoyed.

You can extract the WRAM with vSNES, btw.

Soul Blazer... I did some poking around with its map system a while back.
*rummages through disorganized notes*

The map pointers are part of the map metadata at 0x28200. The metadata is actually a small control code system that I haven't worked out completely, but the [10 01] command loads the map data. ([10 02] is probably for overlays/underlays, like the Grass Valley clouds or the animated background in Leo's Painting.)

A dump of 0x28200

The map data pointed to by a [10 01] has a four-byte header: one byte for width, one for height, and two for the total number of bytes to decompress. The rest is the compressed data.

To decompress, treat the bytes as a stream of bits. There are two basic commands:


C source code for decompression
Sample output: Trial Room (the map from the first post)
Sample output: Mountain of Souls
Sample output: Magridd Castle

The current map is stored in RAM at 7E8000.
The map is divided into blocks of 256 bytes, corresponding to a 16x16 grid of 16x16-pixel map tiles.
These tiles are ordered left to right, and top to bottom.
The blocks themselves are also ordered this way.

ex. A 2x2-block map:

I'm pretty sure the maximum size for a map is 0x1000 bytes, or 16 blocks - more than this and the game thinks the map has multiple "levels", which is how the lair-sealing resurrected areas work. The basic starting "town" map is described by the first 0x1000 bytes, and the next 0x1000 is an overlay with some houses and stuff, and so on.

Because of this, I'm not sure if "height" is the best description for the second byte of the map data header. For example, the Mountain of Souls and Magridd Castle (actually, all of the towns...) have a "height" of 0x10 (16 blocks), but the height of the map you can actually walk on is a mere four blocks.



Unrelated but interesting: Illusion of Gaia uses the same algorithm for map compression. It has different commands for map metadata - [06] instead of [10], for example - but the actual compression is the same.

ASCII maps from Illusion of Gaia, produced with an early version of the decompressor - I think every byte in these maps was ORed by 0x20 to avoid control characters (such as newlines, tabs, and the dreaded 0x07 bell).