The reason I wanted to switch to -mshort is that it allows for more efficient code generation on the 68000. Since that CPU has a 16-bit data bus, needlessly passing around 32-bit values on the stack is wasteful, causing additional CPU cycles to be spent.

By using -mshort, the compiler will default to word-length for integers (type int) and generate code that uses 16-bit values on the stack for those. Of course, you can still use long for 32-bit values when needed (by using the long type), but for many cases, such as loop counters or small offsets, using int is sufficient.

Besides performance gains, -mshort also allows for smaller code size.

Pitfalls

While this worked out quite well for my codebase, I encountered a few pitfalls.

For example, I had to switch libcmini to the short version as well, to make the calling conventions align between the two.

Also, I noticed that controlling fast-forward in Hatari using Natfeats didn’t work properly anymore. Whatever argument I passed (0, 1), it always proceeds to enable fast-forward.

Natfeats is a standard that is implemented by Hatari and it allows you to control certain aspects of the emulator, such as fast-forwarding, from your code. I use this to speed up the startup time of the game during testing, so I can quickly start playing. See Using Natfeats in 68000 Assembly Language for more details on Natfeats.

It turned out that for arguments, Natfeats expects long values on the stack, but with -mshort, a word is pushed onto the stack by my code so Hatari doesn’t find the correct value on the stack.

The reason that my code now pushes a word onto the stack was that the literal that was passed is by default an int, which is now word-length:

nfOps->call(fastForwardId, 1);

This was fixed by making the literal explicitly long:

nfOps->call(fastForwardId, 1L);

Also, I had to change

#define HEIGHT 512
#define SCANLINE_BYTES 160
long offset = HEIGHT * SCANLINE_BYTES

to:

#define HEIGHT 512
#define SCANLINE_BYTES 160
long offset = (long)HEIGHT * SCANLINE_BYTES

Because, again, by default the constants are int and therefore words, causing the expression (512 * 160) to overflow.

I could have also written the following:

#define HEIGHT 512L
#define SCANLINE_BYTES 160L
long offset = HEIGHT * SCANLINE_BYTES

But I think this is less ideal, because now the constants are forced to be longs while in other places using them as words would suffice (i.e., when multiplying by a value that doesn’t cause an overflow).

Finally, I found that calling C library function itoa didn’t work for me anymore in certain cases. It turned out that I had to use ltoa, which explicitly takes a long argument. itoa had silently changed to take a word and I was passing in a long.

Depending on your code, you might encounter similar issues when switching to -mshort, so be sure to check the types of your literals and function arguments.

I’m sure there are many more pitfalls that may arise when switching to -mshort, but these are the ones I encountered so far.

Performance gains

Of course, all of this effort wouldn’t be worth it if it didn’t result in a significant performance gain.

I’m using a special mode for benchmarking, where the game runs for a short while without user interaction where everything that happens is deterministic. The benchmark then measures the number of CPU cycles spent. This allows me to reliably compare the performance of different versions of the code.

While not a very scientifically sound benchmark, it gives a good sense of the performance results:

Without -mshort
Average: 102337086 cycles

With -mshort
Average: 101441200 cycles

The average gain is 0.875%.

Comparing the code size is a bit harder in this case because I’ve made some other changes as well, as a result of the -mshort change, which changed the code size slightly. But I can say that the resulting executable was about 1% smaller.

Conclusion

I must admit that I hoped for a bit more but it was relatively easy to achieve, so I’m happy with it.

Of course the result depends a lot on the codebase and mine already has quite a few assembly-based optimizations in place for tight loops with function calls, which otherwise could benefit from -mshort as well.

In case you’re wondering: sync scrolling refers to the fact that it is implemented using beam synchronization techniques, which I’ll explain later.

Dyno wrote this great Atari ST Fullscreen demos history post on his site, which I urge you to read first because it also touches on the topic of sync scrolling and how it evolved over time.

Before I went on to use sync scrolling, I had been using a rather narrow playfield (much like Xenon did) to be able to maintain an acceptable framerate. But I kept thinking that it could be done better. I wanted a bigger playfield while spending fewer CPU cycles drawing it at the same time. I knew about sync scrolling from back in the day, when quite a few demos used the technique. So, I figured I could try to use sync scrolling to achieve that goal by not having to redraw the entire screen each cycle.

Hardware scrolling

Before we dive into sync scrolling, let’s first talk about hardware scrolling. Hardware scrolling in its simplest form means that the memory address where video hardware starts reading graphics from can be adjusted with a sufficient degree of precision to achieve smooth scrolling in at least one direction. This means that there is no actual moving of graphics in RAM involved in hardware scrolling.

This is my own definition of hardware scrolling. I’m sure there are alternative ones, but this definition suits our needs in this context.

Sync scrolling

So, we’ve already established that sync scrolling is a form of hardware scrolling. However, sync scrolling is a bit more restricted than traditional hardware scrolling.

Although the video address can be changed on the ST, it can only be changed in steps of 256 bytes, which results in 8-line granularity. This is because a scanline on the ST is always 160 bytes long and 8 * 160 = 1280 is the first number that is a multiple of 256. For smooth scrolling at a reasonable pace, such granularity is not sufficient because scrolling the screen by 8 lines each cycle is way too fast for most purposes. With sync scrolling on the ST we get vertical scrolling with 1-scanline precision and horizontal scrolling with 16-pixel precision. For this game, which scrolls vertically only, the horizontal precision is of no concern.

There’s also a technique that allows for 4-pixel horizontal precision, but sadly, it is not compatible with all ST(E) models and wakestates. I’ll refer to wakestates later in this post.

Besides changing the video address, some hardware platforms (like the STE or the Commodore Amiga) provide additional features, such as 1-pixel horizontal offset precision and configurable line lengths (allowing for virtual screens with horizontal screen wrapping), but that is not the case for sync scrolling on the ST.

With this knowledge, I wanted to see if I could implement sync scrolling in my game. I posted a question on atari-forum.com, asking what the best sync scroll routine was. Unsurprisingly, Troed (member of the aptly named demoscene group SYNC) was quick to reply and offer his help. For those who don’t know him, Troed is famous for his knowledge of Atari ST video synchronization tricks, and he has also released very impressive demos such as Closure, taking the concept of implementing effects previously thought impossible on an ST to an extreme.

After a few weeks of hard work and exchanging ideas and questions with Troed, I finally managed to get sync scrolling working in my game.

There were some rough edges to the sync scroll routines that had me puzzled a few times, but Troed was always there to help me out.

Further below, I will explain how I implemented sync scrolling in the game, but first, let’s investigate how sync scrolling actually works.

So how does it work?

Technically, sync scrolling works by tricking the GLUE chip into generating lines of various lengths, which in turn causes the MMU to read more or less graphics memory for those lines. This must be done before the point where graphics start being read (i.e., somewhere in the upper border). We’ll call the amount of graphics being read for a scanline line length from now on. Changing line lengths causes the graphics for the remaining scanlines to be shifted.

If you want to know more about the timing characteristics of the state machines inside the GLUE and Shifter chips, check out this excellent article.

The scanline length manipulation is achieved by switching between monochrome, 50Hz, and 60Hz modes at exactly timed moments during the scanline.

The change of line length causes the graphics for the remaining scanlines to be shifted accordingly. This, by itself, however, is not sufficient to achieve the granularity we need because only twelve different line lengths can be achieved.

But by repeating this process during several consecutive scanlines, several different line lengths can be combined to achieve every total graphics offset required for a 2-byte granularity.

A two-byte video address granularity in practice means a granularity of 16 pixels because of the way video memory is laid out using bitplanes.

Finding the correct combination of line lengths to achieve the desired total graphics offset is not trivial. Fortunately, Troed has created the synctable tool which allows us to generate a table of line length combinations that suits our needs (vertical scrolling with 1-scanline precision in our case).

Limitations

One effect of using sync lines is that graphics on those lines will look distorted. This problem can be solved by blanking the sync lines by setting the palette to all-black during the lines. However, the result is that there are a few fewer scanlines available for display.

Fortunately, this can be mitigated by using an overscan demoscene technique (in particular, opening the upper and/or lower borders) to regain and even extend the number of scanlines that display graphics.

The following diagram illustrates how the top border can be used to regain scanlines for graphics when using sync scrolling.

