Let’s dig into ancient system software and file an entry for the 2026 “Obsolete operating systems bug bounty” with a report that would have been pointless even back then.

Luckily (sadly?), there is no such bug bounty, but the strange behavior is real nonetheless. Here goes:

SetRGB4 overwrites memory

Summary

On Kickstart 1.3:

When address zero contains a Copper instruction to set a color register, a call to SetRGB4(vp,n,r,g,b) will overwrite the word at address 2 if the color number n matches the color register at address 0.

Come again. What?

Read the steps to reproduce and it will become clearer…

Steps to reproduce

• Write the word 0x0186 to address zero
• Call graphics.library’s SetRGB4 to set color #3 to RGB 7/8/9
• Observe memory contents at address zero

        movem.l d0-a6,-(a7)     ; save registers for later
        move.l  4,a6            ; get exec, graphics, intuition
        move.l  156(a6),a6
        move.l  368(a2),a5
        move.l  ib_ActiveScreen(a5),a5
        lea     sc_ViewPort(a5),a0
        moveq   #3,d0           ; n
        moveq   #7,d1           ; r
        moveq   #8,d2           ; g
        moveq   #9,d3           ; b
        move.w  #$0186,0        ; set memory at 0
        jsr     _LVOSetRGB4(a6) ; SetRGB4(a0:vp,d0:n,d1:r,d2:g,d3:b)
        move.l  4,a6            ; prepare text
        lea     .data(pc),a1
        move.l  0,(a1)
        lea     .fmt(pc),a0
        lea     .put(pc),a2
        lea     .buf(pc),a3
        jsr     _LVORawDoFmt(a6)
        movem.l (a7)+,d0-a6     ; restore BCPL environment
        lea     .buf(pc),a0
        move.l  a0,d1
        moveq   #-1,d2
.cnt    addq.l  #1,d2
        tst.b   (a0)+
        bne.b   .cnt
        moveq   #16,d0
        move.l  172(a2),a4      ; writeoutput
        jsr     (a5)
        moveq   #0,d0
        rts
.put    move.b  d0,(a3)+
        rts
.data   dc.l    0
.fmt    dc.b    'Memory at address 0 contains: %08lx',10,0
.buf    ds.b    256

You would expect the longword 0x01860000 at address zero — after a fresh boot, adress zero contains 0x00000000, and you just put a 0x0186 at the start.

But actually you will find 0x01860789 there.

Why?

It seems like some Copper list rewriting magic goes haywire.

• In a Copper list, 0186 xxxx writes a value to color register 3
• Some function tries to patch Copper instructions for color #3:
  0186 xxxx becomes 0186 0789 everywhere
• That’s fine for the current screen, but address zero is also treated as part of the Copper list that needs patching

Ask me how I found out!

How did you find out?

I was working on a tiny intro for ROMA.EXE when I ran into this. Using address zero as a counter was a hack to save two bytes:

        ; we're doing a BCPL call before and we know
        ; a0 will contain 00000000 (system memory base)

        ; now we need execbase in a6

        move.l  (a0)+,a2        ; a0 = 00000004, a2 = 00000000
        move.l  (a0),a6         ; a6 = execbase

        ; now we can use (a2) as a scratch register
        ; (we do this because all other registers are in use)

In the intro, I’m calling SetRGB4 repeatedly. It was only when the counter value accidentally was equal to 390 (0186 in hex) that things started to behave oddly.

That was fun to debug. :) But not enough fun to keep digging and present the actual culprit in the ROM code here – the SetRGB4 code path is a hairy mess of branches, stack manipulation, and subroutine calls. Who knows what other surprises are lingering in there?

My workaround was to multiply the values by 7, which avoids 390 altogether…

By the way: Having a Copper list at address zero isn’t as weird as it sounds – demos for the No-CPU runner start like that. But fear not: SetRGB4 poses no threat in No-CPU land, as there is no CPU to execute it! :)

What is that? A person hanging from a rope? A rune for “WTF”?

It’s neither of those, but it has been appearing in the memory of millions of Amiga computers since the dawn of time, right below the visible screen.

You might have seen it before if you were a very bored teenager in 1992 and used your cool new Action Replay freezer cartridge to inspect the memory contents of a freshly powered-on Amiga 500. That’s a contrived example, of course, and totally not a core memory of mine.

Coppenheimer will show you the same thing in the memory inspector when you load up a Kickstart 1.3 ROM and set the width to 40 bytes:

The location might give you a hint already: That shape is a leftover of the Kickstart hand drawing process! To be precise, it’s the result of the last “fill” command. Here is what the Kickstart ROM is drawing in slow motion:

In the video, all blitter activities are highlighted, i. e. whenever a line is drawn or a a block of data is copied, filled, or inverted. The drawing process is really slow and takes its sweet time to complete: 40 frames in real time, 0.8 seconds! In fact, when I hacked up a modified Kickstart that replaced the slow drawing code, that changed the familiar disk-clicking rhythm as well! It went from click (blank screen) – nothing (still a blank screen while you go get a coffee) – click (Kickstart hand appears) to click-click, with a barely noticeable blank screen between the clicks.

So there you have it. The answer to a mystery that nobody asked for, and a really niche and nerdy T-shirt idea. But it was a welcome opportunity to squeeze a little blog post out of the ongoing Coppenheimer update; “slow-mo” mode while you see what the chips are doing will be one of the features.

Cool stuff to stumble upon, new and old.
What’s Cool? · II · III · IV · V · VI · VII · VIII · IX

• Second Nature
  Gigabates and h0ffman write about the concept, the code, the music, the tech, and the tricks behind “Second Nature” (YouTube) by Desire and TTE. A real treat – both the demo and this write-up!
• 3D Demo 3 - Technical Deep Dive
  Another huge write-up for a huge Amiga production, 3D Demo 3 by Lemon.! I love the mood boards, the technical sketches, and the sheer amount of stuff.
• The magic of typing terminal commands
  An ode to the terminal. Beatiful. Recently, I have come to enjoy that terminal-anticipation a lot on my Amiga 500 as well, whenever I need to lha x (unpack) a file, or httpresume (download) something, and see that trusty old computer do its thing. There’s even terminal-pre-anticipation: Pressung Right-Amiga and E and typing in newcli to launch a new shell window in the first place…
  
  
• Playing ATARI music on Amiga for free!
  A new level of No-CPU madness, a genius way to make use of an obscure feature of the audio hardware, or an oldschool “one better than you” response to the dots part of “3D Demo 3” – which one is it, Leonard? It’s all of that, of course, and a lovingly detailled post about it on top.
• A memory heatmap to analyse BBCMicro code
  More inspiration for new Coppenheimer features (link goes to the old version) snatched off Bluesky. I always liked WinUAE’s heatmap-like visual memory map which looks a lot like this. So far, I’ve only got the buttons for it, and a proof-of-concept blitter visualization. And a 13×10 pixel icon, which is of course the most important bit!
  
  

A nice slogan for a t-shirt! Bit long, maybe…

Not so long is the list of new pointers I’ve added to the Amiga Pointer Archive. It’s just these four guys:

One of them is a blog reader submission, taken from a 1992 utility disk (thanks, LocalH!), and another one was a sketch by myself to test the social media sharing feature of the minisite. The other two appeared after the big update – I did a fresh scan of pouët links and went foraging at some FTP sites. And fixed some bugs while I was at it!

In the end, about a thousand new disk images showed up, but after filtering, nearly all the pointers on them were already in the database. That’s disappointing (in numbers), but also cool: I wasn’t missing a ton of pointers as I feared. I did try my best, though:

• RAR files weren’t processed at all (many pouët prod links have them)
• Neither were LHA archives
• Buried in the code was a val limit = 100000 from debugging, and the number of ADF files was of course just above that
• Upper-case file extensions like were ignored

Most of all I’m glad I resisted the temptation of passing arbitrary condiments, i. e. clean up the code and do a “proper” rewrite, with a nice interface and configurable pipelines. It was tempting because the pointer-file collecting process had become a convoluted mix of self-written programs, external tools, and manual steps.

Painful, but with a rewrite and a cool new über-tool I would still be in the stage of building an ivory tower of code without anything to show for it.

One thing I might add in the future is a method to submit hand-drawn pointers directly to the archive – people are drawing not nearly enough Amiga mouse cursors nowadays! :)

Go visit the archive, see if you can spot the four new additions, and have fun exploring! Maybe even start pixelling a new pointer and save a handy URL for later, using the “export” button…

Months ago, I spotted a cool camera at the local Ramsch-, erm, “antique store”. Last week, I finally gave in and bought it – a nice little Game Boy Camera!

I’m still impressed with the picture quality coming out of the 128×128 pixel sensor.

Naturally, two new questions emerged:

• What is the best way to transfer the photos off the device in 2026, and why is it so complicated?
• What is the legislation on posting old photos you find on a camera you bought if the resolution is only 0.014 megapixels?

The last question might be a non-issue. Everything around the Game Boy Camera is about fun and playfulness. It’s packed with mini-games and whimsical features – which the previous owners wisely used to protect their anonymity… :)