Analysis model: gpt-5.5 xhigh

Takeover by Epical - Technical Dissection

Takeover is a December 1992 MS-DOS demo by the Finnish group Epical. Demozoo lists it as an MS-DOS demo released in December 1992, with Blizzard on music, FCS and Phantom on code, and HEGA on graphics. Each contributor is individually located in Finland by the surviving scener records; this is not a nationality inference from Epical's group identity. Pouet also lists Takeover as an MS-DOS demo released in December 1992. The Hornet 1992 index lists takeover.zip as Takeover by Epical with a four-star rating.

Release year: 1992

The package is an early-PC multipart design:

• one interactive loader;
• six executable visual part files;
• three small auxiliary visual data files;
• five standard ProTracker M.K. music modules;
• a GoldPlay-based music setup path;
• a repeated custom EXE packer on the loader and most visual parts;
• a different LZ-style packed wrapper on the last executable part.

The bundled text says this was Epical's first PC-scene year-end demo and that it was their last demo intended to work on 286 machines. It also explains the shadebob implementation: Phantom wrote the base routine, and FCS added random movement and random palette generation, so that part is meant to vary between runs.

Old private contact listings and old distribution-site notes are deliberately omitted.

Sources

• Pouet production page: https://www.pouet.net/prod.php?which=4227
• Demozoo production page: https://demozoo.org/productions/169009/
• Demozoo Epical group page: https://demozoo.org/groups/7194/
• Individual Demozoo records for Blizzard, FCS, HEGA and Phantom
• Hornet 1992 demo index: https://files.scene.org/get/mirrors/hornet/demos/1992/00_index.txt
• Scene.org archive redirect: https://files.scene.org/get/mirrors/hornet/demos/1992/takeover.zip
• Scene.org archive file: https://archive.scene.org/pub/mirrors/hornet/demos/1992/takeover.zip

The Hornet index line is:

takeover.zip     700786 ****  Takeover by Epical

Demozoo lists the soundtrack as Neophyte, Frozen Moon, Glass A, Mazzard, and 0peration 13, all by Blizzard/Epical in December 1992. Those titles match the five module files in the archive.

Complete Direct Silent Traversal

The exact archive identified below was run in DOSBox-X 2026.01.02 with a 486 CPU model, 16 MB RAM, fixed 30,000 cycles, XMS enabled, and EMS/UMB disabled. The original loader was answered with machine class 5 (486dx) and GoldPlay device 0 (No music). No emulated sound device was exposed; host SDL audio was dummy; and the external 25 fps FFV1/X11 evidence master has no audio stream.

Takeover is an interactive multipart demo rather than one self-advancing trackmo. In the no-music route used here, each part continued until Escape. Escape returns to loader.exe, which starts the next shipped executable. The traversal therefore gave every part at least one long live interval, used one Escape per handoff, reached and observed the endless final tableau, then used a final Escape. The loader returned cleanly and DOSBox exited with status 0.

The direct file-chain timeline, measured from the external capture, is:

The boundaries above identify the visible executable changes to about two seconds. They are capture-stream times, not claims about original module positions. The late t_o.d01 transition pages and brief loader handoffs are part of the route but are not treated as separate executables.

The t_o.d01 clip at 01:00 shows that its opening is a compound scene: the cube logo and striped background remain fixed in composition while the large text advances and a red dot moves independently over the letter field.

The still separates the three layers cleanly. Each cube supplies one quarter of the title, the oversized text fills a rigid cell grid, and the small red dot crosses that grid without belonging to either background layer.

At 06:10, t_o.d02 is well inside its long shape passage. Consecutive frames show both object motion and retained silhouettes, so the soft look is a running afterimage/compositing effect rather than a blurred source still.

At 08:30, t_o.d03 simultaneously animates its upper dot surface, middle dotted text, and lower four-column meter. This direct view corrects the earlier temptation to name the whole executable from one shadebob text reference.

At 11:20, the t_o.d06 shadevector is a rotating wire object with accumulated green edges beneath a separately advancing message. This is the cleanest runtime-to-string match in the package because the same executable explicitly names shadevectors.

One frame makes the compositing order visible: the green wire object can pass over the large blue letterforms while the text remains a separate readable plane. The animation is still required to understand the rotation; the still is useful for inspecting the overlap.

At 14:10, t_o.d07 is scrolling the role credits visible in its own binary. The starfield moves behind the text, and the capture reaches later greetings before the handoff.

At 16:00, t_o.d09 has established its authored endless endpoint. The letters are built from different animated motifs rather than one flat logo: eyes and drips, a burning face, plant strands, a sword, a striped arc, bubbles, and lightning around a keycap.

