Analysis model: gpt-5.5 xhigh

Purity by Distortion - Technical Dissection

Scope

Purity is a 1993 MS-DOS demo by Distortion, entered in the The Party 1993 PC demo competition. The result file lists it in sixth place with 520 points. The bundled DIZ says the same thing: Purity by Distortion, sixth place at The Party III.

Release context: The Party 1993 PC demo entry.

This is a useful target because the public package is not just a normal real-mode EXE with a module beside it. The small shipped executable is PKLITE-packed and expands to a 123 KB protected-mode-oriented loader/show program. The README credits Tran/Renaissance for the PMODE handler, JayKay for the GUS player, and describes a 486/4 MB/GUS target machine. The real payload weight is in a 2.58 MB PURITY.DAT stream plus one large ProTracker module.

Private postal and telephone details in the bundled README are deliberately omitted.

Public References

The result file line is:

6     520    Purity                        Distortion

The archive server reports content-length: 1280927 and a last modified time of 3 April 2000 for the ZIP mirror. The bundled files are dated 28 December 1993, with the DIZ dated 4 January 1994.

Archive Layout

The scene.org ZIP contains five files:

SCRAMBLE.MOD   237468  1993-12-28 22:55
PURITY.DAT    2582408  1993-12-28 20:05
README           2673  1993-12-28 21:17
PURITY.EXE      26726  1993-12-28 22:24
FILE_ID.DIZ       150  1994-01-04 23:19

SHA-256 values from this pass:

2bbfe661de84853c468a74429be86ed7ec78c5559aaf734815649272fe57e305  purity.zip
c77a489221b53c05a05b518abdcb67e47b1214db32eaced2c58e289d3db362a9  PURITY.EXE
cbaa4ac2a1147676e81d3d9698e3568b268fca45c970651d9ea173ebff41fc9d  PURITY.DAT
272496d3edbdc3c43aa9b256902518a683d101dbf385fcc8f555f4c97fe88fe1  SCRAMBLE.MOD
6b8a65182c5e0c2ef73d5af4f16000b9ec65198ff6971cb9f7f4d1bb6b1541e8  README
b8ea5e30d7040c34d07debf1e3840856fc71e6680a86dbdffce885a4941ebcd0  FILE_ID.DIZ

file(1) identifies PURITY.EXE as an MZ executable with a self-extracting PKZIP/PKLITE signature. It identifies SCRAMBLE.MOD as a 4-channel ProTracker module titled lortelarm. PURITY.DAT is an opaque data file.

Bundled Notes

The README is unusually candid. It says the demo was not optimized and did not yet meet the group's intended future standard. It recommends at least:

486dx33
4 MB memory
Gravis UltraSound with 512 KB
totally clean boot

It also warns that too much memory garbage may produce crashes. That warning is consistent with the executable: it contains protected-mode, DPMI, VCPI, V86, A20, extended-memory, and GUS-memory failure strings.

The README credits:

Runtime Smoke Test

Runtime observations come from DOSBox-X:

emulator: DOSBox-X 2026.01.02, Linux SDL2 64-bit
run files: PURITY.EXE, PURITY.DAT, SCRAMBLE.MOD
GUS config: base 240h, DMA 3, IRQ 7, ULTRASND=240,3,3,7,7
EMS: disabled
capture path: ZMBV AVI

The demo started without an interactive setup menu. DOSBox-X captured a short 720x400 text/launch segment, then switched to a 640x400 graphics capture. The capture path aborted after about 16 seconds of decodable graphics frames, but that was enough to verify the opening sequence:

Welcome to the unfinished version of our very first PC demo
Currently requiring Gravis Ultrasound and a load of memory
We do not know when or if we will release it
so keep your eyes wide open now!

The text is rendered as large overlapping fade layers, not as a simple text mode page. The observed wording matches the embedded strings in the expanded executable. This runtime pass therefore proves startup, GUS/environment acceptance, PURITY.DAT access, and progress into the first graphics sequence. It does not prove the whole competition run.

Packed And Expanded EXE

The shipped executable is a small PKLITE-packed MZ:

file size              26726 bytes
MZ image size          26726 bytes
header size            144 bytes
relocations            0
min/max allocation     1886h / ffffh
SS:SP                  0687:0400
CS:IP                  fff0:0100
relocation table       0050h
calculated entry file  100090h

Visible packed-file markers:

00001e  PKLITE
000030  PKWARE
000322  386
0055a9  Gravis
0055e4  GUS

UNP expands the file to 123,412 bytes:

ac4e7acecd7616fe1b9786b8467165a6e16ada21586ef2fd95408931179269c5  expanded PURITY.EXE

Expanded MZ header:

file size              123412 bytes
MZ image size          123412 bytes
header size            512 bytes
relocations            16
min/max allocation     0101h / ffffh
SS:SP                  1e02:1000
CS:IP                  0000:027c
relocation table       003eh
calculated entry file  00047ch

The expanded executable contains the protected-mode setup surface:

386 or better not detected!!!
Not enough low memory!!!
This system is already in V86 mode!!!
Not enough extended memory!!!
Couldn't enable A20 gate!!!
DPMI host is not 32bit!!!
Ran out of DPMI descriptors!!!
Couldn't modify DPMI descriptors as needed!!!
Incompatible VCPI PIC mappings!!!
EMMXXXX0

