Analysis model: GPT-5 (Codex), reasoning level not exposed

Last edited: 2026-08-30

Slave Den BBS (4) by International Network of Crackers and The Humble Guys - Technical Dissection

Slave Den BBS (4) is a 12 October 1990 MS-DOS board-ad intro distributed with International Network of Crackers' release material for Spirit of Excalibur. Demozoo classifies it as a BBStro rather than a cracktro because the package's only executable is the board-ad viewer. The surviving ZIP also contains the game-release note, INC information and credits files, so the software-bundle association is present in the artifact itself rather than inferred from a similar screenshot.

Release year: 1990.

This is a complete pass over the four authored screens and the exit card. The original LZEXE-packed program was run under DOSBox-X with scripted key input, returned normally, and was then restored and followed through its file setup, four-record read loop, direct text-memory writes, prompt overlay, BIOS key gate, EOF test, close and final text-mode cleanup. There is no realtime graphics renderer hidden behind the elaborate artwork: each screen is a complete 4,000-byte B800h character/attribute snapshot.

Old board numbers and postal/contact material in the package are deliberately not reproduced. The four published runtime frames stop short of the final contact card.

Sources

Demozoo production page: https://demozoo.org/productions/164059/
Scene.org archive: https://archive.scene.org/pub/demos/compilations/lost_found_and_more/bbs/slave_den_bbs4.zip
Scene.org BBS collection: https://archive.scene.org/pub/demos/compilations/lost_found_and_more/bbs/
Fabrice Bellard's LZEXE page and original source releases: https://bellard.org/lzexe/

Demozoo gives the 12 October 1990 date, the MS-DOS platform, the INC/THG group credit, the Slave Den advert identity and the textmode tag. It also notes the classification ambiguity: other catalogues call the package The Spirit of Excalibur and list it as a cracktro, while the executable itself is a collection of BBStro screens.

Examined Package

The examined archive and members are:

bbf7bd6220aa8d6616fe436e7e3c3462731a76587478d37c377b6244b082d16b  slave_den_bbs4.zip

0d7c8eab09a62003ab3e1935dcb9dad41755f24157903e5c5e1bdb465c87843d  CREDITS.INC  3,057 bytes
04c0b94a186b98598897d595d52c222edbd8af0d4b95ea1944a9ee91f037469e  EXCALIB.NFO  1,615 bytes
91736e8624a0a9757395e0182e10c95953c246dc5c456d1148167b9ebff90f88  INFO.INC     2,087 bytes
7998817f67f49f0958b3907511c81c0de08e91287e2f667bc3b4eebd8cbe4206  RUNMENOW.COM  3,857 bytes
85d6e196d4baa2a4cdfa2fc4b1acc0334443dec344d1e888db2017cf7eeff63a  SLAVES.DAT   16,000 bytes

The member timestamps range from 19 September to 12 October 1990. EXCALIB.NFO identifies INC's Spirit of Excalibur release and INFO.INC names the same game, supplier, cracker and package roles. Those text files also contain extensive old contact material, so they are used only for identity and provenance here.

RUNMENOW.COM has a misleading extension. It begins with MZ, is a normal DOS EXE, and carries the LZ91 marker. Bellard's LZEXE history dates version 0.91 to the beginning of 1990, which is consistent with this October release.

Complete Silent DOSBox-X Run

The direct run used DOSBox-X 2026.01.02 on 30 August 2026 with machine=svga_s3, fixed 3,000 cycles and the exact packed RUNMENOW.COM plus SLAVES.DAT from the ZIP. DOSBox-X AUTOTYPE supplied four Enter keys at bounded intervals. Host audio used SDL's dummy backend; the mixer, Sound Blaster, MIDI and PC speaker were disabled. The intro does not need audio.

The capture starts immediately before program launch. It reaches all four screens, accepts the fourth key, prints the final text card and returns to DOS. The private MPEG-TS diagnostic has an empty AAC stream generated by the capture container and is not published. The four stills come from its video stream. DOSBox-X captured 720x400 samples with a 20:27 sample aspect ratio; the PNGs are nearest-neighbour 720x540 square-pixel presentations of the complete frame, without cropping or padding.

