Sonic and Sega Retro Message Board: Master System pallets - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Page 1 of 1
    Locked
    Locked Forum

Master System pallets and how they associate with MD ones

#1 User is offline Ambil 

Posted 09 August 2005 - 11:17 AM

  • I want that heinous hedgehog hammered!
  • Posts: 893
  • Joined: 26-April 05
  • Gender:Male
  • Location:Spain
  • Wiki edits:88
This is a tutorial to the SMS palletes in Sonic 2, and I suppose much of the other games for that console.

UPDATED -- Thanks to Korama

Using Hivebrain's guide to hack Sonic 2 SMS, I found the UnderGround Zone pallet (16 colours) at offset 0x241FF.

29 2F 1A 3F 2A 15 03 02 01 0B 0A 06 05 0F 0B 07


I played the game with MEKA 0.71 emulator for SMS/GG and got some information about the meaning of the bits in those offsets. Colours are 8-bit coded in the way I explain: two first bits are zeros, next bits are how much blue, green and red are in the color, in groups of two bits.

Take the example of first color, $29. In binary, it's number %00101001. So we shall get this pale blue in the first color of the pallet.

In the MegaDrive, the colors are 16-bit (actually 12-bit) words, coded as %0000 BBB0 GGG0 RRR0, as only even numbers are allowed.

This research will help me in my project, now that I can take numbers %00, %01, %10 and %11, and manually replace the numbers in the offsets in Marble Zone (future UGZ in my hack) with $0, $4, $A and $E. Example:

$0B = %00100011. -- converting --> $0A0E.

This will surely be useful to me in Sonic lol pallets, just I want to do the game as similar as possible with Sonic 2 SMS.

And if Hivebrain comes here, I suggest you to update your hacking guide, because your table of Master System colors...

Posted Image

has now been owned. Korama has made one for you.
This post has been edited by Ambil: 10 August 2005 - 12:36 PM

#2 User is offline Korama 

Posted 09 August 2005 - 12:52 PM

  • Posts: 272
  • Joined: 18-May 04

Ambil, on Aug 9 2005, 11:17 AM, said:

Colours are 8-bit coded in the way I explain: two first bits are zeros, next bits are how much green, blue and red are in the color, in groups of two bits.

Are you sure? That would be "GBR" order and that seems a bit unlikely. Furthermore, it contradicts the information in Charles MacDonald's MS VDP documentation (chapter 5, Color RAM), where he clearly states that the format is "--BBGGRR".

Quote

This research will help me in my project, now that I can multiply by four the color bits from the SMS pallet,

Simply multiplying by four is not accurate. Think about it. Pure white is represented on the MS by %00111111. If you extend it to the MD format by multiplying each RGB component by 4 (=shift two bits to the left) then you'll get %0000 1100 1100 1100 = $0CCC. Yet pure white is $0EEE on the MD and not $0CCC.

#3 User is offline Ambil 

Posted 09 August 2005 - 01:09 PM

  • I want that heinous hedgehog hammered!
  • Posts: 893
  • Joined: 26-April 05
  • Gender:Male
  • Location:Spain
  • Wiki edits:88

Korama, on Aug 9 2005, 07:52 PM, said:

Ambil, on Aug 9 2005, 11:17 AM, said:

Colours are 8-bit coded in the way I explain: two first bits are zeros, next bits are how much green, blue and red are in the color, in groups of two bits.

Are you sure? That would be "GBR" order and that seems a bit unlikely. Furthermore, it contradicts the information in Charles MacDonald's MS VDP documentation (chapter 5, Color RAM), where he clearly states that the format is "--BBGGRR".

I have just made a pallete dump in my MEKA 0.71, and got this in a text file:

