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

Back to Basic by The Inferiors - Technical Dissection

Release year: 1994

Back to Basic is a 1994 MS-DOS demo released at The Gathering 1994. The competition result file lists it as Back to basic by The Interiors, while the archive NFO calls the group The Inferiors. The archive name and NFO are the basis for the title here; the result-file spelling is kept as useful context.

This is not a normal "beat the machine into submission" 1994 demo. It is a joke production whose own NFO says the group was formed only hours before the deadline and that many routines were made in BASIC. Static analysis supports the gag: the production is a launcher plus many PKLITE-packed child programs, compiled BASIC-style modules, RIX images, FastTracker modules, a font resource, and several deliberate fake-system screens.

Old private contact listings from the NFO are deliberately omitted.

Provenance

• Production: back2bas.zip
• Event: The Gathering 1994, PC demo competition
• Ranking: 4th in the TG94 PC demo result file, after Superunknown, E:XTRA, and Icefever
• Archive URL: back2bas.zip on scene.org
• Result file: TG94 results

Archive hash:

c800ecbd7c001901b439ef3b1977b29c649afb1917384089faad8b923db38794  back2bas.zip

The NFO credits CP/Master, Pizzel, Mr.C64, BitBrat, Phoney Emotion, Eschatus, A.X.L, Marvin, and MixMasterMan, and credits Modplay 1.5 by Robban/CDA for the music system.

Direct Silent Runtime Capture

I ran the untouched release under DOSBox-X 2026.01.02 with machine=svga_s3, 16 MB of memory, the normal CPU core at a fixed 20,000 cycles, and no scaler or aspect processing. The emulated Gravis UltraSound used base port 240h, IRQ 5, DMA 3, and 1 MB of onboard RAM because the launcher uses its player state while sequencing the show. Host audio was routed to SDL's dummy driver; Sound Blaster, MIDI, and PC-speaker output were disabled. Nothing was audible, and no audio stream was captured or published.

The complete emulator window was recorded directly through X11 at 640x400 and 30 frames per second with the pointer suppressed. The source frames were not cropped, padded, or stretched. The main 353.066-second video begins during the starfield after the opening slide. A separate native-window, one-frame-per- second opening pass covers bootstrap, the first RIX image, launcher text, the 3D floor, and the start of that starfield. Together they cover the full show route from process entry to the final key gate.

The scripted sequence reaches the final WE WILL BE BACK RIX image after about 4 minutes 38 seconds. It then remains there until input. I left that screen up for roughly another 98 seconds, pressed Space once, and the demo returned cleanly. This distinguishes an intentional viewer gate from a crash or a music-timing stall.

The runtime now supplies an exact visual identity for every launched child:

This ten-second continuous clip preserves the .005 drawing and fade rather than inferring motion from two stills:

The contact sheet includes only public-safe runtime frames. Old contact details and one period slur present in archive text were not reproduced.

Archive Layout

The production is a directory of numbered assets. The launcher is tiny in its packed form, but after PKLITE expansion it is much larger and clearly acts as a show runner.

The expanded launcher string table also contains BATOBA.013, but that file is not present in the archive. The recovered main path does reach its EXEC at expanded launcher offset 0377h. DOS rejects the missing filename, but the helper does not test the EXEC carry flag and the launcher continues into .014. The runtime's immediate transition into the fake boot screen confirms that this is a tolerated hole in the numbered script, not an unreachable string.

PKLITE Expansion Notes

UNP expands the executable parts into normal MZ files:

a9fbf8c83a4abc02582414686df83c1fa9685d897aae0134d6cc0f969a476eed  expanded BATOBA.EXE

The important structural split is between small C/Pascal-like image viewers and larger BASIC-family compiled modules. The larger parts start with module names such as blSTARFILD, blSCRLTEST, and bmVGAFONT, then mostly dispatch into runtime/helper far calls rather than containing one compact hand-written VGA kernel.

Offsets below are raw offsets in the relevant UNP-expanded executable unless a different basis is stated. Launcher data references use DOS's relocated MZ image: its 512-byte header is not loaded, and image-relative data segment 001Fh begins at raw file offset 03F0h.

Launcher

The launcher starts at expanded file offset 02e9h. Its first important action is DOS memory resizing:

2ee  mov ah,4ah
2f0  mov bx,0900h
2f3  int 21h