However, I will ignore this technique for the remainder of this post to keep things relatively simple.

Another aspect to keep in mind is that when the sync lines are active, timing must be fully predictable. This means that no interrupts must occur. This rules out the use of timers as well. So for example, music that uses timers to achieve SID sound effects cannot be used.

Finally, the timing of the sync lines depends on the actual hardware. As explained in the article mentioned above, there are different possible wakestates across hardware and across boots. A different wakestate often means that timings are different as well, so the code needs to compensate for this. The hardware dependency also means that sync scrolling will not work on non-compatible hardware, such as the Mega STE (running at 16 MHz and having a cache), the TT or the Falcon. Also, accelerated hardware will probably not work because of different timings. Fortunately, the regular STE is supported.

Implementation

Let’s dive into some of the details of how I implemented sync scrolling in the game.

This section is rather technical, so feel free to skip it if you’re not interested in the details.

As I described in the Technical design post, I’m using two libraries to implement sync scrolling:

• Wakestate detector
  • Used to properly initialize the wakestate for the actual hardware.
• Sync scrolling library
  • Contains the actual sync logic.

Basically, I’m using these libraries to set the video address with 2-byte granularity synchronized to each VBL¹. For this to work, a bit of setup is required, which I’ll explain below.

The Sync scrolling library expects the following:

• A table of line length combinations for each possible scroll offset.
• A video address with 256 byte granularity.
• A scroll offset in bytes to further adjust the video address.

Once we have initialized the Sync scroll library with the table, we can use the following flow to handle sync scrolling during each frame:

sequenceDiagram
    autonumber
    activate Main loop
    Main loop->>Main loop: Update video memory
    Main loop->>+Vsync: Call
    Vsync->>Vsync: Wait for sync line routines to complete 
    Vsync->>Vsync: Set up video address + scroll offset
    Vsync->>VBL: Wait for VBL
    Main loop->>+VBL: VBL interrupt
    VBL->>VBL: Set up Timer A
    VBL->>VBL: Blank out palette
    VBL->>-Vsync: Confirm VBL
    Vsync-->>-Main loop: Return
    deactivate Main loop
    Main loop->>+Timer A: Timer A interrupt
    Timer A->>Timer A: Wait for MMU to start reading graphics
    Timer A->>Timer A: Sync lock
    Timer A->>Timer A: Wait (n) cycles
    Timer A->>Timer A: Execute sync line routines
    Timer A->>-Timer A: Restore palette

To elaborate on each step in the flow above:

1. The main loop updates video memory for the current frame. It may also perform other logic, such as updating the positions of sprites, checking for collisions, etc.
2. The main loop calls the Vsync routine before continuing to process the next frame.
3. The Vsync routine waits for the sync line routines to complete, if they haven’t already. This is important because the sync line routines must only be set up for the next frame, not the current.
4. The Vsync routine sets up the video address and scroll offset in the Sync scrolling library for the next frame.
5. The Vsync routine waits for the next VBL interrupt to occur.
6. The VBL interrupt occurs.
7. The VBL interrupt handler sets up Timer A to occur right before the moment when the MMU starts reading graphics. Using a timer saves CPU cycles in contrast to waiting in a loop.
8. The VBL interrupt handler blanks out the palette to hide the sync lines.
9. The VBL interrupt handler confirms the VBL to the Vsync routine by setting a flag.
10. The Vsync routine confirms the VBL to the game loop by returning the call.
11. The Timer A interrupt occurs.
12. The Timer A interrupt handler waits for the MMU to start reading graphics.
13. The Timer A interrupt handler performs a sync lock to ensure that an exact number of cycles has passed since the MMU started reading graphics.
14. The Timer A interrupt handler waits for a specific number of CPU cycles to reach the exact moment when the sync line routines need to be executed.
15. The Timer A interrupt handler executes the sync line routines.
16. The Timer A interrupt handler restores the palette to make the graphics visible again.

The sync line combination table

Before we can initialize the Sync scroll library, we need to generate the line length combination table that it needs. This can be done by running the synctable tool with VERTICAL160 set to true (to indicate our interest in vertical scrolling only).

./Synctables 
Calculating 1 lines of 12 combinations
Press Enter to increase number of lines, ESC+Enter to stop searching
Total searchspace: 12 calculations
Evaluating combos
Position 160 found, 127 combos missing, 8% searched
[...]
Position 206 found, 116 combos missing, 100% searched
Calculating 2 lines of 12 combinations
Press Enter to increase number of lines, ESC+Enter to stop searching
Total searchspace: 144 calculations
Evaluating combos
Position 64 found, 127 combos missing, 0% searched
[...]
Position 156 found, 79 combos missing, 100% searched
Calculating 3 lines of 12 combinations
Press Enter to increase number of lines, ESC+Enter to stop searching
Total searchspace: 1728 calculations
Evaluating combos
Position 224 found, 127 combos missing, 0% searched
[...]
Position 46 found, 22 combos missing, 90% searched
Vertical scroll possible, offset: 4
[...]

The tool then shows the following generated assembly code, which is intended to be included in the codebase:

*********************************************
*  Sync scroll table creator by Troed/SYNC  *
*  12 line lengths used                     *
*********************************************
* Columns as indexes into line-rout table. Last value is 256 byte offset
_linsrc: dc.l _s160,_s162,_s230,_s184,_s204,_s0,_s54,_s56,_s80,_s158,_s186,_s206
_synctab:
    dc.b 5,5,5,0        ; 0 (0)
    dc.b 2,2,6,2        ; 2 (514)
    dc.b 2,2,7,2        ; 4 (516)
    dc.b 5,7,11,1       ; 6 (262)
    dc.b 3,5,8,1        ; 8 (264)
    dc.b 0,4,9,2        ; 10 (522)
    dc.b 0,0,4,2        ; 12 (524)
    dc.b 0,0,11,2       ; 14 (526)
    dc.b 0,1,11,2       ; 16 (528)
    dc.b 0,3,10,2       ; 18 (530)
    dc.b 0,10,10,2      ; 20 (532)
    dc.b 1,10,10,2      ; 22 (534)
    dc.b 0,0,0,0        ; 24 not found
    dc.b 0,0,0,0        ; 26 not found
    dc.b 2,2,8,2        ; 28 (540)
    dc.b 2,5,7,1        ; 30 (286)
    dc.b 0,0,0,0        ; 32 not found
    dc.b 2,9,9,2        ; 34 (546)
    dc.b 0,2,9,2        ; 36 (548)
    dc.b 0,0,2,2        ; 38 (550)
    dc.b 0,1,2,2        ; 40 (552)

    ; ...for brevity, some rows are omitted...
    
    dc.b 0,5,8,0        ; 240 (240)
    dc.b 1,5,8,0        ; 242 (242)
    dc.b 3,9,9,1        ; 244 (500)
    dc.b 0,3,9,1        ; 246 (502)
    dc.b 0,0,3,1        ; 248 (504)
    dc.b 0,0,10,1       ; 250 (506)
    dc.b 0,1,10,1       ; 252 (508)
    dc.b 1,1,10,1       ; 254 (510)

It concludes with the following message:

3 lines needed for the sync scroll

Understanding the synctable tool output

There are a few takeaways from the output of the synctable tool:

• The _linsrc table contains pointers to the sync line routines that the entries in _synctab can choose from.

• The _synctab table contains the line length combinations for each possible scroll offset in the following format:

  dc.b L1[,L2..],O256 ; B (TO)

  where:

  • L1, L2, etc. are the line routine selection in the _linsrc table.
  • O256 is the multiple of 256 that we need to subtract from the video address.
  • B is the desired number of bytes that the row aims to represent as a combination of line lengths. If the row contains all zeros, it means that there is no line length combination possible for the corresponding value.
  • TO is the total offset in bytes that this line length combination achieves. The final number indicates the number of 256 byte steps the video memory address has to be subtracted to reach the value of B.

• The 3 lines needed for the sync scroll message.

  This can be observed in the _synctab table rows, which contain 4 values, one for each of the 3 entries and one for the 256 byte offset.

• The Vertical scroll possible, offset: 4 message.

  It means that the graphics stored in memory should be offset by 4 bytes relative to the actual video address. This may seem strange, but it allows the offsets in the _synctab table to align correctly to obtain the desired offsets. If this offset was not applied, some of the scroll offsets that we need would align with rows in the _synctab table that have no possible line-length combination (as indicated by not found).

