Analysis model: gpt-5.5 xhigh

The Royal Family by Orange - Technical Dissection

The Royal Family is Orange's 64K intro for The Party 1995 PC 64K competition, where it ranked 9th. It is a useful companion to The Sea Robot of Love: same party, same Orange 64K lane, same default 50 Hz video-mode warning, but a different visual idea. Instead of glowing meshes and height fields, it builds a monochrome cyan "video clip" presentation inside the 64K envelope.

The important technical shape is a tiny DOS MZ/RNC method-1 carrier around a 158,630-byte protected-mode runtime. The expanded image contains the familiar 386/VCPI/DPMI/A20 startup strings, module-format probes, a 50 Hz VGA setup path, retrace waits through 3DAh, direct DAC upload through 3C8h/3C9h, and a frame path that writes paired scanlines into A0000h.

Sources

Pouet production page: https://www.pouet.net/prod.php?which=9669
Scene.org party archive: https://files.scene.org/view/parties/1995/theparty95/in64/royal.zip
Public video reference linked from Pouet: https://www.youtube.com/watch?v=aChQEUgqhFg

Pouet metadata:

title:          the royal family
group:          Orange
type:           64k
platform:       MS-Dos/gus
release party:  The Party 1995
compo:          PC 64K
ranked:         9th
release date:   December 1995

Examined Files

Archive hash:

9ecf1e6ab67dbf3486f7764385af28465de40de63f9345ea524acfa335f07edd  royal.zip

Extracted file hashes:

07270ef7958cb0f5a23b83062511dcdd03a2bffb01e41d61d6ceacfa2de3fb14  FILE_ID.DIZ
cf742c046f3b13aa6fa48f286b828897fe07483d54712ab6e3ed60d80d797147  INFO.NFO
c45aa08bc8920398c57d931159d8980f6b7ec6612a6be74446dae8f099ab95f4  ROYAL.EXE

FILE_ID.DIZ identifies the production:

ORANGE - THE ROYAL FAMILY
        presents
    THE ROYAL FAMILY
         64kb

INFO.NFO is short but useful:

ORANGE - THE ROYAL FAMILY
THE ROYAL FAMILY
64kb

yes  it is an intro

use the 50hz video mode if it works
credits:
        doce whoozed by postman-pat
        cumsi whizzed by postman-pat
        rat fizzed by postman-pat

That 50 Hz note is the same class of warning seen in Orange's other 1995 custom-VGA intros: the default mode is part of the intended look, but may be unfriendly to some monitors.

Visual Evidence

The Pouet screenshot is a 240x180 GIF:

f279ea3a77a37e7a3012de9174ce25ab61e258aa6fad6b4f2901d43570299c1c  pouet.gif

The Royal Family Pouet screenshot GIF

The public MP4 linked from Pouet is a 900x720 video. The stills and GIFs below are direct full-frame video extracts downscaled to 450x360 for the article. There is no cropdetect, padding, viewport correction, browser screenshot, lightbox screenshot, or guessed DOSBox canvas size in the asset path.

sha256: cc4c1e7c84766ac33425142859cd401d550082fe09d89a9759f3ce720f3048b9
video:  h264, 900x720, 60 fps
length: 112.97 seconds

The Royal Family public-video contact sheet

The visual language is constrained and deliberate: black/cyan palette, coarse video-window material, chunky noise, and low-resolution fragments that are revealed or smeared rather than drawn as conventional vector effects.

Opening And Identity

The early title/present phase is very small on a black field. It behaves like a presentation cue rather than a full title picture.

The Royal Family public-video present frame

The first large readable image is not a normal logo reveal; it is a flickering, noisy video aperture. The clip matters because the small bright window moves and changes size against a dark dithered background.

The Royal Family public-video moving window clip

The Royal Family public-video moving window still

This matches the contemporary Pouet comment that calls out "video clips in 64k." The trick is not that the source looks clean. The trick is that a watchable moving-image impression is squeezed into a tiny RNC-packed intro by lowering resolution, palette range, and detail.

