Mode X Series on TurboVision

Mode X in Turbo Pascal, Part 1: Planar Memory and Pages

Sun, 22 Feb 2026 00:00:00 +0000

Mode 13h is the famous VGA “easy mode”: one byte per pixel, 320x200, 256 colors, linear memory. It is perfect for first experiments and still great for teaching rendering basics. But old DOS games that felt smoother than your own early experiments usually did not stop there. They switched to Mode X style layouts where planar memory, off-screen pages, and explicit register control gave better composition options and cleaner timing.

This first article in the series is about that mental model. Before writing sprite engines, tile systems, or palette tricks, you need to understand what the VGA memory controller is really doing. If the model is wrong, every optimization turns into folklore.

If you have not read Mode 13h Graphics in Turbo Pascal, do that first. It gives the baseline we are now deliberately leaving behind.

Why Mode X felt “faster” in real games

The practical advantage was not raw arithmetic speed. The advantage was control over layout and buffering:

You could keep multiple pages in video memory.
You could build into a hidden page and flip start address.
You could organize writes in ways that matched planar hardware better.
You could avoid tearing without full-frame copies every frame.

What looked like magic in magazines was mostly disciplined memory mapping plus stable frame pacing.

The key shift: from linear bytes to planes

In Mode X style operation, pixel bytes are distributed across four planes. Adjacent pixel columns are not consecutive memory bytes in the way Mode 13h beginners expect. Instead, pixel ownership rotates by plane. That means one memory offset can represent four neighboring pixels depending on which plane is currently enabled for writes.

The control knobs are VGA registers:

Sequencer map mask: choose writable plane(s).
Graphics controller read map select: choose readable plane.
CRTC start address: choose which memory area is currently displayed.

Once you accept that “address + selected plane = pixel target,” most confusing behavior suddenly becomes deterministic.

Entering a workable 320x240-like unchained setup

Many implementations start by setting BIOS mode 13h and then unchaining to get planar behavior while keeping convenient geometry assumptions. Exact register recipes vary by card and emulator, so treat this as a pattern, not sacred scripture.

procedure SetModeX;
begin
  asm
    mov ax, $0013
    int $10
  end;

  { Disable chain-4 and odd/even, enable all planes }
  Port[$3C4] := $04; Port[$3C5] := $06; { Memory Mode }
  Port[$3C4] := $02; Port[$3C5] := $0F; { Map Mask }

  { Graphics controller tweaks for unchained access }
  Port[$3CE] := $05; Port[$3CF] := $40;
  Port[$3CE] := $06; Port[$3CF] := $05;
end;

Do not panic if this looks low-level. Turbo Pascal is excellent at this style of direct hardware work because compile-run cycles are fast and failures are usually immediately observable.

Plotting one pixel with plane selection

A minimal pixel routine makes the model tangible. X chooses plane and byte offset; Y chooses row stride component.

procedure PutPixelX(X, Y: Integer; C: Byte);
var
  Offset: Word;
  PlaneMask: Byte;
begin
  Offset := (Y * 80) + (X shr 2);
  PlaneMask := 1 shl (X and 3);

  Port[$3C4] := $02;
  Port[$3C5] := PlaneMask;
  Mem[$A000:Offset] := C;
end;

The 80 stride comes from 320/4 bytes per row in planar addressing. That single number is where many beginner bugs hide, because linear assumptions die hard.

Pages and start address flipping

A stronger reason to adopt Mode X is page strategy. If your card memory budget allows it, maintain two or more page regions in VRAM. Render into non-visible page, then point CRTC start address at the finished page. That is cheaper and cleaner than copying full frames through CPU-visible loops every tick.

Conceptually:

displayPage is what CRTC shows.
drawPage is where your renderer writes.
End of frame: swap roles and update CRTC start.

The code details differ by implementation, but the discipline is universal: never draw directly into the page currently being scanned out unless you enjoy tear artifacts as design motif.

Practical debugging advice

When output is wrong, do not “optimize harder.” Validate one axis at a time:

Fill one plane with a color and confirm stripe pattern.
Write known values at fixed offsets and read back by plane.
Verify start-address page flip without any sprite code.
Only then add primitives and scene logic.

This sequence saves hours. Most graphics bugs in this phase are addressing bugs, not “algorithm bugs.”

Where we go next

In Part 2, we build practical drawing primitives (lines, rectangles, clipped blits) that respect planar layout instead of fighting it:

Mode X in Turbo Pascal, Part 2: Primitives and Clipping

Related context:

Mode X is not difficult because it is old. It is difficult because it requires a precise mental model. Once that model clicks, the hardware starts to feel less like a trap and more like an instrument.

