Tutorial on TurboVision

Turbo Pascal BGI Tutorial: Dynamic Drivers, Linked Drivers, and Diagnostic Harnesses

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

This tutorial gives you a practical BGI workflow that survives deployment:

dynamic driver loading from filesystem
linked-driver strategy for lower runtime dependency risk
a minimal diagnostics harness for startup failures

Preflight: what you need

Turbo Pascal / Borland Pascal environment with Graph unit
one known-good BGI driver set and required .CHR fonts
a test machine/profile where paths are not identical to dev directories

TP5 baseline reminder:

compile needs GRAPH.TPU
runtime needs .BGI drivers
stroked fonts need .CHR files

Step 1: dynamic loading baseline

Create BGITEST.PAS:

program BgiTest;

uses
  Graph, Crt;

var
  gd, gm, gr: Integer;

begin
  gd := Detect;
  InitGraph(gd, gm, '.\BGI');
  gr := GraphResult;
  Writeln('Driver=', gd, ' Mode=', gm, ' GraphResult=', gr);
  if gr <> grOk then
    Halt(1);

  SetColor(15);
  OutTextXY(8, 8, 'BGI OK');
  Rectangle(20, 20, 200, 120);
  ReadKey;
  CloseGraph;
end.

Expected outcome:

with correct path/assets: startup succeeds and simple frame draws
with missing assets: GraphResult indicates error and program exits cleanly

Important TP5 behavior: GraphResult resets to zero after being called. Always store it to a variable once, then evaluate that value.

Path behavior detail: if InitGraph(..., PathToDriver) gets an empty path, the driver files must be in the current directory.

Step 2: deployment discipline for dynamic model

Package checklist:

executable
all required .BGI files for target adapters
all required .CHR fonts
documented runtime path policy

Most “BGI bugs” are missing files or wrong path assumptions.

Step 3: linked-driver strategy (when you need robustness)

Some Borland-era setups support converting/linking BGI driver binaries into object modules and registering them before InitGraph (for example through RegisterBGIdriver and related registration APIs).

General workflow:

run BINOBJ on .BGI file(s) to get .OBJ
link .OBJ file(s) into program
call RegisterBGIdriver before InitGraph
call InitGraph and verify GraphResult

Why teams did this:

fewer runtime file dependencies
simpler deployment to constrained/chaotic DOS installations

Tradeoff:

larger executable and tighter build coupling

Ordering constraint from TP5 docs: calling RegisterBGIdriver after graphics are already active yields grError (-11).

If you use InstallUserDriver with an autodetect callback, TP5 expects that callback to be a FAR-call function with no parameters returning an integer mode or grError.

Step 4: diagnostics harness you should keep forever

Keep a dedicated harness separate from game/app engine:

prints detected driver/mode and GraphResult
renders one line, one rectangle, one text string
exits on keypress

This lets you quickly answer: “is graphics stack alive?” before debugging your full renderer.

Add one negative test here too: intentionally pass wrong mode for a known driver and verify expected grInvalidMode (-10).

Step 5: test matrix (predict first, then run)

Define expected outcomes before running each case:

correct BGI path
missing driver file
missing font file
wrong current directory
TSR-heavy memory profile

For each case, record:

startup status
exact error code/output
whether fallback path triggers correctly

Recommended TP5 error codes to classify in logs:

grNotDetected (-2)
grFileNotFound (-3)
grInvalidDriver (-4)
grNoLoadMem (-5)
grFontNotFound (-8)
grNoFontMem (-9)
grInvalidMode (-10)

Step 6: fallback policy for production-ish DOS apps

Never rely on detect-only logic without fallback:

try preferred mode
fallback to known-safe mode
print actionable error if both fail

A black screen is a product bug, even in retro projects.

About creating custom BGI drivers

Writing full custom BGI drivers is advanced and depends on ABI/tooling details that are often version-specific and poorly documented. Practical teams usually ship stock drivers (dynamic or linked) unless there is a hard requirement for new hardware support.