The complete tableau deserves a non-moving reference because each letter uses a different small visual system. The T is crowded with eyes, the A grows from bubbles, and the last letter is replaced by an electrified keyboard key; the surrounding stars and crescent keep those disparate objects in one scene.

The loader contains a t_o.d10 filename string, but no such file exists in the examined ZIP and the observed route does not attempt a missing seventh visual part. After t_o.d09 returns, the loader exits normally.

Runtime-To-File Concordance

Archive

Examined archive:

50814902a590a5884badc65de0935f7fd9b279405a57a9502cb516eb4891a517  takeover.zip

Archive contents:

fotl.nfo       1773 bytes  1993-01-14 15:31
loader.exe    25202 bytes  1992-12-20 23:51
t_o.d01      114160 bytes  1992-12-22 11:52
t_o.d02       31136 bytes  1992-12-20 21:53
t_o.d03       32838 bytes  1992-12-22 12:44
t_o.d04        4910 bytes  1992-12-18 21:38
t_o.d05         768 bytes  1992-12-05 12:02
t_o.d06       42836 bytes  1992-12-20 21:52
t_o.d07       34800 bytes  1992-12-22 12:11
t_o.d08       55301 bytes  1992-12-05 16:37
t_o.d09       33311 bytes  1992-12-19 12:16
t_o.m01      134644 bytes  1992-12-13 17:33
t_o.m02      243902 bytes  1992-12-14 21:03
t_o.m03      146232 bytes  1992-12-13 18:36
t_o.m04      113152 bytes  1992-12-13 22:20
t_o.m05      185448 bytes  1992-12-13 16:54
takeover.nfo   2390 bytes  1992-12-22 11:43

Important hashes:

d77f796f9d55f02fadc0a3821ba4f72a18564492f63d50c441729b68356fbc15  loader.exe
edff7d198e790108f73344f35b0421ff9eac115871bf61113511684410bc141b  t_o.d01
40ede023cc7b84a3b060441e8eb236d4c6ce144bdeb01388df5c36b754d92943  t_o.d02
297eb48098bc1a19748fa32cbb7427d2ef2fef79dfde12e88969cc0d01492eab  t_o.d03
f711be24fd2ea2380ca55e6b96f51b1c90fe6f62455c052bfdd26ff678ea4b78  t_o.d04
461ffe3ff8ae12e59533f26328adc233083c1bdc444c68dfe29046b84ec6d21b  t_o.d05
a379fd36c4ac5fa85aa04af0c529a5f28c5291a2cef58cfd7353232720a5adf4  t_o.d06
b69230ba565dd904ad474851732da604d61b195cdfb7c7fdff0043c13e5e42a5  t_o.d07
d61bd233cda042599e7488b432fd559016eb92356eace1cbe85affe3d274764f  t_o.d08
61728dae0721faa5dcba227cd0c592d4a74fd4c9bd5ff9fe71b699f7f95d280f  t_o.d09
80552fe2075d8661e024de9f0dc43bcc4ba010d9c0c5fbd93200df775ec46e87  t_o.m01
7638f104d8af7f3c699127e8fedee5b65f7239ef24000f6b4e8e5a4544d3ad18  t_o.m02
9d59576213111ef7616fb27343659df6a41ea8c882962873219ed01dc6614942  t_o.m03
928c31531dd6c6d0c1da63bf8ba852eca5ace819e8e36d52d89edc797270e61a  t_o.m04
784ffb49eba0896247438fff905fbdbfea160f2454081375d5d14c6ac4eee48e  t_o.m05
e59bad05f60108e19d1b3965a2be2ea08138f92dd623c470da877284f35a6283  takeover.nfo

File Roles

Measured file roles:

loader.exe  packed MZ loader, hardware/music selector, launches part files
t_o.d01     packed MZ part, references t_o.m01, music.dat, font2.fnt
t_o.d02     packed MZ part, references t_o.m02 and GoldPlay support code
t_o.d03     packed MZ part, references t_o.d04, t_o.d05, t_o.m03
t_o.d04     4910-byte auxiliary data, starts with "=EFF="
t_o.d05     768-byte VGA palette-sized block
t_o.d06     packed MZ part, references t_o.m04, embedded GIF data, shadevectors
t_o.d07     packed MZ part, references t_o.d08, t_o.m05, credits text
t_o.d08     55301-byte auxiliary data, starts with "=EFF="
t_o.d09     MZ payload using a different LZ-style packed wrapper
t_o.m01     ProTracker module, title "Neophyte - Blizzard"
t_o.m02     ProTracker module, title "Frozen moon"
t_o.m03     ProTracker module, title "Glass A"
t_o.m04     ProTracker module, title "Mazzard - Blizzard"
t_o.m05     ProTracker module, title "0peration 13"

