Coverdisc

Retro PC gaming, the mod scene and keeping old files alive

  • Running a period-accurate machine versus emulating one

    Running a period-accurate machine versus emulating one

    Two routes lead to running software from twenty-five years ago. Assemble hardware from the period, or emulate it on a current machine. Both work. They suit different purposes, and the choice is worth making deliberately rather than by default.

    The case for real hardware

    Period hardware gives behaviour that is correct by definition, because it is the thing being reproduced. Timing, audio hardware quirks, video output characteristics and input latency are all simply what they were.

    Audio is where this shows most clearly. Sound cards of the era had distinctive characteristics from their synthesis chips and analogue output stages. Emulation of these has improved enormously and remains an approximation of something that varied between individual cards and even individual units.

    Display output matters too. Games designed for cathode ray tubes assumed the way those displays handled scan lines and colour bleed, and some art depends on it in ways that look different on a sharp flat panel.

    The costs, which are not only financial

    • Components fail. Capacitors degrade, drives lose alignment, disks develop errors. Maintenance is ongoing, not one-off.
    • Getting data onto the machine is a project of its own, since interfaces have moved on.
    • Specific combinations of hardware still need the driver and configuration work the era demanded.
    • Space and power are real constraints that get underestimated at the planning stage.

    The maintenance point is the one most people underestimate. A working period machine is not a stable state but a process. Anyone whose actual goal is playing games rather than maintaining hardware should be honest about which activity they are signing up for, because it is largely the second.

    The case for emulation

    Emulation is available immediately, costs nothing, and has enormous practical advantages: save states, adjustable speed, straightforward file transfer, no maintenance and no failure of irreplaceable parts.

    It is also, for a great deal of software, accurate enough that the differences are undetectable in play. Mature emulators for well-documented systems have had decades of work and correct behaviour that was originally wrong.

    The remaining gaps are narrow and real. Analogue audio character, precise timing in edge cases, and anything depending on undocumented hardware behaviour are where approximations persist. For most purposes these do not matter. For verifying a specific claim about how something behaved, they might.

    A workable way to choose

    The question that resolves it is what you are actually trying to do.

    • Playing games for enjoyment: emulate. The convenience advantage is enormous and the fidelity gap is small.
    • Verifying a specific behaviour or timing claim: real hardware, or at minimum a second emulator to cross-check against.
    • Enjoying the hardware itself as an object: real hardware, and the maintenance is part of the appeal rather than a cost.
    • Archiving media: real hardware, since reading original disks and discs properly needs original drives.

    That last one is worth separating out. Reading a floppy or an unusual disc format correctly is a hardware job, and it is time-sensitive in a way the others are not. Media degrades, and drives capable of reading it are becoming scarcer. Anyone holding original media that has never been imaged has a task with a deadline, whatever they decide about playing the games.

    The middle path most people end up on

    In practice a lot of people run emulation for everyday use and keep one modest period machine for the things emulation does not cover, particularly reading media. This gets most of the benefit of both without the maintenance burden of a full period setup.

    It is also the arrangement that survives losing interest for six months, which no amount of enthusiasm makes unlikely.

  • What gets lost when a game is remastered

    A remastered rerelease is generally good news. A game that was awkward to run becomes easy to run, reaches a new audience and returns to sale. It is also, quietly, a substitution: the version people can obtain is no longer the version that was originally released.

    What tends to change

    Remasters vary enormously in scope, from a compatibility wrapper around the original executable to a substantial rebuild. Even at the light end, changes accumulate.

    • Art is rescaled or replaced, changing how the game looks at its own intended resolution.
    • Audio is re-encoded or re-recorded, and licensed music is sometimes removed entirely.
    • Controls and interfaces are modernised, altering how the game feels to operate.
    • Bugs are fixed, including ones that had become part of how people played.
    • Content is occasionally cut for licensing or other reasons, rarely with a prominent note.

    The music case is the most consequential and the least discussed. Where a soundtrack was licensed for a limited term, a rerelease may have to replace it. The game is otherwise complete and a substantial part of its identity has been substituted.

    The bug question is genuinely difficult

    Fixing bugs sounds unambiguous. In practice some bugs became load-bearing. Techniques built on unintended behaviour, speedrunning routes, and in a few cases whole communities of play depend on the original engine doing something it was not meant to do.

    A remaster that fixes those bugs is more correct and less faithful. There is no answer that satisfies everyone, and the reasonable approach is to document what was changed so people can make an informed choice. That documentation is frequently absent.

    Availability is the real preservation issue

    The mechanism that matters is not the remaster itself but what happens to the original. Where the original stays on sale alongside it, nothing is lost and everyone is served.

    Frequently it does not. The original is delisted, and the only purchasable version becomes the remaster. At that point the original exists only in copies already held by individuals, and its availability depends entirely on the second-hand market and on private collections.

    This is a strange outcome for a medium that generates so much scholarship and discussion. The version people write about becomes unobtainable while a modified version is heavily promoted, and over time the modified version is what everyone actually experiences.

    Practical notes for anyone who cares about the original

    • Where both versions are available, obtaining the original as well costs little and cannot be done retroactively once it is delisted.
    • Keep physical media where it exists, and image it properly, including any audio tracks.
    • Record which version you have. A remastered installation and an original are not interchangeable for research purposes, and the difference is not always visible.
    • When writing about a game, say which version was used. This is basic and routinely omitted.

    Not an argument against remasters

    Remasters keep games playable and commercially alive, and the alternative for many titles is being unavailable in any form. That is plainly worse.

    The argument is narrower: a remaster is a new edition, not a restoration, and treating it as identical to the original quietly corrupts the record. Editions are a solved problem in other media, where nobody confuses a revised edition with a first, and the conventions for noting the difference are well established.

    Games writing has not yet developed the same habit, and the cost of that is a body of discussion where nobody can tell which version anyone is talking about.

  • Reading an old game’s configuration files without breaking anything

    A large share of problems with old PC games are solved in a text file rather than an options menu. Games of this period externalised far more than they exposed, and the file holding those values is usually sitting in the installation directory in a readable format.

    Where the values live

    Several conventions coexisted, and a game may use more than one at once.

    • Plain configuration files in the game directory, often with an obvious extension and readable structure.
    • Console variable dumps, written by the engine itself, listing every setting the console can change.
    • Binary settings files, typically produced by an installer recording hardware choices.
    • Registry entries, increasingly common toward the end of the period, holding install paths and hardware settings.

    The console variable dump is the richest target. Engines with a console frequently wrote out every variable and its current value, which means the file is simultaneously the settings and a complete list of what can be set. Reading one tells you what the engine can do.

    The rules that prevent an evening being wasted

    Configuration editing goes wrong in predictable ways, all of which are avoidable.

    • Copy the file before changing it. This single habit prevents nearly every unrecoverable outcome.
    • Change one value at a time and test. Changing six and finding the game broken tells you nothing useful.
    • Preserve the line ending style of the original file. Some parsers of this era are less forgiving than you expect.
    • Close the game first. Many engines rewrite their configuration on exit and will overwrite edits made while running.

    That last one is responsible for a great deal of confusion. An edit is made, the game is closed, the edit has vanished, and the conclusion drawn is that the setting is ignored. In fact the setting was applied and then overwritten by the engine’s own save on exit. Editing with the game closed avoids it entirely, and marking the file read-only afterwards is the usual approach where an engine insists on rewriting values.

    Values worth knowing about

    Certain settings recur across engines of this era and are frequently absent from the menus.

    Field of view is the most commonly sought, usually stored as a number that the menu never exposes. Raising it helps on widescreen displays, though it is worth confirming whether the game widens the view or crops it vertically.

    Frame rate limits and sound buffer sizes are similarly external, and both are common causes of problems on modern hardware where the original defaults assumed much slower systems.

    Install paths and drive letters are the other big category, recorded at install time and consulted forever after. A game that cannot find its data files after a folder move is usually reading a path from one of these files, and correcting it there is far quicker than reinstalling.

    When the file is binary

    Binary configuration is a harder case and generally not worth attacking directly. The values are usually settable another way: through the game’s own setup utility, which still runs in most cases, or through a console at runtime.

    Where a setup utility exists, running it is nearly always faster and safer than editing bytes. These utilities were built to write exactly this file correctly, and they still do.

    Recording what you changed

    Keeping a short note of edits pays off repeatedly, because these problems recur. Reinstalling the game, moving it to another machine, or returning to it after a year all mean redoing the same work, and reconstructing which four values mattered is far slower than reading a note.

    A plain text file beside the backup of the original configuration is enough. The point is not documentation for its own sake, but that future-you will otherwise repeat the entire diagnostic process from the beginning.

  • Patch culture before automatic updates

    A game bought on disc in 1999 was the version on the disc, permanently, unless the player did something about it. There was no update check, no background download and no notification. Patches existed, and finding out about them was the player’s problem.

    How people actually found out

    Discovery ran through the enthusiast press, cover discs, and word of mouth on forums and newsgroups. A magazine might mention that a patch had been released; the disc on the cover might carry it. Otherwise, a player had to think to check the publisher’s website, which required knowing it existed and having a connection worth using.

    Substantial numbers of people therefore played the shipped version indefinitely, bugs and all, unaware that fixes existed. This was normal rather than exceptional, and it shaped how developers thought about launch quality: the disc version was, for a large share of the audience, the only version.

    Applying a patch was a manual operation with real risk

    A patch was an executable that modified an installation in place. It usually checked the version it was upgrading from and refused if that did not match, because patches were often incremental: 1.0 to 1.1, then 1.1 to 1.2, with no direct route from 1.0 to 1.2.

    Miss a step and the sequence broke. Apply patches in the wrong order and the installation could end up in a state no patch recognised, with reinstallation the only fix. Anyone who modified game files, which included most people running mods, could find a patch refusing to run because a checked file no longer matched what it expected.

    • Patches were frequently one-way. Reverting meant reinstalling from disc and starting the chain again.
    • Saved games often did not survive a version change, and this was not always documented prominently.
    • Mods were version-specific, so patching could break a working setup with no route back short of reinstalling.

    Why version numbers still matter today

    Anyone installing one of these games now inherits the whole situation. The disc is at its original version. The patches that once lived on a publisher’s server may or may not still be findable. And any modification being used will specify a version requirement written when that version was current.

    This produces a recurring and confusing failure: a mod that will not load, with an error suggesting file corruption, when the actual problem is a version mismatch that the mod’s documentation stated plainly two decades ago.

    Digital rereleases complicate it further. A rereleased version is usually the final patch level, sometimes with additional changes for modern compatibility. That is convenient for playing and awkward for mods, because it may not correspond exactly to any version a mod was ever tested against.

    The practical approach

    Establish what version an installation is at before doing anything else. Most games report it on a menu screen or in a file header, and knowing it converts a vague problem into a specific one.

    Then read the mod’s documentation and believe it. Where it names a version, that is not a suggestion. Where a patch is required and no longer available from its original source, community archives frequently hold it, and this is one of the more valuable things such archives do.

    What was lost when updates became automatic

    Automatic updating is better in nearly every respect. Fixes reach everyone, the version is knowable, and nobody has to maintain a mental map of patch chains.

    What it removed is the ability to stay put. A player who preferred an earlier version, or needed one for a mod, could simply not install the patch. That option has largely gone, and with it the ability to preserve a specific version of a game as it existed at a specific moment.

    For a game as a product this rarely matters. For a game as an artefact, being unable to hold a version still is a genuine loss, and one that will become more visible as more of the current era’s software becomes historical.

  • DOS memory management, and why old games asked for so much of it

    Anyone running DOS games encounters the memory question quickly. A game demands a quantity of conventional memory that appears to be available and is not, or wants expanded memory when extended memory is present, or refuses to start on a machine with vastly more RAM than it needs.

    These are not arbitrary requirements. They come from a hardware constraint that shaped a decade of PC software design.

    The 640K boundary

    The original PC architecture could address one megabyte. The lower 640 kilobytes were allocated to programs. The remaining 384 kilobytes were reserved for hardware: video memory, adapter firmware, the system BIOS.

    The 640 kilobyte figure was not a mistake so much as a generous allocation that stopped being generous. Programs grew, the boundary did not move, and the entire subsequent history of DOS memory management is workarounds for a limit that could not be raised without breaking compatibility.

    Four kinds of memory, doing different jobs

    • Conventional memory: the first 640K, where DOS programs actually run. Always the scarce resource.
    • Upper memory: the 384K reserved region above it. Unused portions could host drivers, freeing conventional memory.
    • Expanded memory: additional memory accessed through a window mapped into the upper region, a page at a time.
    • Extended memory: memory above one megabyte, accessible in protected mode but not directly by ordinary DOS programs.

    Expanded and extended are the pair that cause the most confusion, and the names do not help. Expanded memory was a bank-switching scheme, originally implemented on add-in cards, that let a program see a small window onto a large pool. Extended memory was simply the memory beyond one megabyte on a capable processor, which required switching the processor’s mode to use.

    Later systems provided expanded memory by emulating it using extended memory, which is why a machine can offer either depending on how it is configured, and why a game that demands one may fail on a machine configured for the other.

    Why games wanted conventional memory specifically

    Game code and its most performance-critical data had to live in conventional memory to be reachable without paging or mode switching. Anything else meant overhead in the parts of the code that could least afford it.

    This is why loading a mouse driver, a sound driver and a CD-ROM driver could stop a game running. Each occupied conventional memory. Between them they might take a hundred kilobytes from the 640 available, and the game needed most of what remained.

    Hence the era’s characteristic ritual: boot configurations that loaded the minimum set of drivers for a particular game, with everything possible relocated into upper memory. People maintained several such configurations and chose between them at startup.

    What this means today

    Running these games now usually means an emulated DOS environment, which removes the hardware constraint but reproduces the software model. The 640K limit still applies inside the emulation, because the games depend on it existing.

    The practical difference is that resources are no longer genuinely scarce. Emulators can provide expanded and extended memory generously and load drivers into upper memory without the fiddly optimisation the original hardware demanded.

    • If a game reports insufficient memory despite plenty being configured, check which type it wants. It is usually asking for conventional memory specifically.
    • Load only the drivers a given game needs. A CD driver present for a game that does not use one is pure waste.
    • Where a game offers a choice of memory model at install time, the choice is frequently recorded in a configuration file and can be changed without reinstalling.

    The underlying skill has not changed much. Working out what a DOS game wants is mostly reading its documentation carefully and believing what it says, because these requirements were documented precisely at a time when getting them wrong meant the software did not run at all.

  • Mod communities and the archive problem nobody owned

    Mod communities and the archive problem nobody owned

    A large modding community produced, over a few years, thousands of levels, hundreds of substantial modifications and a written record of discussion around them running to millions of words. Very little of that was archived deliberately. What survives is mostly accident.

    The infrastructure was personal

    Community infrastructure of the period ran on individual effort. Someone paid for hosting. Someone ran the forum software. Someone maintained the file index, usually as a hobby, alongside a job and a life.

    This worked well while the person remained interested and solvent. It failed completely when they did not, and the failure was typically abrupt: a server bill unpaid, a domain not renewed, a disk failure without backups. The community found out when the site stopped responding.

    There was rarely a handover mechanism, because nobody had planned for an ending. The material was not owned by an organisation that could pass it on. It was on a machine belonging to a person who had moved on.

    Duplication was uneven in a way that skewed what survived

    Files that circulated widely survive well. A popular modification, mirrored across many sites and burned onto cover discs, exists in many copies and is straightforwardly findable today.

    Everything around it survives poorly. The discussion that explained what a mod was doing, the tutorials that taught people how, the arguments about technique, the credit for who made what: this material existed in one place, on one forum, and when the forum went so did all of it.

    The result is an archive weighted toward artefacts and empty of context. We have the files. We frequently do not have any record of why they were made, by whom, in what order, or what the people making them thought they were doing.

    Attribution decays fastest of all

    Credit was often recorded only in a text file inside an archive, or in the forum post announcing a release. Text files survive if the archive does. Forum posts generally did not survive.

    Repacked and rehosted files frequently lost the accompanying documentation, either through carelessness or through a hosting site’s own format requirements. A file that has passed through three mirrors may arrive with no author information at all.

    • Keep the original archive intact rather than extracting and rehosting the contents. The packaging holds information.
    • Preserve readme and documentation files with the same care as the content. They are frequently the only record of authorship.
    • Where a file’s origin is uncertain, say so rather than guessing. A confident wrong attribution is worse than an honest gap.

    What actually worked

    The efforts that succeeded share a small number of unglamorous properties. Material was mirrored across more than one independently controlled location. Metadata was stored alongside files rather than only in a database. Someone documented how the collection was organised, so a stranger could continue it.

    None of that requires funding or institutional backing. It requires deciding early that the collection should outlive the person maintaining it, and that decision is almost never made early, because at the start nobody thinks of a hobby project as something with a succession problem.

    The uncomfortable conclusion

    A significant share of what an active creative community produced is gone, and its absence is not proportional to its quality. Losses correlate with obscurity, with hosting arrangements and with the personal circumstances of individuals, not with whether the work was any good.

    For anyone maintaining a collection now, the useful question is simple and slightly bleak: if you stopped tomorrow, what would happen to it? If the honest answer is that it would disappear, that is the problem to fix, and it is a considerably smaller job than it will be later.

  • How texture packing worked before texture atlases were automatic

    How texture packing worked before texture atlases were automatic

    Look closely at PC game art from the late 1990s and patterns emerge: textures at consistent small sizes, palettes shared across unrelated surfaces, repetition that looks deliberate and is often necessity. These are the fingerprints of memory limits that no longer exist.

    The constraint

    An early consumer 3D accelerator might carry four megabytes of memory, shared between the frame buffer, the depth buffer and textures. After the buffers took their share, what remained for textures was small, sometimes under two megabytes.

    Textures had to be resident in that memory to be used. Anything not resident had to be transferred across the bus mid-frame, which was slow enough to be visible as a stall. Managing residency was therefore a central performance concern rather than a detail.

    There were hard shape constraints too. Dimensions generally had to be powers of two, and many chips imposed limits on maximum size and on aspect ratio. An artist could not simply produce an image of whatever size suited the surface.

    What artists did about it

    The responses are visible in the finished art once you know to look for them.

    • Small tiles repeated across large surfaces, rather than large unique textures. A 128×128 tile covering a whole wall costs a fraction of a unique texture.
    • Detail concentrated where the player would be close, with distant geometry given the cheapest possible surfaces.
    • Shared palettes across a level, so that a single palette load served many textures.
    • Geometry designed to hide seams, because tiling seams were unavoidable and the alternative was hiding them with level layout.

    The tiling aesthetic that reads as period style today was substantially a memory budget expressed as art direction. It happens to have aged well, which is partly luck and partly that constraints tend to produce consistency.

    Atlases, assembled by hand

    Combining many small textures into one larger image reduces the overhead of switching between them, and the technique was well understood at the time. What did not exist was reliable automation.

    Atlases were frequently laid out by hand, or with in-house tools written for one project and never generalised. That made them expensive to change. Adding one texture to a full atlas could mean relaying out the whole thing and updating every coordinate that referenced it.

    The consequence was that atlas layout got frozen early in a project, and later art had to fit whatever space remained. Art produced late in development is sometimes recognisably squeezed into gaps, which is not a judgment on the artist.

    Filtering created a further trap. Bilinear filtering samples neighbouring pixels, so a texture adjacent to another in an atlas could bleed colour from its neighbour at the edges. Preventing it meant padding borders, which wasted the space the atlas was meant to save. Getting that balance right was a real craft skill.

    Compression arrives

    Hardware texture compression changed the calculation substantially, offering a fixed compression ratio with decompression handled in hardware at no cost during rendering. Roughly four times as much texture in the same memory, for a quality loss that varied by content.

    It was not free of character. The compression schemes handled smooth gradients and photographic detail well, and struggled with sharp colour transitions and particularly with normal maps, producing blocking artefacts around hard edges. Artists learned which content compressed cleanly and which needed to stay uncompressed, and budgeted accordingly.

    Why this matters when looking at old assets

    Anyone extracting or examining textures from games of this era should expect to find them in hardware-specific compressed formats, at power-of-two sizes, often atlased with padding, and sometimes with palettes stored separately from the image data.

    A texture extracted without its palette is not a corrupted file. It is half a file. Similarly, an atlas extracted without the coordinate data that maps surfaces onto it is a picture of a lot of textures rather than a set of textures.

    The information needed to reassemble these things is usually present in the game data somewhere. It is just rarely in the same place as the images, because in the original pipeline nothing needed it to be.

  • Source ports explained: what they change and what they must not

    Source ports explained: what they change and what they must not

    When the source code to a game engine becomes available under a licence that permits redistribution, source ports follow. Someone compiles it for a current operating system, fixes what no longer works, and publishes the result. For a number of significant games this is now the normal way to play them.

    What separates a good port from an awkward one is rarely technical skill. It is discipline about which category a given change falls into.

    The three kinds of change

    Nearly every modification to an old engine falls into one of three buckets, and conflating them is the source of most disagreements about ports.

    • Platform repair: making the code build and run correctly on hardware and operating systems it predates.
    • Capability extension: raising limits, adding resolutions, supporting modern input and audio devices.
    • Design change: altering how the game plays, looks or feels beyond what the original did.

    The first is uncontroversial and necessary. The second is usually welcome but occasionally has side effects. The third is where ports diverge, and where a port that is excellent for one purpose becomes wrong for another.

    Platform repair is subtler than it sounds

    Old engines are full of assumptions that were true and are no longer. Fixed word sizes, particular byte ordering, direct hardware access, timing derived from processor speed, memory layouts that a modern allocator will not reproduce.

    Timing is the recurring troublemaker. An engine that tied its update rate to a hardware timer or, worse, to a counted loop, behaves entirely differently on a fast machine. Fixing this properly means separating simulation rate from rendering rate, which is a real change to how the engine runs even though the intent is purely to restore original behaviour.

    This is where ports quietly diverge from each other. Two ports can both claim faithful behaviour and produce measurably different results, because reproducing original timing on different hardware requires choices, and reasonable people choose differently.

    Capability extension and its side effects

    Raising a limit sounds harmless. Frequently it is. Sometimes the limit was load-bearing.

    Games written against hard engine limits occasionally relied on the behaviour at the boundary. Content built when a limit existed may have been designed around what happened when it was approached. Removing the limit changes that content’s behaviour without touching the content.

    Higher resolutions carry a similar catch. Widening the field of view shows more of the world, which can reveal things the original never intended to be visible from a given position, and can alter difficulty in games where limited sightlines were part of the design.

    None of this argues against extension. It argues for making it optional and documenting what it affects.

    Why faithful modes matter

    The best ports offer a mode that reproduces original behaviour as closely as the platform allows, and make it clearly labelled rather than buried. This serves two audiences that would otherwise be in permanent conflict.

    Someone playing for enjoyment usually wants the modern conveniences: proper resolutions, sensible input handling, no crashes. Someone studying the game, verifying a claim about it, or reproducing a documented behaviour needs the original, quirks included.

    A port that only offers the improved version is fine as a game and useless as a reference. A port that only offers strict fidelity is useful as a reference and frustrating to play. Offering both costs relatively little and serves everyone.

    Choosing one

    • Check whether the port documents its deviations from original behaviour. Ports that do are usually the ones that thought about it.
    • Prefer ports that keep the original data files untouched and load them rather than converting them. Conversion is a one-way door.
    • For anything where behaviour matters, test the specific thing you care about rather than trusting a compatibility claim.

    The wider point is that a source port is an interpretation, not a copy. It is usually a very good interpretation, made by people who cared enough to do the work for nothing. But something that has been rebuilt has been decided about, and knowing which decisions were made is part of using it well.

  • Shareware episodes and the economics of giving away a third of a game

    Shareware episodes and the economics of giving away a third of a game

    For a stretch of the early and mid 1990s, a substantial share of PC gaming reached players as shareware: a complete, playable portion of a game, distributed freely, with the rest available by post or phone order. It is easy to mistake this for an early demo strategy. It was something rather different.

    The problem it solved was distribution, not marketing

    Getting a game onto retail shelves required a publisher, a manufacturing run, and a distributor willing to allocate space. For a small team this was frequently the binding constraint. The game could be finished and still not reach anyone.

    Shareware sidestepped it. The first portion of the game was copied by anyone who felt like copying it, onto bulletin boards, cover discs and floppies passed between friends. Distribution cost the developer nothing and scaled by itself.

    The critical design decision was making that first portion genuinely complete rather than a truncated sample. A shareware episode had a beginning, a difficulty curve and an ending. Someone who never paid still played a finished thing, which meant they were willing to pass it on, which was the whole mechanism.

    Why episodes specifically

    The episodic structure was not incidental. It solved several problems at once.

    • It gave the free portion a natural boundary, so distributing it whole felt complete rather than cut off.
    • It gave the paid portion obvious concrete value: two more episodes rather than a vague notion of more content.
    • It let a small team ship the first part and keep working, funded by whatever the first part brought in.

    That third point mattered enormously for teams without external funding. Revenue arrived while development continued, rather than at the end of a long unfunded stretch.

    The order mechanics were the awkward part

    Paying was deliberately made as easy as the era allowed and was still slow. An order form printed inside the game, a telephone number, a postal address. Money moved, then discs moved back, over days or weeks.

    This friction shaped the games. The registered version had to be worth waiting for, and the free episode had to leave the player wanting it enough to fill in a form and post a cheque. That is a much higher bar than a click, and it pushed developers toward making the free portion genuinely good rather than deliberately frustrating.

    The comparison with later free-to-play design is instructive. Shareware could not annoy people into paying, because annoyance simply ended the relationship with no further contact. It could only persuade them by being good.

    What ended it

    Broadband and digital storefronts removed the distribution problem shareware existed to solve. Once anyone could publish a game where anyone could buy it in one step, the elaborate structure of free episodes and postal ordering was solving nothing.

    Retail expectations also shifted. As production values rose, so did the cost of making a free episode that felt complete. Giving away a third of a game is a very different proposition when a third of a game costs a great deal to build.

    The residue

    What survived is the idea that a free portion should be self-contained and good, rather than a sampler that stops mid-thought. Where that principle is followed today it works for the same reason it worked then, which is that people are more willing to recommend something they enjoyed to the end.

    There is also a preservation consequence worth noting. Shareware episodes were copied so widely that they survive in quantity, while the registered versions, distributed in small numbers by post, are considerably scarcer. For some titles the free part is easy to find and the paid part is the rarity, which is an outcome nobody planned.

  • Redbook audio, and why copying a game disc loses the music

    Redbook audio, and why copying a game disc loses the music

    Copy a game CD from the mid-1990s to a hard drive, run it, and there is a good chance it works perfectly except that the music never plays. No error, no missing file, just silence where a soundtrack should be. The explanation is in how the disc was laid out.

    A game disc could be two kinds of disc at once

    The compact disc standards defined separate track types. Audio tracks hold uncompressed stereo audio in the format a CD player expects. Data tracks hold arbitrary bytes with error correction, which is what a computer reads files from.

    A mixed mode disc holds both. Track one is data, containing the game. Tracks two onward are audio, containing the music. Put that disc in a CD player and it plays the soundtrack, usually starting from track two because track one would be noise.

    The game plays music by asking the drive to start playing a numbered audio track. It does not read a file, decode anything or manage the audio itself. The drive plays the track and routes it to the sound card directly.

    Why this was an attractive design

    On the hardware of the period it was close to free. Compressed audio decoding cost processor time the game needed for everything else. Asking the drive to play a track cost essentially nothing, because the drive did the work in dedicated hardware.

    The audio quality was also excellent by the standards of the alternatives. Full CD quality at a time when compressed formats were rare and expensive to decode was a real advantage, and composers could deliver recorded music rather than sequenced arrangements.

    The tradeoff was that the drive could not read data while playing audio at full speed, which is part of why games using this approach tended to load a level, then start the music, rather than streaming both at once.

    What goes wrong when you copy the disc

    File copying tools see the data track. They copy the files, which is everything the game needs except the music, because the music is not files. It is audio tracks with no filesystem representation at all.

    The result is a complete installation that runs correctly and plays nothing. The game asks the drive to play track four; there is no disc, or the disc image has no audio tracks, and the request quietly fails.

    • Rip the audio tracks separately to lossless files, one per track, keeping the numbering.
    • Check whether a source port or wrapper for the game supports substituting audio files for track playback. Many do, and this is the cleanest route.
    • If using a disc image, use a format that preserves multiple tracks. A single-track data image cannot contain the audio no matter how it was produced.

    That last point catches people repeatedly. Common single-track image formats represent one data track and nothing else. An image in that format is structurally incapable of holding the soundtrack, so no amount of remounting will recover it. A cue sheet with separate track files, or a format that preserves the full disc layout, is required.

    The preservation angle

    Redbook audio is a genuine preservation hazard, because the loss is silent. A copied game that will not start is obviously incomplete. A copied game that runs perfectly with no music looks fine, and may sit in an archive for years before anyone notices that a substantial part of the work is missing.

    Track numbering matters too. Extracting the audio without recording which track was which produces a folder of files that no longer maps onto anything the game asks for. The order is the only metadata there was.

    Anyone archiving discs from this era should check the track layout before assuming a data copy is complete. It takes moments, and the alternative is discovering the gap much later, possibly after the disc is no longer readable.