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](https://demozoo.org/sceners/7657/),
  [FCS](https://demozoo.org/sceners/55996/),
  [HEGA](https://demozoo.org/sceners/7960/) and
  [Phantom](https://demozoo.org/sceners/6774/)
- 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:

```text
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:

| Capture time | Executable | Directly observed state |
| ---: | --- | --- |
| `00:00` - about `00:07` | `loader.exe` | Machine-class and GoldPlay output selectors; class `5`, device `0` |
| about `00:07` - `04:03` | `t_o.d01` | Four TAKEOVER cubes, large block scroller, moving red dot, striped background, then late illustrated transition pages |
| `04:04` - `07:07` | `t_o.d02` | Colored soft-edged shapes move, overlap, rotate, and retain long luminous afterimages |
| `07:08` - `10:35` | `t_o.d03` | Undulating dot surface, large dotted scroller, and four animated colored meter columns |
| `10:36` - `12:57` | `t_o.d06` | Rotating green wire objects share the frame with a separate large-font message stream |
| `12:58` - `15:25` | `t_o.d07` | Starfield credits and greetings scroll through the shipped production roles |
| `15:26` - about `18:07` | `t_o.d09` | Endless illustrated TAKEOVER end tableau with independently animated letter objects, stars, flame, and lightning |
| about `18:08` - `18:12` | `loader.exe` / DOSBox | Final Escape returns through the loader; the following `exit` closes the emulator |

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.

![Takeover direct opening-scroller motion](images/takeover-direct-opening.gif)

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.

![Takeover four-cube logo, block scroller and red cursor](images/takeover-opening-scroller.png)

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.

![Takeover direct luminous-shape motion](images/takeover-direct-shadeblobs.gif)

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.

![Takeover direct dot-surface motion](images/takeover-direct-dotfield.gif)

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.

![Takeover direct shadevector motion](images/takeover-direct-shadevector.gif)

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`.

![Takeover green shadevector crossing the blue message](images/takeover-shadevector.png)

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.

![Takeover direct credits motion](images/takeover-direct-credits.gif)

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.

![Takeover direct animated end-tableau motion](images/takeover-direct-endpart.gif)

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.

![Takeover's complete illustrated terminal tableau](images/takeover-end-tableau.png)

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

| Runtime evidence | Static file evidence | Result |
| --- | --- | --- |
| Interactive class and music selectors | Selector strings and GoldPlay 1.00 text in `loader.exe` | Exact match |
| Four-cube opening, text field, late illustrated pages | Embedded GIF signatures, long text, `t_o.m01` and internal asset names in `t_o.d01` | Directly binds the opening family to `d01` |
| Luminous moving/retained shapes | Standalone executable and `t_o.m02` references in `t_o.d02` | Binds the afterimage part to `d02`; its exact inner compositor remains unpacked |
| Dot surface, dotted text, colored meters | `t_o.d03` names `t_o.d04`, palette-sized `t_o.d05`, and `t_o.m03` | Binds all three simultaneous layers to the `d03` package without claiming that every layer is a shadebob |
| Green rotating wire objects | `shadevectors` string and `t_o.m04` reference in `t_o.d06` | Strong visual/string concordance |
| Credits and greetings | Matching role/greeting text, `t_o.d08`, and `t_o.m05` in `t_o.d07` | Exact content/file concordance |
| Animated illustrated TAKEOVER tableau | Different LZ-style executable wrapper around `t_o.d09`; no sixth module | Binds the terminal authored loop to the distinct final payload |


## Archive

Examined archive:

```text
50814902a590a5884badc65de0935f7fd9b279405a57a9502cb516eb4891a517  takeover.zip
```

Archive contents:

```text
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:

```text
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:

```text
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:

```text
This program uses the GoldPlay ver 1.00 module player
```

Most part executables also embed GoldPlay's object text:

```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.

```text
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:

```text
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:

```asm
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:

```asm
  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:

```asm
  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:

```asm
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`:

```asm
  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:

```asm
  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:

```asm
  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:

```text
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:

```asm
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:

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

Literal run:

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

Match decoding:

```asm
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:

```asm
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:

```asm
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:

```asm
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.