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: ```text 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](images/slave-den-bbs4-runtime-00-01-title.png) 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](images/slave-den-bbs4-runtime-00-03-slave-den.png) 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](images/slave-den-bbs4-runtime-00-06-face.png) 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](images/slave-den-bbs4-runtime-00-09-shrooms.png) 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: ```text 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: ```text 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: ```text 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: ```text 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`: ```asm 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: ```asm 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`: ```asm 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: ```asm 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: ```asm 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: ```asm 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`: ```asm 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: ```asm 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`: ```asm 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.