If you must go custom, treat it as a separate reverse-engineering project with its own test harnesses and compatibility matrix.

Integration notes with overlays and memory strategy

If graphics startup becomes unstable after enabling overlays:

verify overlay initialization order
verify memory headroom before InitGraph
test graphics harness independently from overlayed application paths

This avoids mixing two failure domains during triage.

Memory interaction note from TP5 docs:

Graph allocates heap memory for graphics buffer/driver/font paths
OvrSetBuf also reshapes memory by shrinking heap
call order matters (OvrSetBuf before InitGraph when both are used)

Related reading:

Turbo Pascal Overlay Tutorial: Build, Package, and Debug an OVR Application

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

This tutorial is intentionally practical. You will build a small Turbo Pascal program with one resident path and one overlayed path, then test deployment and failure behavior.

If your install names/options differ, keep the process and adapt the exact menu or command names.

Goal and expected outcomes

Goal: move a cold code path out of always-resident memory and verify it loads on demand from .OVR.

Expected outcomes before you start:

build output includes both .EXE and .OVR
startup succeeds only when overlay initialization succeeds
cold feature call has first-hit latency and warm-hit improvement
removing .OVR produces controlled error path, not random crash

Minimal project layout

OVRDEMO/
  MAIN.PAS
  REPORTS.PAS
  BUILD.BAT

Step 1: write resident core and cold module

REPORTS.PAS (cold path candidate):

{$O+}  { TP5 requirement: unit may be overlaid }
{$F+}  { TP5 requirement for safe calls in overlaid programs }
unit Reports;

interface
procedure RunMonthlyReport;

implementation

procedure RunMonthlyReport;
var
  I: Integer;
  S: LongInt;
begin
  S := 0;
  for I := 1 to 25000 do
    S := S + I;
end;

end.

MAIN.PAS:

program OvrDemo;
{$F+}  { TP5: use FAR call model in non-overlaid code as well }
{$O+}  { keep overlay directives enabled in this module }

uses
  Overlay, Crt, Dos, Reports;
{$O Reports}  { select this used unit for overlay linking }

var
  Ch: Char;
  ExeDir, ExeName, ExeExt: PathStr;
  OvrFile: PathStr;

procedure InitOverlays;
begin
  FSplit(ParamStr(0), ExeDir, ExeName, ExeExt);
  OvrFile := ExeDir + ExeName + '.OVR';
  OvrInit(OvrFile);
  if OvrResult <> ovrOk then
  begin
    Writeln('Overlay init failed for ', OvrFile, ', code=', OvrResult);
    Halt(1);
  end;
  OvrSetBuf(60000);
end;

begin
  InitOverlays;
  Writeln('Press R to run report, ESC to exit');
  repeat
    Ch := ReadKey;
    case UpCase(Ch) of
      'R':
        begin
          Writeln('Running report...');
          RunMonthlyReport;
          Writeln('Done.');
        end;
    end;
  until Ch = #27;
end.

Step 2: enable overlay policy

Overlay output is not triggered by uses Overlay alone. You need both:

mark unit as overlay-eligible at compile time
select unit for overlaying from the main program

For Turbo Pascal 5.0 (per Reference Guide), these are hard rules:

all overlaid units must be compiled with {$O+}
active call chain must use FAR call model in overlaid programs
practical safe pattern: {$O+,F+} in overlaid units, {$F+} in other units and main
{$O UnitName} must appear after uses
uses must name Overlay before any overlaid unit
build must be to disk (not memory)

The full REPORTS.PAS and MAIN.PAS examples above include these directives directly.

Why `{$O+}` exists (TP5 technical reason)

In TP5, {$O+} is not just a “permission bit” for overlaying. It also changes code generation for calls between overlaid units to keep parameter pointers safe.

Classic hazard:

caller unit passes pointer to a code-segment-based constant (for example a string/set constant)
callee is in another overlaid unit
overlay swap can overwrite caller code segment region
raw pointer becomes invalid

