Points of Required Attention™
Please chime in on a proposed restructuring of the ROM hacking sections.
Views: 88,479,605
 Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search 04-25-24 01:56 AM
Guest: Register | Login

0 users currently in ROM Hacking | 2 guests

Main - ROM Hacking - SMB3 Title Screen Palette Definitions New thread | New reply


KP9000
Posted on 07-09-09 11:20 PM Link | Quote | ID: 110228


Boomboom

Level: 90

Posts: 850/1975
EXP: 6952590
Next: 236019

Since: 02-19-07

Last post: 3578 days
Last view: 3202 days


Ok, so I've spent some time figuring out how SMB3's title screen handles Palettes.

Every 16x16 block on the screen can have its own palette. However, each 16x16 block is made up of larger 32x32 blocks that make up the screen. One byte represents a 32x32 block. The palettes are stored in an 8x8 byte array. So: 


032a60	(64 bytes)	Location of Palette Definitions for title Screen

Blocks form palette combinations as follows:

   +----+----+
   | XX | XX |
   +----+----+
   | XX | XX |
   +----+----+

XX = binary vales only. Values 00, 01, 10, and 11 are possible here.
     These values represent palettes 00, 01, 02, and 03 respectively.

So, the translation is as follows:
 
    Palettes:    --->     Binary:  
   +----+----+          +----+----+
   | 01 | 01 |          | 01 | 01 |
   +----+----+   --->   +----+----+
   | 02 | 03 |          | 10 | 11 |
   +----+----+          +----+----+

This gives you a binary value of 0101 1011, which in hex is 5B.

0000 0000 = 00
0000 0001 = 01
0000 0010 = 02
0000 0100 = 04
0000 1000 = 08
0001 0000 = 10
0010 0000 = 20
0100 0000 = 40
1000 0000 = 80

0101 0101 = 55
1010 1010 = AA
1111 1111 = FF

00 == All 4 blocks are palette 0
55 == All 4 blocks are palette 1
AA == All 4 blocks are palette 2
FF == All 4 blocks are palette 3


What I can't figure out so far is why the array is stored differently in the ROM as it appears in the PPU memory. 

     PPU Memory       
+------------------+
| F0F0F0F0F0F0F0F0 |
| 2A8A66555599A2A8 |
| AA555555555555A9 |
| A8A6A5ED77B5A5AA |
| AAAA0A0E0F0BAAAA |
| AAAA22000000AAAA |
| 0000000000000000 |
| 0A0A0A0A0A0A0A0A |
+------------------+


As you can see, the PPU memory represents each byte correctly as it should be. However, in the ROM, you get something else: 

        ROM
+------------------+
| F0F0F0F0F0F0F0F0 |
| 2A8A66555599A2A8 |
| AA555555555555A9 |
| A8A6A5ED77B5A5AA |
| 0023E020AAAA0A0E |
| 0F0BAAAAAAAA2200 |
| 0000AAAA00000000 |
| 000000000A0A0A0A |
+------------------+

It looks like the bottom-right 4x4 block of data of the ROM code is the same as the bottom-left 4x4 block of data in the PPU Memory. I can't seem to figure out the final piece of the puzzle...

____________________

Trax
Posted on 07-10-09 02:01 AM Link | Quote | ID: 110237


Yellow Stalfos
Level: 71

Posts: 851/1145
EXP: 3035456
Next: 131658

Since: 07-06-07
From: Québec

Last post: 3625 days
Last view: 2877 days 		The values are stored this way because of how the individual bit values are processed in the code. In ASM, you typically have something like that:


LDA $whatever
AND 0x03 (keep the last two bits)
STA $3Fxx (store the value somewhere in the palettes memory range of PPU)
LSR (shift right)
LSR (shift right)


Then loop 3 more times. The code doesn't work, but you get the idea. In the end, the palettes codes (0-3) are stored in reverse order relative to how the bytes are stored because you start with the 2 least significant bits...

KP9000
Posted on 07-10-09 02:08 AM Link | Quote | ID: 110239


Boomboom

Level: 90

Posts: 852/1975
EXP: 6952590
Next: 236019

Since: 02-19-07

Last post: 3578 days
Last view: 3202 days


So, say you want to change what's loaded into the PPU... What would you change in the ROM to load what you want into the PPU? How do you translate that chunk of data (the chunk that differs) into something you want instead of garbage? I'm not really understanding of ASM just yet, so layman's terms would be appreciated.

____________________

never-obsolete
Posted on 07-10-09 03:29 AM (rev. 2 of 07-10-09 03:31 AM) Link | Quote | ID: 110242


Rat
Level: 24

Posts: 52/96
EXP: 74487
Next: 3638

Since: 02-22-07
From: Phoenix, AZ

Last post: 2594 days
Last view: 2594 days 

+------------------+
| F0F0F0F0F0F0F0F0 |
| 2A8A66555599A2A8 |
| AA555555555555A9 |
| A8A6A5ED77B5A5AA |
| 0023E020AAAA0A0E |<--
| 0F0BAAAAAAAA2200 |
| 0000AAAA00000000 |
| 000000000A0A0A0A |
+------------------+


The 23E020 looks like it might be saying "write $20 bytes to $23E0" (attribute tables are at $23C0, $27C0, $2BC0, $2FC0 in PPU memory). Is there a 23C020 before the first line of F0s?

I've seen other games store static attribute tables that way.

KP9000
Posted on 07-10-09 03:33 AM (rev. 3 of 07-10-09 03:53 AM) Link | Quote | ID: 110243


Boomboom

Level: 90

Posts: 853/1975
EXP: 6952590
Next: 236019

Since: 02-19-07

Last post: 3578 days
Last view: 3202 days


Yeah, there are... and there are an additional three $a0's after the supposed array ends... so maybe this is it?

Edit: yeah, this is it. Also, there's an extra $00 in there too. 

        ROM       
+------------------+
| F0F0F0F0F0F0F0F0 |   ---+
| 2A8A66555599A2A8 |      |
| AA555555555555A9 |      |
| A8A6A5ED77B5A5AA |   ---+--- 0x032A52 - 0x0352A71 (32 bytes)
| AAAA0A0E0F0BAAAA |   ------+
| AAAA22000000AAAA |         |
| 0000000000000000 |         |
| 0A0A0A0A0A0A0A0A |   ------+--- 0x032A76 - 0x032A91 (32 bytes)
+------------------+


____________________

Trax
Posted on 07-10-09 08:25 AM Link | Quote | ID: 110256


Yellow Stalfos
Level: 71

Posts: 853/1145
EXP: 3035456
Next: 131658

Since: 07-06-07
From: Québec

Last post: 3625 days
Last view: 2877 days 		It depends how your tiles are layered down. My answers follow my experience with Arkanoid, in which the palettes cannot be changed on a "per-tile" basis. In the case of SMB3 overworld map, it's almost only background tiles; the sprites are Mario/Luigi, Koopas, Spades, Flying Boat, etc. I'm not sure how sprites palettes work exactly, but background ones follow the principle explained by KP9000 initially...

One byte in these data tables covers the palette indexes (0-3) for 16 tiles (2x2x2x2). To define a full screen, which is 32x30 tiles, you need 60 bytes. If your map is more than one screen wide, then I guess the table is longer, but I'm not sure...

Main - ROM Hacking - SMB3 Title Screen Palette Definitions New thread | New reply

Acmlmboard 2.1+4δ (2023-01-15)
© 2005-2023 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.024 seconds. (341KB of memory used)
MySQL - queries: 62, rows: 87/88, time: 0.019 seconds.