Software_Environments

The original aim was to run Linux (probably Raspbian (Raspberry Pi OS), though Kevin Koster also suggests PiCore) on the Raspberry Pi, as most of the vector game/emulator software that we intend to modify to use the Vectrex Interface library is already available for Linux.

During development, Chris Salomon pointed out that the graphics glitches that were being experienced while running ported software were due to the Linux kernel suspending execution of the game within the line-drawing routines for long enough that line lengths were sometimes drawn too long (and the beam thereafter misplaced on the screen until it is zeroed).

To escape the control of the Linux kernel, Chris assembled a bare-metal development environment drawing on code from other open-source projects such as raspberrypi-dmx and Circle. With this, the emulator/game code can be booted to directly, akin to the Vectrex running a game ROM, and this eliminated the glitches experienced under Linux while also reducing CPU load. However Linux software has to be modified to run bare-metal, and this can be (particularly for MAME) a significant effort on top of adapting them to use the Vectrex Interface library. It also means that support for USB/Bluetooth/WiFi devices on the Pi will probably be impractical while running game/emulator software.

Linux

It remains to be determined whether it would be possible to avoid the suspension of the line drawing and I/O routines by writing a Linux kernel driver to handle these functions, or whether this could at least reduce the amount of time that they spend suspended to acceptable levels. This should probably be implemented in combination with hardware interrupt support for the PiTrex libraries.
Alternatively there are a variety of Real-Time linux kernels available that are intended to allow user-level software to achieve timing-critical control of I/O. There is already a distro for the Raspberry Pi using the PREEMPT_RT Linux kernel patch.
The GPU has multiple processors able to access the GPIO and run separately from Linux, so custom code running on the GPU shouldn't be influenced by Linux interrupts.

Kevin intends to investigate the above options, but has no experience with the Linux kernel's internal operation, and has not yet found the time to research the topic adequately.

New work in this area is currently focused on the GPU.

Bare-Metal

To ease porting of Linux software, it is preferable that as many C Standard Library functions are provided in the Bare-Metal compiling environment as possible. Chris mainly used libraries from the raspberrypi-dmx project which are assembled from various sources and work without any supporting run-time software layers. This offers a simple and reliable system, and one similar to writing software for the Vectrex itself, but does not provide everything available from Linux and the GNU C Library, particularly it is missing a system clock accessible using functions such as gettimeofday(). Kevin has been investigating using the Newlib C Standard Library instead, with an interrupt-driven system clock routine adapted from Circle.
Chris has written an attractive menu system for the bare-metal environment that displays a program selector on the Vectrex and allows easy selection between binaries to be run.

Chris is now developing his own bare-metal environment in a separate source tree without Linux support.

Real-Time OS

Besides Real-Time Linux kernels, a wide variety of other real-time OSs are available for the Pi. These solve the issues of missing C Standard Library functions and some also provide USB/networking support. However some adaption of the Linux software will often be required, and OS background processes might add more complications than the bare-metal environment.

Non-multi-tasking OS

Graham Toal is currently looking into using Risc OS as an alternative for bare-metal that still provides some OS capabilities. This is because Risc OS is a cooperative multi-tasking OS rather than one that uses interrupt-driven time-slicing. There is an OS call "OS_IntOff" that stops Risc OS from generating or responding to interrupts: https://www.riscosopen.org/wiki/documentation/show/OS_IntOff

If this is called, ongoing wifi/bluetooth/serial transfers are likely to fail, but it is unlikely that any programs we use will need to be doing those at the same time as drawing. (except possibly sound over bluetooth?)

The biggest impediments to using Risc OS at the moment are A) Risc OS on the Pi Zero doesn't support networking, making the installation of software on the system (eg a build environment with GCC) problematic - although that is a one-time problem that is easy but tedious to solve; and B) we have a steep learning curve to climb to find out how to access the external hardware from user-level C code under Risc OS. (And possibly how to insert C code into the confusingly-named (for our application) 'vector' system, which is a sort of dynamic procedure call/system call mechanism like SVC or SWI on other machines.