This article introduces a simple macro that allow us to do overlapping IRQ handlers so easily that they can be used for pretty much every long-running subroutine we call from our raster interrupts.

There is a longer version of this in my talk at Fjälldata 2026:

Rastertime on the C64

On the C64, the CPU and the graphics chip (the VIC-II) are in perfect synch. Each cycle, the CPU runs one cycle and the VIC chip runs one cycle. Sometimes the VIC chip needs to access memory and then it steals a few cycles from the CPU.

This means that everything the CPU does can be measured in the time it takes to paint pixels on the screen. Each CPU cycle matches 8 pixels and every line of pixels corresponds to 63 cycles (unless there are cycled stolen by the VIC chip) – this is typically called one raster line.

This is typically what we mean with rastertime: the time between two raster lines on the screen. Rastertime is typically measured in rasterlines. So if we say that a subroutine has a rastertime of 10 lines, that means that, roughly speaking, that the subroutine consumes some 630 cycles of CPU time.

Rastertime can be visualized easily. By setting the border color to a different color before the subroutine is called and resetting it after the subroutine has returned, we get an immediate visual repressentation of that subroutine’s rastertime.

The code for this, using anonymous IRQ handlers, looks something like this:

irq:
{
    irq_wait_rasterline($80)
    dec $d020
    jsr subroutine
    inc $d020

    jmp irq
}

Rastertime Between Interrupts

Almost everything we do on the screen in a C64 demo has to be updated at 50 frames per second for it to look smooth. With 63 cycles per rasterline, and 312 rasterlines per frame, that gives us a total cycle budget of 19656 cycles per frame. On top to of that, we may lose a few thousand cycles because of the VIC chip stealing cycles (depending on how we tweak it at runtime).

But, in addition to the total cycle budget, we often have to face another challenge: the rastertime between two interrupts. By default on the C64, when one interrupt is handled, other interrupts are blocked. Once we return from the interrupt handler, new interrupts can occur.

In the pictures below, the red arrows indicate where a raster interrupt happens. In the left picture, the first raster interrupt is handled in good time before the second raster interrupt happens. This is fine: the first interrupt handlers will have returned, and re-enabled interrupts, before the second one occurs.

But things are not as good in the right picture. Here, the second raster interrupt is scheduled to occur before the first one completed. This will result in a frame-skip: the second raster interrupt will happen on in the next frame.

Frame-skips are the bane of every C64 demo programmer. They will appear as highly visble glitches on the screen and, because the music routine has to be called at exactly 50 Hz, there will be an audiable glitch as well. Horrible!

We can solve this situation in several different ways:

1. Split the subroutine in the first interrupt handler into two chunks, and call the second chunk in the second interrupt handler.
2. Call the long-running subroutine from the main loop instead of from the interrupt handler.
3. Implement a multi-tasking mechanism.
4. Implement overlapping IRQ handlers.

The talk in the video above goes into detail on how to do 1-3 in the list above. Here we will focus on number 4, overlapping IRQ handlers.

Overlapping IRQ Handlers

Overlapping IRQ handlers is a technique often used by C64 demo coders to avoid rastertime problems between interrupt handlers.

This article presents a very simple implementation of overlapping IRQ handlers that adds no additional complexity to the code that is using it. Is so easy to use that it can be used widely, even in situations where there is plenty of rastertime available. This makes the resulting code much more flexible than it otherwise would have been: the called subroutines can now use as much rastertime as needed, without having to cater for them being called from an interrupt context.

The overhead is very low: 12 bytes of memory and 19 cycles per usage.

How Overlapping IRQ Handlers Work

The idea is simple: inside the interrupt handler, set up the next raster interrupt, acknowledge the existing raster interrupt, then explicitly enable interrupts, before calling the subroutine you wish to call. The next raster interrupt will now take place on top of the subroutine, in case it has not yet completed.

In case the subroutine had already completed, the effect will be exactly the same as when running with no overlapping IRQ handlers: the next raster interrupt handler will execute when its interrupt happens.

The prereuisite for this technique is that we store and restore processor registers to the stack in our interrupt handlers. This ensures that they will be able to execute on top of each other.

Handling Reentrancy With One Flag