TP5 {$O+}-aware code generation mitigates this by copying such constants into stack temporaries before passing pointers in overlaid-to-overlaid scenarios.

Typical source-level shape:

In REPORTS.PAS:

{$O+}  { TP5 mandatory for overlaid units }
{$F+}  { TP5 FAR-call requirement }
unit Reports;
...

In MAIN.PAS:

program OvrDemo;
uses Overlay, Crt, Dos, Reports;
{$O Reports}  { overlay unit-name directive: mark Reports for overlay link }

Without the unit-name selection ({$O Reports} or equivalent IDE setting), the unit can stay fully linked into the EXE even if {$O+} is present.

TP5 constraint from the same documentation set: among standard units, only Dos is overlayable; System, Overlay, Crt, Graph, Turbo3, and Graph3 cannot be overlaid.

Step 2.5: when the `.OVR` file is actually created

This is the key technical point that is often misunderstood:

REPORTS.PAS compiles to REPORTS.TPU (unit artifact).
MAIN.PAS is compiled and then linked with all used units.
During link, overlay-managed code is split out and written to one overlay file.

So .OVR is a link-time output, not a unit-compile output.

How code is selected into `.OVR`

Selection is not by “file extension magic” and not by uses Overlay. The link pipeline does this:

mark used code blocks from reachable entry points
check units marked for overlaying (via overlay unit-name directive/options)
for callable routines in those units, emit call stubs in EXE and write overlayed code blocks to .OVR

So:

unused routines can be omitted entirely
selected routines from one or more units can end up in the same .OVR
unit selection is explicit, routine placement is linker-driven from that set

Naming rule

The overlay file is tied to the final executable base name, not to a single unit.

compile/link target MAIN.EXE -> overlay file MAIN.OVR
compile/link target APP.EXE -> overlay file APP.OVR

It is not REPORTS.OVR just because Reports contains overlayed routines. One executable can include overlayed code from multiple units, and they are packed into that executable’s single overlay payload.

When `.OVR` may not appear

If no code is actually emitted as overlayed in the final link result, no .OVR file is produced. In that case, check project options/directives first.

Step 3: build and verify artifacts

Build with your normal tool path (IDE or CLI). After successful build:

verify your output executable exists (for example MAIN.EXE if compiling MAIN.PAS)
verify matching overlay file exists with the same base name (for example MAIN.OVR)
record file sizes and timestamp

If .OVR is missing, your overlay profile is not active.

Step 4: runtime tests

Test A - healthy run

Expected:

startup prints no overlay error
first R call may be slower
repeated R calls are often faster (buffer reuse)

Test B - missing OVR

Temporarily rename the generated overlay file (for example MAIN.OVR).

Expected:

startup exits with explicit overlay init error
no undefined behavior

If it crashes instead, fix error handling before continuing.

Step 4.5: initialization variants (`OvrInit`, `OvrInitEMS`, `OvrSetBuf`)

Minimal initialization:

OvrInit(OvrFile);

If initialization fails and you still call an overlaid routine, TP5 behavior is runtime failure (the reference guide calls out runtime error 208).

OvrInit practical lookup behavior (TP5): if OvrFile has no drive/path, the manager searches current directory, then EXE directory (DOS 3.x), then PATH.

OvrInit result handling (OvrResult):

ovrOk: initialized
ovrNotFound: overlay file not found
ovrError: invalid overlay format or program has no overlays

EMS-assisted initialization:

OvrInit(OvrFile);
OvrInitEMS;

OvrInitEMS can move overlay backing storage to EMS (when available), but execution still requires copying overlays into the normal-memory overlay buffer.

OvrInitEMS result handling (OvrResult):

ovrOk: overlays loaded into EMS
ovrIOError: read error while loading overlay file
ovrNoEMSDriver: no EMS driver detected
ovrNoEMSMemory: insufficient free EMS

On OvrInitEMS errors, overlay manager still runs from disk-backed loading.

