Analysis model: gpt-5.5 xhigh

F40 Pursuit Simulator Loader by New York Crackers - Technical Dissection

F40 Pursuit Simulator Loader is a 12 July 1989 MS-DOS cracktro / loader by New York Crackers, also known as NYC. Demozoo credits JT, The Mad Scientist, and Phallix for code.

Release year: 1989

This pass is source-limited. Demozoo supplies the production metadata and a public screenshot, and it links a Defacto2 download/external record. The Defacto2 acquisition target returned a Cloudflare 403 challenge from this environment, so no archive directory, executable, batch file, text sidecar, or runtime bytes were acquired here.

The public frame contains no visible private distribution material, so the copied still is not redacted.

Sources

Demozoo production page: https://demozoo.org/productions/363161/
Demozoo New York Crackers group page: https://demozoo.org/groups/53704/
Demozoo original screenshot URL: https://media.demozoo.org/screens/o/64/6d/ebc1.354657.png
Defacto2 download acquisition target, Cloudflare-challenged from this environment: https://defacto2.net/d/ac3bce

Demozoo records:

Title:        F40 Pursuit Simulator Loader
Group:        New York Crackers
Type:         Cracktro
Platform:     MS-Dos
Released:     12 July 1989
Credits:      JT - Code
              The Mad Scientist - Code
              Phallix - Code

Visual References

Time	Still	What is happening
`00:00.000`		Public Demozoo still. The page shows a green `NYC` block logo, title/key prompt, motto box, course/route line art, small hardware/media and game-label boxes, and three text-face signatures.

Generated text-page layout map:

F40 Pursuit Simulator Loader 80x25 text-page layout map

Acquired Assets

The public screenshot is a 720x400 indexed PNG:

1519915b1d5fd9ba30a4d89c98029048ff1f16c3d6237f952b3c1d3c8a78c1ef  Demozoo original screenshot, held only in scratch
6b6ce567f3c4e3e1ef233fe126153b6198654df47d52e7788d48e0f27ebbbc4b  images/f40-pursuit-nyc-demozoo.png
82c00787a4ac754156d72397a9d79c3955257c85cd4660a49ad5d99216650c8e  images/f40-pursuit-nyc-layout-map.png

Image facts:

Original screenshot: 720 x 400, 2-bit indexed PNG, 3,451 bytes, 3 colours
Copied public still: 720 x 400, RGB PNG
Generated map:       720 x 400, RGB PNG
Visible colours:     black, white, green

The geometry is the important technical clue:

80 columns * 9 displayed pixels  = 720 pixels
25 rows    * 16 displayed pixels = 400 pixels

That is the normal 80x25 VGA/EGA text-mode display shape when the renderer exports the 9-pixel character clock. The stored page is still 80 columns by 25 rows of character/attribute cells, conventionally 4,000 bytes at B800:0000. The ninth displayed pixel is a VGA text-display expansion detail, not an extra byte in the screen buffer.

Visible Layout

Approximate text-cell regions:

columns 17..53, rows 00..02  top credit / title strip
columns 00..24, rows 03..08  large green NYC block logo
columns 26..44, rows 02..07  game title and "PRESS A KEY TO PLAY"
columns 02..18, rows 10..17  quote / motto box
columns 20..31, rows 10..13  media / hardware-note box
columns 33..43, rows 10..13  game-label box
columns 20..54, rows 09..22  road-course line-art box
columns 63..72, rows 03..08  JT face/signature
columns 63..72, rows 10..16  The Mad Scientist face/signature
columns 63..72, rows 17..23  Phallix face/signature

The visible page is a text composition. There is no evidence in this frame of scrolling, palette cycling, a timer interrupt, sprite motion, or graphics-mode line drawing. It is still visually more ambitious than a plain one-card loader: the block logo, road-course map, and three face icons show deliberate CP437 / ASCII character layout.

Visual-To-Code Concordance

This concordance is source-limited. It ties the public still and generated map to text-mode renderer classes, but it does not claim recovered executable offsets because the Defacto2 artifact was not acquired here.

The public Demozoo still proves the display model:

visible image:      f40-pursuit-nyc-demozoo.png
capture size:       720x400
screen model:       80 columns * 25 rows, 9x16 displayed character cells
memory target:      conventional B800:0000 text page, 2000 cells
proved behavior:    static black/white/green text-card composition
not proved here:    COM/EXE/BAT format, exact storage, post-key handoff

