Thrust on the PicoComputer 3

Everything that made Thrust hard on a 6502 is something we can delete

Thrust is a small game with one big idea. The physics is a page of arithmetic on about a dozen variables. The terrain is two numbers per scanline. There are at most 32 objects and 32 particles in the world at once. What made it a technical showpiece in 1986 — XOR plotting, collision detection by self-modifying code, a 256-byte circular terrain window, Q7.8 fixed point — was all workaround for 32K of RAM and a 2 MHz CPU, and none of it needs to survive the port.

What does need to survive is the feel, and the feel is a table of constants. The thrust divisors, the two drag ratios, the tick gating, the rotation rate limit, the 32-entry elliptical angle tables: copy those exactly and the ship flies like the original whether the arithmetic underneath is fixed point or MMBasic floats. Per the house rule that interpreting dominates and the arithmetic is free, floats cost us nothing, so there is no argument for reproducing the fixed point.

What the PC3 gives us, measured

The reference point that matters: Chuckie Egg holds 30 fps with nine moving entities, a full-screen framebuffer copy every frame, and a HUD redraw. Thrust asks for more drawing and less logic.

Four subsystems, all documented

Kieran Connell's disassembly ships three technical references alongside the annotated 6502. They are unusually good — the physics one in particular reads like a design document rather than a transcription. Everything below is from them.

Where the disassembly's notes are wrong

The three reference documents are the best thing about that repository and they are what made this port cheap, but they are notes rather than a specification, and two claims in ship-physics.md do not match the 6502 beside them. Both were caught by reading the assembly when the behaviour looked odd, and both would have been silent bugs.

• "The result is negated (thrust opposes the facing direction)." It is not. The sequence after the shifts is AND #$01 / EOR #$FF / ADC #$01, which sign-extends the integer byte that the rotates have shifted the sign out of, and the accumulate is ADC. The table already points the way the ship flies: heading 0 is up and its Y entry is −2.5. Negating it drives the ship backwards.
• "Rotation rate: 3 out of 4 frames, ~8.4 steps/second at 50fps." Neither number is right. ship_input_rotate is exactly AND #$03 / BEQ return, so three frames in four — but the frame is 33.3 Hz, not 50, giving 25 steps a second and a full turn in 1.28 seconds.
• "50fps", in four separate places. The worst of the three, because everything else is expressed relative to it. draw_player_timed_to_vsync waits for the centisecond clock to reach 3, so the frame is 30 ms and the game runs at 33.3 Hz. Believing the notes made this port 1.5× too fast in every axis at once, which is hard to spot precisely because it is uniform: nothing looks wrong, the game is just unplayable.

The cave costs tens of fills a frame, not hundreds

The terrain is drawn as two solid masses with a gap. Drawn naively — one horizontal line per scanline per wall — a 240-row screen costs 240 draws a frame, which would be marginal. But the RLE the original uses is mostly long runs at a constant X, so consecutive scanlines share a wall position and collapse into one rectangle. Decoding all six levels and sliding a 120-scanline window down each of them gives the real cost. The top two thirds of every level is open sky at a constant X — one fill, and the player never flies up there — so "typical" below is the median taken over the cave alone:

So a typical frame is 13 to 56 BOX calls and the pathological frame — a long diagonal on level 5, where every scanline genuinely does differ — is 158. That is the number to size the budget against, and it is comfortably inside 33 ms if a BOX costs anything like what Chuckie Egg's drawing did. Spike 1 confirms it on the board before phase 3 starts.

Two consequences worth noticing. First, the whole bidirectional RLE decoder — four decoder triples, a circular window, forward and reverse step functions — exists only to fit 256 bytes. We decode each level once at load time into two arrays and throw all of it away. Second, because we hold the entire wall profile, terrain collision becomes a handful of array lookups instead of a side effect of XOR plotting.

Architecture

Coordinates: work in BBC world units throughout

The BBC's terrain unit is a byte column (4 pixels) wide and, at its half-resolution rendering, 2 pixel rows tall, on a display whose pixels are about 1.07× wider than tall. Keep the game's arithmetic in those units and map x_px = 4 × world_x, y_px = 2 × world_y and the original geometry comes back within 7%. This matters more than it sounds: the angle-to-force tables are deliberately elliptical (Y range ~5.0 against X ~2.5) to compensate for MODE 1's pixel aspect. Take those tables verbatim and the compensation is already correct. Substituting SIN/COS would throw it away.

Screen layout

The BBC play area is 288 × 146 pixels — a 2.1:1 letterbox once pixel aspect is applied. Our 320 × 240 square-pixel screen is 1.33:1, so a full-screen playfield would show roughly half as much again vertically and make the game easier. Recommendation: 320 × 176 playfield with a 64-row panel beneath it for fuel, score, lives and the shield indicator. That is 80 × 88 world units against the BBC's 72 × 73 — 11% wider and 20% taller. Tunable, and worth playing both before fixing.

Timing: one clock, and it is the BBC's 33.3 Hz

This section said 50 Hz until the game was playable enough to feel wrong. It is the most consequential correction in the port.

draw_player_timed_to_vsync does not wait for a vsync. It spins on OSWORD 1 until the BBC's centisecond clock reads 3 and then zeroes it, so a frame is 30 ms and the game runs at 33.3 Hz. level_tick_counter advances once per pass of tick_loop, and that counter is what gates the rotation, the six-in-sixteen force update and the tether torque — so every rate in the game is 33.3 Hz based, not 50.

