XarkXosera is an FPGA based video adapter designed with the rosco_m68k retro computer in mind (and likely adaptable to most any computer with an 8-bit parallel port and a few control signals).
"Not as clumsy or random as a GPU, an embedded retro video adapter for a more civilized age."
Inspired in concept only by it's "namesake" the Commander X16 VERA, Xosera is an original open-source video adapter design, built with open-source tools, that is being tailored with features generally appropriate for a Motorola 68K era retro computer.
Currently the design is using the Lattice iCE40UP5K FPGA which is fully supported by the open Yosys FPGA tools. Development is now mostly on the Xosera board (PCB available on Tindie) for the rosco_m68k system using the UPduino 3.x FPGA board, but still also builds for the iCEBreaker FPGA board (which can alter Xosera registers via USB to SPI).
Current Xosera features include:
- VGA output at 640x480@60Hz or 848x480@60Hz (16:9 widescreen 480p)
- Register based interface using 16 16-bit main registers (accessed 8-bits at a time)
- 128KB of embedded main video RAM (limited by current modest FPGA)
- 10KB of tile RAM for tilemaps or tile glyph definitions (or either can be stored in main VRAM)
- Xosera memory accessed via multiple 16-bit read/write ports with auto-increment and nibble write masking
- Dual 256 x 16-bit ARGB colormap RAM (16 "blend" values and 4096 colors), one colormap palette per video "playfield"
- Dual overlaid video "playfields" with 4-levels of "alpha blending" or additive blending (wrapping or saturating)
- 8x8 or 8x16 tile based display modes (with adjustable displayed height, e.g., for 8x11)
- 1-bit tiled mode allows 256 8x8/8x16 glyphs (8-bit) and 16 forground/background colors (similar to PC text mode)
- 4-bit and 8-bit tiled modes allow 1024 8x8 glyphs (10-bit), H and/or V mirroring and 16 colormap choices (similar to some consoles)
- 1-bit bitmap mode with 16 foreground/background color attribute byte (similar to a bitmapped PC text mode)
- 4 or 8-bit "chunky pixel" bitmap modes with 16 or 256 colors (128KB VRAM permitting, pixel doubling required for full bitmap at 256 colors)
- Horizontal and/or vertical pixel replication, so pixel size can be from 1x1 up to 4x4 native pixels (e.g., for 320x240 mode)
- Fractional horizontal and/or vertical scaling (e.g., to allow scaling to modes like 640x400 or 512x384 using non-uniform pixel size)
- Smooth horizontal and vertical tile scrolling (with native pixel resolution scrolling offset)
- Amiga-inspired video-synchronized co-processor ("copper") to alter video display registers or colors on the fly
- Rectangular bitmap "blitter" with support for logical operations, transparency, masking and shifting (~10 million words/sec)
- Interrupt generation with maskable interrupt sources including end-of-frame, copper generated, bliiter idle
- C API that provides easy low-level register access (and transforms into efficient inline 68K assembly code)
- Robust ANSI (aka DEC VT) compatible C terminal driver for rosco_m68k (included in recent rosco_m68k firmware)
- Implemented in a System Verilog subset, that is synthesizable and compatible with current versions of the open FPGA tools.
- GNU Make based build using the pre-built YosysHQ OSS CAD Suite Builds tested on Linux (Ubuntu 20.04 and also Ubuntu on RPi4 and RISC-V 64), Windows 10 and MacOS.
- Fast Verilator simulation with host bus emulation (to alter Xosera registers in simulation and upload data) and using SDL2 for PNG screenshot of each video frame
- Icarus Verilog simulation
Planned Xosera features TODO:
- DVI/HDMI output at 640x480@60Hz or 848x480@60Hz (16:9 widescreen 480p) using 1BitSquared DV PMOD (currently this mostly works, but is not 100% solid at this point - not exactly sure what the issue is).
- 4 dual 8-bit (stereo) audio channels with full channel mixer for stereo audio output similar to Amiga (using sigma-delta DAC output)
- At least one "cursor" sprite above video playfields (and ideally more, probably with 16 or 256 colors)
Possible improvements for the future:
- Convert VRAM to be 32-bit from current 16-bit width to allow more bandwidth per cycle
- Treat VRAM as multiple banks to allow for more concurrent operations (probably minor win though)
- Line-draw or polygon acceleration (but very "tight" on iCE40UP5K FPGA resources currently)
- In the fullness of time, port to a larger FPGA (like Lattice ECP5) to support more VRAM and improved resolution and features