That geometry is the key technical evidence. The ninth displayed pixel in each column is a VGA/EGA text-display artifact; it does not mean the program stores a 720-pixel bitmap. A direct executable implementation would still write 80x25 character/attribute words.

The generated layout map identifies the writer regions:

visible image:      f40-pursuit-nyc-layout-map.png
regions:            title/key box, green NYC block logo, quote box,
                    hardware/media labels, road-course line art,
                    three right-side face/signature blocks
core writer types:  full-page copy, row-fragment writer, box helper,
                    block-logo mask writer, face/string records

The green NYC block is the best proof that the visual work is cell-level composition rather than pixel plotting. It can be represented as a short mask table expanded into full-block or space cells with a green attribute. The road diagram and the face signatures use the same text-cell vocabulary: repeated line characters, corner/step glyphs, slashes, spaces, and short strings.

A minimal code-shaped path that explains both images is:

set mode 03h or assume existing 80x25 colour text mode
clear/copy 2000 character/attribute words at B800h
write title/key rows
expand green NYC mask rows
write quote/media/game boxes
write route/road line-art rows or segment records
write three face/signature string blocks
wait for a key
exit or execute the cracked game

The alternative raw-page path is even simpler: copy a 4000-byte prepared text screen to B800h, then wait for a key. The screenshot alone cannot choose between raw text-page storage, compressed text-page storage, table-driven writers, ANSI text, or a batch wrapper. It does, however, rule out the need for graphics-mode raster code for this visible card.

Acquisition Boundary

The Defacto2 download request did not return the artifact:

HTTP/2 403
cf-mitigated: challenge
content-type: text/html; charset=UTF-8

These facts are therefore not proven:

archive filename and directory listing
whether the visible page is stored as text, ANSI, raw B800h cells, or code
whether the runtime is BAT, COM, or EXE
whether the "press a key" gate is COMMAND.COM PAUSE, BIOS INT 16h, or DOS input
the exact game executable or command launched after the key

The visual evidence is strong enough to discuss the likely text-mode loops, but not strong enough to claim exact bytes.

Text Mode Model

A custom executable path would choose normal colour text mode:

mov  ax,0003h       ; 80x25 colour text mode
int  10h

The backing storage is a character/attribute word per cell:

offset = (row * 80 + column) * 2
B800:offset + 0 = character byte
B800:offset + 1 = attribute byte

The page uses only a few attributes:

07h  white/grey on black for boxes, route, faces, and text
02h  green on black for the NYC logo, or a nearby low-intensity green variant

The exact attribute byte is not proven from the PNG, but the visible palette is black, white, and green. The page does not require blinking, high-intensity backgrounds, or palette remapping.

Full Page Copy Path

The simplest implementation is a raw 4,000-byte page image:

80 columns * 25 rows * 2 bytes = 4000 bytes

The runtime inner loop is one copy:

mov  ax,0B800h
mov  es,ax
xor  di,di
mov  si,offset screen_image
mov  cx,2000        ; words, one word per text cell
rep  movsw

That path explains the whole frame at once: green logo cells, white borders, route map, title text, motto text, and face icons. It also avoids special-case code for the big NYC block letters and the road-course geometry.

If the page is compressed, the decompressor would still produce the same 4,000 bytes:

dst = B800:0000
while dst < B800:0FA0:
    token = *src++
    if token is literal:
        copy N character/attribute words
    else:
        word = next character/attribute pair
        repeat N times:
            *dst++ = word

This screen would compress well because it has large blank black areas and many repeated border characters.

Table-Driven Writer Path

A smaller program can generate the page from shape and string records. The basic helpers are:

clear_screen(attr)
draw_box(x, y, w, h, attr)
write_string(x, y, attr, bytes)
write_run(x, y, attr, ch, count)

The clear loop:

mov  ax,0B800h
mov  es,ax
mov  ax,0720h       ; white-on-black space
xor  di,di
mov  cx,80*25
rep  stosw

The string loop:

di = ((row * 80) + column) * 2
for ch in string:
    B800:di   = ch
    B800:di+1 = attr
    di += 2

The box loop:

top/bottom:
    for col in x+1 .. x+w-2:
        put horizontal border at (col, y)
        put horizontal border at (col, y+h-1)

sides:
    for row in y+1 .. y+h-2:
        put vertical border at (x, row)
        put vertical border at (x+w-1, row)

corners:
    put the four corner characters