At 00:01, the first 4,000-byte record is already visible. It is a block-art courier/modem title, not a font or bitmap loaded into a graphics mode:

Slave Den BBS 4 first text-mode title record at 00:01

At 00:03, one Enter key has advanced to the second record. The large Slave Den lettering, sword and smoking object are all CP437 characters with per-cell foreground/background attributes:

Slave Den BBS 4 Slave Den title record at 00:03

At 00:06, the third record fills most of the 80x25 page with a face assembled from block and shading characters:

Slave Den BBS 4 face record at 00:06

At 00:09, the fourth record supplies its own blue background and red/yellow letter art. The red prompt at the bottom is not stored in SLAVES.DAT; the program overlays it after each record read:

Slave Den BBS 4 fourth text-mode record at 00:09

No animation is published because the authored states are static and key-gated. A GIF would merely hold four still pages for arbitrary durations and would obscure the more important fact that the runtime performs four discrete 4,000-byte file reads.

Packed And Restored MZ Shapes

The original file's MZ header describes the entire packed file:

packed file size / declared size   3,857 bytes
header                              32 bytes
packed load image                 3,825 bytes
relocations                           0
entry CS:IP                    00D7:000E
entry file offset                  0D9Eh
stack SS:SP                    013A:0080
marker at file 001Ch                LZ91

The POSIX port of the public-domain UNLZEXE utility restored a conventional relocatable image:

6dc8968cb1b6ec5df23c1aba7454ae29337c83e65c47e77b48925b860b91c093  restored EXE

restored file / declared size      4,848 bytes
header                              512 bytes
load image                         4,336 bytes
relocations                            32
entry CS:IP                     0000:0074
entry file offset                   0274h
stack SS:SP                     013D:4000
overlay bytes                           0

The 32 restored relocation entries matter because the program is divided into the small application body, a CRT/text module and a Pascal-family file/runtime module. In the disassembly below, a far call such as 007B:07A5 means linear load-image offset 0F55h before the DOS load segment is added.

The restored image uses Pascal short strings, file-variable records and the familiar Runtime error ... at ... support text. This is enough to identify a Borland Pascal-family runtime shape; it does not establish an exact compiler version.

The Data File Is Exactly Four Text Pages

SLAVES.DAT is not compressed and has no header:

16,000 bytes = 4 records * 4,000 bytes
4,000 bytes  = 80 columns * 25 rows * 2 bytes per cell
cell byte 0  = CP437 character
cell byte 1  = text attribute

The record hashes and active-cell counts are:

record 1  ac663d74ad1c5c2d9f5f503aa23e9b401faa0aafdcc4f23d21886a77515ba6b5  705 non-space cells
record 2  af167834e3a5a584aa286779c46a24d7e11d192991c33f112ee818aa66092a0e  364 non-space cells
record 3  fc39e7bfde77c17121555315cded11924ba20c7bf5cab5b8c9898304d187f8a7  949 non-space cells
record 4  48a8de5044706e6b96ad32cca31377a58efe831f3dae5e59075435e170b16f31  610 non-space cells

None of the 8,000 attribute bytes has bit 7 set, so the four data pages do not request hardware blink. Attributes above 0Fh are background-colour choices. That distinction is visible in the third and fourth records: their large colour fields are cell backgrounds, while the faces and letter edges are CP437 glyphs.

File Setup And Record Size

The application entry begins at load offset 0074h. Its first two far calls initialize the Pascal runtime and CRT module. It then binds a file-variable record at DS:003Eh to the short string at CS:0000h:

0081  mov  di,003Eh
0084  push ds
0085  push di              ; file variable
0086  mov  di,0000h
0089  push cs
008A  push di              ; 0Ah,"Slaves.Dat"
008B  call 007B:06C2       ; runtime Assign

0090  mov  di,003Eh
0093  push ds
0094  push di
0095  mov  ax,0FA0h
0098  push ax              ; record size = 4,000
0099  call 007B:06F0       ; runtime Reset/Open