But there is one big problem that we need to solve before we can run overlapping IRQ handlers as our default mechanism: reentrancy. That is, what happens if our subroutine does not finish until its interrupt handler gets called again, on the next frame?

If our subroutine gets called again on top of each other, two problems will happen:

• We may run out of stack, if this happens over and over again.
• The subroutine may fail completely, because its code was never intended to be called on top of itself.

Both of these problems are difficult to debug. They will most likely result in a seemingly random crash because the stack overwrites itself or because of a seemingly random failure of the called subroutine.

Fortunately, there is an easy fix for this problem. For every overlapping IRQ handler, we keep a flag that signals if the subroutine is currently being called. If it is already called, we avoid calling it on top of itself.

We can even save memory by encoding this flag as self-modifying code inside the calling code.

The Code

All of this can now be nearly implemented as a new macro, in addition to our anonymous IRQ handlers:

.macro irq_call_wait_rasterline(subroutine, rasterline) {
   irq_setup(next, rasterline)

    // This is the flag that indicates if the subroutine has been called or not:
running: lda #0
    // If we have already called this subroutine, we will not call it again now
    bne dont_call

    // Set the flag so that any subsequent invokations will avoid calling the subroutine
    inc running + 1

    // Acknowledge the raster interrupt with the VIC
    inc $d019

    // Enable IRQs for the CPU
    cli

    // Call the subroutine - this call may take a very long time
    jsr subroutine

    // Once the subroutine is done, we reset the flag again
    lda #0
    sta running + 1
dont_call:
    // We exit the interrupt handler here, 
    // both if we called the subroutine, or if we skipped it
    irq_leave()
next:
    // We will arrive here because of the raster intterupt on the line given by rasterline
    irq_enter()
}

That’s it! Not quite as neat as the anonymous IRQ handlers, but reasonably self-explanatory.

Now let’s take a look at how to use this. Let’s say we want to call three subroutines, which we might call red, green, and blue, on given places on the screen. We simply implement our IRQ code like this:

irq:
{
    irq_wait_rasterline($18)

    // We are now at rasterline $18, call red and wait until rasterline $64
    irq_call_wait_rasterline(red, $64)

    // We are now at rasterline $64, call green and wait until rasterline $b0
    irq_call_wait_rasterline(green, $b0)

    // We are now at rasterline $64, call blue and wait until rasterline $ff
    irq_call_wait_rasterline(blue, $ff)

    // We are now at rasterline $ff

    jmp irq
}

This will result in the following screen:

In this case, the subroutines did not actually end up overlap each other at all. But if we slightly change the raster lines, we get a different picture:

Here we see the green subroutine interrupting the red one. Then green is itself interrupted by the blue subroutine. When the blue subroutine finishes, we see green continue until it is done. Then red will finally get the CPU back and can continue until it is finished.

In this example we also see another sideeffect of overlapping IRQ handlers: we have an ordering of priority. The subroutine that gets called first has to wait for the later ones to finish.

Whe to use Overlapping IRQ Handlers

Because of the easy-to-use macro, overlapping IRQ handlers can be used pretty much every time you need to call a potentially long running subroutine from an interrupt handler.

Myself, I use them all the time, making me worry way less about rastertime than I used to do. See the talk for a few examples.

The Full Source Code

For reference, here is the full source code for this (in Kickasm format):

.macro irq_setup(irqhandler, rasterline) {
    lda #rasterline
    sta $d012 // Set the low 8 bits of the rasterline in $d012
    lda $d011 // Set the 9th bit of the rasterline in the 8th bit of $d011
    .if (rasterline < $100) {
        and #$7f
    } else {
        ora #$80
    }
    sta $d011

    lda #<irqhandler
    sta $fffe
    lda #>irqhandler
    sta $ffff // Set the interrupt handler address
}
.macro irq_enter() {
    pha
    txa
    pha
    tya
    pha  // Store registers on the stack
}
.macro irq_leave() {
    inc $d019 // Acknowledge the raster interrupt

    pla
    tay
    pla
    tax
    pla  // Restore processor registers from the stack
    rti  // Return from interrupt
}

.macro irq_wait_rasterline(rasterline) {
    irq_setup(anonymous, rasterline)
    irq_leave()
anonymous:
    irq_enter()
}


