Technology in 1997

What kind of computer did people play Next Space on in the summer of 1997? To today’s reader it seems a small miracle that the game worked at all. For the people who made it, it was a daily struggle with memory, speed and reading data from the CD.

What comes from the files and what is context. The numbers about the game (12 MB of RAM, the VESA mode, the streaming speed) come from the game’s files and from our analysis of the program. Passages marked Period context are general historical notes, not facts about the game.

DOS and 32-bit mode

The game runs from DOS, an operating system that was already slowly on its way out in 1997, although games went on being made for it for a long time. The reason was practical: DOS gave a program almost everything the computer had, with no interference from Windows.

The problem is memory. By design, DOS understands only the first 640 kilobytes of RAM, and a game that needs twelve megabytes will not fit into that. The solution is a DOS extender: a small program that switches the processor into 32-bit protected mode and lets the game use all of the memory. Next Space uses DOS/4GW, which is supplied on the CD.

The game is therefore made up of three parts:

• NEXT.EXE, a small launcher (10 KB, compiled with Borland C++). It runs the game in a loop, so when the player chooses a new game from the menu, the game simply quits and starts again.
• NEXT.DAT, the game itself (284 to 289 KB), a 32-bit program written in Watcom C/C++. Watcom was a popular compiler for 32-bit DOS games at the time. Period context: Doom, for example, was also developed with it.
• SETUP.EXE, the installer, which writes the settings to the next.cfg file.

Twelve megabytes

According to PROBLEMY.TXT (“Problems”), a file the makers included on the CD, the game needs at least 12 MB of memory. Anyone with only eight was apparently out of luck: “under DOS, the game NEXT SPACE requires at least 12 MB of RAM.” The file advised running the game from Windows 95 and, in the DOS application settings, switching DPMI memory from automatic to 12 MB.

What does the game need the memory for? The biggest items:

For comparison: today’s phones have roughly a thousand times as much memory, and an ordinary photo taken on one takes up more than this entire working block.

Display: 640 × 480 and 256 colours

The game uses graphics mode VESA 0x101. In plain terms: 640 pixels wide, 480 high and 256 colours at once. Those 256 colours are chosen from a palette that each room carries with it. This let the authors paint every room in its own colours, but the game had to recolour the whole screen every time the room changed.

That said, the first 56 colours are the same in every room. They are used by the inventory icons, the cursors and the characters. The remaining 200 colours always belong to the room Frank is currently in.

A room takes up 640 × 400 pixels. The bottom 80 lines form a bar for the inventory and text. Animations are slightly shorter: 640 × 300 pixels.

One more detail: at the time, a graphics card’s memory could not be addressed all at once. The program had to draw to it through a 64 KB window and switch between five “banks”. The game did not redraw the whole screen, however: in each frame it refreshed only the four-pixel segments that had changed.

Sound: Sound Blaster

In the 1990s the sound card was almost always a Sound Blaster or a clone of one. Setting it up was an ordeal for the average user: you had to know the card’s address, its interrupt number (IRQ) and its DMA channel. PROBLEMY.TXT explains where to find them in Windows 95: My Computer → Properties → Device Manager. It also warns that the game does not work on interrupt 10 (the music and animations occasionally freeze). You have to use 5 or 7.

The game has its own sound card driver (as well as the Sound Blaster, it also supports the Gravis UltraSound card) and a software mixer that plays six sounds at once at 22,050 Hz. This means that a single screen can play, say, a voice, a sound effect and music at the same time.

Sound is 8-bit mono. The music is also compressed to 4 bits using ADPCM (see What Was Unique).

CD-ROM: half a gigabyte and drive speed

Next Space came out on a CD holding 504 MiB of data (the Czech version) or 511.2 MiB (the Slovak one), of which:

• 190 MB is 3D animation (25 files),
• 225 MB (Czech version) to 231 MB (Slovak) is the voice track,
• 30 MB is music (20 tracks),
• 56 MB is data for rooms, characters and scripts (DATA).