All five music files are standard four-channel ProTracker-style modules with the M.K. marker at offset 1080. The demo text explicitly says users can copy the t_o.m0? files elsewhere, rename them with a .mod suffix, and play them with a module player. That is exactly what the binary layout shows.

t_o.d05 is exactly 256 * 3 bytes, so it is a full VGA DAC table. Its bytes are in the six-bit VGA range. t_o.d04 and t_o.d08 both start with =EFF=, which is likely an Epical effect-data marker rather than a standard image format. t_o.d08 has repeated high-value byte rows after the marker and is large enough to hold a substantial endpart data block.

Loader Behavior

loader.exe contains the front-end text and checks:

• GoldPlay 1.00 music output selection;
• Sound Blaster and parallel-DAC options;
• IRQ/DMA prompts for Sound Blaster output;
• machine-speed choice from 286 through 486;
• VGA/MCGA requirement check;
• 286-or-better CPU check;
• protected-mode warning, likely to catch EMS managers or multitaskers;
• part filename list from t_o.d01 through t_o.d09, plus the unused t_o.d10 string.

The embedded music setup text says:

This program uses the GoldPlay ver 1.00 module player

Most part executables also embed GoldPlay's object text:

GoldPlay ver 1.00, by Sourcer and Robban
Object File - Not for standalone use.

That means the package is not a single music engine linked only into the loader. The parts themselves carry player code or object-code fragments, which is consistent with part executables being launched one after another.

MZ Layout

loader.exe, t_o.d01, t_o.d02, t_o.d03, t_o.d06, and t_o.d07 share a similar packed MZ shape: no relocation table entries, 512-byte header, entry near the end of the load image, and a custom unpacker there.

file        image bytes  relocs  ss:sp       cs:ip       entry image offset
loader.exe       24690       0   064a:0080   05f3:0010   05f40
t_o.d01        113648       0   2650:0080   1baa:0010   1bab0
t_o.d02         30624       0   09e6:0080   0766:0010   07670
t_o.d03         32326       0   0f68:0080   07d0:0010   07d10
t_o.d06         42324       0   0cff:0080   0a41:0010   0a420
t_o.d07         34288       0   0b04:0080   084b:0010   084c0

t_o.d09 is different:

file        image bytes  relocs  ss:sp       cs:ip       entry behavior
t_o.d09         33183       1   0822:0200   fff0:0100   wraps to image offset 0000

The FFF0:0100 entry is the same real-mode wrap trick seen in other early packed DOS payloads. DOS adds CS to the load segment modulo 16 bits, so loadseg + FFF0h : 0100h executes at the start of the image.

Common Backwards EXE Unpacker

The common wrapper used by the loader and five parts is a backwards unpacker. It starts by relocating a small second stage upward:

entry:
  mov ax,es
  add ax,0010h
  push cs
  pop ds
  mov [0004h],ax
  add ax,[000ch]
  mov es,ax
  mov cx,[0006h]
  mov di,cx
  dec di
  mov si,di
  std
  rep movsb
  push ax
  mov ax,0032h
  push ax
  retf

The important detail is std. The unpacker is meant to move backward through both source and destination. This avoids overwriting packed bytes before they are consumed.

The second stage scans for a small marker area, normalizes segment/offset pairs when either pointer crosses a paragraph boundary, and then reads commands from the packed stream:

  lodsb
  mov dl,al
  dec si
  lodsw
  mov cx,ax
  inc si
  mov al,dl
  and al,0feh
  cmp al,0b0h
  jne maybe_copy

repeat_run:
  lodsb
  rep stosb
  jmp command_done

maybe_copy:
  cmp al,0b2h
  jne corrupt
  rep movsb

command_done:
  mov al,dl
  test al,1
  je next_command

So every command has:

• a command byte in DL;
• a count word in CX;
• opcode class B0h for repeated-byte fill;
• opcode class B2h for literal copy;
• low bit set on the final command.

The fill case reads one byte and expands it through rep stosb. The copy case uses rep movsb. Because direction flag is set, both operations walk backward. That is a simple but effective executable packer for this kind of MZ payload: long zero/flat areas compress as repeated-byte runs, while dense code/data blocks stay as literal spans.

After the final command, the wrapper applies a relocation stream stored inside the packed file:

  mov si,0112h
  push cs
  pop ds
  mov bx,[0004h]
  cld
  xor dx,dx

reloc_page:
  lodsw
  mov cx,ax
  jcxz next_page