Buffer sizing:

TP5 starts with a minimal overlay buffer (large enough for largest overlay).
For cross-calling overlay groups, this can cause excessive swapping.
OvrSetBuf increases buffer by shrinking heap.
legal range (TP5): BufSize >= initial and BufSize <= MemAvail + OvrGetBuf
if you increase buffer, adjust {$M ...} heap minimum accordingly

Important ordering rule (TP5): call OvrSetBuf while heap is effectively empty. If using Graph, call OvrSetBuf before InitGraph, because InitGraph allocates heap memory and can prevent buffer growth.

Step 5: tune overlay buffer with measurement

Run the same interaction script while changing OvrSetBuf:

small buffer (for example 16K)
medium buffer (for example 32K)
larger buffer (for example 60K)

Expected pattern:

too small: frequent reload stalls
too large: less stall, but memory pressure elsewhere

Choose by measured latency and memory headroom, not by guess.

Step 6: boundary correction when overlay thrashes

If one action triggers repeated slowdowns:

move shared helpers from overlay unit to resident unit
keep deep cold logic in overlay unit
reduce cross-calls between overlay units

Overlay design is call-graph design.

Troubleshooting matrix

Symptom: unresolved symbol at link

check unit/object participation in link graph
check far/near and declaration compatibility

Symptom: startup overlay error

check .OVR filename/path assumptions
check deployment directory, not just dev directory

Symptom: intermittent slowdown

profile call path for overlay churn
increase buffer or move hot helpers resident

What this tutorial teaches beyond overlays

You practice four skills that transfer everywhere:

define expected behavior before test
verify artifact set before runtime
isolate runtime dependencies explicitly
tune with measured data, not assumptions

Related reading:

Hand-Soldering 0402 Components

Sun, 28 Dec 2025 00:00:00 +0000

0402 passives measure 1.0 × 0.5 mm. They’re barely visible to the naked eye, yet hand-soldering them is doable with the right technique: flux, a fine conical tip, thin solder wire, and patience.

The key is to tin one pad first, tack the component down, then solder the other side. A stereo microscope helps but isn’t strictly necessary if you have good lighting and steady hands.

What usually fails is not dexterity, but process order. If you approach 0402 work like through-hole soldering, parts tombstone, slide, or disappear into the carpet. If you stage the work correctly, the joints become boringly repeatable.

Workflow that keeps rework low

Clean pads with isopropyl alcohol.
Add liquid flux before touching solder.
Pre-tin exactly one pad with a tiny amount.
Hold the part with tweezers, reflow that pad, and “tack” alignment.
Solder the second pad with minimal dwell time.
Revisit the first pad only if wetting looks poor.

The microscope is optional, but magnification changes quality control. Even a cheap USB scope catches bridges and cold joints before power-on.

Common mistakes

Too much solder: creates hidden bridges under the body.
Too little flux: oxidized pads and grainy joints.
Too much heat: lifted pads, especially on cheap proto boards.
Mechanical pressure while heating: parts shoot away or skew.

My rule is simple: if the joint takes more than a few seconds, stop, re-flux, and try again. Fighting a dry joint with temperature only makes damage faster.

Related reading:

Buffer Overflow 101

Mon, 03 Nov 2025 00:00:00 +0000

A stack-based buffer overflow is the oldest trick in the book and still one of the most instructive. We start with a vulnerable C program, compile it without canaries, and walk through EIP control step by step.

The target binary accepts user input via gets() — a function so dangerous that modern compilers emit a warning just for including it. We feed it a carefully crafted payload: 64 bytes of padding, followed by the address of our shellcode sitting on the stack.

Key takeaways: always compile test binaries with -fno-stack-protector -z execstack when learning, and never on a production box.

What makes this topic timeless is not the exact exploit recipe, but the mental model it gives you: memory layout, calling convention, control-flow integrity, and why unsafe copy primitives are dangerous by construction.

Reliable lab workflow