So there is no accumulator and no second clock: pace to 30 ms, take one simulation step per frame, and every cadence falls out at the rate it had in 1986. The tick gating pattern survives because it is untouched.

Taking the disassembly's "50fps" at its word made the whole game half again too fast — gravity, thrust, turn rate, bullet speed, the pendulum and the countdown all 1.5× — which is exactly the sort of thing that reads as "this port is too hard" rather than as a bug.

Terrain rendering: run-merged solid fills, no scrolling primitive

SPRITE SCROLL is tempting but wrong here. It helps only when the exposed edge is cheap to fill, and Thrust's camera moves diagonally, so a 1-pixel horizontal scroll exposes a full-height strip that needs the same per-scanline work as a complete redraw. Redraw the visible window each frame from the decoded wall arrays, merging runs into BOX calls, into the framebuffer, then one FRAMEBUFFER COPY. This is the same pattern Chuckie Egg already runs at 30 fps, and the measurement above says it fits.

Ship: 17 pre-rotated sprites and the mirror bit

Generate all 17 shapes at build time from the disassembly's sprite data — its single-stream format, where $81-$FE encodes "end of row" and "first pixel of the next row" in one byte, is straightforward to decode in Python. Headings 17-31 are the mirror of 32−a, which the SPRITE SHOW rotation parameter gives us for free. Same gen_sprites.py pipeline as Chuckie Egg.

Objects as sprites, particles as pixels

Up to 32 objects per level (the table above shows 4 to 19 in practice) as sprite buffers, well inside MAXBLITBUF. The 32 particle slots — player bullets, hostile bullets, stars, debris — are single pixels; draw them straight into the framebuffer with PIXEL rather than paying sprite bookkeeping for them.

Collision: cheaper and better than the original

We cannot get collision free from XOR, and we do not want to. Ship against terrain becomes six or eight hull points tested against wallL() and wallR() at the ship's own scanlines — a handful of comparisons, and more robust than the original, which could only notice a collision on the frame after it happened. Bullets and objects use the sprite engine's collision or plain AABB.

The shield is not a shield

shield_tractor_pressed is one key doing one job. Holding it burns a unit of fuel a frame on two frames in four, draws the circle in place of the ship, and runs the engine — and that is the whole of it. There is no path in the 6502 where it stops plot_ship_collision_detected reaching destroy_player_ship, and sheild_tractor_flag is read in exactly one place, to choose the sprite. The bubble is the tractor field made visible, not armour; the name in the disassembly is the author’s reading of the picture. So it is implemented as what it is, which means it costs fuel and gives you a wider outline to catch the rock with.

What we deliberately do not port

Nine sound blocks, straight across

As with Chuckie Egg, the OSWORD &07 blocks are already in PLAY BBC SOUND's parameter order — channel word, amplitude, pitch, duration — so they transcribe rather than translate. Amplitudes 1-4 select the four envelopes; negative amplitudes are plain volumes.

The envelopes decode the same way. Envelope 1, the gun, is PLAY BBC ENVELOPE 1, 2, -5, -3, -5, 2, 3, 50, 126, -7, -7, -12, 126, 0; envelope 3, the explosion, is PLAY BBC ENVELOPE 3, 4, 0, 0, 0, 1, 1, 1, 126, -4, -2, -4, 126, 110; envelope 4, the hostile gun, is PLAY BBC ENVELOPE 4, 1, -1, -1, -1, 18, 18, 18, 50, -12, -12, -12, 110, 70.

Phases

What could go wrong

Data pipeline

Bas/thrust_tools/
    thrust.6502          the disassembly - fetched, NOT vendored
    thrustdata.py        shared reader, colours, geometry
    gen_terrain.py       six levels of RLE; --stats and --png
    gen_objects.py       object tables; --png, and the buried-fraction check
    gen_sprites.py       17 ship headings, pod, shield, nine object shapes
    gen_sound.py         4 envelopes + 9 blocks -> PLAY BBC
    out/                 generated .bas fragments and verification images
    thrust_code.bas      the game, without generated data     (phase 2 on)
    build.py             glue, writing ../thrust.bas          (phase 2 on)

One correction carried over from Chuckie Egg: build.py will write straight to Bas/thrust.bas. A build left sitting in the tools directory is a build nobody runs.

Sources

• kieranhj/thrust-disassembly — the annotated 6502, plus docs/ship-physics.md, docs/landscape-drawing.md and docs/sprite-drawing.md. Disassembly by Kieran HJ Connell, 2016; original notes by jms2; BeebDis by Phill Harvey-Smith; verified against BeebAsm by Rich Talbot-Watkins.
• JamesRandall/ts-thrust — a TypeScript recreation with its own specs directory; a useful second opinion where the disassembly is terse.
• AI Can't Recreate Thrust (But It Can Help You Understand It) — notes from that recreation.
• bbcmicro.co.uk: Thrust — playable in the browser, for screenshots and for settling arguments about feel.
• Wikipedia: Thrust — provenance; Jeremy C. Smith, Superior Software, 1986.
• docs/Elite_Port_Plan.html, Bas/chuckie_tools/, docs/PLAY_BBC_User_Manual.md — our own precedents.