Color 00 : 0x29 | 00101001 | R=15, B=2A, G=2A
Color 01 : 0x2F | 00101111 | R=3F, B=3F, G=2A
Color 02 : 0x1A | 00011010 | R=2A, B=2A, G=15
Color 03 : 0x3F | 00111111 | R=3F, B=3F, G=3F
Color 04 : 0x2A | 00101010 | R=2A, B=2A, G=2A
Color 05 : 0x15 | 00010101 | R=15, B=15, G=15
Color 06 : 0x03 | 00000011 | R=3F, B=00, G=00
Color 07 : 0x02 | 00000010 | R=2A, B=00, G=00
Color 08 : 0x01 | 00000001 | R=15, B=00, G=00
Color 09 : 0x0B | 00001011 | R=3F, B=2A, G=00
Color 10 : 0x0A | 00001010 | R=2A, B=2A, G=00
Color 11 : 0x06 | 00000110 | R=2A, B=15, G=00
Color 12 : 0x05 | 00000101 | R=15, B=15, G=00
Color 13 : 0x0F | 00001111 | R=3F, B=3F, G=00
Color 14 : 0x0B | 00001011 | R=3F, B=2A, G=00
Color 15 : 0x07 | 00000111 | R=3F, B=15, G=00


It clearly states that colors are —GGBBRR (take Color 14 as example). So Charles MacDonald fails. Bock fails. :P

"Korama" said:

Quote

This research will help me in my project, now that I can multiply by four the color bits from the SMS pallet,

Simply multiplying by four is not accurate. Think about it. Pure white is represented on the MS by %00111111. If you extend it to the MD format by multiplying each RGB component by 4 (=shift two bits to the left) then you'll get %0000 1100 1100 1100 = $0CCC. Yet pure white is $0EEE on the MD and not $0CCC.


It's right. I might use 0, 4, A, E instead of 0, 4, 8, C. Colors will fit more to real SMS ones.
This post has been edited by Ambil: 10 August 2005 - 12:34 PM

#4 User is offline Korama 

Posted 09 August 2005 - 01:42 PM

  • Posts: 272
  • Joined: 18-May 04

Ambil, on Aug 9 2005, 01:09 PM, said:

I am completely sure because I checked palletes on the emulator, in a window that lets me to view the binary code for each color, and I proved that it's actually "GBR". If you still don't believe it, I have just made a pallete dump in my MEKA 0.71, and got this in a text file:
...
It clearly states that colors are —GGBBRR (take Color 14 as example). So Charles MacDonald fails.

Sure, Charles MacDonald could have made an error in his docs, but I also checked the source code of SMS Plus, his emulator. It is BGR there, too.
To be absolutely sure I also took a Sonic 2 ROM and changed the first few bytes at file offset 0x241FF to $30. Then I launched the modified ROM in Meka 0.68b (too lazy to download the latest version). Now, if you were right and the order was GBR, then $30 would represent pure green. But if the order is BGR, as one would expect, then $30 would be pure blue. I made a screenshot for you:
Posted Image

See, YOU fail, or at least the palette dump function of your MEKA 0.71. :)

Anyway, you were right that Hivebrain's color table is wrong. It assumes %00rrggbb format. In the actual %00bbggrr it should look like this:

Posted Image
This post has been edited by Korama: 09 August 2005 - 01:56 PM

#5 User is offline Tweaker 

Posted 09 August 2005 - 03:26 PM

  • Posts: 12389
  • Joined: 27-June 04
  • Gender:Male
Hmm... Does this reverse palette format have anything at all to do with the Z80 being a little endian processor?

#6 User is offline Korama 

Posted 09 August 2005 - 03:35 PM

  • Posts: 272
  • Joined: 18-May 04
No. Endianness only applies to data types that are several bytes in size (it determines the order in which the individual bytes of one value are stored). It has no effect at all on single bytes or sequences thereof. And a SMS color value is stored in a single byte.

#7 User is offline Heran Bago 

Posted 10 August 2005 - 04:17 AM

  • Ah! It's Puyo battle then.
  • Posts: 2949
  • Joined: 11-May 04
  • Gender:Male
  • Location:Foggy California
  • Project:勉強
  • Wiki edits:4
The SMS allows more colors on screen at once than the NES.
...
Sorry, that close to ends my experiance with hacking palletes for the SMS.

#8 User is offline Ambil 

Posted 10 August 2005 - 12:13 PM

  • I want that heinous hedgehog hammered!
  • Posts: 893
  • Joined: 26-April 05
  • Gender:Male
  • Location:Spain
  • Wiki edits:88
...wierd.

Korama is right, I checked the colors in the hex code and is —BBGGRR, but the pallet dump still fails, since it appears as —GGBBRR. I'm going to report this at SMS Power.

Page 1 of 1
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users