Palette Hacking tutorial

[earok]

Welp, thought I'd just put this out there. Feel free to correct any technical mistakes I've made, and ask for any clarifications needed.

OCS PALETTE OVERVIEW
The Amiga OCS Palette has 32 entries. This is true even in HAM or EHB (64 colour) mode - in HAM only 16 colours are used as a "base palette", and in EHB the last 32 colours are just "half brite" copies of the first 32.

An OCS Palette entry is always "word" length, meaning two bytes, or four nibbles. A nibble can be represented with one of these hexidecimal characters: 01234567890ABCDEF (Where A equals the decimal 10, B equals the decimal 11 etc etc)

An OCS Palette entry will look like this in memory: 0RGB

Where:
- The first nibble is always zero (unused).
- R is a nibble with the Red channel value.
- G is a nibble with the Green channel value.
- B is a nibble with the Blue channel value.

The last 16 colours in the 32 colour range are always used for sprites, and some of the time for other graphics depending on the number of bitplanes used. So sometimes you might find two separate 16 colour palettes, one for the sprites specifically and one for all of the other graphics.


THE ATARI ST COMPLICATION
Whereas the OCS Amiga supports 4096 distinct colours, the (base) Atari ST only supports 512. Atari ST palette entries are also "0RGB" format, exactly the same as Amiga - except only with the values 01234567. This means that if the colour entries are exactly the same on Amiga, they're only half as bright since the numerical range is only half.

Some games - Midnight Resistance, After the War, Dragon Spirit and others - simply do NOT bother to correct the palette, hence why they look so dark.

Some other games - Giana Sisters, Wonderboy in Monster Land and others - have the original Atari ST palette on the disk, but double it programatically when the game loads. So for the values for R,G and B

0 = Nothing happens
1 = Doubled to 2
2 = Doubled to 4
3 = Doubled to 6
4 = Doubled to 8
5 = Doubled to A
6 = Doubled to C
7 = Doubled to E

Note that no value is increased to F. For instance, white on Atari ST is 0777, and if you double that it only comes to 0EEE on Amiga (a slight shade of grey, pure white would be 0FFF)


FINDING THE EXISTING PALETTE IN MEMORY
Fire up the game in WinUAE and go to a scene with a palette that you want to change (remember, a game may have numerous palettes - for the title screen, individual levels, shop screens etc).

Press SHIFT-F12 to get into the WinUAE debugger - remember that you can get out of this screen at any time by entering g and pressing return.

When you're in the debugger, just enter the letter e and press return. This gives you a long list of all of all custom registers. The only ones you're interested in are the ones that begin with COLOR. Here's an example with just the first four colours.

180 COLOR00 0888
182 COLOR01 0FFF
184 COLOR02 0000
186 COLOR03 0FD0

COLOR00 is a shade of grey, COLOR01 is white, COLOR02 is black and COLOR03 is yellow. Note that 180, 182 etc refers to register addresses. For instance 180 refers to $DFF180, which is the register address for COLOR00.


FINDING AND FIXING THE EXISTING PALETTE ON DISK
Things get a bit more complicated here.

Copy the color entries into a text file in one long line. For instance with the previous example:
08880FFF00000FD0

Open your file (ADF or data file) in a hex editor (my favourite is HxD) and search for that exact entry. Make sure you're searching for 'hex', not 'text', values.

Here's where you could get stuck:
- If you don't find those bytes at all, there could be numerous reasons why and some of them are outlined in the appendix. If it's an Atari ST port it's worthwhile halving all of the entries in your search, for instance if you want "0ACE", look for "0567" instead.
- If you find those bytes multiple times, you may have located multiple palettes, or even something that isn't a palette at all. You could either increase the accuracy of your search by searching for more colours (for instance, I've only used four in the example - but you may want to use more than that, even the full 32 if necessary).

Note that it IS possible for a game to have multiple identical palettes. Every level in Giana Sisters has it's own palette, but many of them are copies of other palettes.


Make sure you've got a backup of your original file before editing it - just replace the colours that are there with the colours you want, save and test in WinUAE.


APPENDIX A: ADDITIONAL COMPLICATIONS
- If it's an Atari ST port, but the colours aren't dark, it may be because the game is doubling the palette values when it loads them. In that case if you put in a value like '0AAA', the game may double it to '1554', and it would look unlike what you intended. If that's the case you'll either need to remove the routine that doubles the palette values (we did this for Giana SE) or only use colours in the Atari ST 0-7 range.
- Crunched files are present in many games, and often the palette itself will be crunched. To change the palette on a crunched game you'd need to do something along these lines:

• Use WRIP to extract the files (or if it's a DOS disk, just copy them off).
• Use a tool like XFDDecrunch or the original crunching tool to decrunch the file.
• Make the change that you need.
• Use the original crunching tool to recrunch the file, and put it back on the disk.

- CRC checks. Sometimes games or WHDLoad slaves use these to verify the integrity or version of a file, and making tweaks like these can break execution of the game.
- AGA palettes, which are considerably more complicated than OCS ones, so I haven't covered them here.
- The tutorial assumes a "hard coded" palette. Some games will have palettes that are generated by code on the fly. In which case you may need to dig deeper to understand how the palette is generated.
- The Copper, which allows for palette changes in the middle of the screen render (for instance, in many games the bottom section of the screen may be underwater, in games like this the copper has changed the entire palette to a blue tint by the time the beam reaches that part of the screen). If you need to change a palette set by the copper, use the WinUAE debugger to examine the memory address of CopLch1 (for instance, if it's 420, type "m 420" in the debugger) to work out some clues as to what those palette entries are - for instance, if you see an entry like "0180 0888" - this means that palette entry 0 is set to 0888.


APPENDIX B: COLOUR REGISTER ADDRESSES
$DFF180 COLOR00
$DFF182 COLOR01
$DFF184 COLOR02
$DFF186 COLOR03
$DFF188 COLOR04
$DFF18A COLOR05
$DFF18C COLOR06
$DFF18E COLOR07
$DFF190 COLOR08
$DFF192 COLOR09
$DFF194 COLOR10
$DFF196 COLOR11
$DFF198 COLOR12
$DFF19A COLOR13
$DFF19C COLOR14
$DFF19E COLOR15
$DFF1A0 COLOR16 (Transparent on all sprites)
$DFF1A2 COLOR17 (Colour 1 for a 16 colour sprite, Colour 1 for a 4 colour sprite in channels 0-1)
$DFF1A4 COLOR18 (Colour 2 for a 16 colour sprite, Colour 2 for a 4 colour sprite in channels 0-1)
$DFF1A6 COLOR19 (Colour 3 for a 16 colour sprite, Colour 3 for a 4 colour sprite in channels 0-1)
$DFF1A8 COLOR20 (Colour 4 for a 16 colour sprite, Transparent on 4 colour sprites)
$DFF1AA COLOR21 (Colour 5 for a 16 colour sprite, Colour 1 for a 4 colour sprite in channels 2-3)
$DFF1AC COLOR22 (Colour 6 for a 16 colour sprite, Colour 2 for a 4 colour sprite in channels 2-3)
$DFF1AE COLOR23 (Colour 7 for a 16 colour sprite, Colour 3 for a 4 colour sprite in channels 2-3)
$DFF1B0 COLOR24 (Colour 8 for a 16 colour sprite, Transparent on 4 colour sprites)
$DFF1B2 COLOR25 (Colour 9 for a 16 colour sprite, Colour 1 for a 4 colour sprite in channels 4-5)
$DFF1B4 COLOR26 (Colour 10 for a 16 colour sprite, Colour 2 for a 4 colour sprite in channels 4-5)
$DFF1B6 COLOR27 (Colour 11 for a 16 colour sprite, Colour 3 for a 4 colour sprite in channels 4-5)
$DFF1B8 COLOR28 (Colour 12 for a 16 colour sprite, Transparent on 4 colour sprites)
$DFF1BA COLOR29 (Colour 13 for a 16 colour sprite, Colour 1 for a 4 colour sprite in channels 6-7)
$DFF1BC COLOR30 (Colour 14 for a 16 colour sprite, Colour 2 for a 4 colour sprite in channels 6-7)
$DFF1BE COLOR31 (Colour 15 for a 16 colour sprite, Colour 3 for a 4 colour sprite in channels 6-7)

APPENDIX C: PROGRAMATICALLY GENERATED PALETTES
Games that generate palettes programatically present their own set of challenges.

This mini-tutorial does not cover how palettes are generated by code, and how to alter those routines (which could be done a limitless number of ways). Rather, this mini-tutorial only covers finding the routine that generates that palette.

- BEFORE reaching the part of the game that displays the palette you want to change, press Shift+F12 in WinUAE.
- Enter the following command "w 0 $DFF180 2 W"

Where:

• w: the command for "watchpoint"
• 0: the index of this specific watchpoint (increase this number for multiple watchpoints, ie if you want WinUAE to pause on multiple different palette changes)
• $DFF180 - the address of the first palette entry. Refer to appendix b for the address of all the rest.
• 2 - Watch for word length
• W - watch for a "write" operation

- After pressing enter, simply type "g" and press enter. Now that you're back in the game, continue playing until you reach the scene with the new palette.
- The WinUAE debugger will pause again on the operation that executes immediately after setting that palette entry. That's all from me, the rest is up to you.


TUTORIAL 1: RAINBOW ISLANDS
For the sake of an actual tutorial, here's how to greyscale the first level of rainbow islands.

1. Fire up an ADF of the game and start the first level.

2. Press Shift+F12 to get into the WinUAE debugger, press e.

COLOR00 0000
COLOR01 0355
COLOR02 0999
COLOR03 0FFF
COLOR04 0D03
COLOR05 0F90
COLOR06 0FF0
COLOR07 00F0
COLOR08 037F
COLOR09 070B
COLOR10 0B09
COLOR11 00FF
COLOR12 0FD9
COLOR13 0930
COLOR14 0090
COLOR15 0F0F

Note that colors 16 onwards are unused - in other words, the game doesn't seem to bother with hardware sprites!

Also that there are odd numbered colours, such as 'F'. In other words this is not a straight Atari ST port where they've doubled the colour values, but this is an Amiga specific palette.

3. Lets put all of these colours into one long line.
0000 0355 0999 0FFF 0D03 0F90 0FF0 00F0 037F 070B 0B09 00FF 0FD9 0930 0090 0F0F

4. Quit WinUAE (so the ADF is no longer in use) and open the file in HXD. Press Shift+F to open the search window, choose Hex Values and copy in the line.

5. Success! If you're using the same ADF I am, you should find this line exactly once (I won't post the exact address here as it could vary by crack). Let's turn all of the values to their greyscale equivalents, copy into HxD over top of the existing values, and save.

0000 0444 0999 0fff 0555 0888 0AAA 0555 0888 0666 0666 0AAA 0CCC 0444 0333 0AAA

Here's what it looks like. Notice that the top and bottom text is still coloured, which suggests separate copper lists are used - you'll need to do some digging if you want to change the palettes for those.

Very nice tutorial, thanks a lot i'm going to try on the game we talked about.

[Retro1234]

Theres some info in this thread from when HH did Midnight Resistance
http://eab.abime.net/showthread.php?p=613663#post613663

[earok]

Interesting stuff - I never thought of using AR3 and DPaint like that, but it makes sense.

An alternative way I've found palettes is making a save state from WinUAE and loading into MapTapper - which immediately recognises the palette. Though in practice just dumping the custom registers in WinUAE's debugger seems to be the most immediate way to find them.

Just tried and i could't reproduce what you did. My first try gave me the total different palette string "000002440FFF0C020FF0008F0F000F600FF00FA800F0008000CC026F060A0A08" (i used the t +3 Setrox cracked version). Then i tried the 100% final release "Rainbow Islands (1990)(Ocean)[cr QTX][t +2 Slipstream]" (this one included the introduction screen) and now COLOR00 to COLOR15 are all set to... 000 in the WinUAE debugger. What did i do unproperly ??????

Which ADF filename did you use ?

Ok solved, the palette strings appears in the t +2 Slipstream cracked disk but not in the other ADF (compressed datas ?).

I started patching the palette to try to match the coin-op, but it's revealing a pain in the ass : in the Amiga version many colors are shared by several sprites or tiles, if you change one then it screws up something else elsewhere.

The first idea was to darken the sky and remove the agressive yellow in the platforms. Complicated because the sky color is used in the rainbow throwed by the player. Why the fuck didn't they use the light avaible blue, don't tell me it was reserved only for the main sprite ?!

Here my first attempt (level 1 only for now). Below the striations color inside the grey platform and the platform color itself have been modified to match at the nearest the coin-op palette. However, i saw later than the spider boss use the grey striation color as the background one, making my modification unappropriated (indeed the original background contrast is great). I used a different yellow for the platforms too, the average value between the Amiga color 0FF0 and the Coin-op one 0xF7E7A5 (expressed in 24-bit, the original coin-op palette is 13-bit, ie 2^13 = 8192 colors). Same kind of troubles, the lemon and rainbow use the original yellow color, so it can't be modified too much...

The main problem is this f****** blue circle arc used by the rainbow sprite. To modify the sky the rainbow gfx must be also modified to add a cyan circle arc. The flowers use the cyan color, so it could be really possible. A coder to the rescue to check the gfx use for the rainbow and tell if they can be instantly modified by adding a cyan layer ?

Seems to be hard to arrive to a compromise to approach the coin-op palette, any opinion is welcome.

The two first screenshort are taken from the Amiga version by running the hacked ADF in WinUAE, the last two ones from the coin-op. Another version than the coin-op could maybe be a good new base, i personnally never liked the yellow plateforms and the blue sky of the Amiga version (i prefer the CPC level 1 color tone for example).

If a graphist want to join and help to find a great new compromise then he is welcome !

[dlfrsilver]

Originally Posted by Vollldo

Ok solved, the palette strings appears in the t +2 Slipstream cracked disk but not in the other ADF (compressed datas ?).

I started patching the palette to try to match the coin-op, but it's revealing a pain in the ass : in the Amiga version many colors are shared by several sprites or tiles, if you change one then it screws up something else elsewhere.

The first idea was to darken the sky and remove the agressive yellow in the platforms. Complicated because the sky color is used in the rainbow throwed by the player. Why the fuck didn't they use the light avaible blue, don't tell me it was reserved only for the main sprite ?!

Here my first attempt (level 1 only for now). Below the striations color inside the grey platform and the platform color itself have been modified to match at the nearest the coin-op palette. However, i saw later than the spider boss use the grey striation color as the background one, making my modification unappropriated (indeed the original background contrast is great). I used a different yellow for the platforms too, the average value between the Amiga color 0FF0 and the Coin-op one 0xF7E7A5 (expressed in 24-bit, the original coin-op palette is 13-bit, ie 2^13 = 8192 colors). Same kind of troubles, the lemon and rainbow use the original yellow color, so it can't be modified too much...

The main problem is this f****** blue circle arc used by the rainbow sprite. To modify the sky the rainbow gfx must be also modified to add a cyan circle arc. The flowers use the cyan color, so it could be really possible. A coder to the rescue to check the gfx use for the rainbow and tell if they can be instantly modified by adding a cyan layer ?

Seems to be hard to arrive to a compromise to approach the coin-op palette, any opinion is welcome.

The two first screenshort are taken from the Amiga version by running the hacked ADF in WinUAE, the last two ones from the coin-op. Another version than the coin-op could maybe be a good new base, i personnally never liked the yellow plateforms and the blue sky of the Amiga version (i prefer the CPC level 1 color tone for example).

If a graphist want to join and help to find a great new compromise then he is welcome !

16 colors when it could have been 5 bpl 32 colors

The game use 4-6 palettes of 16 colors

The game use 4-6 palettes of 16 colors

Which one, the coin-op ? The main Amiga screen uses 16 color only yes.

I'm going to try another approach by using the CPC palette general tone. If a knowledgable coder can look how the gfx are saved and tell me if the rainbow sprite can be modified to add the cyan circle arc then it would be perfect. If there is another way to alterate the grx by using the WinUAE debugger then i'm opened to explainations.

[kriz]

Thanx for info and great tutorial ! Respect Earok and all contributing here ..

[dlfrsilver]

Originally Posted by Vollldo

Which one, the coin-op ? The main Amiga screen uses 16 color only yes.

I'm going to try another approach by using the CPC palette general tone. If a knowledgable coder can look how the gfx are saved and tell me if the rainbow sprite can be modified to add the cyan circle arc then it would be perfect. If there is another way to alterate the grx by using the WinUAE debugger then i'm opened to explainations.

The Amiga version would need to be fully dismembered in order to rework the whole thing......

[dlfrsilver]

Originally Posted by dlfrsilver

The Amiga version would need to be fully dismembered in order to rework the whole thing......

With 32 colors, i'm sure something great could be made. An ocs Amiga with 1mb of chip would be fine for this.

The Amiga version would need to be fully dismembered in order to rework the whole thing......

Out of topic. I can't do this, i don't have the knowledge to fully recode it. Because don't believe that just "to rework" on it would be enough to have a conversion of the same quality than the Pc-Engine one : all would have to be rewritten from scratch (video and scrolling routine, gfx, extra levels and the endless list of missing gameplay stuffs). And i doubt you would find someone to do a such task : Rainbow Island is not the example itself of an easy game to code. On a pure algorithmc, technical and gameplay point of view the coin-op version is a just marvel, one of the best ever done. People behind it are genuises. A lot of stuffs are missing in the Amiga version, to recode it would be a full time 1 year job for an asm expert even by disassembling the coin-op ROMs. A such game needs muuuch more knowledge in coding and algorithmic science than a game like Jim Power for example. A recoding will never happen, but a palette patch yes. All in all the Amiga port isn't so bad, it plays very well but they choosed too vivid colors.

When Taito lost the Bubble Bobble source code en 1996 they had to dissassemble the PCB and spend an endless time to play the game to be able to recode it. If it would have been simple to recode it from scratch (and back in the days they employed pure genius in coding) then they would have done this. The coin-op version of Bubble Bobble is also a coding marvel, and Rainbow Islands is at mnimum 10 times more hard to code. So...

[dlfrsilver]

You're right. taito just throw away all their sources. You must know that's it's a cultural affair : the japanese coder never kept their source code most of the time.

Yes, and in the case of Rainbow Islands not to have the source would be a real problem. The coin-op is in the very restricted circle of 10 on 10 games. It's a such perfection, and on a coding point of view one of the best too.

I'm looking for how to convert PNG screenshot taken by WinUAE to IFF to directly load them in Deluxe Paint and modify the palette in real time. It would save a LOT of time to set a new palette since i'm using photoshop at the moment then test the result in WinUAE to check the result. *** If someone can help me how to do a PNG to IFF i would appreciate ***. I tried with Paint Shop Pro 6 and Deluxe Paint 3 but it didn't work (or i did a mistake i don't know well)