The following example shows how the Sync scrolling library calculates the effective video address to set in hardware and select the correct sync line routines to use to achieve the desired scroll offset that is fed into the Sync scrolling library.

Let’s say we want to offset the screen by 5 scanlines.

• The offset in bytes is 5 * 160 = 800 bytes.
• We add the graphics offset of 4 bytes that the synctable tool advised us to apply, which gives us a total offset of 804 bytes.
• We use the regular way of setting the video memory address as close as we can get, by rounding down the offset to the nearest multiple of 256 which is 768.
• The remainder is 36 which is what we use to accomplish the sync scroll.
• Looking up 36 in _synctab, we see that we need to use the line length combinations 0, 2 and 9 (corresponding to line lengths of 160, 230 and 158 bytes respectively), and then subtract 2 * 256 = 512 bytes from the video memory address.
• The scroll offset can be verified by summing these offsets: 160 + 230 + 158 - 512 = 36.

Initialization

Now that we have the line length combination table, we can initialize the Sync scroll library.

First, a call to the Wakestate detect library needs to be made, so we can properly initialize the wakestate in the Sync scroll library.

    ; Wait for vertical blank (code omitted for brevity)
    ; ...
    
    jsr     _detect_ws

Next, a call to the Sync scroll library needs to be made to properly initialize the wakestate.

    jsr     _ws_patch

And finally, to further set up the sync scroll library:

    jsr     _ssinit

Display cycle

Now that the Sync scrolling library is initialized, let’s take a look at what needs to happen every display cycle to make sync scrolling work.

We’ll need the video address (with 256 byte granularity) and the scroll offset. These must be calculated each screen refresh based on the current scroll position of the game.

Let’s see some code that illustrates how the Vsync routine, the VBL handler and the Timer A handler can be implemented to achieve sync scrolling.

The code shown here is not the actual code used in the game but rather a simplified version that is intended to illustrate the concepts. I have not tested it as such, so there may be some errors in it. Please let me know in the comments below if you find any issues.

First, there’s the Vsync routine.

;----------------------------------------------------------------------------------------------
; Waits for the next VBL interrupt to occur.
;----------------------------------------------------------------------------------------------
vsync:  
        
.waitLines:
        tst.b   lineRoutsFinished               ; Wait for the line routs to complete
        beq.s   .waitLines                      ; if they haven't finished yet.

        ; Update the sync-scroll.

        move.l  videoBase,_hscrladr
        move.l  scrollOffset,d0                  
        add.l   #4,d0                           ; Add the graphics offset (as advised
                                                ; by the sync table tool).
        move.l  d0,_hscrloff

        jsr     _setscr                         ; This routine updates the shifter
                                                ; base address and line routs.
.waitVbl:
        tst.b   vblSyncFlag
        beq.s   .waitVbl

        clr.b   vblSyncFlag                     ; Clear the VBL flag for the next vsync call.

        rts

Next, there’s the VBL handler.

;----------------------------------------------------------------------------------------------
; VBL interrupt handler.
;----------------------------------------------------------------------------------------------
vbl:    move.l  a0,-(sp)                        ; Save register.

        clr.b   lineRoutsFinished

        ; Set up timer A for sync-scroll.

        clr.b   $fffffa19.w                     ; Stop Timer A.
        move.l  #syncScroll_timerA,$134.w       ; Set Timer A handler.

        move.b  #57,$fffffa1f.w                 ; Set Timer A counter. This value may need
                                                ; adjustment for optimal timing.
        move.b  #6,$fffffa19.w                  ; Start Timer A with chosen prescaler.

        ; Clear the palette to hide the distortion that will be caused by the line routs.

        lea.l   $ffff8240.w,a0

        .rept 16/2
        clr.l   (a0)+
        .endr

        move.b   #1,vblSyncFlag

        move.l   (sp)+,a0                       ; Restore register.

        rte

And then the Timer A handler.

;----------------------------------------------------------------------------------------------
; Timer A interrupt handler for sync-scroll.
;----------------------------------------------------------------------------------------------
; This handler should fire right before the scanline where the shifter starts reading graphics.
; - Sync-locks to the first graphics scanline and calls sync-scroll line routs at the right
;    cycle to apply the offset that was configured using _hscrloff and the _setscr call.
; - Waits for the end of the graphics on the current line.
; - Restores the palette.
;----------------------------------------------------------------------------------------------
timerA: move.w  #$2700,sr                       ; Prevent interrupts.
        clr.b   $fffffa19.w                     ; Stop Timer A.

        movem.l d0/a0-a1,-(sp)                  ; Save registers.

        ; Prepare registers for line rout calls.

        lea.l   $ffff820a.w,a0
        lea.l   $ffff8260.w,a1
        moveq.l #0,d0

.syncLock:
        move.b  $ffff8209.w,d0                  ; Wait for video address to start changing.
        cmp.b   $ffff8209.w,d0
        beq.s   .syncLock

        ; The MMU has started reading graphics at this point. The number of already processed
        ; bytes varies slightly.
        ; D0 contains the number of processed graphics bytes. We can use the following trick
        ; to wait for the inverse amount of cycles to compensate for this variation.

        move.b  $ffff8209.w,d0                  ; Read the number of processed bytes.
        not.b   d0
        lsr.w   d0,d0                           ; This instruction takes more cycles the larger
                                                ; the value is.

        ; We're sync-locked right now, which means that the number of cycles passed since the
        ; beginning of the scanline is stable. The cycle count on the scanline should be exactly
        ; 200 at this point.

        ; Delay for 276 cycles.
        .rept 276/4
        nop
        .endr

        ; The jumps below are calls to sync lines 1-3. The addresses will be overwritten
        ; dynamically by _setscr. The first line rout should start at cycle 504 on the scanline
        ; but since the jsr takes 20 cycles by itself, we should be exactly at cycle 484 right
        ; now.

        ; Calls to the sync line routs. They expect #$ffff820a in a0, #$ffff8260 in a1 and #0 in
        ; d0. Each jsr takes 20 cycles by itself.

_jvar0: jsr     _s230
_jvar1: jsr     _s230
_jvar2: jsr     _s230
        jsr     _s204                          ; Finish with an extra stabilizer.

        ; The screen should now be offset according to _hscrloff.

        move.b  #1,lineRoutsFinished

        ; Delay a bit so that the palette will be restored right after the point where the
        ; graphics end on the current line. The exact number of cycles may need adjustment for
        ; optimal timing.
        .rept 52/4
        nop
        .endr

        ; Restore the palette now that we're past the line rout distortion.

        lea.l   palette,a0
        lea.l   $ffff8240.w,a1

        .rept 8
        move.l  (a0)+,(a1)+
        .endr

        ; Finish up.

        movem.l (sp)+,d0/a0-a1                  ; Restore registers.
        move.w  #$2300,sr                       ; Allow interrupts.
        bclr.b  #5,$fffffa0f.w                  ; Signal end of interrupt for timer A.

        rte

As you may have noticed, the code above also includes a call to _s204, which serves as an extra stabilizer in this case. It can be omitted, but chances are that the sync scroll will be less stable without it. A downside of this approach is that an extra scanline is unavailable for graphics.

And finally, a few variables that are used by the code above.

        .bss

vblSyncFlag:        .ds.b 1
lineRoutsFinished:  .ds.b 1

; Make sure to set the following variables in your code and keep them up to date where needed.

videoBase:          .ds.l 1
scrollOffset:       .ds.l 1
palette:            .ds.w 16                    

Virtual scrolling

Now that I could leverage sync scrolling and no longer needed to redraw the entire screen each frame, I only had to draw the parts that come into view at each scrolling step. This would save a large amount of CPU cycles, which then could be spent on other things, like drawing more sprites or achieving a higher frame rate. This can be achieved by using a technique called virtual scrolling, where a virtual screen is used that is larger than the actual screen.

As explained in the Display layout post, I’m calling the visible screen the viewport, and with virtual scrolling it shows a portion of the virtual screen. The viewport can be panned to display any portion of the virtual screen, as long as the viewport fits in the virtual screen entirely. By panning the viewport, we can achieve the illusion of scrolling. In our case, a vertically scrolling game, we need vertical panning only, so the virtual screen should be the same width as the viewport. The height of the virtual screen, however, should be exactly two screens high.