.macro irq_call_wait_rasterline(subroutine, rasterline) {
   irq_setup(next, rasterline)

running: lda #0
    bne dont_call
    inc running + 1
    inc $d019
    cli
    jsr subroutine
    lda #0
    sta running + 1
dont_call:
    irq_leave()
next:
    irq_enter()
}

    * = $0801
    BasicUpstart(start)

    * = $0810
start:
{
    lda #$7f
    sta $dc0d // Turn off timer interrupts
    lda $dc0d // Acknowledge any lingering timer interrupt

    sei       // Disable interrupts while we work on the interrupt settings

    lda #$35
    sta $01   // Turn off ROM

    lda #$01
    sta $d01a // Enable raster interrupts

    irq_setup(trampoline, 0) // Set up our trampoline interrupt at the top of the screen

    cli       // Enable interrupts

              // Here we could load the next part, but for now, just do an
    jmp *     // infinite loop - the interrupt handlers drive everything now

trampoline:
{
    irq_enter()
    jmp irq
}
}

irq:
{
    irq_wait_rasterline($18)

    lda #0
    sta $d011

    irq_call_wait_rasterline(red, $64)

    irq_call_wait_rasterline(green, $b0)

    irq_call_wait_rasterline(blue, $ff)

    jmp irq
}

red:
{
    lda $d020
    pha
    lda #2
    sta $d020
    ldx #0
!:
    {
        ldy #14
    !:
        dey
        bpl !-
    }
    inx
    cpx #40
    bne !-
    pla
    sta $d020
    rts
}


green:
{
    lda $d020
    pha
    lda #5
    sta $d020
    ldx #0
!:
    {
        ldy #14
    !:
        dey
        bpl !-
    }
    inx
    cpx #40
    bne !-
    pla
    sta $d020
    rts
}


blue:
{
    lda $d020
    pha
    lda #6
    sta $d020
    ldx #0
!:
    {
        ldy #14
    !:
        dey
        bpl !-
    }
    inx
    cpx #40
    bne !-
    pla
    sta $d020
    rts
}

I developed this technique after struggling with messy interrupt handlers for some 30+ years. And it made C64 programming so much more fun, because I no longer have to think about low-level details.

The anonymous IRQ handlers technique was also covered in my talk at Fjälldata 2025, which can be seen here:

Background: Commodore 64 Raster Interrupts

When writing C64 demos, everything is driven by the action on the screen. And on the C64 we have a neat way to drive action on the screen in code: raster interrupts.

A raster interrupt happens on specific raster line on the screen. The raster line is provided by writing a value into the $d012 register (you may also need to write one bit to the $d011 register, but ignore that for now). And when the graphics chip is about to paint that line on the screen, it sends an interrupt signal to the CPU. This causes the CPU to interrupt whatever is was doing and jump to an interrupt routine. The interrupt routine’s memory address is taken from the $fffe/$ffff pair of addresses.

Once our interrupt handler has been called, we can update things on the screen, such as the border color.

That interrupt handler can then set up a new raster interrupt, further down on the screen, to update something more.

This chaining of interrupt handlers is key: this lets the underlying code do something else (such as loading the next part from disk) while we are updating the screen.

The raw assembler code to setup a raster interrupt handler looks something like this:

{
    lda #$7f
    sta $dc0d // Turn off timer interrupts 
    lda $dc0d // Acknowledge any lingering timer interrupt

    sei       // Disable interrupts while we work on the interrupt settings

    lda #$35
    sta $01   // Turn off ROM

    lda #$01
    sta $d01a // Enable raster interrupts

    lda #$40 
    sta $d012 // Set up a raster interrupt on raster line $40

    lda #<irq1
    sta $fffe
    lda #>irq1
    sta $ffff // Make the raster interrupt call the routine in irq1
    
    cli       // Enable interrupts

              // Here we could load the next part, but for now, just do an
    jmp *     // infinite loop - the interrupt handlers drive everything now
}

And the interrupt handler might look like this:

