Question about Sonic 2 tile mappings

I'm not quite sure what you mean, but Block mappings#Format might be helpful

 

Yeah, you have to multiply the $38C by $20, not divide it. The tile index can refer to any tile in VRAM, it doesn't necessarily have to refer to a level 8x8 tile (though it usually does), and I'm guessing that's the case here - try looking at the next few 16x16s and see what tiles they refer to.

 

Nope, the game loads everything into VRAM itself. The simplest way to see which tile is at $7180 is using Kmod's VRAM viewer - IIRC the address display in the viewer actually displays the tile index rather than the tile address, so it's quite easy to see which tile is at index $38C.

 

As the guide says, the 0x38C is the address after it has been divided by 0x20.
Multiplying by 0x20 you get 0x7180, correctly. The thing you have done wrong here is that you aren't accounting for the fact that the EHZ tile patterns are compressed in the rom and are decompressed in VRAM. If you open sonic 2 in gens, start emerald hill, and look at the VDP in the debug menu, you'll see EHZ patterns go all the way fro 0x0000 to at least 0x7800. Which means that 0x38C -> 0x7180 is well within the EHZ block art boundaries.

 

Another thing you did wrong is that you didn't decompress the actual mappings; they are Kosinski-compressed.

Code (ASM):

1. ; EHZ 16x16 block mappings (Kosinski compression) ; was: (Kozinski compression)
2. BM16_EHZ:   BINCLUDE    "mappings/16x16/EHZ.bin"

You'll see that the first block is 40 00, so the address of the first tile is at 0x0 (and uses the third palette line).

 

You can use The Sega Data Compressor (get it from the Sonic Hacking Utilities page). You can use it to manually compress and decompress files using Kosinski, Nemesis, Enigma or Saxman compression. If you're decompressing data from a split file, use 0 as the offset. If you've edited the uncompressed data, don't forget to re-compress it before building the ROM.

 

If you had bothered to look at the comments in the disassembly, you'd have seen that those mappings are also compressed. However, I believe they use a different format, as they reference 16x16 blocks.

 

They're also compressed in the Kosinski format, and the format is described at Block_mappings#Format_2

 

You don't have to multiply at all, the II IIII IIII is just the 16x16 number. 0 means the 1st 16x16, 1 means the 2nd 16x16, and so on and so forth

EDIT: Might've misread the above post a bit - if you want to get the position of the 16x16 inside the block table, you'd multiply by 8, since one 16x16 occupies 8 bytes. Shouldn't cross the file boundaries - you decompressed the 16x16s and 128x128s right?

 

Thing is, the 16x16 mappings of each level are decompressed into RAM, and it's this RAM area that's accessed throughout the game. Now, the block table in RAM occupies $1A00 bytes (from $9000 to $AA00), so it can hold a maximum of $340 16x16s. The extra 16x16s are dynamically loaded into RAM - each level has an entry in the offset table known as AnimPatMaps in Xeno's disasm, and the routine at loc_402FA loads these extra 16x16s into RAM.