To achieve infinite scrolling, however, we’d need an infinitely large virtual screen, which of course is not possible. By cleverly painting graphics into the virtual screen each time the screen scrolls, we can keep the virtual screen filled in such a way that when the viewport reaches the end of the virtual screen, it can be rotated all the way back to the other end, and the graphics that are already painted there seamlessly match the graphics at the previous position.

There’s a lot more to be said about virtual scrolling and I’ll elaborate more on it in a future post.

Up next

Continue reading with the next post: Switching to -mshort

Acknowledgements

I want to thank Troed and Rapido for their feedback on this post during its writing. They pointed out some issues and provided valuable suggestions.

Footnotes

Today’s post isn’t about the game itself, but I felt that it was important to cover some of the technical details of how the Atari ST’s screen buffer works for those who don’t have prior knowledge.

I’m assuming you already have a basic understanding of binary arithmetic. Otherwise, this post might be a bit hard to follow. The obligatory Wikipedia link may be of help here.

Display modes

The Atari ST has a few different display modes, but the one used for this game (like most games on the ST) is called low-res mode, with a resolution of 320x200 pixels and 16 simultaneous colors from a palette of 512 possible colors.

Palette

The palette is a set of colors that can be used in the display. Each color in the palette is defined by a combination of red, green, and blue (RGB) values.

Because the Atari ST’s palette allows for 512 different colors, a color consists of 3 bits for each primary color (R, G and B), with a total of 9 bits (2^9 = 512).

Each palette entry is stored as a 16-bit word in memory. The bits for each color are arranged as follows:

Bit 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
     -  -  -  -  -  r  r  r  -  g  g  g  -  b  b  b

On the Atari STE, there’s an extra bit per primary color, which allows for 4096 colors, but this game targets the Atari ST, so we won’t go into that here.

For example, a palette could look like this:

This results in the following hexadecimal values for the palette entries:

     0    1    2    3    4    5    6    7    8    9   10   11   12   13   14   15
$ 0000 0211 0631 0771 0472 0143 0224 0347 0267 0134 0333 0324 0635 0442 0667 0777

Memory layout

Because low-res supports 16 colors, each pixel is represented by 4 bits (since 2^4 = 16).

Each bit of a pixel color is stored separately in a bitplane. Because there are 4 bits per pixel, there are 4 bitplanes. Conceptually, you can think of the bitplanes as layers that together form the final image. Each bitplane contributes one bit to the color of each pixel, and the combination of these bits determines the final color displayed on the screen.

However, the bitplanes are stored in the display buffer in an interleaved manner, divided into 16-bit words. After the first 16-bit word of bitplane 0, the first 16-bit word of bitplane 1 follows, then bitplane 2, and finally bitplane 3. After that, the second 16-bit word of bitplane 0 follows, and so on.

This means that the memory layout can be represented like below, where the first pixel on the display (at coordinates X=0, Y=0) is represented by the first 4 bits of the first 16-bit word in each bitplane, and so on for the rest of the pixels.

In the diagram above, you can see where the bits of the first pixel (located at x=0, y=0, which is the top-left of the screen) are located in the bitplanes.

To further illustrate this, let’s look at the second pixel (located at x=1, y=0):

Example

A fragment of a screen buffer with some example pixels drawn on it could look like this:

          Bitplane 0       Bitplane 1       Bitplane 2       Bitplane 3      
y=0 ---------------- ---------------- ---------------- ----------------
y=1 --111----------- ---------------- --111----------- --111-----------
y=2 -1---1---------- -1---1---------- ---------------- ----------------
y=3 -11111---------- -1---1---------- -11111---------- ----------------
y=4 -1---1---------- -1---1---------- ---------------- ----------------
y=5 -1---1---------- -1---1---------- ---------------- ----------------
y=6 ---------------- ---------------- ---------------- ----------------

Note that I’ve replaced the 0s with dashes for better readability

To find the color of a pixel, you would take the corresponding bits from each bitplane and combine them. For example, for the pixel at the exact center of the A shape (x=3, y=3), you’d take:

• Bit 4 from bitplane 0 on row y=3 (which is 1)
• Bit 4 from bitplane 1 on row y=3 (which is 0)
• Bit 4 from bitplane 2 on row y=3 (which is 1)
• Bit 4 from bitplane 3 on row y=3 (which is 0)

This gives you a binary value of 1010, which translates to 10 in decimal, meaning that the pixel gets the color at index 10 of the palette.

Finally, to get a sense of how this is stored in memory, the example bitmap expressed in hexadecimal values looks like this:

$ 0000 0000 0000 0000
$ 3800 0000 3800 3800
$ 4400 4400 0000 0000
$ 7c00 4400 7c00 0000
$ 4400 4400 0000 0000
$ 4400 4400 0000 0000
$ 0000 0000 0000 0000

Consequences

The bitplane layout makes graphics programming a bit more complex, but it also allows for some interesting techniques, such as using the bitplanes to create special effects by manipulating them separately. For instance, you can draw graphics to only a few of the bitplanes instead of all four, to save CPU time, at the cost of having a limited number of colors for those graphics.

Up next

Continue reading with the next post: Sync scrolling

I thought it best to address this topic early because I’ll use display-related terms a lot, and they can be confusing if not clearly defined.

Over the years as a software developer, I’ve learned that it’s very important to have clear definitions of the concepts and parts that are at play in a system. It’s easy to get lost in the details and lose sight of the big picture, especially when you are using synonyms for the same concept, or worse, when you are using the same word to refer to different concepts.

Definitions

Let’s define some basic aspects of the display.

The screen comprises the entire visible display area. The diagram below shows the addressable screen — the portion of the display that the hardware designates for drawing graphics. I use the term addressable to indicate that this area is the only one where the program can write graphics. The remaining area, the border area, is not intended to be accessible to the program.

Actually, the border area can be made addressable using a demoscene technique that I’ll explain in a later post.

Borders around the screen are a common feature of retro computer systems. They were originally intended as a buffer for the display hardware because picture adjustments varied widely between different monitors and TVs (which were almost always CRTs). Modern displays use panels with fixed pixel dimensions however, so these borders are no longer necessary.

The game’s primary orientation is vertical; most aspects discussed here don’t depend on horizontal dimensions. For brevity, I’m omitting the horizontal borders and dimensions from the diagrams from now on.

The border area is now divided into two different areas: the top border and the bottom border.

Using the demoscene technique I referred to earlier, the game extends the addressable screen to include portions of the top and bottom border areas. Not all of the border areas are reclaimed, however. I decided to keep the reclaimed area limited because players who still use a classic CRT monitor may not see the entire screen as graphics can disappear behind the edges of the display.

While it’s technically possible to extend the addressable screen to include the left and right borders as well, it’s virtually impossible in a game because doing so would introduce timing requirements that are too constraining for a dynamic environment.

Now that we’ve defined the extended addressable screen, we’ll call it the viewport from now on. This makes reasoning about the display layout easier while the previous term remains useful in a more technical context.

To conclude with a final definition for viewport: it’s the area of the screen that is used for drawing the game graphics.

Next are the playfield and the status panel, both contained within the viewport. The playfield holds the level graphics; the status panel shows game information such as the number of lives and the amount of health the player has.

The game uses the sync scrolling demoscene technique (which I’ll cover in a future post as well), and it affects the screen layout. As a result, several scanlines — called sync lines — are not available for drawing and must be blanked out to avoid graphical glitches.

Blanking out graphics means the game uses a completely black palette during rendering of the area to hide any graphical content or background color.

Also, to adjust the vertical position of the viewport, another area at the top is blanked out, as indicated by viewport y-offset in the diagram below.

Combining the aspects

In the diagram below, you can find a combined overview of the aspects explained above. I often use this diagram myself as a reference when I write display-related code for the game.

Summary

Now that we’ve defined the display’s components, we can use this knowledge to understand concepts in future posts. Stay tuned!

Oh, and one more thing… I wanted to share a small teaser of the game, so I here’s a cut-out of a screenshot I took. It’s from an early version; the graphics may change considerably over time.

Up next