Today, half a gigabyte is a trifle. Period context: in 1997 a typical hard disk held 1 to 3 GB, and a CD, at around 650 MB, was the largest medium that could be produced cheaply. The game reads the bulky data (voices, music and animations) on the fly, straight from the CD, which it identifies by its volume label, NEXTSPAC.E. According to the table in a review in Score magazine, 32 MB of hard disk space is enough.

That raises the question of speed. Drive speeds were given as multiples at the time: 1× meant 150 KB per second, 2× 300 KB, 4× 600 KB and so on. Period context: 4× to 8× drives were common in 1997.

How much data did the 3D animations need? We worked it out: all 25 files total 199,343,401 bytes and run for 505 seconds in all, an average of 395 KB per second (sound included). That is more than a 2× drive can handle. Smooth playback therefore needs at least a 3× drive, and a 4× to be comfortable. The most demanding animation is the wormhole: 24 MB in 53 seconds, or 455 KB per second.

Why streaming was crucial

You cannot load 190 MB of animations and 225 MB of voice recordings into 12 MB of memory. That is why the game reads everything large on the fly, in small chunks, exactly when it needs it.

• Voices. Each line is looked up by its number and read from the CD as it plays. The voice track needs only 22 KB per second, a fraction of what an ordinary disk can handle today.
• Music. This is read in 8 KB blocks and decoded as it plays.
• Videos. The player reads the file as a continuous stream and, after each frame, gets a small chunk of sound. Picture and sound therefore always stay in sync.
• Keeping the drive spinning. The program also contains a function that reads a small block from the CD every now and then, apparently so that the drive does not go to sleep and have to spin up again for the next line.

Processor and timing

The game’s files do not say what processor it needed, but magazines of the time all put it in the 486 class (see below). Period context: a typical gaming PC in the summer of 1997 had a Pentium processor clocked at 100 to 200 MHz.

The game runs at exactly 20 frames per second. It is driven by a 100 Hz timer: five ticks make one frame. Because the game follows the timer rather than the processor speed, it runs at its original pace.

System requirements according to magazines of the time

Peter Hegyi does not remember the minimum configuration printed on the box, so we tracked it down in contemporary reviews held in the OldGames.sk archive:

The figures differ slightly. On memory, PROBLEMY.TXT on the CD is unambiguous: under DOS you need 12 MB (8 MB is enough only in a Windows 95 window after adjusting DPMI). The game needed 256-colour SVGA graphics, as Riki also says. Our calculation of the animations’ data rate above shows that a 2× drive is borderline. Level gives 2× as the minimum; 4× would be more comfortable.

Price at launch: the advert for the game in Riki 28 gives a recommended retail price of 799 Sk (Sk = Slovak koruna, the currency at the time). The game was sold in shops and could also be ordered by phone from Magic Systems and Maxtech.

Windows 95 and new graphics cards

The game came out just as users were moving from DOS to Windows 95, and PROBLEMY.TXT reflects that. The authors describe six problems that players might come across:

1. automatic sound card detection does not work,
2. the card is set to interrupt 10 and the game freezes,
3. the game will not start with 8 MB of memory,
4. the controls freeze after a button is pressed (the corridor outside the androids’ flat, the elevator),
5. the 3D animations flicker (new cards such as the Matrox Mystique have a differently written VESA BIOS; fix: SciTech Display Doctor from the UTILS folder),
6. the mouse pointer sometimes jumps to the bottom left-hand corner (fix: a different mouse driver, for example GMOUSE).

With the fourth problem, the authors admit the bug and promise: “A patch for this bug should come out soon.” Three months later, in September 1997, the Czech version came out, in which the authors had fixed 14 rooms. According to our data, however, they did not fix the freeze from this fourth problem (the controls at the elevator in room 36): the fix addressed a different freeze, in room 37 (double-clicking a closed door). In the end, it was we who fixed the elevator bug. As Peter Hegyi confirmed, patches for the game really were distributed via gaming magazines.

Who worked on it

As Peter Hegyi recalls, the whole core of the game was written by Michal Hegyi. Michal Weis and Michal Horka wrote various routines, among them a machine-code video player that could play animations from the CD at 20 frames per second (see Magic Systems). You can read how the game’s machine code made its way into today’s web browsers on the Play Online page.