6

I'm building an retro emulator to connect to a PAL (720x576i @ 50 Hz) CRT TV, and would like a perfect V-blank image, so the visuals are identical to original arcades and retro computers.

In other words, the video card must produce one perfect (albeit interlaced) image every 50th frame on the CRT display, with NO frame skipping/tearing/juddering, and no audio dropouts either.

I'd like to hear from people who have succeeded with this earlier, or have the technical knowledge to know what is possible and how to achieve it.

I'm considering the following possibilities:

  1. Running the latest MAME or similar emulator on modern hardware such as a Mac or a Raspberry Pi. (Is this combination able to provide perfect visuals?)
  2. Running an emulator on an actual retro computer which has perfect native PAL output, such as an Amiga, unless someone knows a better choice.

Update #2: After some research, with MAME 0.199 on macOS, I changed name.ini as shown below. Now Salamander seems to be scrolling perfectly. However, the scrolling background on character selection in Samurai Shodown II is jumping a pixel every second. So it's not perfect. Also, it seems that Windows has many more video effects than macOS/Linux (eg. scanline emulation)

If anyone has specific advice how to take this to 100% perfection, please post an answer.

video                     opengl
waitvsync                 1
syncrefresh               1
filter                    0
gl_glsl                   1
  • 1
    Frame skipping/tearing isn't a function of the video card, but of the application not being able to render frames fast enough or not synchronizing the frames with the vertical retrace. – Ross Ridge Aug 17 '18 at 12:58
  • Have you considered using a Raspberry Pi? They have composite video output. – Mick Aug 17 '18 at 13:30
  • 4
    An FPGA board that can run existing retrocomputer cores and includes composite video output would be more inline with the current state-of-the-art in the retro/emulation community. – Brian H Aug 17 '18 at 13:37
  • 1
    @Tommy Sorry, just meant to say that slight adjustment shouldn't cause a noticeable difference in speed. – Ross Ridge Aug 17 '18 at 16:47
  • 2
    @Marc'netztier'Luethi Strictly speaking PAL is 50 fields per second, two interlaced fields making one frame, for a result of 25 frames per second as you say. However most old consoles and computers didn't really distinguish between fields and so their output was effectively 288p at 50 Hz. – Ross Ridge Aug 18 '18 at 8:38
10

The two specific problems you've mentioned, frame skipping and tearing aren't a function of the video card. They're software and/or CPU problems so your choice of video card don't matter. All video cards capable of outputting a PAL composite signal will output a "perfect" 50 HZ PAL signal, probably even more "perfect" in terms of precise timing than what old consoles outputted. This isn't the problem with getting the best emulation quality of from emulators on a CRT TV or any display for that matter.

Frame Skipping

Frame skipping is a problem that occurs when emulator can't draw each emulated frame fast enough to display the game in real-time, and so skips drawing frames in order to keep up. So for example, imagine you're trying to play a certain 50 Hz game on a slow CPU and/or slow emulator that can only render the game at bout 25 frames per second. The emulator will either have to run the game at half the intended speed or skip rendering frames (roughly every other one) so the game plays at its intended speed.

So frame skipping is a problem that can be avoided simply by using a fast enough CPU or an efficient enough emulator. In the later case cycle accurate emulators are the biggest thing you would have to worry about, as they can push the limits of even the fastest PCs, but cycle accurate emulators are only necessary to play accurate emulations of a very few games.

Tearing

Tearing is a problem caused by the emulator changing the emulated frame being displayed by the video card while it's in the middle of being output. This causes two different emulated frames to be output in the same display frame. The previous emulated frame is show at the top and the new emulated frame at the bottom, with the division between the two appearing as a visual tear.

Tearing has a simple fix that all video cards support: only change emulated frame to display during the vertical retrace interval when nothing is being output by the video card. On a real CRT this is the time when the video raster moves from the bottom of the screen to the top in order to display a new frame.

Your Real Problems

So you can avoid these problems with any video card, you just need a fast enough CPU and you need an emulator, along with suitable operating system support, that can synchronize its output with the vertical retrace (V-sync). However trying to synchronize a emulated game this way can cause other problems: juddering and audio dropouts.

Juddering

Juddering is a problem if the frame rate the game is supposed to be using doesn't exactly match output display rate. The game will either play faster or slower than it should or the emulator will have to periodically resync causing juddering. This most noticeable when smooth scrolling doesn't appear to be smooth. If you're playing a 50 Hz game on 50 Hz CRT TV this shouldn't be a problem, but if you're playing a 60 Hz game (eg. most arcade games) on a 50 Hz CRT TV this is unavoidable.

Audio Dropouts