Continue reading with the next post: The screen buffer

Background

But first, let me briefly address the experience I gained in my career as a software developer. I won’t turn this into a resume, but I think it’s worth mentioning that I have been working as a software developer for over 25 years now and that I’ve learned a lot about software design and development. I’ve been working on .NET-based B2B solutions mostly but there’s so much that I have learned that is applicable to game development as well.

Development environment

As I mentioned in the Introduction post, I managed to set up a C-based cross-compilation development environment for the Atari ST, based on Thorsten Otto’s m68k-atari-mint cross-tools. Combined with the equally great RMAC assembler, this allows me to write the game in C and assembly.

This means that I can write code on my PC and then build the game and test it in an emulator, which is a much more comfortable development environment than working on the ST itself. It also allows for a much faster development cycle since I don’t have to transfer the build files to the ST every time I want to test something.

I’m using version 15.2.0 of GCC (the C compiler) which allows me to use relatively modern C features.

I must admit that I’m not aware of all of those newer features, partly because I hadn’t been programming in C for many years, so I probably take most of them for granted. But I do know that compared to the older C/C89/C90 standards (as was common on the ST), I can use things like single-line comments and freely placeable variable declarations, which is really convenient.

Dependencies and tools

Let’s start with a list of tools:

• Aseprite
  • This is the tool used to create most of the game’s graphics, such as sprites and tiles.
• Arkos Tracker 3
  • This is the tool used to create the game’s music and SFX.
• Godot Engine
  • While this is a complete game engine for modern computers, Godot is only used as an editor for the game’s levels. Using a custom script, level data is exported in a format that can be used by the game.
• UPX
  • This is a general-purpose executable packer that I use to compress the executable game binary.

I decided to use as few libraries as possible to keep the game small and retain full control over the code. This means that I have written my own code for things like sprite drawing, tile drawing, input handling, etc.

I’m not under the illusion that my code is better than some of the available libraries I could have used but I wanted to take the challenge of writing as much as possible myself, to maximize my understanding of the matter.

There are some libraries that I do use, however, mainly because I could not reasonably write them, or it didn’t make sense to do so:

• Libcmini
  • To get some basic C library functions, such as string handling and file I/O.
• Sync scrolling library
  • This library by Troed allows the display address to be positioned with 2-byte granularity.
• Wakestate detector
  • Also by Troed; it is used to properly initialize the sync scroller for the hardware.
• LZ4 depacker
  • This library by Leonard is used to decompress the game’s assets, such as graphics and level data.
• Arkos Music player
  • This is the 68000 port of the official player by GGN.

Note that the list of dependencies and tools is neither complete nor final. More dependencies may be added in the future, or removed if a better solution is found.

Build chain

The build chain is pretty straightforward. I have a Makefile that defines the build process, which includes:

• Running the asset pipeline to process the game’s assets (see below)
• Compiling the C code
• Assembling the assembly code
• Linking the C and assembly build outputs together
• Compressing the linked binary
• Creating a disk image that can be run in an emulator

I’ll elaborate on the build chain in a future post.

Asset pipeline

The asset pipeline is a custom tool that I wrote to process the game’s assets, such as graphics and music. Some of the things that the asset pipeline does include:

• Converting assets into the appropriate format, e.g.,
  • Convert .PNG files to 4-bitplane graphics data (optionally masked).
  • Convert level data into a format that is optimized for use in the game.
• Compress and combine all asset files into a single file.
  • Files are placed in a specific order to minimize the drive head seek times when loading.
• Generate C header files that help address the assets from the game code.

I can sum up many reasons for combining the asset files into a single file, but honestly, I just did it because I thought it was cool.

I’ll elaborate on the asset pipeline in a future post.

Codebase

Design principles

I tried using a modular design for the codebase, with separate modules for things like graphics, input, audio, etc. in an attempt to keep the code organized and maintainable.

But even more importantly, I take great care to use proper names for concepts, functions, variables, etc. I think that this is one of the most important things to do when writing code, as it makes it much easier to understand and maintain the code in the long run.

I’m also trying to stay consistent with coding style and naming conventions, to make the code more readable and easier to navigate.

Object Oriented Programming

Since I’m using C and not C++, there is no built-in support for classes or polymorphism. But for some parts of the code, I wanted some features of Object-Oriented Programming, such as encapsulation and polymorphism. To achieve this, I implemented a simple component system, similar to the one presented in articles like Object-Oriented Programming (OOP) in C. I’ll write more about this in a future post.

C calling convention

One particular convention I’m paying attention to is the so-called calling convention, which defines how functions receive parameters and return values. I’m using the fastcall calling convention, which means that the first few arguments are passed in registers, and the rest are passed on the stack. Because the ST has a notoriously slow memory bus, this is a significant performance boost, at least when doing a lot of calls.

The same calling convention also applies to situations where the compiler generates code that calls linked assembly functions, so it’s important to take into account when writing assembly code that is called from C.

Another aspect of the convention is some of the registers are reserved for the caller and some for the callee. This means that both sides have to take care of saving previous register values before using them. A few registers, however, are designated as clobbered, which means that they can be used by both the caller and the callee without saving their previous values.

Many times, when ‘strange’ things were happening during code execution, I had to conclude that it was because I forgot to save a register.

Memory management

At some point during execution, memory needs to be allocated to hold things like sprites, tilemaps, level data, etc. Those allocations need to be freed at some point as well, to avoid running out of memory. Since the TOS operating system has some known problems regarding memory allocations, I decided to play safe and implement a simple, naive memory manager that suits the needs of the game. Basically, I simply allocate all memory at the start of the game with a single malloc() call, and then manage memory allocations myself.

Object pools

Since performing allocations (and deallocations for that matter) are relatively costly operations, I didn’t want to do them during gameplay. In fact, it is common practice in game development to avoid dynamic memory allocations during gameplay, even in modern games.

This means I had to find a way to pre-allocate memory for all the objects that I need during gameplay. I decided to implement object pools, where arrays of more or less specific types of objects are pre-allocated at the start of the game.

One advantage of this approach is that I can prevent having to search through lists of objects during gameplay, which can be costly. Instead, I can simply make sure there’s an object pool available that is pre-filtered to suit the search criteria. Of course, this means that I have to be careful not to have too many pools because that would become costly as well.

Metrics

When optimizing code, it’s important to have metrics to measure the performance of the code and to identify bottlenecks. I have implemented a simple metrics system that records CPU cycles. This is possible because of a recent addition to the Hatari emulator, which allows using Natfeats to get the current CPU counter value.

Note that this is not possible on a real ST, since there is no CPU counter on the ST.

The program then writes CSV formatted data to the debugger console, which allows me to easily process and analyze the performance of different parts of the game.

Optimization

Talking about optimization, this is a really important aspect of designing games, especially for a platform like the Atari ST, which has very limited resources compared to modern computers. It’s a constant balancing act between writing code that is easy to understand and maintain, and writing code that is optimized for performance or memory usage.

Some of the optimization techniques that I use include:

• Write performance-critical code in assembly.
• Pre-shift sprites in order to avoid shifting them during gameplay, since shift operations are costly on the 68000.
• Pre-calculate data tables to reduce the need for expensive CPU instructions such as mulu and muls for multiplications.

Debugging

Well, this is an area I know I will have to put more effort into. There are a lot of possibilities for improving my workflow here. One of them is checking out Hildenborg’s excellent work on debugging support but I haven’t found the time yet to set it up.

For now, I rely on the Hatari emulator’s built-in CLI-based debugger, which is pretty good although the learning curve is relatively steep. I know about the existence of Hatari Remote Debugger GUI, but I haven’t tried it yet either.

Wrapping up

This is just a brief, high-level overview of the technical design of the game. In future posts, I will dive into more details about specific technical aspects of the game, such as how I implemented scrolling, how I draw graphics, etc. Stay tuned!

Up next

Continue reading with the next post: Display layout

Some more history

I didn’t even mention this in the Introduction, but I was 9 years old when my dad bought his second computer. It was a Sharp MZ-800, the successor of the Sharp MZ-700 which he had sold. We drove to a larger nearby city to buy it at a store called “Kwantum Hallen.” He paid around 500 Dutch guilders, which was a decent price.

I had handled the MZ-700 a few times before, but it was the MZ-800 that really got me interested.

