2000 Part II: The Hard 3D Machines

A Nintendo 64 title screen could look like a victory on a PC. Then came the next test: would the level load, would the character move, and would the game survive the next scene? In 2000, developers were still working through those questions while others tackled the Sega Saturn or aimed their code at the Dreamcast, still a current console. Even after the difficulties of PlayStation emulation, these machines offered plenty of new ways for a promising build to fall apart.

After UltraHLE, a different N64 race

UltraHLE had jolted the scene in 1999 by getting selected Nintendo 64 games moving on Windows PCs. Its high-level approach took shortcuts that made a thrilling subset playable, but it could not make every game behave. During 2000, more of the work behind N64 emulation came into view: reproducing CPU instructions, handling graphics microcode—the small programs that directed graphics processing—and getting audio, controllers, and memory maps right. Developers also needed tools to find out where things went wrong. Getting a game to boot was a start; keeping it running tested the foundations.

1964 was already working on those foundations. 1999 reporting covered its early Windows and DOS builds and the contributors joining the project. The open-source emulator advanced through a succession of small releases in 2000. A June Zophar notice for version 0.4.8 reported fixes to memory instructions and said Super Mario 64 seemed to run correctly. It also noted support for the Adaptoid controller adapter, letting players use a familiar N64 controller on their PC. Instruction fixes were less immediately inviting, but they addressed the code a game had to get through without crashing.

The name 1964 winked at the year, though the machine it was trying to reproduce came decades later. N64 games could depend on peculiar coprocessor behavior and different graphics microcode paths. Fixing one instruction could make demos more stable without solving the next commercial game’s problems. A release note about two repaired opcodes—the individual operations a processor carries out—might sound modest. For a game that needed them, those tiny details stood between continuing to play and a crash.

Joel Middendorf, known as schibo, had appeared in the earlier chapter, but 1964’s development also drew on other contributors. Contemporary release notes credit NooTe with the Adaptoid support reported in June. Graphics, controllers, and game compatibility called for different kinds of expertise, and the team kept improving the code after the first downloads. It was quieter work than UltraHLE’s overnight arrival, with progress measured in fixes and games that behaved a little better.

Nemu64 and the shape of a playable game

Nemu64, another project already part of the 1999 discussion, remained a regular point of comparison throughout 2000. Players weighed it against 1964, TRWin, and newer experiments according to the game they wanted to play. Did the graphics draw correctly? Was there sound? Could they save, and did the controls work? Progress on one title could sit beside another that exposed an unresolved low-level behavior. Nemu64’s developer-focused features and debugging tools also gave it a use beyond playing games, even when a casual user chose another emulator for a favorite title.

Screenshots only captured part of that experience. A title screen said little about movement, level loading, or scene transitions. Later captures show what these projects eventually produced, not necessarily what worked in 2000; the contemporary notices tell that earlier story.

These mixed experiences made the argument over high-level and low-level emulation less tidy than it sounded. A high-level shortcut could get a game playable quickly. A design focused more closely on the hardware might remain slow and incomplete in public builds while laying groundwork for broader compatibility. Neither approach had a permanent claim to the best results. Plugins and borrowed interface ideas blurred the boundaries further, and projects learned from one another even when their authors disagreed about the route.

Sometimes the next improvement arrived as a support file rather than a new emulator. An April contemporary report described Spinal’s updated Nemu64 configuration file, which added entries for games missing from earlier versions. Those entries gathered practical observations: a special setting one game needed, a title that reached its menu, another that was nearly playable, and others still broken. New users could try known settings instead of guessing in the dark. The growing file also showed how much remained unresolved: needing another special setting for each unusual title suggested that the emulator still did not fully account for the hardware’s behavior.

Compatibility lists helped players choose what to try, though “supported” could mean anything from displaying an image to completing a game with saved progress. Users still had to find out how far a tester had actually played. Meanwhile, the N64 was a current machine, and new releases kept supplying fresh cases to investigate. Even a carefully maintained list could feel out of date by Christmas.

Corn’s startling speed and narrow doorway

One of the most memorable N64 projects of 2000 was Corn. Its April public version impressed observers with the speed of a few selected games. A contemporary Zophar hands-on report described Super Mario 64 running quickly with sound on a K6-2 400 MHz machine, and Mario Kart 64 and a Japanese Wave Race build producing results with missing sound. The same tester listed many games that displayed nothing or crashed. That mixture of astonishment and frustration is exactly what made Corn newsworthy.