reloc_word:
  mov ax,dx
  add ax,bx
  mov es,ax
  lodsw
  mov di,ax
  add es:[di],bx
  loop reloc_word

next_page:
  cmp dx,0f000h
  je transfer
  add dx,1000h
  jmp reloc_page

The relocation records are grouped by 64 KB windows: DX advances by 1000h paragraphs per group. Each word listed in the group gets the load base added. That lets the wrapper ship as a no-relocation MZ file while still reconstructing a relocated executable image.

Finally the wrapper restores the final stack and jumps through the far pointer at the rebuilt image start:

transfer:
  mov ax,bx
  mov di,[0008h]     ; final SP
  mov si,[000ah]
  add si,ax          ; final SS
  add [0002h],ax     ; final CS word in far entry pointer
  sub ax,0010h
  mov ds,ax
  mov es,ax
  xor bx,bx
  cli
  mov ss,si
  mov sp,di
  sti
  jmp far cs:[bx]

That is why the real visual code is not visible directly at the MZ entry. The entry is the unpacker. The actual part begins only after the backward unpack, relocation repair, and far transfer.

Loader VGA and Text Tricks

Even inside the packed loader, some helper routines are visible before final unpacking. They show the style used by the front-end:

VGA Palette Fade

The loader writes all 768 DAC bytes through ports 03C8h/03C9h:

  xor ax,ax
  mov dx,03c8h
  out dx,al
  inc dx
  mov cx,0300h
  ...
  lodsb
  shr al,1
  shr al,1
  add al,bl
  clamp to 00h..3fh
  out dx,al
  loop

The right shifts turn an 8-bit-looking component into a six-bit DAC value, then BL supplies the fade bias. This is classic VGA fade code: modify every DAC component, clamp to the legal range, and wait for retrace on selected passes.

Retrace Wait

The loader's vertical retrace wait is the standard status-port loop:

  mov dx,03dah
wait_not_vblank:
  in al,dx
  test al,08h
  jne wait_not_vblank
wait_vblank:
  in al,dx
  test al,08h
  je wait_vblank

It first waits until bit 3 is clear, then waits until bit 3 is set. That gives a clean edge for palette changes and page tricks.

CRTC Start and Text/VGA Copy

The loader also writes CRTC start registers 0Ch/0Dh and copies a 0FA0h byte block between video areas:

  mov dx,03d4h
  mov al,0ch
  mov ah,bh
  out dx,ax
  inc ax
  mov ah,bl
  out dx,ax

  mov si,bx
  mov ax,0a000h
  mov es,ax
  mov ds,ax
  mov di,6d60h
  mov cx,0fa0h
  rep movsb

0FA0h is 4000 bytes, exactly the size of an 80x25 text page when each cell has character plus attribute. The loader is mixing text-mode style buffers and VGA memory tricks, which fits the visible front-end: text prompts, logo pages, and smooth transitions.

Part-Level Evidence

The credits embedded in t_o.d07 divide the production into an opening logo section, first/second/third/fourth visual parts, and an endpart. The direct Escape-driven traversal fixes those roles to the executable chain:

d01 + m01  cube-logo/scroller opening and illustrated transition pages
d02 + m02  luminous moving shapes with long retained afterimages
d03 + d04 + d05 + m03  dot surface, dotted scroller, colored meter columns
d06 + m04  green shadevector plus large-font message stream
d07 + d08 + m05  starfield credits/greetings
d09       animated illustrated TAKEOVER end tableau

t_o.d01 contains the visible release text and several embedded GIF87a signatures. Its strings also reference music.dat and font2.fnt, which look like runtime-internal names or packed member names rather than separate archive files.

t_o.d02 is now directly tied to the moving soft-edged shapes and their long colored trails. Its packed inner compositor is not reconstructed, so "afterimage" describes the observed frame persistence without pretending the exact buffer operation is already named.

t_o.d03 contains the shadebob scroll text and directly names both t_o.d04 and t_o.d05. Runtime shows an undulating dot surface, a dotted message, and four colored meter columns at once. Since t_o.d05 is a palette-sized block and the NFO describes random palette generation, the auxiliary files are strongly connected to this part, but the word shadebob alone is not enough to label every visible layer.

t_o.d06 contains a string naming "shadevectors" and a GIF87a signature. It is paired with t_o.m04, Mazzard. Direct runtime confirms the named effect: green rotating wire geometry accumulates shaded edges while a large-font text stream advances separately.

t_o.d07 contains the credits and greetings text, names t_o.d08, and pairs with t_o.m05, 0peration 13. The observed starfield credit pages reproduce that embedded role text.