The MZ-800 was a very solidly built machine, based on the 8-bit Zilog Z80 CPU, and it had 64 KB of RAM. The architecture was pretty similar to the ZX Spectrum and MSX machines of the time.

Our model had this cool 2.8” Quick Disk drive that could store 64 KB of data on each side (yes, you had to flip the disk to access the other side). The drive had a top-loading mechanism and I still remember the typical sounds it made. One particular aspect of this drive was that data was stored in a spiral pattern, much like the way data is stored on a cassette tape. This meant there were no tracks or sectors on the disk, and when you wanted to delete a file, you had to load the disk’s contents into memory and write it back without the file you wanted to delete.

My Sharp MZ-800 with a Quick Disk drive installed

Games on the MZ-800

We had only a handful of games for the MZ. A friend of mine who had a C64 had many more, and I was a bit envious. But I liked my games nonetheless.

Some of the games I have fond memories of:

Tutanchamun

This is a very tense game where you have to run through a maze, fetch keys while avoiding enemies. Time counts down quickly, so you have to be fast. To survive, you need to collect artifacts that grant extra points, extra lives, and smart bombs. But if you spend too much time collecting artifacts, you’ll run out of time and lose a life anyway.

Tutanchamun on the Sharp MZ-800

Last month, I found out that this game was actually a port (or most likely a clone) of the arcade game Tutankham by Konami (1982). Back then I had no idea, but it didn’t matter because it was exciting to play, although I thought it was very difficult. I played it again recently and still find it pretty hard, although I managed to get much further than when I was a kid.

Nakamoto

I think this is one of the signature Sharp MZ games, probably of Japanese origin, given its name. It’s a puzzle platformer where you have to collect items and avoid enemies.

Nakamoto on the Sharp MZ-800

I didn’t realize it at the time, but now that I have looked at it again, it appears to run in character mode. One of the things that gives it away is that when sprites are supposed to overlap, they cancel each other out. This probably means it runs on an MZ-700 as well, as that machine only had 2 KB of VRAM and no graphics capabilities other than custom fonts in character mode.

VRAM

I soon found out that the MZ needed a VRAM upgrade to be able to play most games. The standard MZ-800 came with 16 KB of VRAM, which was enough for a resolution of 320x200 with 4 colors. But most games required 32 KB of VRAM, which allowed for a resolution of 640x200 with 4 colors or 320x200 with 16 colors (much like the ST but without the extra colors from a palette). The next time my dad took me to a HCC MZ-GG¹ meetup, he bought a 16 KB VRAM chip which we then inserted into the VRAM socket on the motherboard of the MZ. I think it cost around 80 Dutch guilders at the time, which was quite a lot of money. But boy, did it open up a whole new world!

Basic

Not long after, I wrote my first Basic program on the MZ. At that time, I didn’t get much further than drawing a series of growing circles and making the computer play a few simple notes. I don’t remember how I figured out how to even do that. I guess my dad gave me some pointers since he was a bit familiar with programming, but he doesn’t recall that at all. It’s typical for a kid: these kinds of things simply look natural, and you figure them out by playing around.

Talking about circles, it was quite unique for a Basic to be able to draw primitive shapes like circles, lines and rectangles. Most Basics at the time only had a command to plot individual pixels and you’d have to resort to POKE eventually. My Basic interpreter supported drawing scaled text, which was pretty neat.

I remember taking the MZ to my school one day and connecting it to the big TV in the school’s auditorium. During lunch break, under our teacher’s supervision, I showed a few programs to my class; most were puzzled and didn’t really understand what was going on. But I loved showing the MZ — I was so proud of it.

As my Basic skills improved, I started writing some simple games myself. When I was 12 years old, I finally had a working game that was more than a simple concept. It boasted a maze, a player character and some enemies. I called it “Labyrint”.

“Labyrint” is the Dutch spelling of “labyrinth”, so it’s not a typo — though I’m not sure I was aware of that back then.

And you know what? I still have the source code! Back in the day, in a bright moment, I decided to print it on my dad’s dot-matrix printer (probably also because I liked to print stuff anyway). I still have the printout in a box upstairs. I tried OCR-ing it a few years ago, but the dot-matrix typeface didn’t play nice with the OCR software I had. So I decided to just type it out again. Fortunately, it wasn’t too much code, so I managed to do it in an hour or so. I made a handful of errors, which easily happens because there are a lot of hex codes in the source. But I was able to fix the mistakes by debugging. I added a second error handler that shows the error code and the line number.

There are likely a few typos left in the source. The opening screen has some distortion in the logo and there are probably some more subtle bugs as well. I suspect the foe movement code is buggy because it’s showing strange behavior.

My Sharp MZ-800 game called “Labyrint” from 1988

Honestly, I don’t think the game is much fun to play in its current state. But perhaps, after fixing all typos and maybe some bugs as well, it can be nice to play. I do think that the fence that pops up randomly is a little stupid, it can just drop on your head out of nothing. I might want to tune its behavior to make gameplay a little more fair.

But most importantly, it was so much fun to write and it felt like magic that you could put all this work into a program and then run it and see it come to life on the screen. This feeling never left me.

I actually submitted the game to a HCC MZ-GG programming contest. I ended up winning the 4th prize in the gaming category. Unfortunately, I couldn’t make it to the award ceremony because my parents made me visit my grandmother for her birthday. I was quite disappointed at the time, but at least I got my prize in the mail: a nice, red-labeled cassette tape with public domain software.

The HCC MZ-GG cassette tape with public domain software

Tricks

I remember one trick I learned to save memory. Because the Basic interpreter was loaded into memory (the MZ didn’t have Basic in ROM), you’d quickly run out of memory when typing more than a bit of code. You’d have about 18 KB of memory left for writing code and running it!

The particular Basic interpreter I used (Universal Basic) allowed you to omit spaces in many places that contemporary Basic interpreters didn’t, which was a neat trick to save memory.

Universal Basic 4.0, eating away most of the available RAM

So, for example, instead of

FOR I = 1 TO 10

you could write

FORI=1TO10

In retrospect, I think this worked because the interpreter didn’t use bytecode to store the source in RAM (like interpreters on later machines did — for example, GFA Basic on the Atari ST), but instead stored the source code as-is in memory.

Storing source code using bytecode isn’t something most modern programming languages do anymore because it has some serious restrictions but I guess it made sense under the memory constraints at the time.

Something else I remember is that I had this little magazine (probably issued by the HCC MZ-GG but I’m not entirely sure) that showed the bit patterns for byte values 0-255. I didn’t understand binary arithmetic at the time, but I found it really useful to look up the bit values for each byte because I could make sprites that way. I first drew the sprite on graph paper and then translated it to hex values using the table. The Basic interpreter had a command that allowed you to draw a sprite using these hex values.

The table looked something like this:

Another trick I remember was one time, when I was playing with sound on the MZ. I accidentally discovered that you could play a special kind of sound by setting the envelope generator to a really high rate. It sounded a bit off-key but nevertheless special. At lower frequencies it sounded pretty good and not too off-key. I remember showing my trick to people at a Sharp MZ-GG meetup that I went to with my dad (I think in de Jaarbeurshallen in Utrecht). A few years later, with the Atari ST, I learned that this trick was actually a well-known technique called hard sound or hardware sound, most often used for bass sounds called hard bass.

If you’re interested in technical details: the MZ had a Texas Instruments SN76489AN PSG, which is quite similar to the PSG of the Atari ST (a Yamaha YM-2149, which in turn is actually a General Instrument AY-3-8910AY).

The Atari ST

Then, somewhere in 1989, the ST arrived. I already wrote a bit about it in the Introduction, so I won’t repeat all of that here. Suffice to say, it boosted my interest in programming. It offered far more: 1 MB of RAM (vs. 64 KB), a 16/32-bit architecture, a real color palette (the MZ had only 16 fixed colors), and MIDI ports. The sound chip wasn’t a big improvement, however — it was similar to the MZ’s — but I came to love it anyway. The Atari ST also had many great games and demos that made excellent use of the ST’s sound chip; I hadn’t even heard half of what it was capable of.

My Atari ST in our living room back in 1989

Games on the ST

Xenon

I now had access to many more games than I had on the MZ, and man, I was so fascinated by them. One of the first games I remember playing on the ST was Xenon by the legendary The Bitmap Brothers.