Corn concentrated on speed and compatibility for a narrow slice of games. Its archived directory entry says it used no plugin system and required DirectX-capable graphics. While other projects increasingly split their work into interchangeable components, Corn took a different route. A player impressed by its fast Mario still had to weigh that speed against the wider compatibility available elsewhere. N64 developers in 2000 were trying several designs in public, with no obvious winner.

Even with a working game, Corn could be awkward to live with. The same tester reported difficulty leaving full-screen mode, instability when switching away from the program, and crashes. Sometimes the game continued running in the background while the rest of the PC slowed down. Getting Mario moving quickly was an achievement; getting the computer back afterward still needed work.

The wait for another build produced a small scandal in May. Emulation64 reported a supposed Corn 0.3 beta, then published a correction from author ContraSF: he had authorized no such beta. A fake email had prompted another site to distribute a file under that name. The archive later reported a genuine 0.3 release, along with trouble for some Windows 2000 users. Anyone following the closely spaced updates had to keep track of both the release and the retraction.

That May archive also recorded developers helping across project boundaries. Work was underway toward a shared high-level graphics plugin for 1964, Corn, TR64, and TRWin. Separately, a coder named SphinXer had adapted Voodoo Banshee drivers to help Nemu64 run. The emulators remained distinct projects, but their progress drew on more than their core authors: plugin writers and driver tinkerers tackled problems, testers tried the changes, and site editors passed the discoveries on to players.

Apollo starts at the foot of the mountain

Apollo began much further from a playable game. Emulation64’s May 2000 archive reported its first public build, version 0.01a; Zophar’s N64 directory later described the early emulator as supporting only a few instructions. There was no commercial game running to compete with Corn’s Mario demonstration. Apollo was still working at the CPU stage, implementing the instructions the console’s processor carried out. Some authors waited until they could show an image before sharing their work. Publishing a foundation this early instead gave testers and potential contributors something to examine, even if it offered players little to do yet.

TrueReality’s descendants: TRWin and TR64

Other developers built on an existing foundation: TrueReality. Windows adaptations such as TRWin and TR64 carried its work to another host system and paired it with different graphics paths. A later historical directory describes TRWin as a Direct3D Windows port and TR64 as an OpenGL-based one, though those entries may include features added after 2000.

A dated update gives a clearer glimpse of TR64’s progress. In November 2000, Zophar reported a work-in-progress release that appeared to add sound support. A silent N64 game could look impressive and still feel strangely distant from the console. Audio brought it closer, while adding another timing problem for the emulator to solve: the soundtrack and effects had to keep pace with the picture. Crackling music or a sound arriving after the action could spoil a game that looked perfectly convincing in a screenshot.

Getting TrueReality onto Windows took more than a change of address. Port authors and graphics programmers adapted the code, documentation helped people use it, and users reported where it broke. TRWin and TR64 each solved some problems and inherited others, with several codebases—and plenty of people—behind the names.

RealityMan draws a line

People were still waiting for another UltraHLE release when RealityMan, one of its public authors, drew a line. He was also working on a Jaguar emulator called Jagulator. In a September 2000 archive notice, a message attributed to him said UltraHLE was over as a public project and Jagulator would continue privately. He described exhaustion with backbiting and a need to make time for family and life outside the scene. Contemporary pages quickly circulated the message.

UltraHLE had shown that something once seemingly out of reach could work. That achievement also brought its authors legal concerns, rumors, and relentless requests. The early web could offer a free-program developer encouragement one day and cruelty the next. Other N64 teams were still working, but RealityMan no longer wanted his hobby to be a public obligation. His departure left a gap even as the rest of the field carried on.

Jagulator was a separate challenge, not an UltraHLE sequel under another name. Atari’s Jaguar had a different hardware design and its own documentation difficulties. RealityMan’s announced move into private development left followers waiting to see how far that work had reached.

The EmuJag hoax makes a hard month worse

By the end of the month, Jaguar followers had another disappointment. Zophar’s Domain reported that EmuJag had been exposed as a fake. According to the report, the supposed emulator had never progressed beyond a graphical interface. Duncan, a would-be tester, had written about the gap between its claims and what he could actually examine. Zophar’s notice was openly exasperated: readers had spent days debating one public Jaguar developer’s exit, only to find that another promised breakthrough apparently amounted to a front panel with nothing behind it.

Failing to run a favorite Jaguar game did not make an emulator a hoax. Serious authors might hold back unstable code, lack game support or documentation, or worry that an experiment would be judged as a finished product. An honest alpha could still expose a boot sequence, partial chip behavior, or a reproducible failure that another programmer might help fix. EmuJag’s problem, as contemporary observers described it, was the gap between its claims and the interface available to examine.