That leaves a smaller resident block so child programs and module data have room. Then it sets DS and ES to an MZ-relocated segment whose image-relative value is 001Fh and calls into the relocated player segment whose image- relative value is 0560h. The launcher contains the module format markers M.K., FLT4, 6CHN, 8CHN, and OCTA, matching the two 8-channel FastTracker modules in the archive.

EXEC Helper

The child runner lives just before the visible entry code:

21b  mov [0017h],sp
222  mov cs:[0019h],ss
239  mov ax,4b00h
23c  int 21h
23e  cli
23f  mov sp,cs:[0017h]
244  mov ss,cs:[0019h]
249  sti
24c  mov ah,4dh
24e  int 21h
250  retf

The helper saves the launcher stack, calls DOS EXEC, restores SS:SP, then asks DOS for the child's return code. This is the backbone of the production: each part is a separate executable, so the "demo script" is an ordered set of process launches.

Delay Helper

The delay routine reads the BIOS tick counter at 0040:006c and 0040:006e:

254  mov bx,0040h
257  mov es,bx
259  add ax,es:[006ch]
25e  mov bx,es:[006eh]
263  adc bx,0000h
274  mov cx,es:[006eh]
279  cmp bx,cx
27d  mov cx,es:[006ch]
282  cmp ax,cx

So the launcher delays in BIOS-clock ticks, not by busy-counting only. A later slow wait at 03cah still uses a plain nested loop, which is fitting for a joke demo.

Text Print Helper

The colorful text helper sets mode 0dh, then writes characters one by one:

28a  push dx
28b  mov ah,02h       ; set cursor
28d  xor bh,bh
28f  int 10h
291  mov ah,09h       ; write char and attribute
293  mov bh,00h
295  mov cx,0001h
299  lodsb
29c  je done
29e  int 10h
2a0  mov ax,0001h
2a4  call delay
2a7  inc dl
2a9  jmp 028bh

Another wrapper initializes mode 0dh, starts color at attribute 8, prints a line, increments the row, and cycles colors 8 through 15:

2ad  mov ax,000dh
2b0  int 10h
2b4  mov bl,08h
2b6  call print_string
2ba  inc bl
2bc  cmp bl,0fh
2bf  jbe keep
2c1  mov bl,08h
2c3  inc dh

This is intentionally BIOS-heavy. Instead of a fast font blitter, it uses INT 10h character output with a timed delay after each character.

VGA Clear

Between child parts the launcher clears mode-13h memory directly:

361  mov ax,0a000h
364  mov es,ax
366  mov cx,8000h
369  xor di,di
36b  mov ax,di
36d  cld
36e  rep stosw

8000h words is exactly 64,000 bytes, so this clears the entire 320x200 byte framebuffer.

RIX Image Viewers

BATOBA.000, .008, and .022 are small viewers for the RIX3 image files. The RIX files all have a RIX3 signature, a 320x200 size word pair, a 768-byte VGA palette, and 64,000 pixels.

BATOBA.000 and BATOBA.019 have the same first palette bytes, suggesting that the title/end images are related or share a palette template. .008 loads three RIX slides (.009, .010, .011), while .022 loads .019.

VGA Check

The viewer checks for VGA BIOS support before entering graphics mode:

439  mov ah,1ah
43b  mov al,00h
43d  int 10h
43f  cmp al,1ah

If that fails, it prints a sarcastic "no VGA" message. If it succeeds, it hides or adjusts the text cursor, sets mode 13h, allocates a 64,000 byte buffer, and loads the RIX file.

Image Copy

The key blit path is simple:

531  les di,[5a00h]   ; loaded image pixel buffer
537  xor di,di
53a  mov ax,0a000h
53d  push ax
53e  push di
53f  push 0fa00h
542  call far memcpy_like

The helper gets the loaded image buffer, destination A000:0000, and length 0fa00h (64,000). It is a straight copy into the visible framebuffer.

Palette Fade

The more interesting viewer loop is a palette interpolator. It works over 64 palette entries, three RGB components per entry. A simplified version is:

for entry in 0..63:
  for component in 0..2:
    current = fade_palette[entry][component]
    target  = image_palette[entry][component]
    if current > target:
      current -= 2
    if current < target:
      current += 2
    if current == 0xff:
      current = 0
    if current == 0x40:
      current = 0x3f