irq1:
{
    pha
    txa
    pha
    tya
    pha // save the registers on the stack

    lda #$2 
    sta $d020 // Set the border color to dark red

    lda #$50
    sta $d012 // Set up a new raster interrupt on raster line $50

    lda #<irq2
    sta $fffe
    lda #>irq2
    sta $ffff  // Set up a new interrupt handler for the next interrupt

    inc $d019 // Acknowledge the raster interrupt

    pla 
    tay
    pla
    tax
    pla  // Restore processor registers from the stack
    rti  // Return from interrupt
}

The code above set up a second raster interrupt, with an interrupt handler that may look like this:

irq2:
{
    pha
    txa
    pha
    tya
    pha // save the registers on the stack

    lda #$e 
    sta $d020 // Set the border color to light blue again

    lda #$40
    sta $d012 // Set up the raster interrupt on raster line $40 again

    lda #<irq1
    sta $fffe
    lda #>irq1
    sta $ffff  // Set up the first interrupt handler again

    inc $d019 // Acknowledge the raster interrupt

    pla 
    tay
    pla
    tax
    pla  // Restore processor registers from the stack
    rti  // Return from interrupt
}

If we run this code, the result will look something like this:

The border color is switched to dark red at rasterline $40 and then back to light blue at rasterline $50.

From looking at this code, there are some obvious repetition that we can encapsulate using assembler macros. This will make the code a little easier to follow, so let’s do that.

.macro irq_setup(irqhandler, rasterline) {
    lda #rasterline
    sta $d012 // Set the low 8 bits of the rasterline in $d012
    lda $d011 // Set the 9th bit of the rasterline in the 8th bit of $d011
    .if (rasterline < $100) {
        and #$7f
    } else {
        ora #$80
    }
    sta $d011

    lda #<irqhandler
    sta $fffe
    lda #>irqhandler
    sta $ffff // Set the interrupt handler address
}
.macro irq_enter() {
    pha
    txa
    pha
    tya
    pha  // Store registers on the stack
}
.macro irq_leave() {
    inc $d019 // Acknowledge the raster interrupt

    pla 
    tay
    pla
    tax
    pla  // Restore processor registers from the stack
    rti  // Return from interrupt
}

Now our interrupt handlers are briefer:

irq1:
{
    irq_enter()

    lda #$2 
    sta $d020 // Set the border color to dark red

    irq_setup(irq2, $50) // Next interrupt in the chain at rasterline $50

    irq_leave()
}

irq2:
{
    irq_enter()

    lda #$e 
    sta $d020 // Set the border color to light blue again

    irq_setup(irq1, $40) // Next interrupt at rasterline $40

    irq_leave()
}

Although the assembler macros help us make the code easier to read, they do not help with the real problem: that we need to spread our code over multiple interrupt handlers, which we need to give individual names.

The Problem: Interrupt Handlers Get Messy, Quickly

The problem with interrupt handlers is that they need to be in a separate subroutine, which we will have to give a unique name.

We may start with irq1 and irq2, which is reasonably neat, but eventually we may want to insert another interrupt handler between them. If we call this irq3, the order will be difficult to maintain, so we might call it irq1b. And we update the code in irq1 to set up irq1b instead of irq2. But what if we now want to change the order of irq1b and irq2? We will need to update the code inside both irq1 and irq1b so that the chain of interrupts is correct. But should we now change the names too? Sometimes we do, and sometimes we don’t, so we end up with a chain of interrupts that may or may not have names that follow their order.

And regardless of the names of our interrupt handlers, their code will be spread out all over the file, which makes it very difficult to see what the code actually is supposed to do.

I was always writing code like this in the past and it made the code trickier and tricker to get right. We can also see this pattern in the source code of many recent demos, such as Next Level by Performers, Halloweed 4 by Xenon, and No Bounds by Genesis Project.

The Solution: Anonymous IRQ Handlers

Now what if I told you that there is a way to write interrupt handlers like a sequence where everything is encapsulated in the same subroutine and were we could just “wait” for those raster interrupts to occur:

irq:
{
    irq_wait_rasterline($40)
    lda #$2
    sta $d020

    irq_wait_rasterline($50)
    lda #$e
    sta $d020

    jmp irq
}

This code will provide the exact same result as the code above: the border color will be changed to dark red at rasterline $40 and to light blue at rasterline $50. But instead of spreading this code out into multiple IRQ handlers, everything is contained in the same subroutine.