RealityMan had a public track record through UltraHLE, but Jagulator was still at the beginning. He released an alpha around this time, and the September 30 Zophar notice plainly said it did not play games yet. The build could show a startup screen, and the notice promised no more.

The archive’s own headline presented the EmuJag hoax as one more disappointment after UltraHLE’s end. Within the same month, Jaguar hopes had become tangled with skepticism and accusation. An author trying to share an experiment had to contend with that mood as well as the machine.

The Saturn finally shows more than a boot screen

Getting a Saturn game as far as its menu was progress in 2000. Sega’s console had earned its forbidding reputation: its multiple processors and tightly connected graphics and sound systems were difficult to reproduce in a PC program. SSF became one of the projects people followed for signs that games were beginning to work. This was still the early SSF, a long way from the mature emulator later players would know.

A September 16 Zophar post supplied an English translation of an SSF readme and described the emulator as playable. Before trying a game, though, users had to clear a more ordinary hurdle: having the right PC setup. The translation listed Windows 95, 98, and Me, along with DirectX and display requirements, and explicitly said that the build did not work on Windows 2000 at that point. A newer operating system could leave you unable to run an emulator that expected an older graphics setup.

The translated notes measured progress in screens and effects. One game might reach a menu or character-selection screen while another still displayed incorrectly; even getting the Saturn logo to draw properly was something to report. SSF was giving fans visible steps forward, without yet opening up the whole Saturn library.

The readme was candid about how slowly those pictures arrived. On a Pentium II running at 400 MHz, it described a build reaching roughly five frames per second, with one drawing mode slower still. You could watch the Saturn produce recognisable images and see where things went wrong, but this was hardly a comfortable way to play. The notes also described sprite-only display, missing shading, and CD audio rather than a complete sound system: identifiable game screens, incomplete effects, and a long wait between frames.

Trying it also meant learning the emulator’s own controls. The readme mapped Saturn buttons to keyboard keys and assigned function keys to opening and closing the virtual CD drive. It warned users not to alter particular save files and acknowledged that startup could fail. These were the practical details that let someone outside the project attempt a test. A patient Saturn fan had instructions to work through; someone expecting to install a finished product had several reasons to reconsider.

GiriGiri was at an earlier stage. Another contemporary September notice described its debugger build as limited to a timer-setting screen and explicitly said it was not playable. Alongside partial boot sequences and hardware documentation, tools like this helped lay the groundwork for further Saturn work. For someone looking for a game to play in 2000, however, GiriGiri’s debugger build was not an alternative to SSF.

Sega’s awkward 32X and the AGES push

The Sega 32X posed a different headache. The add-on sat between the Genesis and a later generation of consoles, adding processors and graphics behavior to hardware whose own emulation was still improving. Making Genesis games work was only the start. An emulator also had to reproduce the 32X’s SH-2 processors, the way it mixed its display with the Genesis picture, and the interactions between the two machines well enough for games to keep running.

AGES pushed into that territory during 2000. Contemporary Zophar archives carried updates on its 32X and Sega CD work. Many emulators that made Sonic look easy had neglected these add-ons, so a 32X game producing recognisable graphics on a PC could draw more interest than another Genesis compatibility fix. Getting a picture was still only part of the job: behind it could be missing sound, broken effects, or a game that stopped after the intro.

Another 32X project disappeared before it reached a public release. In an October Zophar report, Magical32X author RooFer said he had to shut down development after his employer discovered the project. He asked beta testers to delete their copies. The archive preserves his public account, but gives no independent explanation of the employer’s reasons. Magical32X had reached testers; now its author was asking them to remove even that unfinished version.

A released emulator could leave mirrors and version pages behind. An unfinished beta withdrawn from testers could leave little beyond a news item, making projects like Magical32X easy to miss in later lists. In 2000, watching a promising project appear did not mean you would ever get to download it.

A Dreamcast star demo, and no miracle game library

The Dreamcast emulator could run a star. That was enough to attract attention while Sega’s console was still fresh hardware in 2000. Zophar’s September 8 notice said the released emulator appeared real and ran its included “Star” demo—and stressed that this was the only thing it ran. Nobody was getting Sonic Adventure or Shenmue out of it, let alone loading a retail GD-ROM.

For a scene hungry for the next UltraHLE moment, news of a Dreamcast emulator was inviting. Getting commercial games running meant tackling CPU behavior, graphics, audio, memory, the disc format, and the ways they interacted. Even loading a disc hid a problem: a retail Dreamcast disc was not an ordinary PC CD-ROM. The supplied demo gave the authors a known program to test, avoiding many of the surprises a commercial game could throw at them. Drawing the star was progress, but a whole console in a zip file remained a rather larger request.