Yesterday i did read an interview of Mr Braybrook, he said that one of the biggest triumph of John Cumming had been to find a 16 color palette that could been used for the tiles and sprites. Not a surprise that i struggle to find a new palette, it's a real pain since the colors are shared by plenty of items. But island 1 is almost done, i will soon post here 2 versions to have the members opinions.

[Retro1234]

If you use the Action Replay Mkiii on Amiga or Uae press the freeze button
iirc
Type P to display screen shot
Type SP name to save iff screenshot to Df0 in correct pallet
type X to exit
Dont know if the WinUae Debugger has a similar feature

Thanks but I don't have the Action Replay on Amiga and i'm looking for a way to do this from PC, not Amiga. I use WinUAE to take the screenshots. So i need a way to do this on PC, not on a real Amiga.

[Retro1234]

Use the Action Replay Rom on WinUae
or reduce the colour depth in photoshop

[idrougge]

Personal Paint can load PNG, but keep in mind that games may use the Copper to change palette at different spots in the screen and that sprites may use different colour registers than the main playfield.

[Anakirob]

I had a suggestion that I might have liked to post to another thread on the topic of palette hacking, but that thread is closed because of an argument, so I'll ask here.

If you are going to patch the colours of a game is it really too much trouble to make some kind of a palette preferences application for said game using Blitz, C or E? Or maybe even just an AmigaDOS script which uses existing tools to allow the user to specify their choice of palette?