t_o.d09 is the final animated illustrated TAKEOVER tableau. That direct assignment matters because this payload has the different LZ-style wrapper dissected below and no sixth music module.

t_o.d09 LZ-Style Wrapper

The final executable uses a more advanced packed wrapper than the earlier parts. It has an MZ header with one relocation and the wrapped entry described above. The first stage checks memory, builds a new stack, copies a 0x244-byte second stage, and far-returns into it:

0000  mov ax,1163h
0003  mov dx,081ah
0006  add ax,0000h
0009  cmp ax,[0002h]
000d  jae 0029h
000f  sub ax,0020h
0012  cli
0013  mov ss,ax
0015  sti
0016  sub ax,0025h
0019  mov es,ax
001b  push ax
001c  mov cx,0122h
001f  xor di,di
0021  push di
0022  mov si,0144h
0025  cld
0026  rep movsw
0028  retf

The depacker core is a bitstream LZ decoder:

007e  mov di,0100h
0081  xor si,si
0083  lodsw
0084  xchg bp,ax
0085  mov dx,0010h
0088  jmp 00c1h

Literal run:

00be  jb  00c8h
00c0  movsb
00c1  shr bp,1
00c3  dec dx
00c4  je  00bah
00c6  jae 00c0h

Match decoding:

00c8  xor cx,cx
00ca  xor bx,bx
00cc  shr bp,1
00ce  dec dx
00cf  je  008ah
00d1  rcl bx,1
...
0102  mov bl,cs:[bx+0206h]
0107  xchg cx,bx

Back-reference copy:

013a  lodsb
013b  mov bl,al
013d  push si
013e  mov si,di
0140  sub si,bx
0142  push ds
0143  push es
0144  pop ds
0145  rep movsb
0147  pop ds
0148  pop si
0149  jmp 00c1h

The source segment is temporarily changed to ES, so rep movsb copies from already-expanded output back into later output. That is the key LZ operation. Unlike the simpler earlier wrapper, this one can encode repeated patterns as distance/length matches rather than only fill runs and literal copies.

It also contains a segment-normalization path:

01bd  lea bx,[di-2000h]
01c1  and di,000fh
01c4  add di,2000h
01c8  mov cl,04h
01ca  shr bx,cl
01cc  mov ax,es
01ce  add ax,bx
01d0  mov es,ax
...
01d6  and si,000fh
01d9  shr bx,cl
01db  add ax,bx
01dd  mov ds,ax

That keeps 16-bit offsets usable while the logical output and input streams move through larger memory ranges.

The final transfer applies relocation bytes, restores the stack, zeroes general registers, and far-returns into the unpacked image:

020d  pop bx
020e  mov bp,bx
0210  add bx,0010h
...
0219  lodsw
021a  add ax,bx
021c  mov es,ax
021e  lodsw
021f  xchg di,ax
0220  add es:[di],bx
...
0227  lodsw
0228  add ax,bx
022a  cli
022b  mov ss,ax
022d  lodsw
022e  mov sp,ax
0230  sti
0231  lodsw
0232  add bx,ax
0234  push bx
0235  lodsw
0236  push ax
0237  mov es,bp
0239  mov ds,bp
023b  xor ax,ax
...
0249  retf

This means t_o.d09 is not just another part using the same shared packer. It is wrapped with a more capable executable compressor, probably because its final payload compressed better with LZ-style matches.

Why It Is Interesting

Takeover sits at a useful point in late 1992 PC demo practice:

• it still targets 286 machines;
• it uses standard ProTracker modules rather than a bespoke music format;
• it relies on GoldPlay for device support;
• it packages each visual section as its own executable;
• it packs every major executable section;
• it combines VGA DAC fades, CRTC page tricks, text buffers, GIF-like embedded art, palette data, and generated/randomized effects.

It is not as historically loud as the most famous 1992 party winners, but it is technically representative: lots of small real-mode tools glued together with custom packing, public fallback options, and enough effect-specific data to make each part look independent.

Limits

This pass verifies the archive, metadata, MZ layouts, file roles, common backwards unpacker, loader helper loops, the final t_o.d09 LZ wrapper, and a complete interactive direct runtime through all six shipped visual executables. The capture now proves the executable order, handoffs, major visible layers, credits, and endless endpoint.

It still does not reconstruct the final unpacked visual programs after the common backwards unpacker. Consequently, labels such as afterimage, dot surface, and shadevector are tied to observed files and shipped strings, but the exact per-pixel loops for d02 and d03 remain future work. The GIFs prove motion and composition; they are not being used as a substitute for missing disassembly.