-
Notifications
You must be signed in to change notification settings - Fork 0
Video
One of the problems with FPGA based retro setups is the fact that video displays have improved over the time and that it can be tricky to convert the retro video signals into some digital video signal a modern display would accept.
Furthermore, the basic principles of driving displays have changed. In the 80s and 90s the connection between a computer and a display was strictly one-way. The computer was delivering a signal, and it was up to the display to somehow cope with it. The video signals generated by computers were very similar (but not identical!) to standard TV signals and the analog TVs back then were quite forgiving and were accepting signals that weren't exactly matching the TV signals. This has changed. Today's displays provide information to a computer telling it exactly what kind of video signals it accepts. It's up to the computer to read this information from the display and to act accordingly. However, certain video modes are very common and supported by most modern displays. Chances are that a video signal of this kind will be accepted by a display even without requesting the supported timing information from the display at all. This allows to a certain extent to implement the old "one-way" solutions with a modern display. But this is outside the specifications and there is no guarantee a modern display will cope with these signals. Such a solution therefore e.g. is not HDMI compliant.
Emulators running on PCs and small SBCs like the Raspberry Pi don't have this problem since these devices are directly supporting the modern video modes. This comes with a drawback and the frame conversion taking place inside the emulator and in the GPU can cause tearing effects, stuttering and noticeable lagging.
FPGA setups may also implement such an advanced frame conversion to transform the retro video signals into a signal exactly suited for modern displays. But this requires significant resources inside the FPGA and comes with the same drawbacks seen on emulators.
Like most retro FPGA projects, MiSTle thus does something much simpler. The TV video signals of the 80s were interlaced 50 hertz (PAL) or 60 hertz (NTSC) signals. In today's nomenclature these would be 288i@50hz or 240i@60hz signals. The majority of retro computers was using progressive (non interlaced) modes that were close to these TV signals. Today these would be called 288p@50hz and 240p@60hz.
These signals are actually directly supported by some modern displays. But significantly more common are signals with exactly twice these lines. These modes have 576 lines for a 50hz PAL signal and 480 lines for NTSC derived signals. These modes are named 576p@50hz or 480p@60hz. They can be derived from the retro signals by scan doubling each display line. This can easily be done inside even small FPGAs and requires very few resources only.
The number of horizontal pixels was not a fixed value in the early times of analog TV signals. A machine would simply generate the video signal at any rate, and it very much depended on the display how well higher horizontal resolutions were displayed. Above a certain limit, pixels would look blurred, and color artifacts would start to show up. Most retro machines would thus limit the horizontal resolution to values around 320 pixels. Higher resolutions in the range of 640 pixels horizontally as required for 80 column text modes were also common but would already be hitting the limits and not all screens would display these satisfyingly.
Due to their digital nature, on modern screens the horizontal number of pixels that can be displayed is an exact value which typically correlates with the number of lines being displayed. A 576p or 480p video mode would often have 768 or 720 horizontal pixels with 720 being the most common. The 720x576p@50hz and 720x480p@60hz modes are actually standardized and supported by most modern computer displays and TVs. These nicely match with common retro video modes like 320x200 pixels when pixels are doubled horizontally and vertically. The resulting image of 640x400 pixels fits into 720x576 as well as 720x480 modes of modern screens. The remaining pixels are used for the border area that was common on early computer displays.
However, many retro computers could be tricked by clever programming tricks into using the border area to display pixel content as well. An Atari ST can e.g. be made to display up to 848x280 pixels (848x560 scan doubled). These pixels would not all be visible on a screen back then, and they also don't fit into the 720x576 or 720x480 modern displays will accept. Some content may therefore be cut off and being invisible.
The most flexible solution thus is to implement 720x576p@50 and 720x480p@60hz as the default video mode as these modes have the best chances of being compatible with modern screens. The further the video modes generated differ from these, the higher the probability that the display will not accept it. Some cores thus offer screen options like "Overscan" and/or "Wide". These may allow displaying more pixels incl. ones placed on the border area, but fewer displays will cope with this.
Finally, not all video signals generated by retro machines were meant for TVs. Machines like the Atari ST and the Apple Mac Plus came with (optional) custom screens using custom resolutions of 640x400@72hz (Atari ST high resolution) or 512x352@62hz (early Apple Macs). These are quite different from any standard video mode and only few modern displays will accept them.