Clip Material

The middle of the run contains more recognizable picture material: a face, a king/royal figure, and noisy motion fragments. The video is still abstracted heavily enough that the mechanism reads as video-texture playback rather than full photographic storage.

The Royal Family public-video clip motion

The Royal Family public-video royal figure frame

The later mosaic/noisy scene keeps the same cyan-only design. There are no separate RGB images hiding here; the palette and renderer are part of the compression strategy.

The Royal Family public-video mosaic frame

The final frame stays within the same vocabulary: noisy cyan image material, high contrast, and no full-color credit screen.

The Royal Family public-video final frame

Video Clip Mechanics

The public-video timeline is not a normal bitmap slideshow and not a hidden full-color movie player. It is a deliberately reduced clip renderer. The recurring visual traits are all compression-friendly: one dominant cyan ramp, large black areas, coarse blocky picture fragments, paired scanlines, and high-frequency speckle that can hide quantization.

The contact sheet shows that the same renderer vocabulary is used across the run:

The opening presents/aperture section is a small moving window on a noisy cyan-black field.
The face and king fragments are recognizable only after aggressive downsampling and palette reduction.
The mosaic/final sections keep the same doubled-line texture and moving noise rather than switching to a separate high-color renderer.
The 50 Hz warning in INFO.NFO matters because the default video timing is part of how the reduced frames are made stable enough to read.

That reading lines up with the recovered display routine. The expanded runtime does not copy 64,000 bytes of clean 320x200 image data each frame. It clears a roughly half-frame work area, builds a small 17-color DAC ramp, waits for vertical retrace, then expands reduced source bytes into paired scanlines in A0000h. The visible "video clip" is therefore a timed reconstruction: small source field, cyan ramp, doubled output rows, and a moving dither/noise term.

The two GIFs in this article capture different parts of that mechanism. The window clip shows the aperture/position side of the player; the larger video-clips GIF shows the content side: face, royal figure, and noisy interstitial fragments all passing through the same palette and scanline expander. This is why the intro feels like a video even though the recovered routine points to reduced intermediate data rather than stored full frames.

Packed MZ And RNC Boundary

ROYAL.EXE is a 65,054-byte DOS MZ executable with a 32-byte MZ header and an RNC block starting immediately after it:

file size:            65054 bytes
MZ header paragraphs:     2
relocations:              0
CS:IP:               0fb2:000c
SS:SP:               26bc:04de
RNC marker:          file offset 0x20

The RNC header is method 1:

method:          RNC1
RNC offset:      0x20
packed size:     64262 bytes
unpacked size:   158630 bytes
header CRCs:     ecef / 285c

Expanding the RNC block with the local RNC ProPack tool produced:

1328ec26bf8336557ae166ab63db573002fb0e267faf93e92017476b421f6fe7  RNC-expanded image

The expanded image starts with protected-mode loader/runtime material rather than a second MZ header. The visible startup strings include:

386 or better not detected!!!
Not enough low memory!!!
System is already in V86 mode, and no VCPI or DPMI found!!!
Not enough extended memory!!!
Couldn't enable A20 gate!!!
Extended memory allocation failure. (weird eh???)
DPMI host is not 32bit!!!
Ran out of DPMI descriptors!!!
Couldn't set DPMI descriptors as needed!!!
Couldn't enter 32bit protected mode!!!
Incompatible VCPI PIC mappings!!!

The expanded image also contains tracker module-format probes:

M.K.
FLT4
6CHN
8CHN
OCTA

There are no ULTRASND or GUS ASCII strings in the recovered image, so the music-device evidence is weaker than in several other Orange analyses. The Pouet platform says MS-DOS/GUS, and the executable contains tracker-format signatures, but this pass does not claim a recovered GUS setup routine by name.

Video Mode And Palette Setup

