Interrupts and Game Timing on the Tatung Einstein

1. Introduction

In earlier lessons we relied on delays and loops to control program flow and speed.
While this works for simple programs, it is not suitable for games.

Games require:

• Smooth, consistent movement
• Reliable animation speed
• Predictable timing, regardless of game complexity

On many systems this is achieved using hardware interrupts.
On the Tatung Einstein, however, reliable game timing requires a slightly different approach.

This lesson explains:

• What interrupts mean in game programming terms
• Why traditional interrupt based frame timing is unreliable on the Einstein
• How the Einstein actually signals video frames
• How to build a frame accurate game timer
• How to update game timers 50 times per second, aligned to screen frames

2. What an “Interrupt” Means in a Game

For a game programmer, an interrupt is not about background processes or multitasking.

In game terms, an interrupt simply means:

“A fixed moment in time when the game advances by one step.”

Ideally, this happens once per video frame.

That fixed step is often called:

• a frame tick
• a game tick
• or a game clock update

The important idea is fixed timing, not how the signal is generated.

3. Why Games Need Fixed Timing

If timing is controlled using delay loops:

• Game speed depends on how much code is running
• Adding enemies slows the game down
• Animation becomes uneven
• Gameplay feels wrong

Games solve this by separating:

• Time keeping
• Game logic

Once time is separated from logic, game speed becomes stable and predictable.

4. The Reality of Interrupts on the Tatung Einstein

4.1 The VDP Interrupt

The Einstein’s video chip does generate a vertical blank interrupt every frame (about 50 Hz).

However:

• This interrupt is handled internally by MOS
• User programs do not receive it directly
• Hooking IM 1 only gives a slow system tick (about 1 Hz)

So:

You cannot reliably hook a per frame VDP interrupt for games.

4.2 The CTC and IM 2

The Einstein includes a Zilog CTC, and the documentation describes IM 2 interrupt handling.

In theory this could be used for frame timing.

In practice:

• The CTC is not reliably wired to the VDP on all machines
• Behaviour varies by model, DOS version, and expansion hardware
• IM 2 interferes with MOS and often causes hangs or program exits
• Calling MOS from interrupt routines is unsafe

This makes IM 2 unsuitable for arcade game timing.

5. The Correct Mental Model for Games on the Einstein

Because reliable per frame interrupts are not available, Einstein games use a different but very effective technique:

Synchronise the main loop to the video frame using VDP polling.

This gives:

• Exactly one update per video frame
• Perfect 50 Hz timing
• No interrupt conflicts
• Deterministic behaviour

From a game logic point of view, this behaves exactly like an interrupt.

6. The Big Idea: Frame Based Game Timing

Key concept:

All game timing is based on counting frames.

There are no special hardware game timers.

Instead, timers are:

• Simple counters in memory
• Updated once per frame

One frame = one game tick.

7. Waiting for a Video Frame

The Einstein VDP status register contains a flag that changes once per frame.

By polling this flag, we can wait for the next vertical blank period.

This gives us perfect frame synchronisation.

8. Working Proof of Concept (Frame Aligned Game Timer)

The following program:

• Updates game logic 50 times per second
• Is aligned to screen frames
• Prints a * every 200 frames (about 4 seconds)
• Uses no interrupts
• Is safe and reliable

Frame aligned game timer PoC

‍

ORG     256

; -----
; START
; -----

START:
       LD      A,0
       LD      (FRAME_COUNTER),A

; --------------
; MAIN GAME LOOP
; --------------

MAIN:
       CALL    WAIT_FOR_FRAME   ; WAIT UNTIL ONE VIDEO FRAME HAS PASSED
       CALL    GAME_TICK        ; UPDATE GAME TIMERS ONCE
       JR      MAIN

; ----------------------
; WAIT FOR ONE VDP FRAME
; ----------------------

WAIT_FOR_FRAME:

WAIT_LOOP:
       IN      A,(9)            ; READ VDP STATUS PORT
       BIT     7,A              ; TEST VERTICAL BLANK FLAG
       JR      Z,WAIT_LOOP      ; LOOP UNTIL FLAG BECOMES SET

       IN      A,(9)            ; CLEAR THE FLAG
       RET

; -------------------------
; GAME TIMER UPDATE (50 HZ)
; -------------------------

GAME_TICK:
       LD      HL,FRAME_COUNTER
       INC     (HL)

       LD      A,(HL)
       CP      200              ; 200 FRAMES ≈ 4 SECONDS
       RET     NZ

       LD      A,0
       LD      (HL),A

       LD      A,42             ; ASCII CODE FOR '*'
       RST     8
       DEFB    158

       RET

; -------------
; FRAME COUNTER
; -------------

FRAME_COUNTER:
       DB      0

‍

‍

9. The Game Clock

The frame counter acts as the master game clock.

Example:

• 50 frames ≈ 1 second
• 200 frames ≈ 4 seconds

The clock never stops.
Everything else is timed relative to it.

10. Sprite and Animation Timers

Each game object gets its own timer:

PlayerAnimTimer   DB 0
EnemyAnimTimer    DB 0
BulletTimer       DB 0


Inside game_tick:

INC (PlayerAnimTimer)
INC (EnemyAnimTimer)
INC (BulletTimer)


Each timer now counts frames independently.

11. Using Timers in the Main Loop

The main loop reacts to timers reaching certain values.

Example: animate player every 8 frames.

LD A,(PlayerAnimTimer)
CP 8
JR C,NoAnim
XOR A
LD (PlayerAnimTimer),A
CALL AdvancePlayerAnimation
NoAnim:


This guarantees:

• Fixed animation speed
• No dependency on CPU load
• Smooth motion

12. Different Timers, Different Speeds

By choosing different limits:

Timer    Frames    Result
Player animation    8    Smooth walk
Enemy animation    16    Slower movement
Bullet movement    2    Fast motion
Game clock    50    One second

All updated once per frame.

13. Logical Interrupts vs Hardware Interrupts

Conceptually:

• game_tick is your interrupt
• It runs once per frame
• It updates all timing

Physically:

• It is called from the main loop
• Synchronised to the VDP

This is safer and more reliable than hardware interrupts on the Einstein.

14. What Should Run in the Frame Tick

Good frame tick tasks:

• Update timers
• Advance animations
• Update object positions
• Handle countdowns

Bad frame tick tasks:

• Blocking input
• Long calculations
• Disk access

Keep it deterministic and fast.

15. Putting It All Together

Think of the system like this:

Wait for frame
Update timers
Update game state
Draw frame
Repeat


Once this structure is in place:

• Game speed becomes stable
• Animation becomes smooth
• Code becomes easier to reason about

16. Summary

• Reliable per frame interrupts are not available to user code on the Einstein
• IM 2 and CTC interrupts are unreliable for games
• The correct approach is VDP frame polling
• One frame = one game tick
• Game timing is based on counting frames
• This approach is arcade accurate, stable, and proven

‍