OSSC puts retro consoles on a modern display with an FPGA you can rebuild

The latency problem this board exists to solve

OSSC stands for Open Source Scan Converter, and it is described as a low latency video digitizer and scan conversion board designed mainly for connecting retro video game consoles and home computers into modern displays. The word low latency is doing the work in that sentence. A classic console outputs a signal that a flat panel television is not built to accept, and the usual answer is a converter box that the owner cannot inspect, let alone modify. OSSC takes the opposite position: the board is a published design, the firmware is in source form, and the person holding it is expected to be able to rebuild and reprogram it. The catch is stated just as plainly in the documentation. Building and debugging the firmware requires the board itself, a USB Blaster compatible JTAG debugger such as a Terasic Blaster for firmware installation and debugging, a micro SD or SDHC card for firmware updates via the card, Altera Quartus II with Cyclone IV support in version 16.1 or higher where the free Lite Edition is enough, a RISC-V GNU compiler toolchain, Picolibc for RISC-V, a C compiler for the host architecture to build the SD card image, Make, and iconv if you want the Japanese language menu.

The toolchain is a RISC-V cross build with a small host helper

The software side of the board is a RISC-V controller, so the first build step is a cross toolchain with RV32EMC support plus Picolibc. The documentation gives both a from source route and a package manager shortcut for Debian style distributions. The source route is the one to copy if you need a specific configuration.

git clone --recursive https://github.com/riscv/riscv-gnu-toolchain
git clone --recursive https://github.com/picolibc/picolibc
cd riscv-gnu-toolchain
./configure --prefix=/opt/riscv --with-arch=rv32emc --with-abi=ilp32e
sudo make    # sudo needed if installing under default /opt/riscv location

The architecture and ABI flags are the important part, since the controller is a 32 bit RISC-V core with the compact instruction set and the ilp32e ABI. On a Debian style distribution the documentation instead suggests the packaged toolchain and Picolibc in one line.

sudo apt install gcc-riscv64-unknown-elf binutils-riscv64-unknown-elf picolibc-riscv64-unknown-elf

One small host side tool is also compiled by hand, the converter that turns a binary into the Intel hex format the flash programmer expects.

gcc tools/bin2hex.c -o tools/bin2hex

The bitstream build is a Quartus project with a manual QSYS step

The hardware design is a Quartus project, with the top level files visible in the repository as ossc.qpf, ossc.qsf, ossc.sdc and ossc.cof, plus a sys.qsys platform configuration and the rtl/ and ip/ directories. Building the bitstream starts by bringing in the submodules, and the project says to do this once after cloning or whenever the submodules have been updated.

git submodule update --init --recursive

After that the project is opened in Quartus, and the platform configuration in sys.qsys is generated through Platform Designer. That step is only needed before the first compilation or when the platform structure has changed, and the generated files are then patched to reduce block RAM usage, after which a timestamp file is touched to acknowledge the update. The final compile is started from the Processing menu, and the Timing Analyzer report is where you check that no timing violations were introduced.

The controller software is a plain make build with two options

Once the bitstream exists, the software image that runs on the RISC-V controller is built from the software/sys_controller directory. The build is a single make invocation with an options part and a target part, and the README documents both.

cd software/sys_controller

make [OPTIONS] [TARGET]

The target all is the default and compiles an ELF file, while clean removes the ELF and the intermediate files, and the documentation says clean should be invoked whenever the options change between compilations, unless generate_hex is used, which does it automatically. The only option given is OSDLANG=JP, which switches the menu to Japanese. The same directory also has a make rv-reprogram target, which downloads an updated software image directly to flash over JTAG and needs a valid FPGA bitstream to be present already.

Volatile programming for tests, flash programming for permanence

There are two ways to get firmware onto the board, and the documentation is explicit about which one suits which purpose. The bitstream can be programmed straight into the FPGA, which is volatile and therefore fine for quick testing, or it can be written into the serial flash chip next to the software image, where it is loaded automatically every time the FPGA is powered on, which is the nonvolatile route for long term use. Direct programming uses the Programmer in Quartus: select the USB Blaster device, add the configuration file from output_files, and press Start, then download the software image if it is missing or out of date in flash. Flash programming needs an extra step, because the FPGA image and the software image have to be combined into a single indirect configuration file. The conversion tool in Quartus produces a .jic file from the setup data, and the programmer then has two options checked in Tools, Initiate configuration after programming and Unprotect EPCS or EPCQ devices selected for Erase and Program operation, before the file list is cleared and the generated file is added.

SD card updates need a header, a checksum and two fixed offsets

Updating the firmware from an SD card is friendlier than attaching a debugger, but it needs a small piece of preparation, because the bitstream is in a proprietary Altera format and has to be wrapped in a custom header structure with checksums so the CPU can process it reliably. The helper application in tools/ builds that image, and it is a host compile step rather than a cross compile.

cd tools && gcc create_fw_img.c -o create_fw_img

The image is then assembled from the bitstream, the software binary, the offset for the software image, a version string and an optional suffix of up to eight characters.

./create_fw_img ../output_files/ossc.rbf ../software/sys_controller/mem_init/flash.bin 0x50000 1.21 mytest

The two fixed numbers are the point of the layout. The primary firmware has the FPGA bitstream at offset 0x0 and the software image at 0x50000, and a secondary firmware, identified by a specific key in the header, is installed automatically at the flash base address 0x00080000. The command produces a file named after the version and the suffix, and that file is what you copy to the fw folder of the SD card, which has to be FAT32 or exFAT formatted.

Debugging runs the same makefile with a flag and a serial terminal

The debugging path reuses the software build with a debug flag and then opens a UART terminal on the board, and the documentation warns about one specific trap at the end of a session.

make clean && make APP_CFLAGS_DEBUG_LEVEL="-DDEBUG"

make rv-reprogram && nios2-terminal

The second command flashes the software image over JTAG and opens a terminal on the UART, and the reminder at the end of the README matters: nios2-terminal has to be closed after the debug session, otherwise any JTAG transaction will hang or fail. That is a small detail, but it is the kind of thing that costs an evening when you are new to a board.

GPL-3.0, a v1-series branch and a fast release rhythm

The firmware is distributed under GPL3, which matters for a board people are encouraged to modify, since a derived board design inherits the same obligation. The repository also separates the reference hardware from the firmware, with schematic and PCB project links pointing at a separate ossc_pcb repository. The default branch is named v1-series, so the project keeps a stable line rather than developing on a rolling trunk, and the release record shows three versions in under a year: v1.20 on 2025-12-21, v1.21 on 2026-03-14 and v1.22 on 2026-09-13, with the last push on 2026-09-28. The wiki page linked from the README is where the current feature list lives, which is worth reading before buying or building a board.

Editorial conclusion

OSSC fits a tinkerer who owns a retro console and a modern television, owns or can build the board, and wants to change the firmware rather than accept a fixed product. It does not fit someone looking for a plug and play adapter, since the toolchain assumes a USB Blaster compatible JTAG debugger, Quartus and a RISC-V compiler on the same machine. Before you start, confirm the hardware list in the README, build the toolchain with the rv32emc architecture as shown, and decide whether you will program the FPGA volatilely over JTAG for quick tests or write the flash image for permanent use.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. marqs85/ossc on GitHub
3. Project website
4. README
5. Releases