Check out this Xenon 1 gameplay video.

Xenon on the Atari ST

While I didn’t have a color monitor until a few years later, I managed to run it using a color emulator. Only a few games worked with the emulator and you had to accept some serious downsides: the frame rate was really low and, to make it not bog down completely, you had to run it in half-width mode, which made the game look even worse. But it was still playable.

I don’t know if this was the exact program I used but this one is similar to it: Omnires.

And the music… it was so good! The famous David Whittaker soundtrack has never left my mind. And that sampled voice at the beginning of the game — “Sector One” — was one of the first samples I’d ever heard come directly from a computer.

Xenon 2: Megablast

And then, there was Xenon 2: Megablast. My best friend Roberto (you might remember him from the Introduction) had gotten the Atari ST Action Pack which contained Xenon 2, and we couldn’t believe how much better it looked than the previous edition. The graphics were so much more detailed and refined (drawn by the talented Mark Coleman).

Check out this Xenon 2 gameplay video.

Xenon 2: Megablast on the Atari ST

I remember that we’d often play Xenon 2 at his house, where he would control the player ship and I would mash the right mouse button like crazy to shoot. I don’t know if his joystick lacked auto-fire or that this just worked better, it was our way to play together.

It is a well-known fact that the right mouse button on the Atari ST is wired to the same input as the fire button of the first joystick, probably to cut costs.

Flying Shark

Now, Flying Shark wasn’t a game that excelled in graphics quality or performance, but it still stood its ground as a port of the popular arcade game. It’s a pretty difficult and unforgiving game, but I loved it anyway. The game mechanics are simple but solid.

Check out this Flying Shark gameplay video.

Flying Shark on the Atari ST

Lethal Xcess

Well, Lethal Xcess (aka Wings of Death II) is a bit of a special game. Graphically, it’s not the best-looking game but it definitely sits above average in that respect. Gameplay-wise, it’s also not the most exciting game, mainly because it is extremely difficult and it doesn’t have very interesting game mechanics. But technically? Boy oh boy. It was written by demoscene members and it shows. It has a large scrolling playfield with a resolution of 320x256 pixels, for which the creators had to open up the vertical borders. It also uses sync scrolling, which allows for larger playfields and smoother scrolling. All in all it was a very impressive technical achievement for the Atari ST.

Check out this Lethal Xcess gameplay video.

Lethal Xcess on the Atari ST

Endless list

I could go on and on to talk about many more great games that I liked, but I have to stop somewhere.

It probably hasn’t gone unnoticed that all of these games are vertically-scrolling shoot ‘em ups. Although I had quite a lot of games I liked a lot that were from other genres, I definitely had a taste for vertically-scrolling shoot ‘em ups and you probably can guess what genre the game I’m working on is in.

Basic programming on the ST

But before we get to that, let me tell you a bit about how I got into programming on the ST. You already know that I had experience with Basic programming on the MZ and it was a no-brainer to start with GFA Basic on the ST, which was the de-facto standard Basic for the ST. It was a lot better than Atari ST Basic (I think I hardly even tried that one) and there were good books about it as well.

At first, I spent most time writing graphics drawing programs, which was a lot of fun. I still didn’t have a color monitor so I could only use high resolution (640x400). I also wrote a few simple games.

Once I had the color monitor, Roberto and I started working on a game called “Dr. Woody”. Sadly, we never finished it.

Our (unfinished) game called “Dr. Woody”

Dr. Woody sprite sheet

Demoscene

At some point, Roberto and I got in touch with the demoscene. I don’t really remember how but we must have met some scene people at a Atari ST meetup or something.

We quickly came up with a name for our little group: “CCC”, which stood for “Crazy Coding Crew”. Soon, we changed it to Odyssey (this was the name under which we released the Symbiosis guest screen for the Synergy Megademo). Later, we settled with Dawn (or “Dawn MultiMedia”, which was a sign of the times).

Our aliases also changed over time; I went from “Fix” and “Vulture” to Zeme and Roberto went from “Digital Coolness” to ManTra.

We went to a few notable parties, but I mentioned that in the Introduction already.

Today, Roberto and I are still in close touch with some of the demoscene people we met back then: Wingleader, BoNuS and Rapido. We regularly meet up and they’re also in the loop concerning the game I’m working on, providing invaluable contributions, feedback and support.

Assembly programming on the ST

Well, you know, if you have the potential to learn assembly programming and you’ve had a taste of the demoscene, the math is clear: you have to learn assembly programming. So I did. I never got extremely good at it but I could write some pretty decent code.

In the light of that, let me tell you a bit about the development of Symbiosis.

Symbiosis

The idea for this demo screen came from a rain effect I had recently coded.

The rain effect in the Symbiosis demo screen

Although it was not a groundbreaking effect, it had such a nice cinematographic atmosphere.

I had wanted to do something with 3D balls for a while and I finally took the plunge. I went to the local library (because, you know, the internet wasn’t a thing yet) and I found a book about 3D graphics programming. I learned how to do 3D transformations and projections and I managed to transform it into assembly code.

I later learned that I could have done matrix transformations instead of doing the transformations separately, which would have been more efficient. But I didn’t know that at the time.

Now that I had the transformations working, I was able to display 3D objects constructed from small sphere-shaped sprites. I used only 2 bitplanes and used a specific palette so that I could draw the sprites without masking (using OR instructions only) to save precious CPU cycles.

I then wrote a small scripting system where I could specify when to transition to the next object (I used morphing for that), the timing of the subtitles, the color of the object, etc.

A 3D object in the Symbiosis demo screen

Many of the objects themselves were typed directly into assembly code using dc.w directives. This means those 3D coordinates were all made up on the spot.

    dc.w 0,0,0
    dc.w 1,10,0
    dc.w 2,20,0
    dc.w 3,30,0
    dc.w 4,40,0
    dc.w 6,50,0
    dc.w 8,60,0
    ...

Some of the objects were generated using a small GFA program I wrote, mainly because of the relatively complicated animation or shape. One example is the running man:

The running man in the Symbiosis demo screen

Roberto then went to draw these cool logo screens and they really finished off the demo screen nicely. And of course, the music by Scavenger was the cherry on top.

The Odyssey logo

The Symbiosis logo

Something we only realized much later, when the demo was long finished and released, was that the graphics were a bit too dark. This was caused by my monitor, which was set too bright and Roberto used it to do a lot of the drawing on. We’re thinking of doing a remaster version somewhere in the future so who knows, we’ll finally fix the issue then.

One more anecdote

There’s one last anecdote I want to share before I get into the game concept.

At some point, I got a sample cartridge for the ST and I wrote a little pitch shifter routine in assembly, which allowed me to talk into a microphone and hear my voice back at a higher pitch (Chipmunk style).

I called my grandfather over the phone, having taped the microphone and a pair of headphones to the telephone, and I talked to him in that high-pitched voice. He got really confused and didn’t get what was going on but I had so much fun!

The new game

So I guess it’s finally time to talk about the vertically-scrolling shoot ‘em up I’m working on.

I have been working on it for 9 months now and I’m really, really excited about it. You have to be a bit crazy and really passionate about something like this to spend so much time on it. Not only am I 9 months in, but also pretty intensively so, meaning that I spent over 1000 hours already, to give you a sense of scale.

Besides all of the predictable elements that a game from this genre typically has, there are a few unique features that set the game apart. I’ll post about them later, mainly because this part is still a work in progress. But let me say that there will probably be some Metroidvania elements in the game that hopefully will make it much more interesting and fun to play.

Visually, the game sports a large scrolling playfield with a resolution of approximately 320x256 pixels, much like Lethal Xcess has. The game also uses sync scrolling, which allows for larger playfields and smoother scrolling and/or more sprites.

I’m targeting 25 frames per second (2 VBLs). This gives a smooth gameplay experience compared to most Atari ST games, but I’ll have to see if I can maintain it during development. At some point I might have to decide between lowering the frame rate to add more content or keeping the current rate.

But that’s just technical stuff. The most important thing is that the game is fun to play and will make you want to keep playing, right? That’s what I’m aiming for and it’s definitely not an afterthought. But I assure you that good looks, sound and features will be there as well.

State of the game

