Recovering the Source Code of a 1992 MS-DOS Game

The 1992 MS-DOS game "Pole Chudes" (Поле Чудес — the Russian adaptation of Wheel of Fortune) was one of the first commercially successful Russian computer games. The source code was never preserved. So I decided to reconstruct it.

This is not a byte-accurate binary recreation. The goal was to produce clean, readable C source code that, when compiled, produces a game functionally identical to the original — using the same assets, same game logic, same visual output. Something you could actually read and learn from.

The Toolchain

Reverse engineering a 16-bit DOS binary in 2024 requires some care in tool selection:

• IDA Pro — primary disassembler, loaded with Turbo Pascal FLIRT signatures (the original was compiled with Turbo Pascal)
• Ghidra — decompilation to readable pseudocode
• SoftICE — classic DOS debugger, synchronized with IDA through MAP file conversion
• DOSBox-X and Bochs — emulators for testing at various stages
• Open Watcom 2 — cross-compiler targeting 16-bit DOS executables

The original used Turbo Pascal's Medium memory model: multiple code segments but a single data segment, with Pascal calling conventions (callees clean the stack). Knowing this upfront saved enormous time interpreting the disassembly.

The Asset Archive: POLE.LIB

All game resources are packed into a single file, POLE.LIB, containing 58 assets. The format was undocumented, so I traced the loading code to reverse-engineer it:

• 128-byte header
• First byte: asset count
• Followed by size tables for each resource
• Assets stored sequentially with no fixed offsets — you must walk the size table to find any given asset

Most sprite blocks contain trailing garbage at the end — the beginning of the next sprite. This suggests the original packing utility had a minor off-by-one bug that was never noticed because the rendering code stopped reading at the right place anyway.

Graphics: RLE Sprites and EGA Magic

Sprites use Run-Length Encoding (RLE) compression. The format:

• 6-byte header per sprite
• Per-row length indicators
• Control bytes: values below 0x80 indicate a literal run of pixels; values at or above 0x80 indicate a repeated single color (value & 0x7F gives the count)

After much confusion trying to match the format against known specifications, I eventually identified it as compatible with the Dr. Halo CUT file format — albeit with some quirks in this particular implementation.

EGA Write Mode 1: Fast Block Copying

The game makes heavy use of EGA's Write Mode 1, one of the more obscure EGA hardware features. In this mode, reading from video memory loads the EGA's internal latches for all four color bitplanes simultaneously. A subsequent write to any address in video memory copies those latched values to that address — across all four bitplanes at once — without the CPU ever seeing the color data.

The practical result: you can copy a rectangular region of video memory to another location at four times the effective throughput of a naive pixel-by-pixel copy, because each write operation moves 8 pixels (one byte per plane × 4 planes) rather than 2 pixels (4-bit EGA color per pixel).

The game uses an offscreen buffer at A000:7D00 — a region of EGA memory beyond the visible framebuffer — to stage animations before blitting them to screen, avoiding flicker.

The Wheel Animation

The spinning wheel has 16 sectors. The animation runs through 32 phases. Sector position during spin is calculated as:

sector = (28 - counter / 2) mod 16

The constant 28 (0x1C) accounts for the offset between the wheel's visual starting position and sector zero in the data array. The character's walking animation across the revealed letter tiles uses sine/cosine lookups for smooth elliptical motion along the board.

AI Cheating Logic

The computer opponents cheat. This is documented in the code, not speculation. The cheat system works on a probability curve:

• If more than half the letters in the current word are still unrevealed, cheating is disabled entirely
• As more letters are revealed, the cheating probability increases
• In the late game, the computer's probability of "guessing" a correct letter approaches certainty

This is fairly common game design for the era — pure random play by the AI makes early rounds trivially easy, while a probability-based cheat system creates escalating tension.

Sound: Frequency Glissando and Random Footsteps

Sound is generated directly via the PC speaker using port I/O. Character appearance animations use a frequency glissando effect: the frequency steps from 20 to 100 Hz (for the acceleration phase) then back down (deceleration), creating a swooping sound. Footstep sounds during walking use randomly selected frequencies, giving a less mechanical feel.

The Word List: XOR Obfuscation

Words are stored in POLE.OVL and are obfuscated by subtracting 0x20 from each character byte. This shifts letters out of the printable ASCII range, making the file unreadable in a hex editor without processing. It's not encryption — it's obfuscation, presumably to prevent players from simply opening the word list file and reading the answers.

Fonts

Three fonts are packed in POLE.FNT: 8×8, 8×14, and 8×6 pixel variants. The 8×8 and 8×14 variants are nearly identical to the publicly available VEGA_Pankov CP866 font collection — a common Soviet-era Cyrillic PC font. The 8×6 font appears to be custom-designed for the game's score display.

Notable Discoveries

• An unused "50" icon in the asset archive — suggesting either a cut feature or incomplete development
• EGA palette remapping used to produce proper skin tones for the female host character from a limited 16-color palette
• Hidden data storage in the offscreen video memory region, reusing EGA VRAM as general-purpose RAM
• A debugging screenshot capture system that writes to PCX format, presumably used during original development

The Result

The reconstructed source code is available on GitHub as open-pole-dos. The repository includes:

• Full C source, compilable with Open Watcom 2 to a working DOS executable
• OVLEDIT.EXE — a word database editor for POLE.OVL
• Asset extraction utilities demonstrating the POLE.LIB format

The project took several months of evenings and weekends. The most satisfying moment was getting the wheel to spin correctly — the sector calculation with its magic constant 0x1C only clicked after tracing through the original animation loop a dozen times with SoftICE. After that, everything else felt tractable.

If you have any interest in DOS-era game internals, EGA programming, or the history of Russian software development, I hope this writeup is useful. All tools and methods described are standard reverse-engineering practice, applied to a thirty-year-old piece of software with no living copyright enforcement.