Analysis model: gpt-5.5 xhigh

Second Reality by Future Crew - Technical Dissection

Scope

Second Reality is Future Crew's Assembly 1993 winning MS-DOS demo. This page does not try to re-tell the already over-documented cultural story. The useful Chronologia angle is narrower: package shape, patch behavior, runtime capture evidence, and concrete loader/resource observations from the files.

Primary artifacts used here:

The original README.1ST states that the demo was released on 7 October 1993, won the Assembly 1993 demo competition, requires a 386 with 570,000 bytes of free conventional memory, and supports Sound Blaster, Sound Blaster Pro, Gravis UltraSound, and a no-sound option. It also documents direct part starts:

Parameter Start point
1 beginning
2 title screen
3 landscape scroller
4 vector part
5 end credits

The 1994 2ndpatch.zip contains 2NDFIX.EXE. Its READ.ME describes the fix as a workaround for a motherboard timer slow-down bug that could make the demo crawl on some fast machines. The runtime captures below used that patch launcher with parameter 3 so the landscape/vector material could be reached directly.

Package Layout

Scene.org's single 2nd_real.zip combines the two historical distribution ZIPs described by the readme:

2nd_real.zip   2,122,910 bytes
README.1ST         4,222  release notes
FCINFO10.TXT      48,462  Future Crew information text
FILE_ID.DIZ          378  BBS description
SECOND.EXE     1,451,093  LZEXE-packed main executable
REALITY.FC       992,188  packed data/music/resource file

Hashes:

9dfdb9c312d736003cc363b151b6f366c481b3bd3bb78233cfff72ae677c5c95  2nd_real.zip
7fe7d8e28ceb4104a9a53310cc28f43e698446583d71f0d13016c28b7793b7a5  2ndpatch.zip
a0b637b1c6729aeee8874cb7de701f608fe6ec3028fd72652a962a3a2bd25d8f  SECOND.EXE
cffb5839d0660f646c2474ff46452543997c3fc9469fa64401556c2d271aa63b  REALITY.FC
6203fc2c67946298ce6ec8f1e4fa66e4a6d29150e1240497f66cd2cda1c72f9d  2NDFIX.EXE

SECOND.EXE is a DOS MZ executable detected as LZEXE 0.91 compressed:

file size              1,451,093 bytes
declared MZ size          27,073 bytes
header size                   32 bytes
load image                27,041 bytes
relocations                    0
entry                  CS:IP = 0651:0006
stack                  SS:SP = 0651:0074

2NDFIX.EXE is a much smaller MZ launcher:

file size                 20,459 bytes
header size                   32 bytes
load image                20,427 bytes
relocations                    0
entry                  CS:IP = 04e7:000e
stack                  SS:SP = 07c2:0080

Strings in the patch launcher include SECOND.EXE, REALITY.FC, DATA\, part names such as STARTMU2, BEGLOGO, TUNNELI, MNTSC, LNS&ZOO, and MINVB, plus STMIK/Scream Tracker support strings and soundcard setup text. That makes it more than a tiny binary patcher: it is a replacement launch path that knows the same external files and part identifiers.

REALITY.FC Starts With Music Data

REALITY.FC begins with a compact container header and then recognizable Scream Tracker module material:

00000000  10 00 00 00 a0 f8 05 00 ...
00000010  55 6e 72 65 61 4c 20 5d 5b 20 2d 20 54 68 65 20
00000020  32 4e 44 20 52 65 61 6c 69 74 79 00 ...
0000003d  53 43 52 4d

Decoded as text, the title is:

UnreaL ][ - The 2ND Reality

The first two little-endian dwords are not random padding. They point to two embedded S3M modules:

Container offset S3M title Orders Instruments Patterns Visible credit evidence
00000010h UnreaL ][ - The 2ND Reality 80 44 77 sample text says Start & End music and composed by Skaven/FC
0005F8A0h UnreaL ][ / PM 100 54 77 instrument text says By Purple Motion of, Future Crew 1993, and Big thanx to Skaven / FC

Both modules have SCRM at module offset 002Ch, tracker word 1300h, and file-format word 0002h. The first module's early sample names include HiStrings.HiQual(Marcato), Noisy StringBass (Mixed), Big Cymbal Hit (Mixed), Blipp (looped), SonixLead, and several StarShip samples. The second module starts with text-like instrument names: By Purple Motion of, Future Crew 1993, Big thanx to Skaven / FC, then greeting/name strings.

This matters for the visual clips because REALITY.FC is not just a late bitmap bundle. The runtime shell and part launcher are wrapped around a shared resource file whose first-class payloads include the music timeline. For a demo as synchronized as Second Reality, the resource boundary is part of the effect boundary.

Patch Launcher Part Names

The 1994 2NDFIX.EXE patch launcher carries a compact part-name region around file offsets 0DC6h..0E32h. It is not a clean C string table; high-bit bytes and small control bytes are interleaved with ASCII names. The readable anchors are still useful:

0DC6h  STARTMU2
0DDDh  ALKU
0DE5h  PAM
0DEAh  BEGLOGO
0DFBh  TUNNELI      ; appears across flagged/control bytes
0E13h  MNTSC
0E1Dh  LNS&ZOO
0E2Eh  MINVB

This table is the strongest available package-side map for the current runtime GIFs. The 2NDFIX.EXE 3 capture was started through the official part-start path, and the launcher contains MNTSC immediately before the LNS&ZOO and MINVB anchors. That supports the article's split between the landscape/leaf/rotozoom material and the later face/vector material without inventing recovered renderer names.

Runtime Capture

Capture environment:

Emulator:        DOSBox-X 2026.01.02 SDL2
Capture method:  DOSBox-X internal MPEG-TS/H.264 recorder
Launcher:        2NDFIX.EXE 3
Sound path:      Gravis UltraSound configured in DOSBox-X; host mixer muted
Machine:         VGA-compatible DOSBox-X default with 16 MB RAM
CPU:             normal core, 50000 cycles
Capture stream:  720x400 setup/text, then 640x400 demo graphics

The initial setup screen contains historical BBS/address/contact text and is not published. The published frames and GIFs are from the demo graphics portion after the part-3 start. ffmpeg reported recoverable H.264 decode warnings while seeking into the capture, so each published asset was visually checked before being included.

The landscape/leaf clip is a direct 640x400 slice from the part-3 capture. This is the section where a foreground silhouette/leaf layer sits over a moving, warped background. The point of the GIF is the relative motion and redraw behavior; a still does not show why the part works.

Second Reality leaf and rotozoom motion GIF

Clean still from the same section:

Second Reality leaf and warped landscape runtime frame

The later face/vector clip is another direct 640x400 slice from the same run. It shows the iconic face and orbiting/shifting object layers. This should stay as its own clip rather than being merged into a general overview GIF; the visual grammar is different from the leaf/landscape section.

Second Reality face/vector motion GIF

Clean stills from that section:

Second Reality centered face runtime frame

Second Reality close face/vector runtime frame

Why Multiple GIFs

For this demo, one sparse "whole demo" GIF would be misleading. The important engineering object is not a single renderer with different parameters; it is a chain of sharply different parts. The current page therefore uses separate motion clips for separate visual systems:

A later pass should add similarly isolated clips for the title/tunnel/vector/end sections once clean captures are available. That will be more useful than a fast montage.

First-Pass Technical Notes

The direct part-start parameters are unusually useful for analysis. Rather than recording only one long show run, each part can be captured independently and compared against its corresponding loader/resource strings. In the patch launcher, the part-name strings around STARTMU2, BEGLOGO, TUNNELI, MNTSC, LNS&ZOO, and MINVB are a practical map for choosing future capture targets.

The external REALITY.FC file is not just late-stage picture data. Its first visible payload is a Scream Tracker module with Future Crew/Skaven music metadata and instrument/sample names. The executable and patch launcher then provide the runtime shell around that data: sound setup, part selection, resource lookup, and handoff into the visual parts.

The patch note is also technically relevant. Future Crew did not describe the 1994 patch as a new feature release; it was specifically a timer compatibility fix for machines where the demo could drop to only a few frames per second. That is why this page records the patch as a capture launcher while keeping the original SECOND.EXE and REALITY.FC hashes as the main package evidence.

Runtime-To-Package Concordance

The two GIFs are mapped to package/runtime boundaries and to the patch-launcher part-name table, not to a recovered function map. That is an intentional limit: the local workspace has the 2NDFIX.EXE 3 capture, published frame slices, and stronger REALITY.FC / 2NDFIX.EXE resource evidence, but still no clean unpacked SECOND.EXE image that would support inner-loop addresses.

The leaf/landscape GIF maps to the documented part-start path rather than to a guessed renderer name. README.1ST says parameter 3 starts at the landscape scroller, and the patch launcher part-name region includes MNTSC at 0E13h near LNS&ZOO at 0E1Dh. The GIF proves separate foreground and background motion: a dark silhouette/leaf layer remains readable while the landscape/rotozoom background warps underneath it. The package-side evidence is the replacement launcher, part-name table, and shared REALITY.FC container, not a single monolithic hard-coded bitmap.

The face/vector GIF maps to a later visual family in the same part-start run. The visible evidence is different from the leaf section: a centered bitmap face is used as the stable composition anchor while orbiting/shifting vector or object layers move around it. That is why the article keeps a separate GIF for this section; merging it into one overview clip would hide the change from layered rotozoom/landscape work to face-plus-object presentation. The nearby patch-launcher MINVB anchor at 0E2Eh is useful as a later-stage marker, but without a clean SECOND.EXE image it should stay a package marker, not be promoted into a named draw routine.

The timer patch is part of the concordance. The official 2NDFIX.EXE note says the fix exists because some machines ran the demo only a few frames per second. That makes the patch launcher relevant to visual analysis: the GIFs are not just from "some emulator run", they are from the historically supplied timing workaround path, using parameter 3 to reach the landscape/vector material.

The next useful deeper pass is now narrower: produce a clean unpacked image of SECOND.EXE, then connect the patch-launcher anchors (STARTMU2, BEGLOGO, TUNNELI, MNTSC, LNS&ZOO, MINVB) to actual code and REALITY.FC payload offsets beyond the two proved S3M modules. Until that is done, assigning function names or VGA inner loops to the two GIFs would be fake precision.