Search options (Page 2 of 2)

7.4. How to restore audio and video synchronization in modern MAME.

In the previous chapters, we have followed the evolution of MAME's main video features, and how certain changes introduced in their implementation have lead us to a situation of compromise, to say the least, even if workarounds can be found in some cases.

There are several fronts where a certain degree of progress can definitely be achieved. Some of the features that are already being implemented by alternative builds of MAME, like system independent integer scaling or multithreaded video management, represent a tangible improvement and a clean solution for some of the issues we have discussed.

But, in our opinion, the most important single feature, that should be addressed at some point, is the broken syncrefresh functionality. Restoring a properly working syncrefresh feature is fundamental, for several reasons:

- It will provide a single option (instead an obscure combination of options) to use the video card as the master timing source.
- Things will work as advertised in the documentation.
- The use of triple buffering will become unnecessary for Direct Draw, eliminating its associated input lag.

We are going to demonstrate how it is possible to re-implement this feature, just like it worked for older versions of MAME, and we will take a further step forward, by making audio and video work together in perfect synchronization. The beauty of this is that we won’t be adding any uncertain hack at all; everything is achieved by using the gears that are already built in MAME. At the end of the chapter, you will find the complete source code for the patch.

The first thing that we have to do is, in appearance, a very trivial change in the source. However, it is responsible for the bulk of the patch code. We need to move the –syncrefresh option definition from the OSD layer into the core layer of the emulator. This deserves a brief explanation.

MAME is structured in several layers. Simplified, there is a core layer, that embeds the emulator itself, and then there are several OSD layers. OSD stands for “operating system dependent”, because this is the layer that deals with the different implementations for each specific operating system, like Windows or Linux. The core layer would be the piano nobile of the emulator's building, and it is common to all platforms. On the ground level, we have the OSD layer, dealing with the mundane world of operating system's bureaucracy. Each layer has its own set of options the user can play with. The relevant point to understand here is this: the core layer of the emulator is unaware of the options set on the OSD layer.

At some point of MAME’s evolution, it was decided that the right place for the syncrefresh feature was down, with the service. One might argue that this decision makes sense, because, after all, synchronizing with the refresh involves waiting for the vertical retrace, which is something definitely operating system specific. And here is where the conceptual error lies: synchronizing with the refresh and waiting for v-sync are related but completely separate things. The syncrefresh feature must be in the very heart of MAME, telling the emulator what to use as the master timing source: either the CPU or the video card. Its role is to control the behaviour of the throttling mechanism, but it has nothing to do with how the vertical retrace is read from the real hardware. Then, the particular implementation of waiting for v-sync can stay in the OSD layer, doing its job as usual.

Due to the way things are now, the syncrefresh feature is foreign to MAME’s core. This design keeps the throttling mechanism out of the retrace discipline. We need to revert this situation by moving the syncrefresh feature back to where it belongs. This is quite a simple change, however it requires patching several files (see the complete patch for detais):

Once we have an operative -syncrefresh option inside MAME’s core, we can focus on the patch itself. The key is to modify the video_manager::update_throttle method inside src/emu/video.c, which is responsible for the throttling mechanism, and just check if -syncrefresh is enabled, and if so, just exit:

    // if we're only syncing to the refresh, bail now
    if (m_syncrefresh)
        return;

So simple. This restores the syncrefresh full functionality. The funny part is these two lines are actually c-o-p-i-e-d from MAME pre-v0.114 source! Yes, this was included in the throttling function back when syncrefresh still worked. The reason why this was removed remains a mystery.

Now, although it’s a relief to have a reliable syncrefresh feature again, which ensures totally glitch-free video, you’ll probably remember from the previous chapters that the sound code in MAME has a mind of its own. So even with the syncrefresh option enabled, it will insist on emulating the sound at the pre-defined speed, regardless of the actual emulation speed. This will go unnoticed as far as the refresh of the video card is very close to the original, but it’s definitely there. Wouldn’t it make much more sense that both audio and video worked hand by hand at the same speed when the syncrefresh option is enabled? We whole-heartedly believe the answer is yes.

Fortunately for us, MAME already has the required mechanisms to achieve this in a painless way. The sound code is indeed prepared to accept a speed factor that is applied to the final mix (this is the principle behind the –speed option). We only need to make use of this internal speed factor, by making it aware of the current speed, as imposed by the video card. A straightforward approach for this is to use the video_manager::recompute_speed method, still in src/emu/video.c, adding this:

        if (m_syncrefresh && m_throttle)
            m_speed = m_speed_percent * 1000;

That’s all! Now the audio will be forced to be sampled at the emulation speed, whatever it is, and being the emulation speed the result of the refresh, this means that video and audio will be perfectly synchronized. Of course, this also means that if the CPU can’t keep the emulation at the required speed, the sound will reflect the slowdowns as pitch variations, like a vynil player does. But, isn’t it much more sincere than letting the sound stutter?