I call this technique anonymous IRQ handlers: inside those irq_wait_rasterline() they are IRQ handlers, just like in the old code, but they are anonymous: we do not need to give them names.

This is what the irq_wait_rasterline() macro looks like:

.macro irq_wait_rasterline(rasterline) {
    irq_setup(anonymous, rasterline)
    irq_leave()
anonymous:
    irq_enter()
}

Extremely simple!

The next interrupt will be handled by that anonymous label, which is completely contained inside the macro.

Anonynmous IRQ handlers mean that we don’t need to think about how to name our IRQ handlers. We don’t even need to think of them as IRQ handlers, all we need to think about is what we want to do on the screen, and where we want to do it.

It is now easy to change the order of things, simply by moving the code around inside that irq subroutine. And updating the place on screen at which that interrupt will occur is easy too: just change the number in the code. The updated code will be exactly as easy to read as the original code was, before the change.

Conditionals

Anonymous IRQ handlers make it easy to selectively chose which IRQ handlers that should be run. And the intent of the code becomes immediately evident from reading it. Like this:

irq:
{
    irq_wait_rasterline($40)
    jsr do_something

    lda should_show_rasterbar
    beq dont_show_rasterbar
    {
        irq_wait_rasterline($50)
        jsr show_rasterbar
    }
dont_show_rasterbar:

    jmp irq
}
should_show_rasterbar:
    .byte 0

Loops

Anonymous IRQ handlers even make it possible to loop around IRQ handlers. For this example we need to define a shorter version of our waiting macro:

.macro irq_wait() {    
    lda #<anonymous
    sta $fffe
    lda #>anonymous
    sta $ffff 
    // Do not set $d012 here - let the caller do that
    irq_leave()
anonymous:
    irq_enter()
}

And now we can update the border color in a loop:

irq:
{
    lda #0
    sta color_counter
    lda #$40
    sta rasterline_counter

loop:
    lda rasterline_counter
    sta $d012
    irq_wait()
    lda color_counter
    sta $d020

    inc color_counter
    lda rasterline_counter
    clc
    adc #8
    cmp #$f0
    bne loop
    
    lda #$e
    sta $d020

    jmp irq

color_counter:
    .byte 0
rasterline_counter:
    .byte 0    
}

This will result in the following screen output:

The First IRQ Handler

There is one more thing we need to do here before using or anonymous IRQ handlers: we need to make sure that our irq subroutine is called with the correct context. Because the first irq_wait_rasterline() will restore the stack with irq_restore(), we need to set up the stack correctly before calling it.

The easiest way to do this is to have a trampoline interrupt, which we set up during the initialization code, that will jump into our anonymous IRQ handler subroutine. This code will look something like this:

{
    lda #$7f
    sta $dc0d // Turn off timer interrupts 
    lda $dc0d // Acknowledge any lingering timer interrupt

    sei       // Disable interrupts while we work on the interrupt settings

    lda #$35
    sta $01   // Turn off ROM

    lda #$01
    sta $d01a // Enable raster interrupts

    irq_setup(trampoline, 0) // Set up our trampoline interrupt at the top of the screen
    
    cli       // Enable interrupts

              // Here we could load the next part, but for now, just do an
    jmp *     // infinite loop - the interrupt handlers drive everything now

trampoline:
{
    irq_enter()
    jmp irq
}
}

Conclusions

Raster interupts are a cornerstone of C64 demo programming, but the code quickly gets messy after adding a few of them. This makes the code difficult to write and to read, which makes it difficult to change and will make the resulting code error-prone.

Anonymous IRQ handlers is a set of macros that remove the need to give each IRQ handler a name, resulting in code that is sequential and can be contained in a single subroutine. The resulting code is easier to write, easier to read, easier to modify and usually is less error-prone as a result.

Full Source Code

For reference, here is the full source code for this (in Kickasm format):

