This is the note about the drawer that would not look right. Everything else on the disk had come good. The screen was 1280 by 720 in 16-bit color, Scalos came up as the backdrop on its own, the disk and trashcan icons had their NewIcons pictures. Then you opened UserTools/StateOfTheArt and two icons sat there looking like a satellite photo of a chemical fire. The big one, the game, was orange and magenta noise with a dragon somewhere under it. The small one, the ReadMe, was a document drawn in blue and cyan by someone who had run out of the other colors.
The tempting theory arrives fully formed, because it is the theory everyone has about Amiga icons: it is the palette. MagicWB icons want the MagicWB colors, NewIcons remaps, Scalos remaps, a graphics card changes the pens. Boot a plain Workbench, compare, install the MagicWB palette, done. That theory is half right, and the half it gets wrong would have cost an evening, so this note is about the order the questions were asked in.
Decode the file before you touch the palette. A screenshot cannot tell a bad picture from a bad screen.
An Amiga icon is a small binary with a fixed header, one or two planar images, an optional default tool, and a list of tooltypes. Reading one on the host takes a page of Python and gives you three facts a screenshot cannot: how many bitplanes the picture has, which pen numbers it actually uses, and what the tooltypes say. That page is now icon_report.py, and it gave a different answer for each icon.
The dither
The game icon carried a tooltype that read *** Colors = ROMIcon ***. That is the WHDLoad installer’s doing. When it asks which icon style you want, it offers three: RomIcon, NewIcon, and a plain color icon. RomIcon is a 16-color dither meant for a screen that has those sixteen colors in the right order, which a Picasso96 desktop does not. No palette on earth fixes it, because the picture was drawn for a palette the screen is never going to have. The guide even says so, in passing, on the games page: pick NewIcon.
The install drawer still had the answer sitting next to the question. StateOfTheArt.newicon is the same icon with the same SLAVE= and PRELOAD tooltypes plus the NewIcon picture, encoded as a stack of IM1= and IM2= tooltypes. Merging those lines into the icon on the disk keeps its position and its tooltypes and gives NewIcons something to draw. NewIcons ships a tool for it, copynewicon, which silently does nothing unless the source file is named .info, and which produced a file byte-identical to a merge done on the host. So the merge is done on the host now, for every game icon on the disk at once, as part of minting the hardfile.
The other one
The ReadMe icon was the palette after all, and it is where the evening went. It is a MagicWB icon: three bitplanes, eight pens, and it draws on pens 4, 6 and 7. Those pens have a meaning in the MagicWB world, medium grey, tan, salmon, and the icon was painted assuming them. Workbench 3.1 ships with no palette.prefs at all, so the desktop runs on Kickstart’s defaults, and on a Picasso96 screen the defaults for pens 4 to 7 are whatever the card’s driver put there. Here that was pure blue and pure cyan, which is what the icon was being drawn with.
The obvious fix is the one every MagicWB readme gives: open Palette Preferences, set the eight colors, save. The file it writes is an IFF PREF form with a PALT chunk, 400 bytes, holding two pen tables and thirty-two color entries. The Palette program on the disk is a plain GadTools window, so AmiPilot could click its Save button and the result could be pulled back and decoded. That gave a byte-exact template to write on the host, with the MagicWB colors swapped in. Reboot, open the drawer, measure the pixels.
The desktop went MagicWB grey. The icon stayed blue and cyan.
Pens 0 to 3 had moved. The screen background was now #959595 and the blue was #3B67A2, both exact. Pens 4 to 7 had not moved at all. This is not a bug; it is what IPrefs does on a screen deeper than eight colors. It applies palette colors 0 to 3 where you expect, and it puts colors 4 to 7 at the top four pens of the screen, the ones the system reserves for its own look, leaving pens 4 to 7 free for programs to allocate. The pen tables in the file even carry a special range for “the last four colors” to make that work. An icon that draws directly on pen 6 is drawing on a pen IPrefs deliberately did not touch.
The screen was not Workbench’s, though. It was Scalos’s, and Scalos has its own idea about colors. The 1.2b archive ships a Scalos Palette preferences program, and the open-source Scalos has the reader for its file: ENV:Scalos/Palette.prefs, an IFF form with a SPAL chunk shaped like a LoadRGB32 table, count and first color, then a 32-bit red, green and blue for each. That is applied to the screen Scalos opens, which is the one the icons are drawn on. The preferences program itself is MUI, and MUI gadgets are invisible to AmiPilot, so there was no Save to click and read back this time. The writer in the Scalos source is short and unambiguous, and a 138-byte file written from it went onto the disk beside the first one.
Another restart. Pens 4, 6 and 7 read #7B7B7B, #AA907C and #FFA997, the MagicWB values to the byte. The ReadMe was a document again.
One more restart settled which file had done what. With the Scalos file alone, pens 4 to 7 were MagicWB and pens 0 and 3 fell back to Workbench’s grey and blue. So both files are needed, and they split the work along a line nobody documents: IPrefs owns the first four pens, Scalos owns the next four. Neither file does anything to a running screen. Copying either into ENV: changes nothing until the next boot, which is why every panel above is a fresh start of the emulator rather than a quick look.
The measurement
The discipline that made the difference was refusing to grade by eye. Each state of the disk was proved the same way: quit WinUAE through its pipe so the hardfile flushes, relaunch it, wait for AmiPilot, open the drawer with Scalos’s own opendrawer tool because a backdrop root window has no title to click in, capture the client area, and ask ImageMagick which colors the icon is made of. The histogram is the verdict. A pen either reads #AA907C or it does not.
# On the Cygwin host that runs WinUAE. Clean restart, then the drawer.
scripts/verify_winuae_desktop.sh \
--winuae 'C:/Program Files/WinUAE/winuae64.exe' \
--config build/scripted-smoke/a1200-acceptance.uae \
--artifacts build/palette-restart --require-backdrop
scripts/show_drawer.sh SYS:UserTools/StateOfTheArt --artifacts build/palette-after
# On the Mac. The ReadMe icon is the 64x58 box at 94,100 in the capture.
magick build/palette-after/drawer.png -crop 64x58+94+100 +repage \
-format %c histogram:info:- | sort -rn | head -8
# Before either file:
# 1097 #FFFFFF 1012 #AAAAAA 608 #6688BB 426 #000000 346 #0000FF 223 #00FFFF
# With palette.prefs and Scalos/Palette.prefs:
# 1026 #FFFFFF 1012 #959595 608 #3B67A2 426 #000000 346 #7B7B7B 223 #AA907C 71 #FFA997The files
Both palettes are now written by the installer, on the host, from the same eight colors, so they cannot disagree. write_palette_prefs.py reproduces the file Palette Preferences saved, byte for byte, then changes the colors; the saved file is kept as a test fixture so that claim is checked every run. write_scalos_palette_prefs.py follows the Scalos writer. install_scalos.sh puts both under Prefs/Env-Archive, check_guide_hdf.sh decodes the Scalos one and reports the color count, and the host test asserts both. The RomIcon merge runs in the same mint as --romicon-newicons, pointed at the folder the WHDLoad installers came from.
# What the two writers produce. Same colors, two shapes.
$ scripts/write_palette_prefs.py palette.prefs --preset magicwb --decode
pens4 0 1 1 2 1 3 1 0 2 1 2 1
pens8 0 1 1 2 1 3 1 0 2 1 2 1
pen 0 #959595
pen 1 #000000
pen 2 #FFFFFF
pen 3 #3B67A2
pen 4 #7B7B7B
pen 5 #AFAFAF
pen 6 #AA907C
pen 7 #FFA997
$ scripts/write_scalos_palette_prefs.py Palette.prefs --preset magicwb --decode
pen 0 #959595
...
pen 7 #FFA997
# One mint, both fixes, checked before it is shipped.
scripts/build_mister_image.sh --source A1200e-fresh.hdf \
--out build/mister/A1200e-2026-09-27c.hdf \
--romicon-newicons whdload-installers/ --shipTwo small things bit on the way and are worth a line each. Palette.prefs and palette.prefs are one file on a Mac, so the two temporary copies need different names before they go onto the Amiga volume, where they are different. And the board rejected its password once, mid-copy, and accepted it a second later; the copy script used to read that failure as “file not there” and carry on, which is exactly the wrong guess when the file it might be overwriting is one the core has mounted. It stops now.