Once this patch is applied, the correct MAME configuration is the following:

A couple of notes here. First, now the –throttle option is assumed to be enabled all the time. In fact, disabling –throttle (for instance, by pressing F10), results in MAME going full speed, as it is supposed to be. So now, the syncrefresh functionality is conditioned to having the –throttle option enabled, which makes all sense. Second, the –multithreading option can now be safely enabled or disabled without affecting the syncrefresh functionality.

There are more sophisticated changes that could be done to the source code in order to improve several features, as the ones being done by the derivative builds Cab MAME and Groovy MAME. But the one described here is probably the most simple but still effective possible change, which, at the same time, respects the existing design without breaking anything.

The source code for the syncrefresh fix patch (based on MAME v0.148):

diff -Nrup src/emu/emuopts.c src/emu/emuopts.c
--- src/emu/emuopts.c    2013-01-11 08:32:46.000000000 +0100
+++ src/emu/emuopts.c    2013-03-03 21:26:50.000000000 +0100
@@ -103,6 +103,7 @@ const options_entry emu_options::s_optio
     { OPTION_FRAMESKIP ";fs(0-10)",                      "0",         OPTION_INTEGER,    "set frameskip to fixed value, 0-10 (autoframeskip must be disabled)" },
     { OPTION_SECONDS_TO_RUN ";str",                      "0",         OPTION_INTEGER,    "number of emulated seconds to run before automatically exiting" },
     { OPTION_THROTTLE,                                   "1",         OPTION_BOOLEAN,    "enable throttling to keep game running in sync with real time" },