The 0xff and 0x40 repair steps make sense for 6-bit VGA DAC values: legal component values are 00h..3fh. The viewer then writes the changing palette to DAC ports 3c8h/3c9h and waits around the input status port 3dah so the fade lands on retrace-ish boundaries.

The outer fade count is 3fh, so the viewer performs 64 fade steps:

54e  inc word [0060h]
56e  cmp word [0060h],003fh
573  jne fade_step

The fade-out loop mirrors the same structure after a delay.

The final viewer has a different hold policy. After copying .019 to A000h, expanded .022 loops at 03CCh..03D3h around a linked keyboard-status helper:

3cc  call far key_status
3d1  or   al,al
3d3  je   03cch

That loop is the final key gate seen in the runtime. One Space press makes the helper return nonzero, the viewer returns to the launcher, and the process exits normally.

BASIC-Style Parts

Most numbered effect parts begin with a module name at expanded offset 0200h. The names are not ornamental; they align with compiled BASIC-style code layout and the NFO joke.

The compiler emits lots of far calls like:

push argument
push argument
lcall helper_segment:helper_offset

That is the real inner-loop shape for many parts: the BASIC entry module keeps state in near variables, then repeatedly calls runtime/helper functions for plotting, font drawing, random values, string output, and delays.

BATOBA.003: Starfield

This is the clearest self-documenting part. The binary contains short BASIC-like text snippets:

IF POINT(StarX(A),StarY(A))=0 THEN...
PSET(StarX(A),StarY(A)),StarC(A)
StarX(A)=StarX(A)-(StarC(A)*StarC(A))/100
IF StarX(A) < 0 THEN StarX(A) = 320

The compiled module sets up a count of 200 stars:

242  mov word [1048h],00c8h
248  mov word [104ah],0004h
24e  mov word [104ch],0004h

Then it initializes parallel arrays. The loop index is kept at [0056h]; the compiler multiplies it by four to reach 32-bit array slots:

313  mov ax,[0056h]
316  shl ax,2
319  mov bx,ax
31b  add ax,0058h
323  mov [bp-16h],dx
326  call array_store

The star update loop is not direct A000: plotting. It is compiled BASIC POINT and PSET behavior routed through helpers. The conceptual loop is:

for A = 1 to 200:
  if POINT(x[A], y[A]) == 0:
    PSET(x[A], y[A]), color[A]

  if POINT(old_x[A], old_y[A]) == color[A]:
    PSET(old_x[A], old_y[A]), 0

  old_x[A] = x[A]
  old_y[A] = y[A]
  x[A] = x[A] - (color[A] * color[A]) / 100

  if x[A] < 0:
    x[A] = 320

That explains the joke perfectly: a starfield that could be a handful of hand-written VGA stores is instead expressed as per-star BASIC graphics calls. The heavier colors move faster because color*color is the speed term.

BATOBA.007: Scroll Test

BATOBA.007 is a greeting scroller module. The embedded greeting string says:

GREETINGS GO TO.... TWILIGHT ZONE.... ZWILIGHT TONE....

The main module initializes a font helper and starts near the right side of the screen:

24d  mov word [0068h],0001h
253  mov word [006ah],0002h
27b  mov ax,[006ah]
27e  neg ax
280  mov [0074h],ax
283  mov ax,013fh

013fh is 319, the rightmost pixel column in mode 13h. The loop repeatedly draws and erases text at changing X positions, with a boundary check near 012fh:

337  mov ax,[0074h]
33a  add ax,[007ch]
33e  mov [007ch],ax
348  cmp ax,012fh
34b  jge draw_more
352  cmp ax,012fh
355  jle draw_more

The embedded bmVGAFONT module is the real pixel helper. It checks font setup, initializes output state, and uses bit masks such as 0010h, 0020h, and 0040h to choose which pixels of a glyph row should be plotted. Again, the outer loop is BASIC-like and the low-level pixels live in a helper module.

BATOBA.012: BASIC Instincts

This module is mainly a title/text section. It contains:

BACK TO BASIC
BASIC INSTINCTS
PURE BASIC CODE!
THE GATHERING 94

The module first opens a graphics mode through its helper layer, then repeatedly draws text with bmVGAFONT. Static structure mirrors .007: module-local variables set positions and loop bounds, while the font module performs the actual glyph plotting.

The inner loop is therefore not a raw span filler. It is a BASIC text layout loop:

set x/y
call font_draw(text, x, y, color)
change x/y or color
repeat until the local counter reaches its bound