The strongest recovered code island starts at expanded+0x263c8. It is a presentation setup path: enable interrupts, set a small runtime state word, call internal setup helpers, derive palette step values from retrace timing, build a 16-entry RGB ramp, allocate/clear a work area, and then enter a custom VGA setup path.

The palette builder writes RGB triples capped at 0x3f, matching the 6-bit VGA DAC component range:

expanded+0x263ea: mov    edi, 0x1f108
expanded+0x263ef: call   0x26887        ; retrace-timed byte source
expanded+0x263f9: mov    [0x1f89c], bl  ; red step
expanded+0x26409: mov    [0x1f89d], bl  ; green step
expanded+0x26419: mov    [0x1f89e], bl  ; blue step
...
expanded+0x26492: mov    ecx, 0x10
expanded+0x2649d: mov    [edi], al
expanded+0x2649f: mov    [edi+1], bl
expanded+0x264a2: mov    [edi+2], dl
expanded+0x264a8: add    al, [0x1f89c]
expanded+0x264ae: add    bl, [0x1f89d]
expanded+0x264b4: add    dl, [0x1f89e]
expanded+0x264ba: cmp    al, 0x3f

After allocating a buffer at 0x3963, the code clears 0x1f90 dwords:

expanded+0x264e0: mov    [0x3963], eax
expanded+0x264e5: mov    edi, [0x3963]
expanded+0x264eb: xor    eax, eax
expanded+0x264f0: mov    ecx, 0x1f90
expanded+0x264f5: rep stosd

0x1f90 * 4 = 32320 bytes, close to half a 320x200 8-bit frame. That is a useful clue for the later paired-line copy path: the runtime is not storing a full clean 64,000-byte photographic frame per step. It is storing reduced or intermediate video data and expanding it during display.

The custom VGA setup path then programs VGA registers rather than using a BIOS int 10h mode call. The expanded image has no int 10h hits. Around expanded+0x26512 it writes CRTC registers through 3D4h/3D5h; around expanded+0x26660 it writes Graphics Controller register 3CFh; and around expanded+0x26676 it uploads a small DAC table:

expanded+0x26676: mov    al, 0
expanded+0x26678: mov    dx, 0x03c8
expanded+0x2667c: out    dx, al
expanded+0x2667d: inc    dx              ; 3C9h
expanded+0x2667f: mov    esi, 0x1f108
expanded+0x26684: mov    ecx, 0x33
expanded+0x26689: rep outsb

The 0x33 byte upload is 17 RGB triples. That is enough for the black/cyan video look: a small ramp, not a full 256-color palette.

Retace And Frame Commit Path

The helper at expanded+0x26887 is a compact vertical-retrace synchronizer that also increments BL while waiting:

expanded+0x26887: mov    dx, 0x03da
expanded+0x2688b: inc    bl
expanded+0x2688d: in     al, dx
expanded+0x2688e: test   al, 0x08
expanded+0x26890: jne    0x2688b
expanded+0x26892: inc    bl
expanded+0x26894: in     al, dx
expanded+0x26895: test   al, 0x08
expanded+0x26897: je     0x26892
expanded+0x26899: ret

The frame commit path at expanded+0x267b1 waits for retrace, then copies the reduced/intermediate image into VGA memory:

expanded+0x267b1: mov    dx, 0x03da
expanded+0x267b5: in     al, dx
expanded+0x267b6: test   al, 0x08
expanded+0x267b8: jne    0x267b5
expanded+0x267ba: in     al, dx
expanded+0x267bb: test   al, 0x08
expanded+0x267bd: je     0x267ba
expanded+0x267bf: mov    esi, [0x3963]
expanded+0x267c5: mov    edi, 0xa0000
expanded+0x267ca: sub    edi, [0x18]
expanded+0x267d0: mov    ebp, [0x3967]
expanded+0x267d6: mov    ecx, 0x64
expanded+0x267db: mov    edx, 0x50

The inner loop consumes two source bytes and writes one dword twice: once at edi, and once at edi + ebp.