+    { OPTION_SYNCREFRESH ";srf",                         "0",         OPTION_BOOLEAN,    "enable using the start of VBLANK for throttling instead of the game time" 

},
     { OPTION_SLEEP,                                      "1",         OPTION_BOOLEAN,    "enable sleeping, which gives time back to other applications when idle" 

},
     { OPTION_SPEED "(0.01-100)",                         "1.0",       OPTION_FLOAT,      "controls the speed of gameplay, relative to realtime; smaller numbers are 

slower" },
     { OPTION_REFRESHSPEED ";rs",                         "0",         OPTION_BOOLEAN,    "automatically adjusts the speed of gameplay to keep the refresh rate 

lower than the screen" },
diff -Nrup src/emu/emuopts.h src/emu/emuopts.h
--- src/emu/emuopts.h    2013-01-11 08:32:46.000000000 +0100
+++ src/emu/emuopts.h    2013-03-03 21:26:48.000000000 +0100
@@ -114,6 +114,7 @@ enum
 #define OPTION_FRAMESKIP            "frameskip"
 #define OPTION_SECONDS_TO_RUN       "seconds_to_run"
 #define OPTION_THROTTLE             "throttle"
+#define OPTION_SYNCREFRESH            "syncrefresh"
 #define OPTION_SLEEP                "sleep"
 #define OPTION_SPEED                "speed"
 #define OPTION_REFRESHSPEED         "refreshspeed"
@@ -270,6 +271,7 @@ public:
     int frameskip() const { return int_value(OPTION_FRAMESKIP); }
     int seconds_to_run() const { return int_value(OPTION_SECONDS_TO_RUN); }
     bool throttle() const { return bool_value(OPTION_THROTTLE); }
+    bool sync_refresh() const { return bool_value(OPTION_SYNCREFRESH); }
     bool sleep() const { return bool_value(OPTION_SLEEP); }
     float speed() const { return float_value(OPTION_SPEED); }
     bool refresh_speed() const { return bool_value(OPTION_REFRESHSPEED); }
diff -Nrup src/emu/video.c src/emu/video.c
--- src/emu/video.c    2013-01-11 08:32:46.000000000 +0100
+++ src/emu/video.c    2013-03-03 22:18:06.000000000 +0100
@@ -115,6 +115,7 @@ video_manager::video_manager(running_mac
         m_overall_emutime(attotime::zero),
         m_overall_valid_counter(0),
         m_throttle(machine.options().throttle()),
+        m_syncrefresh(machine.options().sync_refresh()),
         m_fastforward(false),
         m_seconds_to_run(machine.options().seconds_to_run()),
         m_auto_frameskip(machine.options().auto_frameskip()),
@@ -735,6 +736,10 @@ void video_manager::update_throttle(atto
         3,4,4,5,4,5,5,6, 4,5,5,6,5,6,6,7, 4,5,5,6,5,6,6,7, 5,6,6,7,6,7,7,8
     };
 
+    // if we're only syncing to the refresh, bail now
+    if (m_syncrefresh)
+        return;
+
     // outer scope so we can break out in case of a resync
     while (1)
     {
@@ -1008,6 +1013,9 @@ void video_manager::recompute_speed(atto
         osd_ticks_t tps = osd_ticks_per_second();
         m_speed_percent = delta_emutime.as_double() * (double)tps / (double)delta_realtime;
 
+        if (m_syncrefresh && m_throttle)
+            m_speed = m_speed_percent * 1000;
+
         // remember the last times
         m_speed_last_realtime = realtime;
         m_speed_last_emutime = emutime;
diff -Nrup src/emu/video.h src/emu/video.h
--- src/emu/video.h    2013-01-11 08:32:46.000000000 +0100
+++ src/emu/video.h    2013-03-03 22:25:07.000000000 +0100
@@ -91,6 +91,7 @@ public:
     int speed_factor() const { return m_speed; }
     int frameskip() const { return m_auto_frameskip ? -1 : m_frameskip_level; }
     bool throttled() const { return m_throttle; }
+    bool sync_refresh() const { return m_syncrefresh; }
     bool fastforward() const { return m_fastforward; }
     bool is_recording() const { return (m_mngfile != NULL || m_avifile != NULL); }
 
@@ -168,6 +169,7 @@ private:
 
     // configuration
     bool                m_throttle;                 // flag: TRUE if we're currently throttled
+    bool                m_syncrefresh;              // flag: TRUE if we're currently refresh-synced
     bool                m_fastforward;              // flag: TRUE if we're currently fast-forwarding
     UINT32              m_seconds_to_run;           // number of seconds to run before quitting
     bool                m_auto_frameskip;           // flag: TRUE if we're automatically frameskipping
diff -Nrup src/osd/windows/video.c src/osd/windows/video.c
--- src/osd/windows/video.c    2011-12-15 15:10:46.000000000 +0100
+++ src/osd/windows/video.c    2013-03-03 23:39:40.000000000 +0100
@@ -424,7 +424,7 @@ static void extract_video_config(running
         video_config.mode = VIDEO_MODE_GDI;
     }
     video_config.waitvsync     = options.wait_vsync();
-    video_config.syncrefresh   = options.sync_refresh();
+    video_config.syncrefresh   = machine.options().sync_refresh();
     video_config.triplebuf     = options.triple_buffer();
     video_config.switchres     = options.switch_res();
 
diff -Nrup src/osd/windows/winmain.c src/osd/windows/winmain.c
--- src/osd/windows/winmain.c    2013-01-11 08:32:46.000000000 +0100
+++ src/osd/windows/winmain.c    2013-03-03 22:43:58.000000000 +0100
@@ -319,7 +319,6 @@ const options_entry windows_options::s_o
     { WINOPTION_KEEPASPECT ";ka",                     "1",        OPTION_BOOLEAN,    "constrain to the proper aspect ratio" },
     { WINOPTION_PRESCALE,                             "1",        OPTION_INTEGER,    "scale screen rendering by this amount in software" },
     { WINOPTION_WAITVSYNC ";vs",                      "0",        OPTION_BOOLEAN,    "enable waiting for the start of VBLANK before flipping screens; reduces 

tearing effects" },
-    { WINOPTION_SYNCREFRESH ";srf",                   "0",        OPTION_BOOLEAN,    "enable using the start of VBLANK for throttling instead of the game time" },
     { WINOPTION_MENU,                                 "0",        OPTION_BOOLEAN,    "enable menu bar if available by UI implementation" },
 
     // DirectDraw-specific options
diff -Nrup src/osd/windows/winmain.h src/osd/windows/winmain.h
--- src/osd/windows/winmain.h    2013-01-11 08:32:46.000000000 +0100
+++ src/osd/windows/winmain.h    2013-03-03 22:43:55.000000000 +0100
@@ -68,7 +68,6 @@
 #define WINOPTION_KEEPASPECT            "keepaspect"
 #define WINOPTION_PRESCALE              "prescale"
 #define WINOPTION_WAITVSYNC             "waitvsync"
-#define WINOPTION_SYNCREFRESH           "syncrefresh"
 #define WINOPTION_MENU                  "menu"
 
 // DirectDraw-specific options
@@ -183,7 +182,6 @@ public:
     bool keep_aspect() const { return bool_value(WINOPTION_KEEPASPECT); }
     int prescale() const { return int_value(WINOPTION_PRESCALE); }
     bool wait_vsync() const { return bool_value(WINOPTION_WAITVSYNC); }
-    bool sync_refresh() const { return bool_value(WINOPTION_SYNCREFRESH); }
     bool menu() const { return bool_value(WINOPTION_MENU); }
 
     // DirectDraw-specific options

6.2. List of relevant video modes.

This tries to be a compilation of the video modes used by the most relevant video-game (home and arcade) systems from the 80's and 90's so that it can serve as a reference for configuring VMM. Excluded for now are PAL versions of NTSC systems since they're not really relevant for gaming purposes (with some exceptions such as the Commodore Amiga series, which would need further elaboration), but it still is far from comprehensive.

Normally, MAME, MESS as well as other emulators' documentation are the source, but it may not be up-to-date given that new measurements and discoveries are made every now and then, especially for arcade hardware. The idea, though, is getting the list updated twice a year. Keep in mind that some modes for these sytems aren't actually verified (marked with "(Hz?)" in the list).

Number of video modes listed: 134 ("low resolution") + 19 ("medium" and "high resolution"). Game and maker names are given only as examples for arcade games to help mode identification. Conciliated with MAME 0.145:

224 x 224 x 61.034091 Bank Panic, Combat Hawk

240 x 160 x 59.730000 Game Boy Advance (note: screen aspect ratio is 3 : 2)

240 x 192 x 59.659091 Universal

240 x 216 x 60.000000 Momoko 120%

240 x 224 x 60.000000 Roller Aces, Super Cross II, Dai Ressha Goutou, Jackal, Mr. Goemon, Youma Ninpou Chou

240 x 224 x 60.606061 Manhattan 24

240 x 240 x 57.000000 Tropical Angel

240 x 240 x 57.370000 Son Son

240 x 240 x 57.444853 Kyohkoh-Toppa, Darwin 4078, DECO Cassette

240 x 256 x 60.000000 Knuckle Joe

248 x 224 x 60.000000 Formation Z

256 x 192 x 59.610000 Ninja-kun 2, Atomic Robokid

256 x 192 x 60.000000 Raiders 5, Ninja-kun

256 x 208 x 60.000000 Gekisou

256 x 224 x 53.800000 Psychic 5

256 x 224 x 54.000000 Bombs Away, Mad Ball

256 x 224 x 56.180000 NMK-1

256 x 224 x 57.412200 Chanbara

256 x 224 x 57.500000 DJ Boy, Snow Bros

256 x 224 x 59.000000 Battlecry, Reikai Doushi, Bakuretsu Breaker, Akumajou

256 x 224 x 59.150000 Chuka Taisen, New Zealand Story

256 x 224 x 59.170000 Ninja Ryuukenden, Raiga

256 x 224 x 59.185400 B. Rap Boys

256 x 224 x 59.185606 Bubble Bobble, Scramble Formation, SAR, Ikari III, Datsugoku, Street Smart

256 x 224 x 59.390000 Sky Smasher, Blood Bros

256 x 224 x 59.600000 Raiden, Cabal

256 x 224 x 59.610000 Juju Densetsu

256 x 224 x 60.000000 Mega Drive (A), PC Engine (A) (Hz?), Baluba-Louk, Top Secret, Tatakai no Banka, System C-2, Battlantis, Sand Scorpion, Mega System 1, Magical Crystals

256 x 224 x 60.080000 Tora he no Michi

256 x 224 x 60.096154 Sega System 1

256 x 224 x 60.098476 Super Famicom (A)

256 x 224 x 60.191409 Alpha Denshi

256 x 224 x 60.606061 Black Panther, City Bomber, Gradius

256 x 232 x 59.826098 Bloody Wolf

256 x 240 x 54.000000 Butasan, Argus, Valtric

256 x 240 x 55.450000 X-680000 (A) (Hz?)

256 x 240 x 57.403400 Fire Trap

256 x 240 x 57.444853 DECO16, Double Dragon, Sai Yuu Gou Ma Roku, Xain'd Sleena

256 x 240 x 57.500000 Puzzle King

256 x 240 x 58.000000 DECO8

256 x 240 x 59.637405 Western Express

256 x 240 x 60.000000 Act-Fancer, Trio the Punch, Chelnov, Performan

256 x 240 x 60.098000 Family Computer, Super Famicom (B)

256 x 256 x 55.000000 Buccaneers, Youjuuden, Spartan-X, Vigilante

256 x 256 x 55.450000 X-68000 (B) (Hz?)

256 x 256 x 60.000000 Heated Barrel

272 x 224 x 60.000000 Finalizer

272 x 240 x 60.000000 MSX-2 (A) (Hz?)

280 x 224 x 60.000000 Contra, Fast Lane, Flak Attack, Labyrinth Runner

280 x 240 x 60.000000 Slap Fight, Kyuukyoku Tiger, Get Star

288 x 216 x 60.000000 ASO, Ikari, Athena, Jumping Cross, Gladiator, Rabio Lepus

288 x 224 x 59.170000 Super Contra

288 x 224 x 59.185606 GX System (A), Dadandarn, Simpsons

288 x 224 x 59.700000 NB-1

288 x 224 x 60.000000 A-Jax, Aliens, Asterix, Detana!!, Crazy Cop, GI Joe, Trigon, NA-1 (A)

288 x 224 x 60.606060 Namco System I & II

296 x 240 x 60.000000 Return of the Jedi

304 x 224 x 59.170000 Crime Fighters, Crime Fighters 2, X-Men

304 x 224 x 58.000000 Blazing Tornado, Grand Striker 2

304 x 224 x 60.000000 Garuka, SPY, NA-1 (B)

304 x 224 x 60.606061 MIA

304 x 232 x 60.000000 Denjin Makai II

320 x 224 x 56.000000 Gouketsuji

320 x 224 x 57.230000 System 18

320 x 224 x 57.550645 Gaia Crusaders

320 x 224 x 58.000000 Moudja, Daitoride, Puzzli

320 x 224 x 58.970000 F-3 (A)

320 x 224 x 59.185606 Neo-Geo

320 x 224 x 59.300000 Psikyo-1 (A)

320 x 224 x 59.637405 X-Board

320 x 224 x 59.764793 ST-V (A)

320 x 224 x 59.900000 Psikyo-1 (B)

320 x 224 x 60.000000 Mega Drive (B), System 16, System 32 (A), Psikyo-2, Deniam, Sel Feena, Rabbit, Varia Metal, Nostradamus, Mega System 32, Gun Master, TMNT

320 x 224 x 60.054389 Out Run, Turbo OR, Enduro Racer, Space Harrier, Super Hang-On, System 16B

320 x 224 x 60.606061 Majuu no Ookoku, Gradius II, Hard Puncher

320 x 232 x 58.970000 F-3 (B)

320 x 232 x 60.000000 Blazeon, Chase Bombers

320 x 240 x 53.986864 SPI

320 x 240 x 54.877858 Wardner no Mori, Kyuukyoku Tiger

320 x 240 x 55.161545 Dash Yarou, Horror Story

320 x 240 x 55.407801 Raiden II

320 x 240 x 55.803571 Apache 3

320 x 240 x 57.000000 Armed-F, Terra Force, Big Fighter

320 x 240 x 57.444853 Double Dragon 3, Wrestle Fest, Combatribes, Touki Denshou, Deroon Dero-Dero

320 x 240 x 57.550645 Cave

320 x 240 x 57.613169 Zero Wing, Vimana, Tatsujin

320 x 240 x 58.000000 Ragtime, Joe & Mac, Dark Seal, Charlie Ninja, Osman

320 x 240 x 59.100000 Alligator Hunt, Bang!

320 x 240 x 59.572440 Shadow Force

320 x 240 x 59.597100 Super Nova System

320 x 240 x 59.637405 Dogyuun, V-V, Knuckle Bash, Eighting

320 x 240 x 60.000000 Naname, Oh My God, DECO32, Fuuki, M-92

320 x 256 x 49.764608 Art & Magic

320 x 256 x 55.407801 Zero Team

320 x 256 x 55.470000 New Zero Team

320 x 256 x 60.000000 BNB Arcade

320 x 256 x 61.000000 Denjin Makai

336 x 224 x 60.000000 PC Engine (B) (Hz?)

336 x 240 x 59.922743 Atari

336 x 240 x 60.186720 SSV (A)

336 x 248 x 60.000000 Wheels & Fire

338 x 240 x 60.186720 SSV (A')

352 x 224 x 59.764793 ST-V (B)

352 x 240 x 60.000000 Action Hollywood, Spinal Breakers, Karate Blazers

352 x 240 x 60.186720 SSV (B')

352 x 240 x 61.310000 Turbo Force, Super Volley 91

352 x 256 x 60.000000 Fantasy Land

360 x 224 x 60.000000 Last Fortress Toride

360 x 224 x 60.000000 Pang Pom's, Poitto!, Sky Alert

360 x 240 x 59.922743 Vicious Circle

360 x 240 x 60.000000 Ninja Clowns, FM Towns (Hz?)

366 x 240 x 54.000000 Mighty Warriors

368 x 232 x 60.000000 World Rally

368 x 240 x 58.000000 Steel Force

376 x 224 x 59.185606 Gaiapolis

380 x 224 x 60.000000 Silkroad, Bomb Kick, Shocking

384 x 224 x 56.180000 NMK-2

384 x 224 x 59.185606H GX System (B), Martial Champion, Violent Storm, Silkroad 2

384 x 224 x 59.583393 CP-S III

384 x 224 x 59.637405 CP-S, CP-S II

384 x 224 x 60.000000 Mad Shark, EX Revue, Bucky O'Hare, Moo Mesa, Eight Forces

384 x 240 x 57.420000 Mitchell, Mokugeki, Superman

384 x 240 x 57.550645 Oni

384 x 240 x 59.100000 World Rally 2

384 x 240 x 60.000000 Gundhara, Blandia, Rezon, Zing Zing Zip, Macross Plus, Gundam, Last Duel, Gigandes

384 x 256 x 54.253472 Xexex

384 x 256 x 55.000000 DBZ, Kaiketsu Yanchamaru, Meikyuujima

384 x 256 x 55.017606 M-72

384 x 256 x 60.106990 Blood Storm, SF the Movie, Time Killers

392 x 224 x 60.000000 Koukuu Kihei Monogatari

399 x 253 x 54.706840 MK, Judge Dredd, NBA Jam, Rampage WT, WWF, Smash TV

400 x 224 x 60.000000 Psycho Soldier, Bermuda Triangle, Fighting Soccer

416 x 224 x 60.000000 System 32 (B)

448 x 224 x 59.170000 Cave (PGM)

448 x 224 x 60.000000 PGM

512 x 192 x 60.000000 XX Mission

512 x 224 x 60.098476 Super Famicom (C) (Hz?)

512 x 224 x 60.000000 Super Pinball Action, PC Engine (C) (Hz?)

512 x 224 x 60.797665 Battletoads

512 x 240 x 55.450000 X-68000 (C) (Hz?)

512 x 256 x 55.450000 X-68000 (D) (Hz?)

512 x 256 x 60.000000 Hexion

544 x 240 x 60.000000 MSX-2 (B) (Hz?)

576 x 224 x 59.185606 Vs Net Soccer

640 x 200 x 56.533419 PC-88 (A) (15kHz)






496 x 384 x 57.524160 System 24, Model 1, Model 2

496 x 384 x 60.000000 Model 3

511 x 299 x 54.824186 Narc

512 x 384 x 60.000000 Konami GV, GTI Club

512 x 384 x 60.096154 APB

512 x 400 x 57.134789 Midzeus

512 x 400 x 57.349016 Cruis'n USA, Cruis'n World, Off Road Challenge

512 x 400 x 60.000000 Five A Side Soccer, Taito JC, Syvalion

512 x 448 x 60.000000 Popeye

512 x 448 x 60.098476 Super Famicom (D) (interlaced)

512 x 448 x 61.651673  Hyper NG 64

512 x 480 x 60.000000 FM Towns (interlaced and progressive) (Hz?)

512 x 512 x 55.450000 X-68000 (F) (Hz?)

576 x 432 x 60.000000 Radikal Bikers, Speed Up, Surf Planet

640 x 480 x 53.178707 California Chase

640 x 480 x 55.450000 X-68000 (E) (Hz?)

640 x 480 x 57.000000 Seattle

768 x 512 x 55.450000 X-68000 (G) (Hz?)

7.2. How MAME handles the video emulation. The different video and sound options.

Since its start in 1997, the MAME project has gone through various transformations affecting how video emulation is handled. One of these changes was required due to the transition from DOS to Windows, back in 2001, which meant the end of direct hardware access era, imposed by the Windows operating system design -think that once upon a time, main line MAME had native support for 15 kHz video modes-. Anyway, this was quite a natural move since DOS was definitely a dead end. A second revolution, also known simply as the new video system, came in 2006 with version 0.107. This is the system we'll be discussing in the next chapter. We may consider the recent integration of HLSL as a third fundamental change, though this one is definitely on the antipodes of the way we understand video emulation.

But before going into further details on how modern MAME handles video emulation, let us introduce some of the concepts by following MAME's evolution since its early days. As DOS-based MAME was abandoned and the development focus moved to Windows, MAME's video system evolved accordingly by taking advantage of the DirectDraw API. For a 2-D-graphics programmer, DirectDraw was a godsend, as it provided an intuitive way to access the frame buffer, without the hassle of dealing with specific hardware issues. The basic idea is to gain access to a portion of memory -known as a surface- that represents, one by one, the RGB values of each pixel on the screen, in a sweet sequential way. Now, although DirectDraw supports hardware stretching of the game's frame to any arbitrary screen resolution, this is generally contrary to our purposes; rather than that, we need to ensure that the pixels on the game's frame are faithfully transcribed into the screen. What we users have been doing during these years -through all sorts of hacks and methods- is providing MAME with a bunch of usable low resolution video modes in order to allow displaying the games without any kind of stretching artifact. Usually we tell MAME which specific video mode to pick, and DirectDraw is responsible for creating the full screen display. In case there's a small difference between original and target resolutions, MAME will either leave black borders or crop the frame as required, without any additional artificial adjustment.

The options involved here are -nohwstretch, that disables hardware stretching, and -switchres, that tells MAME to enable video mode switching. MAME will try to find the video mode that best fits the one of the game, from the list reported by Windows.

But generally it's not a good idea to let MAME do this. Instead, we will explicitly tell MAME which video mode to pick, and in MAME pre-0.107 this is performed by the pair of options -resolution and -refresh. By displaying emulated games on a CRT screen at their native resolutions, we will enjoy a picture that's undistinguishable from the real thing... until things start moving. Unfortunately, as soon as animation starts, a new family of visual artifacts becomes evident: tearing and scroll hiccups. As you know, these nasty artifacts happen whenever an application updates the contents of the video memory outside of the vertical blanking interval. This is something that the real video game hardware wouldn't do, and for this reason, the human eye automatically detects the fake and the illusion vanishes. It is definitely amazing how some people can live with these issues and still pretend they don't ruin emulation altogether!

For a very good reason, MAME implements an option specifically designed to solve this problem: the -syncrefresh option. What this option is supposed to do is to ignore the game's original refresh rate and adjust the emulation speed to be synchronized with the video card's refresh. Now, before you go through hours of frustration, be aware that the -syncrefresh option doesn't work any more since version 0.114, as we'll be explaining a bit later.

It's just important to grasp the concept of what we're trying to achieve here. Enabling -syncrefresh used to result in perfectly smooth scroll and animation, however, there's an obvious side effect to this approach: the game's action will be either accelerated or slowed down. How much? That will depend on the difference between the original refresh and the one that the video card is outputting. For instance, a game which originally run at 55 Hz, when synchronized to a 60 Hz video mode -the most common case with today's screens-, will run smoothly, though accelerated up to 109% of its original speed (60/55 = 1,09). The traditional workaround has been creating different instances of each resolution, combined with the required vertical refresh values for our target games, and then manually telling MAME which one to use for each specific case. On this regard, it's important to notice that, in practice, it's almost impossible to get a perfect match for a given refresh rate, though it's generally possible to get a good-enough approximation -about 0.1 Hz precision-. By using a refresh rate that is sufficiently close to the original one, the difference in emulation's speed introduced by -syncrefresh will be negligible.

On the other hand, inexplicably, the sound code is not aware of the -syncrefresh option, so it keeps trying to work at the original speed, causing sound glitches, as the sound tries to catch up video emulation. So, in a way, we're transferring the video problem to the audio side. This issue, however, will be hardly noticeable as long as we manage to create a video mode with a refresh rate that's very close to the original one.

Anyway, if we're actually capable of generating any desired target refresh, at least with a reasonable level of accuracy, you may be wondering why in the world we need the -syncrefresh option at all. After all, our refresh matches the game's refresh, doesn't it? There are some common misconceptions regarding video synchronization and MAME. Usually people tend to believe that just by selecting a refresh that matches the target refresh, combined with the -waitvsync or -triplebuffer options, the video synchronization issue should be solved in MAME. In practice, this removes tearing indeed, but at the price of adding some degree of scroll and sound stuttering in most situations. But, why? Fortunately, there is a simple explanation for this, under the hood. By default, MAME will try to keep the game running at the theoretical speed it is supposed to run. This is performed by an internal throttling mechanism, which uses the computer's CPU clock to keep the frame-time adjusted to the values measured in the original hardware. In modern computers, most games emulated by MAME would run too fast, so what the throttling mechanism does is to introduce an accurate delay between frames, of the required length, in terms of CPU clock cycles. This is controlled by the -throttle option, which is enabled by default -when disabled, MAME will run at full speed-.

Keeping a game throttled like this reproduces the original game's speed, with more or less accuracy, but as we said, results in tearing, as the CPU-based clock completely ignores the cadence of our physical video signal. Now what happens when we add -waitvsync or -triplebuffer as an attempt to fix tearing, is that, in addition to the throttling delay, MAME will need to wait for the video card's vertical retrace -essential to avoid tearing' so we'll be introducing a second clock in the scene, the one in the video card's GPU. In fact, our video card can be seen as an external clock that produces vertical retrace pulses at a constant rate, for instance 16.17 ms for a 60 Hz refresh. Indeed, MAME is trying to emulate the same thing with its CPU-based clock.

And this leads us to one of the most important concepts we need to understand here: in the scope of PC hardware, trying to keep two clocks synchronized like this, is impossible in practice. There will always be some degree of phase lag between them. On this regard, it's irrelevant if this is a tiny value as 0.05 Hz or as huge as 5.00 Hz; the difference will get accumulated after several frames, and at some point, unavoidably, one vertical blank interval will get missed, resulting in a visible scroll hiccup. Of course, the magnitude of this difference will matter in how often this dreaded artifact occurs, but the only way to guarantee a hiccup-free animation is getting rid of one of the two clocks, and being video fluency critical for us, it's the CPU clock what needs to go. This is exactly what the -syncrefresh option does -well, did, remind we're still talking about MAME pre-v0.114-, and why it's preferred to the other two. By enabling -syncrefresh, MAME internally instructs its throttling mechanism to just wait for vertical retrace without any other CPU-based delay, adjusting the emulation speed to our video card's current refresh rate. Still, it's our responsibility to provide MAME with the proper refresh rate to synchronize to; otherwise sound and emulation's speed will be noticeably affected. This involves the creation of custom video modes with the desired refresh rate.

Compared to other emulators, MAME is somewhat confusing, as it has three different implementations for the video synchronization thing. Then, is there any use for the -waitvsync and -triplebuffer options? Well, according to our extensive tests, as long as there is a functional -syncrefresh option -as is the case for MAME pre-0.114-, we don't need the others at all. Both -syncrefresh and -waitvsync contain the same wait for vertical sync functionality. But unlike -syncrefresh, -waitvsync keeps the throttling mechanism enabled, so both clocks continue interacting with each other, resulting in erratic frame rates and scroll stuttering. On the other hand, the -triplebuffer option is meant to improve performance by creating two back buffers, so in theory one of them will always be free for MAME to draw to, while its counterpart is locked, waiting to be displayed as soon as the next vertical retrace happens. As a consequence of this, MAME should be able to start drawing to either one of the two back buffers immediately after a new frame is computed, resulting in smoother performance than enabling -waitvsync alone, which implies there's no practical use for -waitvsync in MAME. The third buffer is known as the front buffer, and it's the one which contents are currently being transferred to the screen at the raster pace. Each one of the two back buffers will become the front buffer at some point: this is known as surface flipping.

The ultimate purpose of the triple buffering idea is to release the game loop code from having to wait for vertical retrace. Obviously the wait for vertical retrace still needs to be performed somewhere, otherwise tearing would happen, but it's supposed to be done by different code that only deals with the screen update, running in parallel. So, the triple buffering concept implies that both game loop and screen update routines must run asynchronously in different threads of execution. Unfortunately, DirectX doesn't support such functionality natively, although its documentation is misleading on this regard: v-sync'ed flipping methods don't return immediately as requested and expected -they are not scheduled-, which causes the game's speed to be limited, in practice, by the video card's refresh, if this one is lower than the original game's refresh.

But it's even worse. The triple buffering concept also involves that the system must be capable of dropping frames when required. For instance, if a new frame is ready and the previous one is still in the queue, the older frame should be dropped. This is to make sure that it is always the most recent frame the one that ends up showing, at the time the vertical retrace occurs, so there's no additional lag derived from the use of buffered frames. Unfortunately for us, DirectX arranges the buffers in a stupid circular queue, so adding more buffers to the queue only results in adding more frames of input lag -actually video lag-. This completely defeats the purpose of triple buffering.

So the theoretical benefits of triple buffering don't apply here, and what we get is just a sophisticated sort of double buffering. Nevertheless, we'll see how we can exploit this issue in modern versions of MAME, as a workaround to mimic the behaviour of the -syncrefresh option, although with a lag penalty.

The -triplebuffer option does not disable the throttling mechanism either, because its purpose is to eliminate tearing while keeping games running at their original speed. This causes tearing artifacts to disappear, but introduces scroll stuttering instead, for reasons explained above. However, MAME's -triplebuffer option only works as it's supposed to -keeping game's speed at 100%- when the video card's refresh is higher than the game's refresh. Notice that, with a correct triple buffering implementation, this shouldn't be the case!

So, putting it all together, here is a sample of how a correct configuration for MAME pre-v0.107 would look like:

Notice that MAME can't create the 384 x 256 @ 55 video mode by its own means. MAME needs this video mode to be already present in the system, so it will just request it to the display driver. Before we can use this video mode in MAME, we must have taught the driver how to build this particular mode, to our desired specs. This is done by means of a modeline, although the details on how this is performed are worth for a whole different chapter. For our sample, this is the modeline we'd prepare behind the 384 x 256 @ 55 label:

R-Type's native refresh is 55.0176 Hz. This modeline, theoretically, will make for a refresh of 55.0274 Hz. This means that by synchronizing R-Type to this modeline, it should run at 100.017 % of its original speed. Not perfect but not so bad.

So that was, summarized, how MAME was configured back in the pre-0.107 days, for what video emulation is concerned.

This article was written for the most part during February of 2012, but for several reasons it hadn't been published yet. Today, with MAME v0.155 about to be released, the information contained here is outdated to some extent. However I preferred to leave the article in its original form.

Bear in mind that the configuration that's explained here only applies to official MAME. It is NOT applicable to GroovyMAME, which already targets the issues discussed in this article with its own implementation.

I want to thank MAME developers for keeping up the good work improving this awesome emulator day by day.

Calamity

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

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.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.