Blog
Welcome to the Blog.
Mode X (TP) II: Primitives
2026-02-22
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.
For old DOS rendering pipelines, primitives should optimize for correctness first:
Performance matters, but undefined writes kill performance faster than any missing micro-optimization.
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. ... continue
Mode X (TP) I: Planar Memory
2026-02-22
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.
The practical advantage was not raw arithmetic speed. The advantage was control over layout and buffering:
What looked like magic in magazines was mostly disciplined memory mapping plus stable frame pacing. ... continue
Mode 13h in Turbo Pascal
2026-02-22
Turbo Pascal graphics programming is one of the cleanest ways to learn what a frame actually is. In modern stacks, rendering often passes through layers that hide timing, memory layout, and write costs. In DOS Mode 13h, almost nothing is hidden. You get 320x200, 256 colors, and a linear framebuffer at segment $A000. Every pixel you draw is your responsibility.
Mode 13h became a favorite because it removed complexity that earlier VGA modes imposed. No planar bit operations, no complicated bank switching for this resolution, and no mystery about where bytes go. Pixel (x, y) maps to offset y * 320 + x. That directness made it ideal for demos, games, and educational experiments. It rewarded people who could reason about memory as geometry.
A minimal setup in Turbo Pascal is refreshingly explicit: switch video mode via BIOS interrupt, get access to VGA memory, write bytes, wait for input, restore text mode. There is no rendering engine to configure. You control lifecycle directly. That means you also own failure states. Forget to restore mode and you leave the user in graphics. Corrupt memory and artifacts appear instantly.
Early experiments usually start with single-pixel writes and quickly hit performance limits. Calling a procedure per pixel is expressive but expensive. The first optimization lesson is batching and locality: draw contiguous spans, avoid repeated multiplies, precompute line offsets, and minimize branch-heavy inner loops. Mode 13h teaches a truth that still holds in GPU-heavy times: throughput loves predictable memory access.
Palette control is another powerful concept students often miss today. In 256-color mode, pixel values are indices, not direct RGB triples. By writing DAC registers, you can change global color mappings without touching framebuffer bytes. This enables palette cycling, day-night transitions, and cheap animation effects that look far richer than their computational cost. You are effectively animating interpretation, not data. ... continue
Interrupts as User Interface
2026-02-22
In modern systems, user interface usually means windows, widgets, and event loops. In classic DOS environments, the interface boundary often looked very different: software interrupts. INT calls were not only low-level plumbing; they were stable contracts that programs used as operating surfaces for display, input, disk services, time, and devices.
Thinking about interrupts as a user interface reveals why DOS programming felt both constrained and elegant. You were not calling giant frameworks. You were speaking a compact protocol: registers in, registers out, carry flag for status, documented side effects.
Take INT 21h, the core DOS service API. It offered file IO, process management, memory functions, and console interaction. A text tool could feel interactive and polished while relying entirely on these calls and a handful of conventions. The interface was narrow but predictable.
INT 10h for video and INT 16h for keyboard provided another layer. Combined, they formed a practical interaction stack:
That is a full UI model, just encoded in BIOS and DOS vectors instead of GUI widget trees. ... continue
CONFIG.SYS as Architecture
2026-02-22
In DOS culture, CONFIG.SYS is often remembered as a startup file full of cryptic lines. That memory is accurate and incomplete. In practice, CONFIG.SYS was architecture: a compact declaration of runtime policy, resource allocation, compatibility strategy, and operational profile.
Before your application loaded, your architecture was already making decisions:
The shape of your software experience depended on this pre-application contract.
Take a typical line like:
DOS=HIGH,UMB ... continue
C:\> After Midnight
2026-02-22
There is a particular blue that only old screens know how to make. Not sky blue, not electric blue, not any brand color from modern design systems. It is the blue of waiting, the blue of discipline, the blue of possibility. It is the blue that appears when a machine, after clearing its throat with a POST beep, hands you a bare prompt and says: now it is your turn.
C:\>
No dock, no notifications, no assistant bubble, no pretense of helping you think. Only an invitation and a challenge. The operating system has done almost nothing. You must do the rest.
This is not an article about nostalgia as decoration. It is about a working world that existed inside limits so hard they became architecture. A world where your startup sequence was a design document, your tools fit on a few floppies, your failures had names, and your victories often looked like reclaiming 37 kilobytes of conventional memory so a game or compiler could start. It is also a story, because DOS was never just a technical environment. It was a culture of rituals: boot rituals, backup rituals, anti-virus rituals, debugging rituals, and social rituals that happened in school labs, basements, bedrooms, and noisy clubs where people traded disks like rare books.
So let us spend one long night there. Let us walk into a fictional but faithful 1994 room that smells like warm plastic and printer paper. Let us build and run a complete DOS life from dusk to dawn. Every choice in this chronicle is plausible. Most of them were common. Some of them were mistakes. All of them are true to the era. ... continue
Benchmarking with a Stopwatch
2026-02-22
When people imagine benchmarking, they picture automated harnesses, high-resolution timers, and dashboards with percentile charts. Useful tools, absolutely. But many core lessons of performance engineering can be learned with much humbler methods, including one old trick from retro workflows: benchmarking with a stopwatch and disciplined procedure.
On vintage systems, instrumentation was often limited, intrusive, or unavailable. So users built practical measurement habits with what they had:
It sounds primitive until you realize it enforces the exact thing modern teams often skip: experimental discipline.
The first rule was baseline control. Before measuring anything, define the environment:
Without this, numbers are stories, not data. ... continue
Archive Discipline for the Floppy Era
2026-02-22
People remember floppy disks as inconvenience, but they were also a strict training ground for information discipline. Limited capacity, media fragility, and transfer friction forced users to become intentional about naming, versioning, verification, and recovery. Those habits remain useful even in cloud-heavy workflows.
A floppy-era archive was never just “copy files somewhere.” It was an operating procedure:
Each step existed because failure was common and expensive.
Naming conventions carried real weight. You could not hide disorder behind full-text search and huge storage. A good archive label included date, project, and version. A bad label produced weeks of confusion later. Many users adopted compact but expressive patterns like:
Crude by modern standards, but operationally effective. ... continue
The Cost of Unclear Interfaces
2026-02-22
Most teams think interface problems are technical. Sometimes they are. More often, they are social problems expressed through technical artifacts.
An interface is any boundary where one thing asks another thing to behave predictably. In code, that can be a function signature, an API schema, a queue contract, or a config file format. In teams, it can be a handoff checklist, an on-call escalation rule, or a release approval process. In both cases, the cost of ambiguity is delayed, compounding, and usually paid by someone who was not in the room when the ambiguity was created.
We notice unclear interfaces first as friction:
Each sentence sounds small. Together, they create reliability tax.
The dangerous part is that unclear interfaces rarely fail loudly at first. They degrade trust slowly. One team adds defensive checks “just in case.” Another adds retries to compensate for uncertain behavior. A third adds custom adapters to normalize inconsistent outputs. Soon, the architecture looks complicated, and everyone blames complexity. But complexity was often an adaptation to interface uncertainty. ... continue
Maintenance Is a Creative Act
2026-02-22
In software culture, novelty gets applause and maintenance gets scheduling leftovers. We celebrate launches, rewrites, and shiny architecture diagrams. We quietly postpone dependency cleanup, operational hardening, naming consistency, test stability, and documentation repair. Then we wonder why velocity decays.
This framing is wrong. Maintenance is not the opposite of creativity. Maintenance is applied creativity under constraints.
Creating something new from a blank page is one creative mode. Improving a living system without breaking commitments is another, often harder, mode. It demands understanding history, preserving intent, and evolving design with minimal collateral damage.
Good maintenance starts with respect for continuity. Existing systems encode decisions that may no longer be obvious but still matter. Some are outdated and should change. Some are hard-earned safeguards that protect production behavior. The maintainer’s job is to tell the difference.
That requires curiosity, not cynicism. “This code is ugly” is easy. “Why did this shape emerge, and what risks does it currently absorb?” is useful. ... continue