.macro irq_setup(irqhandler, rasterline) {
    lda #rasterline
    sta $d012 // Set the low 8 bits of the rasterline in $d012
    lda $d011 // Set the 9th bit of the rasterline in the 8th bit of $d011
    .if (rasterline < $100) {
        and #$7f
    } else {
        ora #$80
    }
    sta $d011

    lda #<irqhandler
    sta $fffe
    lda #>irqhandler
    sta $ffff // Set the interrupt handler address
}
.macro irq_enter() {
    pha
    txa
    pha
    tya
    pha  // Store registers on the stack
}
.macro irq_leave() {
    inc $d019 // Acknowledge the raster interrupt

    pla
    tay
    pla
    tax
    pla  // Restore processor registers from the stack
    rti  // Return from interrupt
}

.macro irq_wait_rasterline(rasterline) {
    irq_setup(anonymous, rasterline)
    irq_leave()
anonymous:
    irq_enter()
}

    * = $0801
    BasicUpstart(start)

    * = $0810
start:
{
    lda #$7f
    sta $dc0d // Turn off timer interrupts
    lda $dc0d // Acknowledge any lingering timer interrupt

    sei       // Disable interrupts while we work on the interrupt settings

    lda #$35
    sta $01   // Turn off ROM

    lda #$01
    sta $d01a // Enable raster interrupts

    irq_setup(trampoline, 0) // Set up our trampoline interrupt at the top of the screen

    cli       // Enable interrupts

              // Here we could load the next part, but for now, just do an
    jmp *     // infinite loop - the interrupt handlers drive everything now

trampoline:
{
    irq_enter()
    jmp irq
}
}

irq:
{
    irq_wait_rasterline($40)
    lda #$2
    sta $d020

    irq_wait_rasterline($50)
    lda #$e
    sta $d020

    jmp irq
}

Background

On the Commodore 64, there are a few ways to produce graphics in the border area. Two the most commonly used are sprites and ghostbytes.

Sprites are very flexible in terms of what type of graphics we can produce, including multicolor graphics. But they are limited to 8 sprites per line and their width is limited to either 24 pixels or 48 expanded pixels per sprite. With unexpanded sprites, we can get 8 * 24 = 192 pixels wide graphics. This will cover less than 2/3 of the visible screen area. With expanded sprites, we can fill the entire visible area, but our pixels will twice as wide due to the need for expanded sprites.

The ghostbyte is extremely restricted. It provides 8 bits of black pixels that are repeated every 8 pixels on in the visible screen area when the border is opened. Also, ghostbytes can only be used in the upper and lower borders and cannot be used in the side borders.

The three pictures below illustrate how sprites and ghostbytes work. The leftmost picture shows how the C64 screen looks by default, with all borders intact. The middle picture shows all 8 sprites in the lower border, with both the lower and upper borders removed. The sprites are placed adjacent to each other and expanded in the X direction so that they cover the entire width of the border area. The third picture shows the effect of the ghostbyte. In this case, the ghostbyte is set to $01, resulting in one-pixel wide bands across the upper and lower borders.

C64 screen with borders	Sprites in lower border	Ghostbyte $01 in upper and lower border

If we combine sprites and ghostbytes, we can produce what looks like unexpanded graphics in the lower and upper borders.

A First Approach: Ghostbyte Masking

The simplest way to produce what appears to be an unexpanded scroll in the upper or lower border is to use ghostbyte masking. This involves setting the sprite priority lower than the ghostbyte priority and use the ghostbyte to mask out some of the pixels of the expanded sprites.

This makes it possible to produce single-pixel width graphics, as long as the pixels are positioned under the ghostbyte mask.

The pictures below shows how ghostbyte masking works to make an expanded letter A appear to be non-expanded. The A consists of 4 expanded single color pixels, that result in an 8 pixel wide A.

This A is visibly expanded.

By setting the sprite priority so that the sprite is behind the ghostbyte and by setting the ghostbyte to the pixel pattern $81, we end up with the A below.

This A now looks like it is unexpanded.

This technique has often been used to make border scrolls look like they are unexpanded. Two examples are Rash’s part in My, Oh My by Light from 1991 (youtube link) and Graham’s border scroll in the 1998 Crest and Oxyron production Coma Job (youtube link).

My, Oh My (1991)	Coma Job (1998)

The My Oh My scroller shows some of the limitations of this technique: pixels that are in the middle of a letter cannot easily be masked, leading to an awkward looking M character. Graham’s scroller overcomes this by using a more appropriate font, as well as a changing background color that makes the problems less visible.