For a serious 64K this would be wasteful. In this demo, the waste is the point.

BATOBA.005: Fade Basic

BATOBA.005 carries the module name blFADEBAS and a long BASIC DRAW-style path string:

E20R60F20D40L30U20H5L30G5D120F5R30E5U20R30D40G20L60H20U160

The start of the module sets graphics mode through helper calls, prepares integer and floating values, and repeatedly calls runtime math and drawing helpers. The effect is exactly what the name suggests: a BASIC graphics drawing part with fading around it. The static code is a sequence of helper dispatches around local temporaries rather than a hand-written pixel loop:

open graphics helper
initialize numeric temporaries
interpret/draw the BASIC path string
adjust palette or colors through helper calls
repeat until the local loop counter expires

The meaningful point is that the line art is stored as a BASIC path string instead of as direct line endpoints or raster data.

BATOBA.002: 3D Floor

BATOBA.002 is labelled bl3DFLOOR3. It starts by opening the graphics helper and pushing constants that include IEEE-style 32-bit float encodings such as 3f800000h (1.0) and 41400000h (12.0):

push 0001h
push 0007h
push 0000h
push 0001h
...
push dword 3f800000h
call numeric_graphics_helper
push dword 41400000h

That tells us this is a high-level numeric renderer. The part has a lot of runtime rep movs/stos support code and many output-port writes in helper areas, but the entry module itself is a call graph of coordinate/math helpers. In practice the 3D floor's inner work is:

calculate per-row or per-point floor coordinates through helper math
call a line/span/draw helper
repeat for each visible row or strip

This is why the code looks so different from a hand-written texture mapper: the per-pixel work is hidden behind a thick BASIC/compiler support layer.

BATOBA.004: Rule World and Test2

BATOBA.004 is the largest executable in the set after expansion and contains two labelled modules, blRULEWRLD and blTEST2. The first module starts with graphics initialization, calls into a helper segment, and jumps into a long body. The second labelled body appears much later in the file and starts another graphics-oriented routine.

The binary also contains direct VGA helper code: it loads A000h, touches DAC port 3c8h, and has many rep movsb, rep movsw, rep stosb, and rep stosw blocks. So .004 is a mixed case:

• BASIC-style outer logic and module metadata
• compiled helper code for framebuffer copies, clears, and palette writes
• at least two logical routines linked into one MZ

The useful reading is that .004 is not "pure BASIC source running under an interpreter"; it is compiled BASIC-family code linked with graphics support that drops to normal real-mode VGA helpers where needed.

BATOBA.006: Offbeat

BATOBA.006 combines blOFFBEAT with bmVGAFONT. It includes strings around the font toolkit and the line:

that's why the spectrum isn't

It has the same graphics/font helper pattern as .007 and .012, plus optional x87-related runtime strings (MSEM87, NO87=). The module start pushes a cluster of mode/color arguments, then calls a graphics helper, then positions text/font data.

The inner loops are font and palette work rather than raw polygons:

initialize graphics state
load or bind VGA font data
for each text step:
  compute position
  call glyph plot helper
  optionally adjust palette or wait

BATOBA.016: Greetings and Font Resource

BATOBA.016 is labelled blGREETING and references BATOBA.017. The .017 file is a Windows real-mode font resource containing Courier strings, so the greeting part appears to use an external font file as part of the joke.

The module also contains NOEMS, MSEM87, and NO87= strings, meaning the linked runtime can test EMS and x87 availability. The visible text includes "Some/one more greeting(s)" and "Vote Inferiors!".

The greeting module starts with a short repeated helper-call loop:

261  mov ax,0001h
264  jmp 02e5h
268  call helper_1380h
...
2e1  mov ax,[0056h]
2e4  inc ax
2e5  mov [0056h],ax
2e8  cmp ax,0064h
2eb  jle 0268h

0064h is 100, so this is a hundred-step setup/animation loop. Later it loads font/text resources and repeatedly calls into bmFONT drawing helpers. It is a greetings part built as high-level text choreography, not as a bespoke scroller kernel.

BATOBA.018: Fake Newton Disk Doctor

BATOBA.018 is labelled blFAKENDD and contains the visible string "Newton Disk Doctor". It creates a fake system-tool screen with random-looking values, status rows, and disk-error themed text.

The module initializes a text/graphics helper layer, then enters a nested loop. The inner loop repeatedly queries a helper, compares against 004eh (78), and keeps writing characters until a row is filled:

