Raspberry Pi

The Raspberry Pi is an inexpensive single-board general purpose computer. While originally intended to teach programming in public schools, the is popular in hobbyist circles for its capacity to serve as a controller for customizable embedded devices. Due to its generous processing power, memory, 1080p output, and  interfaces, it was only a matter of time before Doom was ported to this platform.

The shareware version of Doom was used during development of the Raspberry Pi in its benchmarking tests, and was useful in debugging compilation issues when porting software to the Raspberry Pi's, a relatively rare ARMv6 variant. Chocolate Doom was the only source port available on the official Raspberry Pi Store until its closure in February 2016.

While a handful of source ports are available through Raspbian, a Debian fork created for the Pi, they are largely out of date and may not be configured correctly. The best practice currently is to compile from scratch. This article is not intended to be a specific how-to, as many ports may differ, but will discuss the basics of the models, the problems faced when using these devices for Doom, and a list of source ports which have been tested and confirmed to work.

Models
There are three product runs and six models of the Raspberry Pi, with model names mimicking the. All feature HDMI output, can communicate with other computers over an network, and can utilize s for storage (with the exception of the Compute Module, which has no ports at all and only fixed flash storage). The following list below will give simple specs and advice for those who wish to use Raspberry Pi for playing.

First Run
These models are the initial run, and have known hardware issues under stress. Thankfully, updated firmware releases have worked around most of these issues, but s may still occur under heavy load for an extended period of time. They are all clocked at 700 MHz by default. If one desires to overclock the system, he or she can choose the "High" option from the program. See the official Raspberry Pi website for details.


 * Model A: 256MB RAM, one USB port. USB to Ethernet port adapter is required for netplay with a powered USB hub.
 * Model B: 512MB RAM, two USB ports and Ethernet port. Multiple Model Bs can be easily connected for LAN.

Second Run
These models fix hardware issues, consume less power, and can be overclocked safely. These are still clocked at 700MHz, but can be overclocked to "Turbo" without issue. More complex maps will benefit from overclocking these models.


 * Model A+: 256MB RAM, one USB port.
 * Model B+: 512MB RAM, two USB ports and Ethernet port.
 * Compute Module: Same as the Model B+ but requires an expansion board to use. Not recommended.

Third Run (Pi 2)
The third run brings an update to the Raspberry Pi Model B+, called the "Pi 2", with an ARMv7 instruction set, a 900MHz quad core processor, and 1GB RAM. There is no "A" model for this run. Due to its quad core processor, this eliminates many of the problems with the previous models, and thanks to recent firmware updates, is virtually error-free. Source ports that use multiple threads for execution will benefit the most. These can also be overclocked, but may not be needed.

Soon after the Pi 2, an updated version of the Model A was released, called the "Pi Zero", with a 1GHz single core CPU and 512MB RAM. Other than hardware stability improvements, RAM size increase, and reduction of USB ports to Micro USB, this is similar to an overclocked Model A.

Fourth Run (Pi 3)
The fourth run, the Pi 3, was an unexpected upgrade to the Raspberry Pi line. With a Cortex-A53, a 64-bit ARMv8 1.2GHz quad core processor, it rivals recent smartphones in power and CPU features. However, there is still 1GB RAM due to backwards compatibility limitations. In better news, the stability of the machine far exceeds the previous models, and the GPU clock has been doubled to 400 MHz.

Compilation
Compilation can be very slow and tedious. It is not recommended to perform other tasks as source ports compile, and an underpowered unit may, or worse, kernel panic in an endless loop. With a Pi 2, compilation can be accelerated via use of multiple cores through the switch. Use of however should be avoided, as it may cause  to issue bogus errors or crash. Ensure that the system boot SD card is fully functional.

If you are going to be rebuilding ports from source frequently, consider using the tool to speed up the process.

CPU/GPU Bugs
The Raspberry Pi's GPU supports a video overlay and 2, and requires special builds of SDL and SDL 2 from the RetroPie project as of this writing. As these changes have not been accepted into the upstream project, use of the vanilla versions of SDL can cause problems such as blank screens, loss of keyboard control, system lockups, and poor frame rates.

With the introduction of the Raspberry Pi 3, all known CPU bugs have been eliminated. Source ports can be compiled using with no risk of corruption or segfaults. However, the SDL2 libraries released with the latest Raspbian distribution for the Pi 3 do not have proper GPU support, and ports using SDL2 will be unbearably slow. Compiling SDL 2.0.4 from scratch or using the RetroPie libraries are the only solutions available at this time.

Architecture
Compiling source ports to the ARM platform is a relatively recent undertaking. There may exist issues with alignment, type signedness, casting, floating point strictness, and CPU extensions. Fixing these issues have ranged from simple one-line changes to months of refactoring work. Due to the majority of source ports being developed, tested, and played on the x86 architecture, issues that once were negligible or completely nonexistent become potential show-stoppers. Ports without ARM compatibility may fail to compile, run slower, exhibit rendering issues, or crash. Fortunately, there has been increasing pressure on source port maintainers to fix these issues, as ARM-based devices become more prevalent with the advent of inexpensive notebooks, smartphones, and tablets.

Ports
This list is by no means complete. Unless indicated otherwise, all ports noted in this list are best played in framebuffer mode, not X11, due to hardware acceleration. Most of the display problems described are remedied by installing the custom RetroPie SDL libraries. It is best to have the latest Raspbian release (Jessie as of this writing) due to the increasing number of source ports switching to the C++11 standard.