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

• AmigaOS 2: The Greatest Upgrade
  In the beginning, the Amiga gods created the classic GUI. The gods said “let there be blue,” and the blue was good. That was all nice and well, and I really dig the efforts to stay oldschool and keep modernizing the old look at the same time. But it’s also true that the fancy, professional-looking 3D update to the Amiga UI was really exciting at the time. Before we even got the update at home (by acquiring an Amiga 1200), I spent a lot of time designing application mockups (see here and here) out of sheer excitement. And that was only the visual part – the datagubbe post discusses a lot of the improvements under the hood as well.
• How to start writing a music replayer for your demo in <200 lines
  I don’t know if I will ever write a Windows demo (again *cough*), but it can’t hurt to keep up with the basics in Microsoft-land, either. Together with Gargaj’s demo writing mini tutorial referenced in the very first What’s Cool? post, this is a great starting point for dummies like me.
• Der PET und die Demoszene
  (German) Bodo und Krill wurden vom „Besser Wissen“-Podcast eingeladen, über den PET und die Demoszene zu quackeln. Natürlich auch über C64, Hardware, Demopartys und den kreativen Prozess. Reinhör-Empfehlung!
• Building an AmigaOS Development Environment in 2026
  Because why not? I remember when Hannibal’s WinUAE demo toolchain was all the rage in 2012 (because it was great, and at least for me, it was released just at the right time – thanks, Han!). Nowadays, there are a million more ways to conveniently build Amiga software, and that’s great. This one is built on gcc and Amiberry and even sports a gdb server on the Amiga side – cool stuff!
• BoingKick
  A boot screen replacement reminiscent of my own hack, but specifically for the Amiga 1000. This one also patches the “strap” module that is normally responsible for showing the boot prompt, i. e. the weird hand holding a Workbench disk. Instead of merely showing an alternative boot prompt picture, BoingKick also procedurally creates a Boing ball and animates it with palette cycling. Sweet!
  
  

“Why are you upset, honey?”

“It’s just a mug…” :(

Of course, I’m not really upset! Well, not upset-upset; ignore the teeth-grinding noises. I try to move on, and accept that out of a hundred cups that we own this is the one that takes a dent.

Also, it’s not that there wasn’t a way to replace this mug with a new one in the future – even if it’s the distant future! :)

PS: Since I’m on vacation and don’t post a lot: Here is where I got that mug…

Four years ago, I was toying around with Teletext rendering prototypes for an Amiga demo. Those prototypes quickly turned into a demo in its own right, and I put aside the original goal of doing this on the Amiga.

That demo became 420 Years of Teletext.

Teletext output on the Amiga took another year to crack. It then turned out it wasn’t a “world’s first” achievement after all, but fun was had all around!

Back then, it was only a month before the party (Evoke 2022) when we had proof: This can actually work! The demo was already half done when Green hooked up the trusty Nokia TV of his youth, and it ran some effects in 25 fps. I only had a stupid smart TV myself, and the software-based Teletext rendering in those devices cops out at seven frames per second. Lame!

At the party place, we recorded the thing hours before the deadline with Ghost’s mobile phone in a dark orga room, and this has been the only proper recording of the demo ever since.

Until now! A higher-resolution version is on YouTube, too. Enjoy and learn all about Teletext’s history! :)

A 256 byte adaption of an infamous screen saver for ROMA.EXE 2026.

Due to space constraints, the DVD logo is drawn with escape sequences and ASCII* characters…

Read more about it on the write-up page: Fireworks!

Of course, making a 256 byte Amiga intro isn’t the only obvious adaption of the bouncing DVD logo – why not turn it into a drum machine?

*) Well, akshually the macron ¯ is not ASCII, but ISO-8859-1 :)

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, address 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! :)