324  push 009eh
327  call print_or_place
32c  call helper_0020h
332  call helper_0037h
337  cmp ax,004eh
33a  jg row_done
...
3bf  jmp 032ch
3c2  push 000dh
3c4  call append_newline
3cf  mov ax,[005ch]
3d2  inc ax
3d3  mov [005ch],ax
3d6  cmp ax,000dh
3d9  jle next_row

So the fake utility is a row builder. It calls into helper functions for random or calculated values, writes a row until the column limit, appends a newline, and repeats for 13 rows.

BATOBA.014: Fake Boot and GW-BASIC

BATOBA.014 contains the strings:

ERICCSON PORTABLE PC VERSION 1.23
PC-DOS 2.11
GW-BASIC v.1.5

This is a fake old-PC boot sequence. Static code shows mode 03h and 13h setup calls, plus ordinary text output support. It is not trying to be a visual showpiece; it is another gag that reinforces the "back to BASIC" premise.

BATOBA.015: Unlabelled VGA Part

BATOBA.015 is less self-documenting. It has no useful ASCII module name in the expanded file, but pattern scanning finds:

• mode 13h setup
• A000h framebuffer use
• DAC port 3c8h
• a 3dah wait
• a small number of clears/copies

Those signatures alone only support a short transition or simple visual part. Runtime supplies the missing identity: it is the rotating BACK 2 BASIC logo over a starfield. The capture resolves the visible role without pretending the remaining static signatures reveal its complete drawing algorithm.

Music

The two music files are not ordinary four-channel MODs:

• BATOBA.020: Main2-chip echo
• BATOBA.021: World of delight

Both are detected as 8-channel FastTracker modules. The launcher links a player with module-type strings for M.K., FLT4, 6CHN, 8CHN, and OCTA, and the NFO credits Modplay 1.5. The launcher calls into the player before and between parts, so its internal timing/player state is centralized rather than duplicated in every child program. Audio was deliberately inaudible in the runtime pass and is not evaluated here.

Exact Recovered Show Script

The earlier approximation can now be replaced by the actual launcher path. For a data reference DS:DX, raw expanded-file offset is 0200h + 01F0h + DX. That maps player path offsets 0000h and 000Bh to BATOBA.020 and .021, and the first child offset 0016h to BATOBA.000.

1. 02FCh..030Eh initializes the player, loads .020, and starts the first module state.
2. 0313h executes .000; 031Ah prints the opening joke line and 0321h waits 54 BIOS ticks.
3. 0328h, 032Fh, 0336h, and 033Dh execute .002, .003, .004, and .005 in that exact order.
4. 0344h prints the first colored launcher text block with the BIOS-heavy mode-0Dh helper.
5. 0348h and 034Fh execute .006 and .007; 0356h prints the second colored launcher block.
6. 035Ah executes .008, then 0361h..036Eh clears all 64,000 bytes of mode-13h video memory.
7. 0370h executes .012. 0377h attempts missing .013; the unchecked failure falls through. 037Eh updates player state and 0383h executes .014.
8. 038Ah..03A1h stops/reinitializes the player and loads .021.
9. 03A6h, 03ADh, 03B4h, and 03BBh execute .015, .016, .018, and .022.
10. After the final viewer's key gate returns, 03C2h..03D6h performs the launcher's short player-state countdown, 03D8h restores text mode, and 03E7h exits through DOS.

The sequence is not elegant in the "one tight engine" sense. Its architecture is the joke: many separate executables, many compiler runtime calls, BASIC-like graphics statements, RIX slides, and system parodies glued together by a small launcher.

Why It Matters

Back to Basic is useful because it inverts the usual 1994 PC demo values. A top demo from the same event wants tight protected-mode code, custom resource systems, direct VGA tricks, and a small number of fast engines. This demo instead puts the overhead in plain sight:

• DOS EXEC part chaining
• PKLITE-packed child files
• BIOS text output in the launcher
• RIX image viewers with palette fades
• compiled BASIC-style POINT, PSET, DRAW, and font calls
• fake boot and disk-tool screens
• a real but tolerated EXEC attempt for the archive's missing .013

The result is fancy in a very different way: it is technically literate enough to fake incompetence convincingly. The starfield is the best example. It knows exactly how a fast starfield should be done, then expresses it as BASIC POINT/PSET work anyway.