3. Emulation of old video-game systems on modern computers

3.1. Profane emulation vs. advanced emulation vs. real hardware.

We can't deny there's a well-established contempt among many video-game enthusiasts towards video-game emulation, particularly of old systems from the 80's and 90's. On the one hand, there're those who despise it for the lack of both, a tangible medium and the immediateness of the emulated hardware in its original form, or be it just for its unavoidable links with pirated software and non-legitimate ways of playing video-games. On the other hand, there are those who claim that a game through an emulator for PC can never perform as it does with the original hardware; that the technical differentiations are so huge that the experience can never be exactly the same. Disregarding the former group since all those are aspects which don't belong to the act itself of playing a video-game therefore it's not a matter for this place, maybe it's time to stop the second group's nonsense once and for all by telling them this -- you're not using your emulator programs properly.

Really.

Maybe they're not the ones to blame, though. Video-game emulators, traditionally for DOS/Windows-based computers, were born with a stigmata -- video technology. Simply put, you couldn't, and can't, replicate the visuals of old video-games on a standard computer due to the technical differences in the video hardware. And sadly, the authors of emulator programs were never very interested in telling you so -- usually, should we add, because they were happy enough with the results, which, no matter what, were always much worse than the real thing.

And indeed it's much worse. Modern computers simply aren't able to properly work at the usual resolutions the video-game systems from the 80's and 90's did. They weren't already in those years, once the EGA and VGA video benchmarks were introduced and the display medium for the PCs stopped supporting the so-called low resolutions. TV sets and arcade monitors (as well as other particular monitors for certain computers) never did, though, and so the technological boundary which would always separate IBM-compatible PCs and most of the other video-game platforms was set. Using a standard VGA monitor for PC to display low-resolution games results (no matter what you'll hear) in a quite unnatural, distorted picture since the graphics need to be line-multiplied or upscaled for a full-screen image. Some invented all kinds of filter artifacts to mask the imperfections or even to simulate the look of the scanlines from a low-resolution CRT when displaying a progressive picture, but it was never the same thing.

But it's not only an issue of resolution discrepancies. Not at all. Many people tend to forget that the displayed picture from a video-game system is not a still image. It moves. Changes. And it does it according to a given refresh rate on the screen. CRT-based sets can work at multiple display resolutions and vertical refresh rates, and indeed that's what they did depending on what video-game system you used them for, since they usually were not the same. It's true that the vertical refresh was almost always set around 60 Hz (meaning that the display was updated 60 times per second) on NTSC systems, but you could find anything between 54 and 61 Hz, generally. Much like a PC with a standard video card configuration won't display under 640 x 480 pixels on screen, it won't work under 60 Hz either, so a video-game using originally a refresh of say, 55 Hz will either, run at ~110% the original speed or bring in severe visual issues (discontinuos scroll, tearing effects, etc.) when you display it by way of an emulator on your everyday PC. Additionally, usual emulator configurations which try to mask these video issues caused by desynchronization will normally serve to also introduce lag problems. Not good, especially in action games.

So yeah; profane emulation, when you compare it with the real thing, sucks.

Now, how many people are aware that the video issue is indeed solvable, that you actually can make a PC behave display-wise like old video-game systems did with the proper hardware and software configuration? The resolution thing has been more or less solved actually for many years now -- a British aficionado managed to modify a certain model of ATI Radeon video card to make it display a variety of true low resolutions so that one could use a standard Windows-based PC on a 15-kHz RGB TV set/monitor -- it was marketed as the Arcade VGA video card from Ultimarc. You only needed the cable which would carry the RGB signal from the card to the monitor. Unfortunately, this card, as it was sold, was only able to use a very limited number of predetermined video modes -- those from the emulator MAME with a vertical refresh of 60 Hz. These days, though, there's more than one solution to this thanks to the great work of some skillful people, and many PC video cards can be fully customized to display any video mode from any video-game system, and notice we mean both -- the display resolution and the vertical refresh rate. And for free, should we add.