Mode X in Turbo Pascal, Part 2: Primitives and Clipping

Sun, 22 Feb 2026 00:00:00 +0000

After the planar memory model clicks, the next trap is pretending linear drawing code can be “ported” to Mode X by changing one helper. That works for demos and fails for games. Robust Mode X rendering starts with primitives that are aware of planes, clipping, and page targets from day one.

If you missed the foundation, begin with Part 1: Planar Memory and Pages. This article assumes you already have working pixel output and page flipping.

Primitive design goals

For old DOS rendering pipelines, primitives should optimize for correctness first:

Never write outside page bounds.
Keep clipping deterministic and centralized.
Minimize per-pixel register churn where possible.
Separate addressing math from shape logic.

Performance matters, but undefined writes kill performance faster than any missing micro-optimization.

Clipping is policy, not an afterthought

A common beginner pattern is “draw first, check later.” On VGA memory that quickly becomes silent corruption. Instead, apply clipping at primitive boundaries before entering the hot loops.

For axis-aligned boxes, clipping is straightforward:

function ClipRect(var X1, Y1, X2, Y2: Integer): Boolean;
begin
  if X1 < 0 then X1 := 0;
  if Y1 < 0 then Y1 := 0;
  if X2 > 319 then X2 := 319;
  if Y2 > 199 then Y2 := 199;
  ClipRect := (X1 <= X2) and (Y1 <= Y2);
end;

Once clipped, your inner loop can stay simple and trustworthy. This is less glamorous than fancy blitters and infinitely more important.

Horizontal fills with reduced state changes

Naive pixel-by-pixel fills set map mask every write. Better approach: process spans in groups where plane mask pattern repeats predictably. Even a modest rework reduces I/O pressure.

procedure HLineX(X1, X2, Y: Integer; C: Byte);
var
  X: Integer;
begin
  if (Y < 0) or (Y > 199) then Exit;
  if X1 > X2 then begin X := X1; X1 := X2; X2 := X; end;
  if X1 < 0 then X1 := 0;
  if X2 > 319 then X2 := 319;

  for X := X1 to X2 do
    PutPixelX(X, Y, C);
end;

This still calls PutPixelX, but with clipping discipline built in. Later you can specialize spans and batch by plane.

Rectangle fills and UI panels

Old DOS interfaces often combine world rendering plus overlays. A clipped rectangle fill is the workhorse for panels, bars, and damage flashes.

procedure FillRectX(X1, Y1, X2, Y2: Integer; C: Byte);
var
  Y: Integer;
begin
  if not ClipRect(X1, Y1, X2, Y2) then Exit;
  for Y := Y1 to Y2 do
    HLineX(X1, X2, Y, C);
end;

It looks boring because good infrastructure often does. Boring primitives are stable primitives.

Line drawing without hidden chaos

For general lines, Bresenham remains practical. The Mode X-specific advice is to keep the stepping algorithm independent from memory layout and delegate write target handling to one consistent pixel primitive.

Why this matters: when bugs appear, you can isolate whether the issue is geometric stepping or planar addressing. Mixed concerns create mixed failures and bad debugging sessions.

Instrument your renderer early

Before moving to sprites, add a diagnostic frame:

draw clipped and unclipped test rectangles at edges
draw diagonal lines through all corners
render page index and frame counter
flash a corner pixel each frame

If this test scene is unstable, your game scene will be chaos with better art.

Structured pass order

A practical frame pipeline in Mode X might be:

clear draw page
draw background spans
draw world primitives
draw sprite layer placeholders
draw HUD rectangles/text
flip display page

This ordering gives deterministic overdraw and clear extension points for Part 3.

Cross-reference with existing DOS workflow

These graphics routines live inside the same operational reality as your boot and tooling discipline:

Old graphics programming is rarely “graphics only.” It is always an ecosystem of memory policy, startup profile, and debugging rhythm.

Next step

Part 3 moves from primitives to actual game-feeling output: masked sprites, palette cycling, and timing control:

Mode X in Turbo Pascal, Part 3: Sprites and Palette Cycling

Primitives are where reliability is born. If your clips are correct and your spans are deterministic, everything built above them gets cheaper to reason about.

One extra practice that helps immediately is recording a tiny “primitive conformance” script in your repo: expected screenshots or checksum-like pixel probes for a fixed test scene. Run it after every renderer change. In retro projects, visual regressions often creep in from seemingly unrelated optimizations, and this one habit catches them early.

Mode X in Turbo Pascal, Part 3: Sprites and Palette Cycling

Sun, 22 Feb 2026 00:00:00 +0000