expanded+0x267e0: mov    ax, [esi]
expanded+0x267e3: rol    eax, 8
expanded+0x267f5: mov    ebx, [0x395f]
expanded+0x267fb: and    ebx, 0x03030303
expanded+0x26801: add    eax, ebx
expanded+0x26803: mov    [edi], eax
expanded+0x26805: add    esi, 2
expanded+0x26808: mov    [edi+ebp], eax
expanded+0x2680b: add    edi, 4
expanded+0x2681e: dec    edx
expanded+0x2681f: jne    0x267e0
expanded+0x26821: add    edi, 0x140
expanded+0x26827: dec    ecx
expanded+0x26828: jne    0x267db

The dimensions are explicit: 0x64 rows and 0x50 dword groups per row. 0x50 * 4 = 320 output bytes per row. Because each source pair becomes one dword, and each dword is written to two scanline addresses, the routine turns a small source field into a doubled 320-wide display. The added 0x03030303 dither/noise term explains some of the moving speckle visible in the public video.

Runtime-To-Code Concordance

The two public-video GIFs in this article map directly to the recovered display path.

The moving-window GIF corresponds to the aperture side of the renderer. The visible window is small, noisy, and cyan-only, and the code does not allocate or commit a clean 320x200 full-color frame for it. Instead, the setup path builds a 17-entry DAC ramp at 0x1f108, allocates a reduced work buffer at [0x3963], clears 0x1f90 dwords, and uses custom VGA register programming rather than a plain BIOS mode call. That code shape matches a low-detail clip window being expanded and tinted at display time.

The larger video-clips GIF corresponds to the content side: face fragments, king/royal material, and noisy interstitial blocks all pass through the same cyan scanline expander. The frame commit path at 0x267b1 waits for 03DAh retrace, reads the reduced source field through [0x3963], writes to A0000h - [0x18], and mirrors each generated dword to a second scanline using [0x3967]. The 0x64 by 0x50 loop proves the half-height / doubled-row model behind the public-video look.

The mosaic/noise frames are not accidental capture artifacts. The code adds a masked 0x03030303 term from [0x395f] before each dword write, which fits the moving speckle and low-bit cyan texture seen in the GIFs and stills. The small 0x33-byte DAC upload at 0x26676 also explains why the presentation stays inside a narrow cyan ramp instead of revealing hidden full-color source frames.

So the "video clips in 64K" comment is technically accurate but bounded. The intro is not storing normal video frames; it is reconstructing a video-like stream from reduced source data, a tiny palette ramp, retrace-paced commits, paired scanlines, and deliberate dither/noise. The remaining unknown is the source packing and high-level segment dispatcher, not the display strategy used by the visible GIFs.

What This Pass Proves

The recovered evidence supports these conclusions:

ROYAL.EXE is an MZ/RNC1 64K carrier with a 158,630-byte expanded runtime.
The runtime is protected-mode oriented, with 386, VCPI, DPMI, A20, and extended-memory diagnostics.
The default path uses custom VGA programming, not a visible BIOS int 10h mode call in the expanded image.
The palette is a small DAC ramp, consistent with the cyan/black visual presentation.
The main recovered display routine expands reduced video-like source data into paired A0000h scanlines under vertical-retrace control.
The direct public-video GIFs map to that display strategy: aperture/window motion, cyan video fragments, mosaic noise, 17-entry DAC ramp, 03DAh retrace pacing, and paired scanline expansion.
The public-video timeline matches that routine: aperture motion, recognizable low-detail face/king fragments, mosaic noise, doubled scanlines, and a small cyan ramp used as the compression strategy.
The public-video assets in this article are direct MP4 frame/time slices, downscaled only for page weight.

The remaining weak point is the higher-level scene dispatcher. This pass maps the carrier, expanded runtime boundary, palette/timing/display commit path, and visible video-clip strategy. It does not yet label every content segment or recover the source packing format for the individual clip frames.