It seems that the whole issue of "I don't like the colours you picked" could be negated completely if once you have located all the necessary data that needs to be patched you had some kind of palette requester for the user to tweak their colours to suit their tastes.

For example on my TV fully-saturated colours tend to bleed like a haemophiliac, but knock just one bit off the value and then it's fine. And on some displays I have used the gamma is way off and there is nothing I can do to make the darker colours visible as anything other than black.

So therefore if I had a tool to adjust certain colours, even if only on some games, then that would be a most useful thing indeed.

[earok]

Originally Posted by Anakirob

I had a suggestion that I might have liked to post to another thread on the topic of palette hacking, but that thread is closed because of an argument, so I'll ask here.

If you are going to patch the colours of a game is it really too much trouble to make some kind of a palette preferences application for said game using Blitz, C or E? Or maybe even just an AmigaDOS script which uses existing tools to allow the user to specify their choice of palette?

It seems that the whole issue of "I don't like the colours you picked" could be negated completely if once you have located all the necessary data that needs to be patched you had some kind of palette requester for the user to tweak their colours to suit their tastes.

For example on my TV fully-saturated colours tend to bleed like a haemophiliac, but knock just one bit off the value and then it's fine. And on some displays I have used the gamma is way off and there is nothing I can do to make the darker colours visible as anything other than black.

So therefore if I had a tool to adjust certain colours, even if only on some games, then that would be a most useful thing indeed.

We actually did that for Giana SE.. though it was a Windows app using a CSV (to be honest, not hard to port to Blitz, I've already written Blitz apps that can parse CSVs..)