The target at restored linear 0E72h constructs the runtime file record. It zeros the record, installs the runtime file-handler pointer D7B0h, clears 22 words of state and copies at most 79 bytes from the Pascal short string:

0E7E  xor  ax,ax
0E80  stosw
0E81  mov  ax,D7B0h
0E84  stosw
0E85  xor  ax,ax
0E87  mov  cx,0016h
0E8A  rep  stosw
0E8C  lodsb                 ; short-string length
0E8D  cmp  al,4Fh
0E8F  jbe  0E93h
0E91  mov  al,4Fh
0E93  mov  cl,al
0E97  rep  movsb
0E99  xor  al,al
0E9B  stosb                 ; ASCIIZ filename terminator

The open path at 0EA0h issues DOS INT 21h/AH=3Dh; after success it stores the DOS handle in file-record offset +00h, the open marker at +02h, and the caller-supplied 0FA0h record size at +04h. That +04h field later becomes the exact CX value for every screen read.

EOF Is A Measured File-Position Test

The loop does not carry a hard-coded screen counter. At 009Eh it calls the runtime EOF function at linear 1055h:

009E  mov  di,003Eh
00A1  push ds
00A2  push di
00A3  call 007B:08A5       ; linear 1055h
00A8  or   al,al
00AA  jne  00F7h           ; close after current offset reaches file size

The helper behind that Boolean obtains the current and final offsets using DOS seek calls and restores the original position:

1078  xor  cx,cx
107A  xor  dx,dx
107C  mov  bx,es:[di]      ; DOS handle
107F  mov  ax,4201h        ; seek 0 from current: tell
1082  int  21h
1084  push dx
1085  push ax

1086  xor  cx,cx
1088  xor  dx,dx
108A  mov  bx,es:[di]
108D  mov  ax,4202h        ; seek 0 from end: size
1090  int  21h

1092  pop  bx              ; saved current low word
1093  pop  cx              ; saved current high word
1094  push dx              ; preserve end position
1095  push ax
1096  mov  dx,bx
1098  mov  bx,es:[di]
109B  mov  ax,4200h        ; restore current position
109E  int  21h

The wrapper at 1055h subtracts the final offset from the current offset and returns true when the current position is at or beyond EOF. For the examined 16,000-byte file, this turns the loop exactly four times without embedding the number four in the application code.

One Read Is One Complete Visible Screen

When EOF is false, the application passes the file variable and the literal far destination B800:0000 to the runtime read routine:

00AC  mov  di,003Eh
00AF  push ds
00B0  push di              ; file variable
00B1  mov  si,B800h
00B4  mov  es,si
00B6  mov  di,0000h
00B9  push es
00BA  push di              ; destination B800:0000
00BB  call 007B:07A5       ; linear 0F55h
00C0  add  sp,0004h

The runtime target is a thin DOS read wrapper. There is no intermediate page, decode loop or per-cell compositor:

0F55  mov  ah,3Fh          ; DOS read
0F61  push bp
0F62  mov  bp,sp
0F64  les  di,[bp+0Ah]     ; file variable
0F6C  push ds
0F6D  push dx
0F6E  lds  dx,[bp+06h]     ; caller's B800:0000
0F71  mov  cx,es:[di+04h]  ; 0FA0h = 4,000 bytes
0F75  mov  bx,es:[di+00h]  ; DOS handle
0F78  int  21h
0F7C  jb   0F84h
0F7E  cmp  ax,cx           ; short read is an error
0F80  je   0F87h
0F82  mov  ax,dx
0F84  mov  [0036h],ax      ; runtime I/O error state

The common path therefore performs one DOS call and replaces all 2,000 visible character/attribute words at once. Its write count is exactly 4,000 bytes per page and 16,000 bytes across the four authored records. The only later writes to those pages are the prompt characters and normal CRT cursor state.

Prompt Placement And Key Gate

After each read, the code calls the CRT GotoXY implementation at linear 03A5h with one-based coordinates (29,24), selects colour 12 and writes the 25-byte Pascal short string beginning at CS:000Bh:

00C3  mov  al,1Dh
00C5  push ax
00C6  mov  al,18h
00C8  push ax
00C9  call 0019:0215       ; GotoXY(29,24), linear 03A5h

00CE  mov  al,0Ch
00D0  push ax
00D1  call 0019:0259       ; TextColor(12), linear 03E9h

00D6  mov  di,01D6h
00D9  push ds
00DA  push di              ; CRT text-output record
00DB  mov  di,000Bh
00DE  push cs
00DF  push di              ; prompt short string
00E0  xor  ax,ax
00E2  push ax
00E3  call 007B:0684       ; string writer, linear 0E34h

The string writer at 0E34h reads the leading Pascal length, emits optional padding and then sends exactly that many characters through the CRT output handler. This is why the bottom prompt remains red even though every SLAVES.DAT record has its own unrelated attribute palette.

The actual gate at linear 049Ch is BIOS-based:

049C  mov  al,[00D3h]      ; pending extended-key byte
049F  mov  byte [00D3h],0
04A4  or   al,al
04A6  jne  04BAh
04A8  xor  ah,ah
04AA  int  16h             ; AH=00h: wait for key
04AC  or   al,al
04AE  jne  04BAh
04B0  mov  [00D3h],ah      ; preserve extended scan code
04B4  or   ah,ah
04B6  jne  04BAh
04B8  mov  al,03h

The main loop stores the returned key byte at DS:00C0h but does not branch on its value. Enter, Escape or any ordinary key advances exactly one record.

Close, Final Card And Normal Return

After the fourth key, the next EOF check succeeds. 00F7h..0100h calls the runtime close path. At linear 0F21h it validates the file marker, issues DOS INT 21h/AH=3Eh for handles above the standard-device range, and restores the closed marker.

The application then clears the active text window through the CRT routine at 0352h:

0352  mov  ax,0600h        ; BIOS scroll-up, AL=0 means clear
0355  mov  bh,[00C8h]      ; current text attribute
0359  mov  cx,[00CAh]      ; window top-left
035D  mov  dx,[00CCh]      ; window bottom-right
0361  call 0798h           ; INT 10h wrapper
0364  mov  dx,[00CAh]
0368  call 068Ch           ; reset cursor to window origin

It writes a white sentence at the upper left, a magenta board name near the middle, and a yellow historical contact line below it. The latter is why no exit-card frame is published here. Finally the program positions the cursor at the bottom-left and returns through the Pascal runtime exit at 007B:00D8. The DOSBox-X capture observes that normal return; no timeout or forced kill was needed for the complete run.

Runtime-To-Code Concordance

Runtime evidence	Recovered mechanism	Conclusion
Four discrete full-screen states at `00:01`, `00:03`, `00:06` and `00:09`	`SLAVES.DAT` is exactly four 4,000-byte records; EOF is checked by current/end file positions	The authored sequence is file-length driven, not a hidden screen counter or animation timer.
All four states use 80x25 block/shading characters and cell backgrounds	Every record is 2,000 `(character,attribute)` words; no attribute has the blink bit	The apparent illustrations are static CP437 text art, not EGA/VGA bitmaps or a custom font.
Each key reveals a completely new page with no wipe	`0F55h` reads `CX=0FA0h` directly into `B800:0000`	One DOS read replaces the complete visible text page.
The same red prompt overlays unrelated palettes	The application executes `GotoXY(29,24)`, `TextColor(12)` and the runtime string writer after every file read	The prompt belongs to code, not to any of the four data records.
Enter and Escape both advance one page	`049Ch` waits through BIOS `INT 16h`; the returned byte is stored but never tested	The four gates are “any key” gates exactly as advertised.
The fourth key reaches a separate text card and DOS	EOF succeeds at 16,000 bytes; close, BIOS clear, final writes and Pascal runtime exit follow	The observed run covers the full authored route and normal cleanup.

The main preservation result is therefore pleasantly simple: the release is real, the software-bundle provenance is internally supported, and the fancy screens are four raw colour-text snapshots presented by a small LZEXE-packed Pascal viewer. The runtime and restored code agree down to the page size, screen count, destination segment, prompt coordinates and key-to-page cadence.