Confirm binary protections (checksec style checks).
Crash with pattern input to find exact overwrite offset.
Validate instruction pointer control with marker values.
Build payload in small increments and verify each stage.
Only then attempt shellcode or return-oriented payloads.

Expected outcome before each run should be explicit. If behavior differs, do not “try random bytes”; explain the difference first. That habit turns exploit practice into engineering instead of cargo cult.

Defensive mirror

Learning offensive mechanics should immediately map to mitigation:

remove dangerous APIs (gets, unchecked strcpy)
enable stack canaries, NX, PIE, and RELRO
reduce attack surface in parser and input-heavy code paths
test with sanitizers during development

Related reading:

AVR Bare-Metal Blinking

Wed, 20 Aug 2025 00:00:00 +0000

No Arduino libraries. No HAL. Just registers.

An ATmega328P has DDRB, PORTB, and a 16-bit timer. We configure Timer1 in CTC mode with a 1 Hz compare match, toggle PB5 (the onboard LED pin) in the ISR, and end up with a binary that fits in 176 bytes. The Makefile uses avr-gcc and avrdude directly — no IDE required.

This exercise looks trivial, but it trains the exact muscle many developers skip: understanding cause and effect between register writes and hardware behavior. You do not “ask an API” to blink. You define direction bits, timer prescalers, compare values, and interrupt masks yourself.

Minimal mental model

DDRB configures PB5 as output.
TCCR1A/TCCR1B define timer mode and prescaler.
OCR1A sets compare threshold.
TIMSK1 enables compare interrupt.
ISR toggles PORTB bit for the LED.

When this chain is explicit, debugging gets faster. If timing is wrong, you inspect clock and prescaler. If the LED is dark, verify direction and pin. Each symptom maps to a small set of causes.

Why still do this in 2026

Bare-metal AVR is still a great teaching platform because feedback is fast and tooling is mature. You can compile, flash, and verify behavior in a few seconds, then iterate. Even if your production target is different, this discipline transfers directly to RISC-V, ARM, and RTOS-based projects.

Related reading:

Tutorial on TurboVision

Turbo Pascal BGI Tutorial: Dynamic Drivers, Linked Drivers, and Diagnostic Harnesses

Preflight: what you need

Step 1: dynamic loading baseline

Step 2: deployment discipline for dynamic model

Step 3: linked-driver strategy (when you need robustness)

Step 4: diagnostics harness you should keep forever

Step 5: test matrix (predict first, then run)

Step 6: fallback policy for production-ish DOS apps

About creating custom BGI drivers

Integration notes with overlays and memory strategy

Turbo Pascal Overlay Tutorial: Build, Package, and Debug an OVR Application

Goal and expected outcomes

Minimal project layout

Step 1: write resident core and cold module

Step 2: enable overlay policy

Why {$O+} exists (TP5 technical reason)

Step 2.5: when the .OVR file is actually created

How code is selected into .OVR

Naming rule

When .OVR may not appear

Step 3: build and verify artifacts

Step 4: runtime tests

Test A - healthy run

Test B - missing OVR

Step 4.5: initialization variants (OvrInit, OvrInitEMS, OvrSetBuf)

Step 5: tune overlay buffer with measurement

Step 6: boundary correction when overlay thrashes

Troubleshooting matrix

Symptom: unresolved symbol at link

Symptom: startup overlay error

Symptom: intermittent slowdown

What this tutorial teaches beyond overlays

Hand-Soldering 0402 Components

Workflow that keeps rework low

Common mistakes

Buffer Overflow 101

Reliable lab workflow

Defensive mirror

AVR Bare-Metal Blinking

Minimal mental model

Why still do this in 2026

Why `{$O+}` exists (TP5 technical reason)

Step 2.5: when the `.OVR` file is actually created

How code is selected into `.OVR`

When `.OVR` may not appear

Step 4.5: initialization variants (`OvrInit`, `OvrInitEMS`, `OvrSetBuf`)