Sprites are where a renderer starts to feel like a game engine. In Mode X, the challenge is not just drawing images quickly. The challenge is managing transparency, overlap order, and visual dynamism while staying within the strict memory and bandwidth constraints of VGA-era hardware.

If your primitives and clipping are not stable yet, go back to Part 2. Sprite bugs are hard enough without foundational uncertainty.

Sprite data strategy: keep it explicit

A reliable sprite pipeline separates three concerns:

Source pixel data.
Optional transparency mask.
Draw routine that respects clipping and planes.

Trying to “infer” transparency from arbitrary colors in ad-hoc code works until assets evolve. Use explicit conventions and document them in your asset converter notes.

Masked blit pattern

A classic masked blit uses one pass to preserve destination where mask says transparent, then overlays sprite pixels where opaque. In Turbo Pascal, even simple byte-level logic remains effective if your loops are predictable.

Pseudo-shape:

for sy := 0 to SpriteH - 1 do
  for sx := 0 to SpriteW - 1 do
    if Mask[sx, sy] <> 0 then
      PutPixelX(DstX + sx, DstY + sy, Sprite[sx, sy]);

You can optimize later with span-based opaque runs. First make it correct under clipping and page boundaries.

Clipping sprites without branching chaos

A practical trick: precompute clipped source and destination windows once per sprite draw call. Then inner loops run branch-light:

srcStartX/srcStartY
srcEndX/srcEndY
dstStartX/dstStartY

This keeps the “should I draw this pixel?” decision out of every iteration and dramatically reduces bug surface.

Draw order as policy

In old-school 2D engines, z-order usually means “draw in sorted sequence.” Keep that sequence explicit:

background
terrain decals
actors
projectiles
effects
HUD

When overlap glitches appear, deterministic order lets you debug with confidence instead of guessing whether timing or memory corruption is involved.

Palette cycling: cheap motion, strong mood

Palette tricks are one of the most useful VGA-era superpowers. Instead of rewriting pixel memory, rotate a subset of palette entries and let existing pixels “animate” automatically. Water shimmer, terminal glow, warning lights, and magic effects become nearly free per frame.

procedure RotatePaletteRange(FirstIdx, LastIdx: Byte);
var
  TmpR, TmpG, TmpB: Byte;
  I: Integer;
begin
  { Assume Palette[] holds RGB triples in 0..63 VGA range }
  TmpR := Palette[LastIdx].R;
  TmpG := Palette[LastIdx].G;
  TmpB := Palette[LastIdx].B;
  for I := LastIdx downto FirstIdx + 1 do
    Palette[I] := Palette[I - 1];
  Palette[FirstIdx].R := TmpR;
  Palette[FirstIdx].G := TmpG;
  Palette[FirstIdx].B := TmpB;
  ApplyPaletteRange(FirstIdx, LastIdx);
end;

The artistic rule is simple: reserve palette bands intentionally. If artists and programmers share the same palette map vocabulary, effects stay predictable.

Timing: lock behavior before optimization

Animation quality depends more on frame pacing than raw speed. Old DOS projects often tied simulation to variable frame rate and then fought phantom bugs for weeks. Better pattern:

fixed simulation tick (e.g., 70 Hz or 60 Hz equivalent)
render as often as practical
interpolate only when necessary

Even on retro hardware, disciplined timing produces smoother perceived motion than occasional fast spikes.

Debug overlays save projects

Add optional overlays you can toggle with a key:

sprite bounding boxes
clip rectangles
page index
tick/frame counters
palette band IDs

These overlays are not “debug clutter.” They are observability for graphics systems that otherwise fail visually without explanation.

Cross references that help this stage

Each one contributes a different layer: memory model, primitive discipline, and workflow habits.

Part 4 moves to tilemaps, camera movement, and data streaming from disk into playable scenes:

Mode X in Turbo Pascal, Part 4: Tilemaps and Streaming

Sprites make a renderer feel alive. Palette cycling makes it feel alive on a budget. Together they are a practical lesson in constraint-driven expressiveness.

If you maintain this code over time, keep a small palette allocation map next to your asset pipeline notes. Which index bands are reserved for UI, which are cycle-safe, which are gameplay-critical. Teams that write this down once avoid months of accidental palette collisions later.

Mode X in Turbo Pascal, Part 4: Tilemaps and Streaming

Sun, 22 Feb 2026 00:00:00 +0000

A renderer becomes a game when it can show world-scale structure, not just local effects. That means tilemaps, camera movement, and disciplined data loading. In Mode X-era development, these systems were not optional polish. They were the only way to present rich scenes inside strict memory budgets.

This final Mode X article focuses on operational structure: how to build scenes that scroll smoothly, load predictably, and remain debuggable.

Start with memory budget, not features

Before defining map format, set your memory envelope:

available conventional/extended memory
VRAM page layout
sprite and tile cache size
IO buffer size

Then derive map chunk dimensions from those limits. Teams that reverse the order usually rewrite their map loader halfway through the project.

Tilemap schema that survives growth

A practical map record often includes:

tile index grid (primary layer)
collision flags
optional overlay/effect layer
spawn metadata
trigger markers

Keep versioning in the file header. Old DOS projects often outlived their first map format and paid dearly for “quick binary dumps” with no compatibility markers.

type
  TMapHeader = record
    Magic: array[0..3] of Char;  { 'MAPX' }
    Version: Word;
    Width, Height: Word;         { in tiles }
    TileW, TileH: Byte;
    LayerCount: Byte;
  end;

Version fields are boring until you need to load yesterday’s assets under today’s executable.

Camera math and draw windows

For each frame:

determine camera pixel position
convert to tile-space window
draw only visible tile rectangle plus one-tile margin

The one-tile margin prevents edge pop during sub-tile movement. Combine this with clipped blits from Part 2 and you get stable scrolling without full-map redraw.

Chunked streaming from disk

Large maps should be chunked. Load around camera, evict far chunks, keep hot set warm.

A simple policy works well:

chunk size fixed (for example 32x32 tiles)
maintain 3x3 chunk neighborhood around camera chunk
prefetch movement direction neighbor

This is not overengineering. On slow storage, missing prefetch translates directly into visible hitching.

Keep IO deterministic

Disk access must avoid unpredictable burst behavior during input-critical moments. Two rules help:

schedule loads at known frame points (post-render or pre-update)
cap max bytes read per frame under stress

When a chunk is not ready, prefer visual fallback tile over frame stall. Small visual degradation is often less disruptive than control latency spikes.

Practical cache keys

Use integer chunk coordinates as cache keys. String keys are unnecessary overhead in this environment and complicate diagnostics.

type
  TChunkKey = record
    CX, CY: SmallInt;
  end;

Pair keys with explicit state flags: Absent, Loading, Ready, Dirty. State clarity is more important than clever container choice.

HUD and world composition

Render world layers first, then entities, then HUD into same draw page. Keep HUD draw routines independent from camera transforms. Many old engines leaked camera offsets into UI code and carried that bug tax for years.

You can validate this quickly by forcing camera to extreme coordinates and checking whether UI still anchors correctly.

Failure modes to test intentionally

Test these early, not at content freeze:

camera crossing chunk boundaries repeatedly
high-speed movement through dense trigger zones
partial chunk read failure
map version mismatch
missing tile index fallback path

Each one should degrade gracefully with explicit logging. Silent corruption is far worse than a visible placeholder tile.

Cross references for full pipeline context

These pieces together describe not just rendering, but operation: startup profile, page policy, draw order, and asset logistics.

Closing note on Mode X projects

Mode X is often presented as nostalgic low-level craft. It is also a great systems-design classroom. You learn cache boundaries, streaming policies, deterministic updates, and diagnostic overlays in an environment where consequences are immediate.

If this series worked, you now have a path from first pixel to world-scale scene architecture:

memory model
primitives
sprites and timing
streaming and camera

That sequence is still useful on modern engines. The APIs changed. The discipline did not.

Treat your map format docs as part of runtime code quality. A map pipeline without explicit contracts eventually becomes an incident response problem.

Mode X Series on TurboVision

Mode X in Turbo Pascal, Part 1: Planar Memory and Pages

Why Mode X felt “faster” in real games

The key shift: from linear bytes to planes

Entering a workable 320x240-like unchained setup

Plotting one pixel with plane selection

Pages and start address flipping

Practical debugging advice

Where we go next

Mode X in Turbo Pascal, Part 2: Primitives and Clipping

Primitive design goals

Clipping is policy, not an afterthought

Horizontal fills with reduced state changes

Rectangle fills and UI panels

Line drawing without hidden chaos

Instrument your renderer early

Structured pass order

Cross-reference with existing DOS workflow

Next step

Mode X in Turbo Pascal, Part 3: Sprites and Palette Cycling

Sprite data strategy: keep it explicit

Masked blit pattern

Clipping sprites without branching chaos

Draw order as policy

Palette cycling: cheap motion, strong mood

Timing: lock behavior before optimization

Debug overlays save projects

Cross references that help this stage

Next article

Mode X in Turbo Pascal, Part 4: Tilemaps and Streaming

Start with memory budget, not features

Tilemap schema that survives growth

Camera math and draw windows

Chunked streaming from disk

Keep IO deterministic

Practical cache keys

HUD and world composition

Failure modes to test intentionally

Cross references for full pipeline context

Closing note on Mode X projects