By using the original video mode when you emulate a given game on the PC plugged into a 15-kHz RGB monitor/TV set, you'll not only get the game to look exactly like it did on the original hardware (even much better in many cases, given the limitations of the video signal of not few old systems), you'll get the game to run at the original speed with no software artifacts which could affect input responses. There'll always be a certain degree of latency when you measure it against the original hardware due to how a computer works and the own nature of emulation, but on its own, the difference shouldn't be perceivable even by the most expert (and sensitive) player, which is what really matters in the end.

Therefore, to get the same experience with emulator programs as with the original hardware (and let us underline this -- the same; we're talking about gaming experience and not necessarily of hardware behaviour, after all), the only real thing we should be caring about is emulation accuracy, that is, the emulator's code itself, which, sadly, is not as perfect in most cases as we could expect. But that makes for another issue altogether which, at any rate, can be solved as long as the authors have the skills and interest.

3.3. Solving the video issue. Hardware needed.

As it has been said, the whole issue derived from the different video modes used by the original hardware and the PC when you emulate a video-game can be solved by properly configuring your set-up:

a) Get a 15-kHz RGB TV set/monitor. You won't be able to reproduce the old video-games' visuals if you don't have one of this. Home systems from the early days, from Nintendo's Family Computer and Sega's SG-1000 to more modern consoles such as the Sony Play Station 2 and Nintendo Wii were designed for 15-kHz TVs. Not unlike arcade games, which you'll find most indeed use 15-kHz monitors, with only a small part from the recent years being designed for 31-kHz displays or above and even a smaller group from some particular developers for 24-kHz monitors. The RGB part is mandatory, so non-European users will normally need to ignore TV sets and look for an arcade, broadcast or 15-kHz computer monitor (the latter will rarely be bigger than 14'', though).

There are no performance differentiations between RGB TVs, arcade/broadcast monitors and 15-kHz computer monitors per se, and the picture quality just depends on the maker and model. You should keep in mind that arcade and computer monitors allow for an easier picture position and geometry tweaking, though Sony Trinitron devices (either, TV or broadcast sets) usually have a good and easy-to-access service menu for the labor, as well as excellent picture quality and scan flexibility, depending on the model. Users interested in 24- and/or 31-kHz games should always take the arcade/broadcast or computer monitor route. Please, refer to the chapter dedicated to monitors here for further elaboration.

b) Get the proper video cable. We want to connect the PC to the 15-kHz monitor/TV with an RGB signal, and that's not a standard purpose, so we'll have these solutions:

- For an RGB TV/15-kHz computer monitor with SCART input, you'll need a cable with a male 15-pin D-sub connector (for the PC's video card) and a male 21-pin SCART connector (for the TV set) which carries RGBS signal. You can make it at home by joining a standard VGA cable and an RGB SCART cable together as this diagram explains or buy it from some retailers which have been listing them lately, though you must make sure it serves for RGBS purposes and not for other (low-quality or encoded) signals. Cable linkers such as this are also a recent solution to check out.

- For 15-kHz arcade monitors, making a cable at home is not recommendable with low level of expertise given that you'll normally need an amplifier due to the different voltage an arcade monitor uses for video-game PCBs. The easiest way is Ultimarc's J-Pac device, of which you can learn more here.

- For multi-sync arcade/broadcast monitors and 15-kHz computer monitors with 15-pin D-sub input, normally a standard VGA (RGBHV) cable will do. Note that broadcast monitors will normally use BNC inputs, though.

c) Get a low-res-friendly PC video card. By low-res-friendly we mean a card which is well-known to support 15-kHz low-resolution custom video modes through its RGB (VGA or DVI-I) connection. Although, in theory, nearly any video card should be susceptible of being programmed to output 15-kHz video signals, modern operating systems make direct hardware programming impossible in practice, so we have to rely on specific vendor's device drivers to undertake this task. Depending on the manufacturer, these drivers often include some limited custom video mode generation functionality, which we will exploit for our purposes. At the moment, we have found ATI (now AMD) Radeon cards to be the most flexible ones when it comes to custom video modes support, with no possible comparison. We are stuck, however, to some relatively old models: the ones up to the HD-4000 generation. These are the cards and methods we'll be discussing in this Site.