Those strings match the README's clean-boot warning. The program expects to control the machine closely enough that V86 mode, EMS managers, or incompatible VCPI/DPMI state are treated as problems.

External File Names And Text

The expanded EXE names both shipped payload files in lower case:

purity.dat
scramble.mod

It also embeds the opening runtime text shown above, plus a later self-aware message:

this is my version of the common starwars scroller
not awfully original but it is twice the size of tritons

That is useful because it identifies one planned part style directly from the binary. It also supports the README's "unfinished" claim: the production does not hide its rough state.

GUS And Module Player

The expanded executable contains a GUS setup path:

Gravis Ultrasound detected
256 512 768 1024
Not enough GUS-memory for samples !
ULTRASND=
No soundcard detected
Not enough memory for music !

Near the module loader it checks common ProTracker/FastTracker signatures:

M.K.
FLT4
FLT8
8CHN

The shipped module is a standard 4-channel MOD:

title           lortelarm
signature       M.K.
orders          18
restart         127
patterns        11
sample bytes    225120
computed size   237468
file size       237468
trailing bytes  0

Selected samples include large named sample bodies such as techno-aff0rring at 41,964 bytes and storhedslyd1 at 61,710 bytes. The large sample total explains the README's request for a GUS with at least 512 KB.

PURITY.DAT

PURITY.DAT is 2,582,408 bytes and does not begin with a normal archive directory. The first nonzero region starts around 000000e5h and looks like small event/script bytes rather than a file table. Common-format scans found no valid GIF, PCX, RIX, RIFF, FLI/FLC, or embedded MOD signatures. The one BM hit at 002694d5h is not a valid BMP header; the following bytes are image-like payload data, not a BMP file.

The data file has clear bands:

00000000-00010000  entropy 2.84, many zeros
00010000-000a0000  entropy mostly 3.8-4.6
000a0000-00200000  entropy mostly 5.1-5.9
00219000-0025c000  all bytes <= 63 in 4 KB clusters
00271000-00277000  all bytes <= 63 in 4 KB clusters

The low-byte bands are consistent with palette-index maps, six-bit palette material, or generated lookup/image data. The executable has many plausible references into the 0025xxxx-0026xxxx region, so PURITY.DAT is best treated as a monolithic resource stream rather than a collection of ordinary embedded files.

Long zero runs mark sparse or padded regions near the end:

0020edf6  522 bytes
0023ed97  1817 bytes
00266d86  2236 bytes
00270eb8  8356 bytes
00273b56  11314 bytes

This is enough to characterize the storage model, but not enough to label every asset.

Hardware Evidence

The expanded executable contains direct low-level markers:

INT 21h DOS services          6
INT 31h DPMI services        18
A000h VGA memory marker      20
B800h text memory marker     75
3DAh retrace port marker     10
3C8h DAC index marker        20
GUS base 240h marker          1
GUS/SB base 220h marker       3

The absence of normal INT 10h setup in the expanded image is notable: the demo is not leaning on BIOS video services for its graphics work. The DPMI interrupt markers, V86/VCPI strings, A20 strings, and direct A000h/DAC/retrace markers fit the README's PMODE credit and the observed switch into a 640x400 graphics capture.

What The Program Is Doing

The evidence supports this architecture:

  1. PKLITE restores a larger MZ image.
  2. The restored program performs 386+, memory, A20, V86, VCPI/DPMI, and clean environment checks.
  3. Tran's PMODE-style handler moves the demo into protected-mode execution.
  4. The program opens purity.dat as a monolithic resource stream.
  5. The GUS path parses ULTRASND, detects UltraSound memory, and loads scramble.mod.
  6. The module loader recognizes multiple MOD signatures but the shipped module is a normal 4-channel M.K. file.
  7. The graphics path writes directly to VGA memory, palette ports, and retrace timing.
  8. The observed first sequence draws large text overlays with fade/overlap timing from code and data.

The public package is therefore a protected-mode PC demo with a big custom data stream, not a simple real-mode slideshow.

Why It Matters

Purity is interesting precisely because it is rough. The README says it is unfinished and not optimized, while the code already has the same building blocks associated with more mature 1993-1994 DOS demos: PMODE setup, DPMI/VCPI handling, GUS module playback, direct VGA timing, and a large opaque data stream. It also documents the practical fragility of that transition: clean boot, enough memory, enough GUS RAM, and avoiding V86/EMS environments all matter.

For the 1993 pass, it is a good companion to the more polished TP93 entries. It shows a team pushing toward protected-mode, GUS-heavy PC demo structure under party deadline pressure, and leaving the seams visible in both the README and the executable.

Limits

This pass verified the archive, DIZ/result metadata, README claims, file hashes, PKLITE expansion, packed and expanded MZ headers, protected-mode/GUS strings, the ProTracker module layout, broad PURITY.DAT structure, hardware marker counts, and a DOSBox-X startup capture through the first large text sequence. It did not fully recover the PURITY.DAT resource format or produce a complete timed capture of the full demo, because DOSBox-X aborted while writing the second graphics capture file.