The same archive mentions a compatibility page being assembled for the early Dreamcast effort. Users were already looking beyond the demo and asking the practical question: would their games work? For most retail software in 2000, the answer was no. The excitement lay in seeing someone already working out how Sega’s newest machine behaved, even if the playable reward was still just a star.

Arcade hardware gets three-dimensional

Away from the living room, 3D arcade boards presented another tangle of specialized chips and protection schemes. Hardware varied across the arcade floor, so reproducing one board did not settle the next. Impact became a conspicuous project in 2000, and a January Zophar notice already described users searching for its plugins. Arcade players were encountering the same mix of choice and setup trouble familiar from PlayStation emulation.

The preserved Impact directory describes an emulator targeting newer Capcom games and notes its renderers. These offered different graphics paths alongside the emulator’s core; users had to match plugins to their PC hardware to get a particular board’s game looking right. An “arcade emulator” had to accommodate far more variation than the name suggested. The directory also records Impact’s eventual replacement by ZiNc, which belongs to the later story.

Killer Instinct drew specialist efforts of its own. Reproducing its dedicated arcade cabinet on a PC meant working through the processor, storage, video, and sound, a task that could occupy developers for years. Projects such as U64Emu pursued that narrower target alongside broader efforts like Impact. Getting the familiar title logo on screen was a start; making the rest of the game work was the longer job.

An October 2000 Zophar release notice introduced U64Emu beta 1.02 as the first public version of a Killer Instinct emulator previously called KIAME. Its author, RCP, had changed the name because he hoped to support more games using related hardware. The project had begun around one game, but RCP was already looking beyond it to what else the hardware model might run.

Despite the “U64” name, this was an arcade Killer Instinct project, not an N64 emulator. Related games could share characters and title art while running on very different machines. A later directory entry describes sound and configurable controls; it does not establish that those features were present in beta 1.02.

Getting a picture onto the screen could take work from several people. One programmer documented a graphics command; another reverse-engineered a sound chip, wrote a controller interface, or tested a protection routine. Hard bugs and uncertain documentation spread the work well beyond the person whose name appeared on the executable. A successful build showed players what that scattered effort had managed to put together.

Calling part of an emulator a “plugin” did not mean it would simply plug in and behave. A renderer written for one emulator might expect data in a different form from the one another supplied. A new build could fix a game on one graphics card and break it on another. Capturing video from an arcade board brought its own difficulties: graphics planes, timing, and effects worked together in ways a single frame could not reveal. Release notes and bug reports let us follow that repair work—who spotted a defect, how the team described it, and whether the next version fixed it.

Even getting the code to run left plenty to translate. Some arcade cabinets had hardware no home console reproduced exactly, with specialized controls, display geometry, and sound that shaped how a game felt. A PC emulator could bring the game within reach without fully recreating the experience of standing at the cabinet. Impact and the specialist 3D projects were working their way through those compromises, rather than merely adding names to a list of supported games.

A little further into the game

By the end of 2000, progress could mean a more playable game or simply a screen that had never appeared before. A fast Mario, a slow Saturn menu, and a Dreamcast star were very different rewards for the work behind them. Some projects kept improving; others vanished before a public release, or continued away from public view. The breakthroughs were real, but so were the unfinished games and the strain of keeping a hobby open to everyone.

A 2000 game in the GameBase

Perfect Dark in the Retro Replay GameBase brings us back to a game released while the emulator authors were trying to catch up. Rare’s 2000 shooter pushed the original N64 in ways those early emulators could not be assumed to reproduce. It belongs here as a game from that year, not as a claim that Corn, 1964, Nemu64, or any other 2000 build could run it. Cover art tells us what was on the shelf; documented testing tells us what ran on a PC.

People in this chapter

• Joel Middendorf (schibo) — returning 1964 contributor.
• RealityMan — UltraHLE author whose September statement ended his public N64 project and moved Jagulator into private work.
• NooTe — credited in the June 1964 release notice for Adaptoid support; further identity details need verification before a biography.
• Shima — the public handle associated with SSF; a full profile should avoid inventing a private identity.
• RooFer — Magical32X author whose reported October shutdown deserves a cautious profile.

Sources and further reading

• Zophar’s January 2000 archive: Impact and other early-year releases.
• Zophar’s June 2000 archive: 1964 0.4.8.
• Zophar’s September 2000 archive: RealityMan, SSF, GiriGiri, Dreamcast demonstration.
• Zophar’s October 2000 archive: AGES and Magical32X.
• Zophar’s November 2000 archive: TR64 sound.
• Emulation64 May 2000 archive: first Apollo build.
• Impact historical emulator directory entry.