 |
|
 |
|
Views: 317,179,985
Time: 2014-10-17 09:11:27 AM | 18 users online: 8Nairb, Aurel509, BlackMageMario, BS187, ergazoobi, gabriel alves, Hinalyte, JaphethMario21st, MaxodeX,  Mirann, pikachu101, Pilzinsel64, RPG Hacker, shreerocks1324, Syndical, tcdw, TheHoohGames, Y for yoshi - Guests: 31 - Bots: 30 | Users: 25,718 (1,108 active)
Latest: MarioFan_0902 |
|
|
 |
|
|
|
|
|
|
|
|
|
 |
|
 |
|
| Map16 Tiles, VRAM Tilemaps, and $65 |
|
Forum Index - SMW Hacking - General SMW Hacking Help - ASM & Related Topics - Map16 Tiles, VRAM Tilemaps, and $65 |
|
Pages:  1  |
|
|
|
| Posted on 2009-02-28 11:02:40 PM |
Link | Quote |
|
I've just been looking into how the Map16 data in RAM is assembled into tilemaps to be uploaded to VRAM. I think I just found something, but I have to go, so I thought I'd just post my suspicions to see if anyone can verify them.
04DCEA seems to be reading Map16 tile #s from RAM, multiplying by 8 - this could be it
LDA [$65],Y what is $65? "24bit pointer to Level Data."
STA.L $7EE400,X ???
it does that 4 times
I bet $65 actually points to tilemaps
So does anyone know just what $65 points to here? If my hunch is correct it's actually pointing to Map16 tile data in ROM, not level data.
Oddly enough the game doesn't seem to be keeping the Map16 tile data in RAM at all, nor assembling it into a tilemap in RAM to DMA to VRAM. That would suggest it's manually writing tilemaps into VRAM as it constructs them from the Map16 data, instead of using DMA. Isn't that a lot slower?
|
|
| Posted on 2009-03-01 04:25:57 AM |
Link | Quote |
|
Originally posted by HyperHackerI've just been looking into how the Map16 data in RAM is assembled into tilemaps to be uploaded to VRAM. I think I just found something, but I have to go, so I thought I'd just post my suspicions to see if anyone can verify them.
04DCEA seems to be reading Map16 tile #s from RAM, multiplying by 8 - this could be it
LDA [$65],Y what is $65? "24bit pointer to Level Data."
STA.L $7EE400,X ???
it does that 4 times
I bet $65 actually points to tilemaps
So does anyone know just what $65 points to here? If my hunch is correct it's actually pointing to Map16 tile data in ROM, not level data.
Oddly enough the game doesn't seem to be keeping the Map16 tile data in RAM at all, nor assembling it into a tilemap in RAM to DMA to VRAM. That would suggest it's manually writing tilemaps into VRAM as it constructs them from the Map16 data, instead of using DMA. Isn't that a lot slower?
I'm not 100% sure, but I thought, most of the time, [$65] pointed to the Map16 tables (for the entire level) itself (the low byte for what it acts like), not per se the tile data.
I think $0FBE does that instead.
It's a 1024-byte table, which contains 16-bit pointers for each Map16 block. They're all 8 bytes wide (4 8x8 tiles, 2 bytes each) and there's one for each Map16 tile.
They're all set to be located in bank 0D.
Quote
CODE_00C17C: B9 BE 0F LDA.W $0FBE,Y
CODE_00C17F: 85 04 STA $04
CODE_00C181: A0 00 00 LDY.W #$0000
CODE_00C184: B7 04 LDA [$04],Y
CODE_00C186: 9F 81 83 7F STA.L $7F8381,X
CODE_00C18A: C8 INY
CODE_00C18B: C8 INY
CODE_00C18C: B7 04 LDA [$04],Y
CODE_00C18E: 9F 89 83 7F STA.L $7F8389,X
CODE_00C192: C8 INY
CODE_00C193: C8 INY
CODE_00C194: B7 04 LDA [$04],Y
CODE_00C196: 9F 83 83 7F STA.L $7F8383,X
CODE_00C19A: C8 INY
CODE_00C19B: C8 INY
CODE_00C19C: B7 04 LDA [$04],Y
CODE_00C19E: 9F 8B 83 7F STA.L $7F838B,X
Not entirely sure if this is what you mean though.
The tile data starts either at $0D8000 or $0D9100. Both seem to be tilemaps, but I'm not quite sure which one is used for which purpose...
As for the order in that huge table, I'm not completely sure.
The first few Map16 blocks seem to go in order (first 8 bytes for tile 000, then 8 bytes for tile 001, etc.)
However, at some point the order gets different (or at least in $0D8000, I think not in $0D9100). Probably because of the pipe tiles, which can have multiple colours.
Edit:
I think $0D8000 is for Layer 1 Map16 tile data, while $0D9100 is probably for Layer 2 Map16 tile data (Pages 10 and on)
|
| Last edited on 2009-03-01 04:47:11 AM by Roy. |
|
| Posted on 2009-03-01 05:54:56 AM |
Link | Quote |
|
i think i am the one that submitted $65. the level loader puts one of the pointers in there i forgot the specifics. the pointer is written just above the code you posted and it's use changed depending on what's going on at the moment:
CodeCODE_04DCBB: A2 00 D0 LDX.W #$D000
CODE_04DCBE: 86 65 STX $65
CODE_04DCC0: A9 05 LDA.B #$05
CODE_04DCC2: 85 67 STA $67
so you're working from $05 000 for whatever it is doing.
four time store is looped 256 times.
CodeCODE_04DD33: E6 00 INC $00
CODE_04DD35: A5 00 LDA $00
CODE_04DD37: 29 FF AND.B #$FF ;useless here, it's not masking anything
CODE_04DD39: D0 AD BNE CODE_04DCE8
anyway are you actually seeing a dma in gieger's snes9x from the addresses you posted to the tilemap in vram? that's a quick way to eliminate stuff
actually, that will find the code that assembles tile data. the code which uploads to BG1 tilemap during an active game (in a regular level) can easily lead you to where it is assembled. gieger's let's you do that conveniently.
|
| Last edited on 2009-03-01 05:56:17 AM by smkdan. |
|
| Posted on 2009-03-01 06:39:03 AM |
Link | Quote |
|
Oh never mind I was thinking of [$6E] >_< (which is the Map16 tile data).
Heh, my bad.
|
| Last edited on 2009-03-01 06:39:35 AM by Roy. |
|
| Posted on 2009-03-19 09:27:52 PM |
Link | Quote |
|
I just looked and $65 appears to point to the actual level data (i.e. object data in ROM) for layer 2 (which is just FF for levels without it - it skips the 5-byte header). $6E points to some place in the middle of the level's Map16 data (decoded object data).
$0FBE looks like what I'm looking for. I just need to figure out where those pointers come from.
BTW, 05:8776 ("MAP16AppTable") is pointers to the pipe tiles.
|
| Last edited on 2009-03-19 10:12:29 PM by HyperHacker. |
|
| Posted on 2009-03-21 11:10:47 PM |
Link | Quote |
|
Got it. 05:81BB is a bit table. The game uses it to set the table at 7E0FBE:
P1 = word from 0x8000 + (tileset * 2)
P2 = 0x8000
TilePtr = 0x0FBE
for n = 0 to 64
b = next bit from 05:81BB
if bit is set:
TilePtr[n] = P2
P2 += 2
else:
TilePtr[n] = P1
P1 += 2
next n
So this table defines which tiles are tileset-specific, but if you go changing it, you'll throw all the other tiles out of place.
[edit] stupid italics tag
|
| Last edited on 2009-03-21 11:12:03 PM by HyperHacker. |
|
|
| Pages: 1 |
|
|
|
|
Forum Index - SMW Hacking - General SMW Hacking Help - ASM & Related Topics - Map16 Tiles, VRAM Tilemaps, and $65 |
|
|
 |
|
 |
The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.
Copyright © 2005 - 2014 - SMW Central
Legal Information - Privacy Policy - Link To UsTotal queries: 27
|
|
|
|