So our advice is -- pick the right card (your emulation system's heart) and then build your dedicated computer upon it. And never hesitate to go second-hand if necessary. Most novice users tend to purchase a new generation video card, basing their uninformed decision on features which become secondary when it comes to emulation, such as 3-D performance, availability and price. They will argue that one particular emulator they're planning to use does require a lot of GPU power and whatnot. After their acquisition, they'll usually spend some nights struggling to get the damned thing output a useful signal by means of a trial and error process which involves testing software like Soft-15-kHz or Powerstrip. In the best case, a few useful low resolution video modes will be successfully achieved and the user may obtain a somewhat acceptable support for usual modes, highly depending on the video card's brand and model, but in many not-so-lucky cases (which are becoming the rule for newer generation cards) the process will end up in plain frustration. There are just too many variables to consider -- OS version, driver version, video card generation, etc. etc., which, when combined, can produce rather unpredictable results. This frustration will often make the user decide for the plug-and-play solution Ultimarc's Arcade VGA video card, which, as we'll see later, is not the best choice as of now.

3.5. Other 15-kHz-focused applications.

As discussed above, CRT Emudriver is just one of many methods that have been developed as an approach to the video issue. In fact, for the most part, the driver-based methods used by CRT Emudriver were discovered and documented by the Soft-15kHz and Winmodeline's creators, so we just used that previous knowledge and improved the modeline generation techniques and MAME integration. Here's is a brief overview of some of those methods:

Advance MAME

It's a derivative build of MAME, developed between 1998 and 2008. Its creator, Andrea Mazzoleni, was probably the first person to have a clear picture in his head of the video issue as a whole. Mazzoleni built an incredibly sophisticated engine upon MAME's core to deal with low-level video hardware initialization and modeline generation, which created nearly perfect video modes for most games right out of the box. Direct video hardware management involves specific code for each different chipset -- what a titanic effort! DOS or Linux operating systems are required to enjoy Advance MAME to its full glory. Under Windows XP, unfortunately, direct hardware access is restricted to device drivers, thus the Advance MAME special features are seriously handicapped. Since version 0.107, mainline MAME's video subsystem was fully rewritten, causing Mazzoleni to refuse keeping Advance MAME updated. However, many people use it still nowadays, as its advantages weren't beaten since recently.

Link

Ultimarc Arcade VGA

Actually conceived as a hardware piece rather than a software application, the Arcade VGA card was created by Andy Warne as the plug-and-play solution for using PCs with arcade monitors and TV screens. It's based on an ATI Radeon card with a modified BIOS firmware, which allows native 15-kHz video output right from boot, unlike other solutions that require the operating system to load until a 15-kHz signal is possible, being this feature its biggest advantage. The Arcade VGA offers about 30 built-in video modes, which were selected to cover most emulation situations. Definitely, this card made life much easier for many of us in the emulation scene. However, its features were not exactly perfect -- each resolution was provided at a single refresh rate. Moreover, there were some remarkable absences in the resolution list (for instance, a suitable ~55 Hz mode for Irem games was missing). Some advanced users started demanding the possibility of adding new video modes or customizing the existing ones (this, by the way, was the first motivation for the CRT Emu-Driver project). First generation Arcade VGA cards (versions 1 and 2) used chipsets based on the Radeon 7000, 9200, 9250, X600 and HD-2400. As users demanded more GPU power, a new generation Arcade VGA was released -- the ArcadeVGA 3000, based on the HD-2600 chipset. This one includes a brand new BIOS firmware to support both, CRT and LCD devices, Windows XP/Vista/7, as well as a configuration utility -- Arcade Perfect, Ultimarc's approach to the video mode customization problem. The Arcade Perfect software is conceived as an emulator wrapper, which provides an on-screen display to allow real-time geometry and refresh adjustments for individual games, which are stored since then. Unfortunately, Arcade Perfect uses its own format for storing video timings, so it won't accept raw modelines, making it unsuitable for serving as interface with emulators that generate their own modelines dynamically, such as Groovy MAME. The idea behind this design decision is that the average user shouldn't need to mess with modelines. However, Andy mentioned the possibility of porting the Arcade Perfect's functionality into a .DLL, which could be interfaced programmatically and accept usual modelines as input data. This addition, including some method for defining new custom video modes, combined with the existing 15-kHz BIOS support, would make the Arcade VGA 3000 the ultimate video card for emulation.

Link

Soft-15-kHz

Created by Ariane Fuggman (AKA Sailorsat), Soft-15-kHz is probably the most popular and easy to use 15-kHz-focused application. Just by pressing a button, 15-kHz support is enabled for a wide range of video cards -- ATI, Nvidia, Matrox, 3D-FX and Intel. Soft-15-kHz works by storing its custom video mode definitions into the Windows registry, specifically in the area that video display drivers use for saving their settings. Once installed, the new video modes are available right from Windows start-up, with no resource cost, as Soft-15-kHz doesn't need to be loaded again. For some reason, Soft-15-kHz was designed with a fixed list of ready-made modelines, as a software clone of the Arcade VGA. Fortunately though, it supports the definition of custom video modes by adding modelines to a text file. However, the total amount of custom video modes that can be added is limited to the display driver's capacity, depending on the video card's brand (ATI drivers: 60 modes; NVidia drivers: 32 modes). Sailorsat's contributions to the emulation scene are invaluable. The Soft-15-kHz project includes a detailed documentation of the methods and formats for custom video mode creation used by the main video card's brands. Several dozens models of cards were tested for compatibility, being their reviews the best available reference to this date.

Link

Winmodelines

Created by Jeroni Paul (AKA Nixie), this tool is our favourite. Just like Soft-15-kHz, it's capable of creating driver-based custom video modes for mostly the same range of cards, with the addition of the first generation Arcade VGAs. But its most remarkable feature is the integrated modeline generator and editor, which allows the user to create automatic modelines for different video standards, just by entering the resolution and refresh. Winmodeline's interface includes a text box showing the currently installed modelines, used as a work area too, where the user can add and remove modelines, or just edit the existing ones. The resulting video timing values are updated and prompted as the user types, making it easy to get familiar with basic video signal arithmetics. This feature alone makes Winmodelines the most pedagogical tool out there. Furthermore, the application comes with an accurate, complete and carefully written documentation, thanks to Nixie's technical background. Winmodelines is fully compatible with CRT Emu-Driver's modeline format, so they can be safely used together. In fact, it becomes handy in much more situations than one would think.

Link

Powerstrip

Created by En-Tech Taiwan, this shareware tool is the all-time reference for custom video managing. Though mainly conceived for HTPC use, it's flexible enough to serve as a general purpose custom video tool, including its use in emulation. Moreover, it's probably the only software solution to work for all Windows versions since Windows 95, and to support new generation GPUs. Its power comes from the fact that it's mostly driver-independent: Powerstrip actually installs its own generic driver to deal with video hardware directly, overriding the vendor's display drivers. However, contrary to their creator's statement (in our experience) it can't actually install an unlimited amount of different video modes, so the restrictions imposed by display drivers seem to keep applying to some extent. Powerstrip seems to work by intercepting system's resolution change requests, and when any of these resolutions matches one of the user's custom defined video modes, it will apply the customized settings. There's a serious limitation to this design that's lethal for our purposes -- Powerstrip can only store a custom timing definition (thus, a vertical refresh) per resolution. Despite of that, there's an interesting workaround to this issue that, surprisingly, hasn't been exploited at all by the emulation community till recently -- Powerstrip can be remote-controlled programmatically through a very simple API. This feature itself, when properly used, could be the future of accurate video emulation. There's, still, an additional drawback for using Powertrip as our custom video mode server, either directly or programmatically, and it's related to the way it manages the dot-clocks. Dot-clock (or pixel-clock) programming is the very heart of video mode generation. It involves developing techniques for dealing with PLL dividers, which are responsible for converting the card's master clock's frequency into our requested frequency. We usually trust this painful task to the display drivers, but Powerstrip uses its own code to perform that, being its methods a jealously guarded secret. The problem comes when the accuracy of the value achieved is uncertain or, even worse, the results are not fully deterministic, something you wouldn't expect with usual driver-based methods.

Link