The color of the ghostbyte mask is restricted to the color black, because the ghostbyte is always black.

The ghostbyte masking trick is very commonly used in demos from the 1990s era.

In Crest Avantgarde from 1992, Crossbow and Vision of Crest took the ghostbyte masking trick one step further to create what appears to be a fully unexpanded upscroll (youtube link). In this case, they change the ghostbyte throughout the screen and use an additional black sprite to cover the side border area. This is evident if we change the background color from black to red.

Crest Avantgarde (1992)	The trick revealed

Multicolor Ghostbyte Shine-through

Multicolor ghostbyte shine-through - the trick used in Orbit Untold - is similar to ghostbyte masking, but with a few key differences. Instead of using the ghostbyte to mask the sprite pixels, we create holes in the pixel data and let the ghostbyte and background shine through. By crafting specific patterns with the ghostbyte, we can achieve complex graphics that appear to be unexpanded even if the sprites are expanded.

There are a couple of more differences between multicolor ghostbyte shine-through and ghostbyte masking:

• the ghostbyte is underneath the sprites, not on top of them
• the ghostbyte is typically changed every raster line
• we use multicolor to be able to selectively decide where our ghostbytes will shine through

The main drawback of multicolor ghostbyte shine-through over ghostbyte masking is that since we are using multicolor, each pixel is now 4 pixels wide.

This trick was probably first found by Crossbow and used in the 1992 Crest demo Crest Avantgarde (youtube link). HCL then used it in Totally Stoned 2 by Booze Design from 1993 (youtube link). Cruzer / Camelot made excellent use of the trick in his GULBData intro from 2018.

Crest Avantgarde (1992)	Totally Stoned 2 (1993)	GULBData (2018)

There are probably several other examples of this trick being used in demos, but it does not seem to be very widely used. Possibly because it is so hard to figure out how it is supposed to be done. Myself, I was not able to figure out how this was done when I saw Crest Avantgarde and Totally Stoned 2 back in 1992-1993. It wasn’t until seeing Cruzer’s GULBData intro it finally clicked for me.

Making it Work: a Case Study

We arrange the ghostbytes, which we change each rasterline, into the pattern below. The black pixels are the ghostbyte pixels, and the gray pixels are the background ($d021) color.

We can then draw an upper case A in a way where those ghostbyte pixels will shine through on specific locations. To make the ghostbyte pattern shine through, we use multicolor 00 for those pixels. We set one of the other multicolors to the same color as the background color, and set a third multicolor to black. The black color is used to make it blend together with the black ghostbyte pixels.

In the picture below, the blue pixels correspond to the 00 multicolor, the one that will let the underlying ghostbyte and background color shine through.

If we apply the ghostbyte mask underneath the letter, it will shine through only on the blue areas of the A. If we use white color for the background color, we end up with a reasonably looking A:

We can now draw an entire font to take advantage of this technique:

Those are the first characters of the font from the intro, as they were drawn in gimp. This is the result as they are displayed with the ghostbyte shine-through and with background raster colors that change on every raster line:

If we put all this together, we can create an unexpanded border scroll by drawing selected characters on 7 expanded sprites and moving them horizontally:

To reveal what parts of each character use sprite multicolor and what parts use the background and ghostbyte shine-through, we can use two different colors. The picture below shows the sprite multicolor in red and the background colors in green. We can now see what parts of each character are sprite multicolor and where the background color and ghostbyte shine through.

Conclusions

Multicolor ghostbyte shine-through is a really neat way to produce what appears to be unexpanded graphics in the lower and upper borders. The trick has been used a few times over the years, but does not appear to be very widely adopted, possibly because of how difficult it is to figure out how it works. The trick uses the fact that the background color of a multicolor sprite lets the background + ghostbyte to shine through, allowing us to selectively use ghostbyte shine-through, even within individual characters.

Acknowledgments

Many thanks to Cruzer and HCL for reading and commenting on early drafts of this paper. Also thanks to HCL for revealing how ghostbyte masking was used for the upscroll in Crest Avantgarde

Orbit Untold credits:

• Code + scroll font: trident
• Music: Danko
• Logo + font: tNG