The screenshot's boxes are so regular that this model is credible. The top credit strip, title/key prompt box, motto box, media box, game-label box, road area, and face boxes all reuse the same rectangle vocabulary.

Green NYC Logo

The green NYC block is probably not a bitmap. In text mode, it can be drawn with full-block cells and spaces:

logo_table[row] = 24 columns of 0/1 values
for row in 0 .. logo_height-1:
    for col in 0 .. logo_width-1:
        if logo_table[row][col]:
            put_cell(logo_x+col, logo_y+row, full_block, green_attr)
        else:
            put_cell(logo_x+col, logo_y+row, space, normal_attr)

The storage for that table can be bit-packed:

3 bytes per 24-column logo row
6 rows -> 18 bytes plus dimensions

Or it can be stored as pre-expanded text cells. The visible evidence only says the output is cell-aligned green block art.

The relevant inner loop is therefore a mask-to-cell writer, not a pixel blitter:

mask = *src++
for bit in 7..0:
    if mask & (1 << bit):
        write green full-block cell
    else:
        skip or write black space

Road-Course Line Art

The central road/course diagram uses character geometry:

horizontal strokes  '-' or CP437 horizontal border
vertical strokes    '|' or CP437 vertical border
corners / steps     corner glyphs, slash/backslash, or underscore fragments
route marker        small `0` cells

There are two plausible construction styles.

First, store every line as text:

row 10: "   F40 PURSU..."
row 11: "   SIMULAT..."
...
row 18: "             ... stepped route ..."

This is effectively the full-page or row-fragment model.

Second, build the route from a short vector/segment list:

segment = x, y, direction, length, character
for each segment:
    for i in 0 .. length-1:
        put_cell(x, y, character, attr)
        x += dx[direction]
        y += dy[direction]

That would be overkill for a static loader, but it is a clean way to author the stepped track without hand-padding long strings. The resulting output is still text cells. There is no reason to assume a graphics-mode line drawer from this frame.

Text Faces

The three right-hand faces are compact multi-row string blocks. For example, each face can be represented as:

record:
    x, y, attr
    line 0: border / hair
    line 1: eyes
    line 2: nose / mouth
    line 3: lower border
    caption line

The inner loop is a nested line writer:

for face in faces:
    y = face.y
    for line in face.lines:
        write_string(face.x, y, attr, line)
        y += 1

Because the faces are separated and captioned, a table-driven writer is more space-efficient than a raw 4,000-byte screen image if the executable was meant to stay small.

ANSI Or Batch Alternative

The same frame can also be emitted by a DOS text sidecar:

@echo off
cls
type f40nyc.txt
pause
f40

The exact filenames are unknown. The important loop is COMMAND.COM plus the console device:

read next byte from sidecar
if byte is CR/LF:
    move cursor to next row
else:
    write byte at cursor
    advance cursor

If ANSI escape sequences were used, the file could jump between the logo, boxes, and face regions:

ESC[2J      clear screen
ESC[4;1H    logo origin
ESC[11;3H   motto origin
ESC[4;64H   first face origin

ANSI is possible, but not required. The screenshot is compatible with ordinary padded text rows and with direct B800h writes.

Key Gate And Handoff

The visible prompt says to press a key to play. Credible waits include:

COMMAND.COM PAUSE or a batch/helper equivalent
DOS INT 21h AH=08h no-echo console read
BIOS INT 16h AH=00h keyboard wait

BIOS path:

xor  ah,ah
int  16h

DOS path:

mov  ah,08h
int  21h

After the key, a custom loader could exit or execute the game:

mov  ax,4B00h       ; EXEC
mov  dx,offset game_name
mov  bx,offset exec_parameter_block
int  21h

Or a batch wrapper could simply continue with the next command. The preserved frame does not show the post-key state, so the exact handoff remains unknown.

What The Frame Proves

The strong claims supported by the frame are:

720x400 public capture
80x25 text-mode display with 9x16 rendered cells
black/white/green text-cell palette
static text-card composition
large cell-aligned green NYC logo
CP437/ASCII rectangle and route line art
right-side text-face signature blocks
key-gated loader intent

The frame does not prove:

scrolling or animation
music or timer interrupt use
graphics-mode pixel plotting
exact packed format
exact executable type
exact game-handoff command

The core loop here is not a raster effect. It is a well-composed text-mode release card: clear or copy the 80x25 page, write green block-logo cells, write white boxes and route/face text, wait for a key, then try to launch the game.