Move a player onto a star. Hear a sound, see the count change, then restart. It is a small piece of play, but there is enough going on to answer a useful question: how do these routines fit together?
The five examples below keep that connection visible. Each has a complete caller and separate routines for input edges, bounded movement, box collision, drawing and sound. Start with one, run it, change it, and take the pieces that serve your game.
Choose your machine
| Example | Picture | Sound | Who keeps the frame clock? |
|---|---|---|---|
| C64 | Screen codes and colour RAM | SID voice with a frame-serviced gate | Main polls the raster |
| 48K Spectrum | Software glyphs in the bitmap | Brief CPU-driven beep | ROM IM1 service, outside the beep |
| A500 Amiga | CPU copies into one bitplane | Paula DMA sample with a frame-serviced stop | Main polls VERTB |
| NES | Nametable tiles during vblank | Pulse channel with a frame-serviced stop | NMI announces; main updates |
| BBC Model B | MOS cursor and text output | MOS SOUND queue | MOS retains its IRQ services |
These are deliberately modest rendering choices. They let us concentrate on how a sample of input becomes a change in the world and then a visible or audible result. Hardware sprites, richer software sprites and blitter work can replace the drawing part when they earn their place.
One update, several responsibilities
Wait → read → detect edges → service sound → update → draw. On the BBC, MOS services sound; the Spectrum’s short beep runs inside the collection event.
Holding a direction repeats movement at a chosen rate. Restart is a new-press action. Both use the same input sample, with separate decisions about what it means. Input edge detection explains the bit operation behind that distinction.
The update owns the rule that a star can be collected once. It clears item_active before requesting a sound. The renderer then sees the new state and leaves the star out. Sound and drawing do not get to award another point.
Give the routines a place to live
The caller establishes the machine. It allocates state, starts the clock and takes ownership of the resources it needs. Smaller routines can then make precise promises about what they read and change.
Each example shows where to include the code, how to initialise it and when to call it. The accompanying README names register effects, memory, hardware ownership and incompatible writers. Keep those agreements when combining a routine with code of your own.
The routines share a small scene, while their hardware interfaces remain explicit. For example, the Amiga reader keeps its native joystick bit layout; the NES caller maps controller bits into its local action layout. Those details are useful when you need to debug a real machine.
Let the limitation suggest the next step
The player occupies one cell and moves one cell at a time. A reusable box test handles contact; simple coordinate equality would also work for this exact scene. Larger or freely positioned objects give the box test more to do. A precise mask test can follow it when the contact shape matters enough to justify the extra code, data and runtime work.
Erasing with a blank works on this empty background. A map needs its underlying tile restored. Several overlapping objects need an agreed redraw order. The collision entry, fixed-point movement and machine rendering entries give those questions somewhere to go.
A short blocking beep is an understandable first sound routine. If it interrupts an action the player must control continuously, a shorter sound or a different implementation becomes valuable. A hardware sound channel can continue while the CPU works, but something still needs to decide its duration, retriggering and ownership.
Beyond these five
The capability inventory follows input, drawing and sound across the other 25 emulated configurations. It distinguishes blocking command input, sampled controls, text-cell drawing, actual graphics and sound output. A configuration without sound hardware is recorded explicitly.
That inventory supplies starting points for more library entries. Each new entry still needs an explanation and an integration contract that a reader can use. The loop comparison also covers games that advance by commands or timed turns.