To give you a sense of where the game is at, I have a pretty good prototype running, with most of the technical features working:

• Scrolling, tile-based playfield
• Player ship with basic movement and shooting
• Collision detection
• Loot, including weapon upgrades and health pickups
• Enemies, enemy projectiles, and attack waves
• Background music and sound effects

This means you can already play a bit of the game; there’s a level with enemies, loot, and music. It’s pretty fun to play already, and it looks relatively polished if I may say so.

I’ve drawn most of the graphics myself, but I’m teaming up with Roberto now. I feel the game deserves the best and I’m really happy he agreed to collaborate.

The music is all my work, but I’m open to collaborating with other composers as well.

There are still many missing features, however, such as:

• Checkpoints
• Level progression system
• Boss fights
• More enemy types and attack patterns
• More weapons and power-ups
• More levels and accompanying graphics
• More music

So while the game is definitely not finished yet, it’s in a good state and I’m happy with the progress so far.

Target platform

This may not be the most exciting paragraph but it has to be mentioned to manage expectations: I’m targeting the Atari ST with 1 MB of RAM. The game will run from a single floppy disk or a hard drive (in the latter case, more memory is required).

The main reason for this is that it’s what I had back in the day, and I want to stay true to the experience it gave me back then.

The game will run on an STE as well, but I’m not yet planning to implement support for the extra features of the STE, such as the blitter or the extra colors.

There will probably be no support for later machines like the Falcon or the TT, because the game heavily relies on specific hardware timings of the ST. But I haven’t ruled it out completely yet, so who knows.

I know that by targeting the basic ST, I’m making it harder to achieve some of my goals but this entire project is all about the challenge and the fun of working within the constraints of the hardware anyway. Otherwise, I could just make a game for modern PCs.

Future plans

Of course I’ll make a public announcement about the game at some point, but I’m not yet sure when — hopefully sometime this year.

Oh, and before I forget: I’m planning a physical release in a custom box with a printed manual, distributed on either a floppy disk or a USB stick.

Wrapping up

I hope this gives you a good idea of what the game is about and what to expect. I’m not ready for full disclosure yet, but I’ll be sharing more details in future posts and I will also dive into a lot of the technical details, so stay tuned! I really want to share much more (honestly, it’s quite difficult to hold back with all this enthusiasm), but I have to be sensible about it, because I don’t want to spoil the fun and leave some room for surprises when the game is finally released.

Up next

Continue reading with the next post: Technical design

Footnotes

What am I using AI for?

• I am using AI to check the grammar of my texts.
• I am using AI to help me find bugs or issues in my code.
• I am using AI to help me find potential optimizations in my code.
• I am using AI to generate small fragments of auto-completed code (e.g., small loops).
• I am using AI to generate scripts ¹.
• I am using AI to help me reason about complex problems.

What am I not using AI for?

• I am not using AI to write entire paragraphs of text.
• I am not using AI to write entire sections of code.
• I am not using AI to generate any creative content ².

Why?

I think that AI (LLMs in particular) is a great invention but also one that is broadly misunderstood. Like with any advanced technology, some understanding is required to be able to properly judge it, and LLMs are not easy to understand on a technical level.

Let me make a one-time exception to my rule of not writing entire paragraphs of text and ask Copilot to write a short explanation of how LLMs work:

At a basic level, LLMs are just a very powerful autocomplete system. They are trained on a large amount of data and learn to predict the next word in a sentence based on the previous words. This is why they can generate coherent and fluent text, but it also means that they don’t have any understanding of the world or the meaning of the words they are generating.

One particular problem with this is that users are often presented with output that sounds very confident and convincing while it may be completely wrong. If the user then corrects the LLM, it often accepts the correction without any question, even if the correction is actually wrong. The LLM simply has no means of properly judging the quality of its output.

If you’re not an expert in a particular topic, it can be very difficult to judge the quality of the output and you might end up trusting it too much.

I do think that AI can be very helpful, however. But more often, it has sent me onto the wrong track, so I have to be careful about when to employ it; otherwise, I lose more time than I gain. But admittedly, it has helped me find a few very nasty bugs in my code over time, so there’s definitely some value in it.

Finally, let’s talk about AI-generated creative content. While I was impressed at first, I now often have strong uncanny feelings whenever I see AI-generated content. I’m not sure where this is going, but I think human creativity cannot and should not be replaced by AI, unless it wasn’t creative in the first place. This leaves the question of what creativity actually is, but that’s a topic for another day.

Up next

Continue reading with the next post: Game concept

Footnotes

Personal history

Let’s start with a bit of personal history from the late 80s and early 90s. When I was a 13-year-old kid, my dad bought me an Atari ST 520+ (which had 1MB of RAM, as the ‘+’ sign designates) and a monochrome monitor (SM124) — thanks, Dad. I’m still grateful; you changed my life!

His primary motivation was the ST’s MIDI capabilities, since I already had a MIDI-compatible synthesizer. I had a lot of fun with it and did quite a lot of MIDI sequencing with Cubase.

Of course, I was also interested in games, but most games required a color monitor, which I didn’t have. I did play some games on the monochrome monitor, but most ‘serious’ games didn’t support it. It wasn’t until a few years later that I got a color monitor and could finally play the games I wanted to play.

When I got the ST, I already had a few years of experience with Basic programming on my trusty 8-bit Sharp MZ-800. Naturally, I started writing GFA-Basic programs on the ST.

My best friend Roberto, who turned out to have an incredible talent for pixel art drawing and music composition, bought an ST as well and soon we started making stuff together.

One of our fields of interest was game development. Like many kids (I presume), we dreamt of making our own games. We made some attempts at writing games in Basic/STOS, but we quickly realized that the performance of Basic was not good enough for the kind of games we wanted to make. Still, it was great fun and also a very educational process.

Some of the games we were particularly inspired by were the shoot ‘em up games like Xenon I and Xenon II. I knew I had to learn assembly programming to achieve the performance we needed for a game similar to Xenon, but it took a year or two before I finally started learning it. One other motivation was that we wanted to start making demos.

Roberto (rear) and I (front) playing Starglider 2 sometime around 1990

Later, we visited a few notable demo parties, among them a Sentry party in Breda, the Netherlands, and Fried Bits in Bremen, Germany. We made some great friends in the scene, some of whom we still keep in touch with today.

I (black t-shirt, center, standing) and Roberto (white t-shirt, center, standing) at a Sentry party around 1992

We used a few crew names over the years and we were also prone to changing our names, but at one point our crew name was Odyssey and we called ourselves Vulture (me) and Digital Coolness (Roberto).

The Odyssey logo

This ultimately culminated in us creating the Symbiosis guest screen (YouTube video) for the famous Synergy Megademo. We’re still proud of this screen and very honored to have been asked by the Synergy people to contribute to their megademo, which is one of the most famous Atari ST demos of all time. The code and graphics were all done by us, the fabulous music was composed by Scavenger from Synergy.

Later, we changed our crew name to Dawn and our names to Zeme (I) and ManTra (Roberto), and we still use those names today.

The game

Although we never got to finish a full game, the dream of making a game remained…

Let’s fast-forward to the (near) present. In May 2025, I couldn’t hold back anymore, now that I had finally managed to get hold of a proper m68k cross-compiler setup on my PC, thanks to Thorsten Otto’s m68k-atari-mint cross-tools.

I had been working on some small projects a few years earlier, using a native C compiler in an Atari ST emulator, but I have to say that it is a real pain to work that way, especially when you are used to modern development environments. I have a lot of respect for those who work that way, but I really prefer working on my PC and then testing the game in an emulator.

So, I got to work and started writing the game. At the time of writing, roughly nine months later, the game is in pretty decent shape, and most technical features are working well. What’s mainly missing is content.

I’m not ready to reveal all the details or what it looks (or sounds) like yet, but I will be sharing some interesting details now and then.

This blog

Because I’ve had to jump through quite a few hoops so far, I wanted to share some of the things I learned. In this blog, you can expect a few posts to appear in the coming months, covering technical details of the game, as well as the design process and the creative process in general. I will also share some of the challenges I faced and how I overcame them, as well as some of the things I wish I had known when I started.

If at any time you want to contact me, check the social links in the footer. Or leave a comment below!

Up next

Continue reading with the next post: AI Statement