The audio dropout is problem is similar. While the emulator is rendering frames, it's also rendering the audio. Most emulators actually synchronize the speed they run at to the output rate of the audio. When they're synchronized to the video card's refresh rate instead they will likely end up providing audio too fast or too slow for the sound card, causing dropouts when it's forced to resync the audio.

There are a couple of possible solutions to audio drop out problem, but they require your emulator to implement them.

Input Lag

Another related issue you might want to worry about it is input lag. This is the delay between pushing a button on the controller and the resulting action appearing on screen. Buffering in video drivers and flat panel TVs can make this delay long enough to be a noticeable problem. Since you're using a CRT TV you don't have to worry about buffering in the TV (unless it happens to be a rare HD CRT TV), but buffering in the video drivers and operating system may be a problem. While this is ultimately a software problem, your choice of video card may limit your options in terms of bypassing this

So really it's your choice of software, mainly the emulator and how you configure it that matters. To a certain extent your choice of operating system may also matter, but both Linux and Windows should be fine.

  • Following your 'couple of possible solutions' link and reading further down the page (especially because the relevant sections don't really explain themselves very well), it looks like perhaps what we should be saying is: buy a G-sync/Freesync monitor and endure MAME? – Tommy Aug 17 '18 at 16:24
  • @Tommy G-Sync/Freesync does seem to be best possible all around solution for LCD monitors, though it's highly dependent on software support. Won't help with a CRT TV though. – Ross Ridge Aug 17 '18 at 16:30
  • @RR Good on you for not saying it, so I will: I'm a dunce. Must learn to read questions more carefully. – Tommy Aug 17 '18 at 16:36
  • The reason cycle accurate emulators require so much CPU is because so much CPU is wasted on synchronization, right? Would it help to have additional clocks on the motherboard tuned to the exact same frequencies as the original hardware? – traal Aug 17 '18 at 21:13
  • @traal Synchronization overhead means you can't use multiple threads across multiple CPUs to do cycle accurate emulation. The performance problem mainly comes from the fact you can't do the emulation in batches, rendering an entire line at once for example. Additional clocks won't help because modern CPU cycles have no resemblance to emulated CPU cycles. If you were to somehow clock a modern Intel CPU at 4.77 Mhz it would still run orders of magnitude faster than an 4.77 MHz 8088 CPU in an IBM PC, and how much faster would vary considerably on what exactly it was doing. – Ross Ridge Aug 17 '18 at 22:16
3

If an emulator is supposed to display a picture from an emulated computer that outputs 59.82 or 60.05 frames/second to a monitor that's going to display 59.94 fields/second and won't adapt to such incoming frame rates, it will need to do one of two things: 1. Occasionally duplicate or drop fields, or 2. Run the emulator about 0.2% faster or slower than actual speed. Many systems' frame rates are close enough to standard video rates that making the emulated system run at a speed to match the frame rate wouldn't be a problem for most purposes, but a drift of more than 6 seconds per hour might cause trouble in applications intended for real-world time keeping.

3

(Edited, as the focus of the questions has changed quite a bit).

First, let me make clear that getting a "perfect V-sync image" is necessary, but far from sufficient for "visuals identical to original arcades and retro computers". CRT TVs have a lot of artifacts due to the analog nature of the signal. Having proper v-sync will avoid tearing, which is a very obvious flaw when emulating, but that's all that it does. It won't give you an experience that's close to the original visuals.

Now, to the various parts.

Using emulation systems with TV out

Video cards with composite TV outputs exist, from quite a few manufacturers. The bulk of that would be AGP cards, with a few PCI cards thrown in. I think finding a PCIe card would be a challenge.

So (1) is difficult, (2) definitely doable (if you have the right motherboard).

Those cards used specific encoder chips (mostly Philips, Brooktree/Conexant, Chrontel) with varying capabilities; timing was often constrained (the Chrontel chips only support few modes). Later NVidia cards used their own proprietary TV encoder. Programming those chips is done via I2C bus, if you want a specific resolution, you'll need a datasheet (I still should have them somewhere).

An alternative way that would need a considerable amount of hacking is to use a Fresco FL2000 VGA dongle. This have been repurposed as general D/A converters, and the bandwidth should be enough for a composite TV signal, at least black and white (maybe also with color). With some use of the other two channels maybe one could even use something closer to the original VGA mode, and somehow put a SYNC signal in.

That would be a fun project, but requires some good programming skills.

As for (3): I wouldn't think an actual retro computer with TV composite output only has enough processing power to successfully emulate another retro computer of the same era at a reasonable speed.

Perfect V-Sync

Perfect V-sync is easy, and is a problem of the emulator software communicating with the graphics card, and the graphics card producing an image with the correct (multiple of the PAL/NTSC) vertical sync frequency. For that, it doesn't matter if you use a CRT TV or an LCD monitor.

You could ask for an interrupt every frame and thus do things exactly once per frame. As long as you updated visuals after they were drawn (not during), you got a perfect picture. How does this work on modern hardware, eg. a Rpi?

In the same way, it's just that the graphics driver, kernel, OpenGL etc. put a lot more distance in between the hardware interrupts and the application problem.

Does the CPU have access to something identical to a "raster register" or "timer" that lets it spit out exactly one picture per 1/50 second (1/60 for NTSC)?

Yes, it has. However, the raster line counter and/or retrace interrupts are only accessible at the kernel/driver level. They get passed on to the application program via various APIs, depending on the OS, graphics library etc.

Is there any one or two way communication between CPU and video card?

That depends on what you mean by "video card": The part responsible for the timing and framebuffer readout can be programmed by writing values to registers, and gives feedback by reading registers or interrupts. The various GPU ("graphics CPU") are a different topic.

Or is the CPU completely oblivious to the video card / connected monitor, and just does a "best effort" at trying to produce sequential images, which means that visuals will skip a frame sooner or later?

The "CPU" isn't, but an application program like an emulator may be, in particular if it's not reprogramming the graphics mode, but using whatever mode is currently selected (which many emulators do, because it's more convenient).

  • I'm not aware of any retro emulation that targets CRT TVs - these are not so easy to get nowadays, so people tend to focus on LCD monitors etc. Which doesn't mean it doesn't exist - in principle, it's not hard to do. Emulators of e.g. C64 for the Amiga do exist, but speed is inferior to the real computer. – dirkt Aug 17 '18 at 14:34
  • The encoder chip shouldn't matter. PAL/NTSC encoders are dumb devices that require the input timing to match the output timing. They don't have the frame buffers necessary to do change resolutions or frame rates. – Ross Ridge Aug 17 '18 at 16:14
  • @RossRidge: I'd recommend to read some of the data sheets, then it will be much easier to say what "should" and "shouldn't" matter (e.g. this one, have a look at Appendix A. Bonus points if you can calculate the rest of the registers from the values given in the tables). No, they don't have framebuffers, the existing CRTCs/Pipes or whatever the GPU calls them are used to read out the framebuffer. But yes, timing does matter. A lot. – dirkt Aug 17 '18 at 16:54
  • I didn't say timing didn't matter, just the opposite in fact. With the encoder chip you linked, either the video chip (GPU) needs to use the timings provided by the encoder (in the "master interface" configuration) or encoder uses the timings provided by the video chip ("slave interface"), or a hybrid approach is used where the encoder provides the clock and the video chip derives the sync timings ('pseudo-mater interface"). Either way the 50 Hz vertical sync is synchronized between both chips, and an emulator need not know how the encoder is configured nor need to reprogram it. – Ross Ridge Aug 17 '18 at 17:42
  • @RossRidge: The point is that the encoder timing needs to be programmed to produce the correct scaling and overscan area, so if the goal is to produce a "visually identical" image, you need the size and timing of the original image, you need to find encoder settings that are close, and then you need video chip needs resolution and timings to match the encoder settings (on existing cards, the master interface is always used). So "encoders are dumb devices that require the input timing to match the output timing" is just not true. It's a lot more complicated. – dirkt Aug 18 '18 at 7:24
2

Just an answer of scepticism: If you gonna support several different retro platforms, you are most probably unable to generate PAL composite signal indistinguishable from the originals.

Let's consider, ZX 48k and C64. The first has 7.00 MHz pixel rate, the second -- 7.88 MHz (I might be wrong here). None are multiples of the PAL color subcarrier frequency, neither that frequency is a multiple of their pixel rates. Both, if connected to composite, leak color subcarrier into the luminance channel -- and vice versa, sharp luminance edges leak into the chrominance channel. Both machines do that in their own ways and give dissimilar artefacts. I'd suggest you won't be able to get such an accurate composite signal using ANY existing video card, that is capable of PAL output.

Even the differing pixel rates alone yield the problem to accurately emulate the composite signal, since the videocard most probably will have only a single possible pixel rate in PAL mode.

A suggestion: you could try to synthesize PAL signal directly using fast DAC (with, say, around 20 MHz sampling rate), somehow being able to prepare lots of data for it frame by frame.

  • As I frequently mention, I am the author of an emulator that attempts an actual computation of the real original composite video stream prior to decoding it. I'll add as an additional constraint: for most machines, detailed information about the generated composite signal isn't well-documented. I can think of the NES and, to a lesser extent, the C64 as exceptions, and in the case of the Apple II it's self-documenting, but those are particularly rigorous communities. So that's an added obstacle to emulator development. – Tommy Aug 17 '18 at 16:34

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.