Programming the JVF 2010-A

The JVF 2010-A is a large electronic sign consisting of 128 × 48 red LEDs.

There is some information online about the official software provided with this sign. There's less information about the hardware, or how to write custom software. Here's what I've learned on these subjects. If you're itching to start hacking, skip to the end for downloadable C code.

The sign I worked on lives at MITERS. There is a similar sign at Noisebridge. See their writeup for pictures and more hardware description.

Hardware

The removable back panel of the unit holds three circuit boards: a PC motherboard, a power supply, and a custom board I'll call the LED controller.

The motherboard has a 386-compatible (?) processor, some RAM sticks, and a number of ISA slots. One slot provides a connector to the floppy drive, as well as an unused hard-drive connector. Another slot connects directly to the LED controller by a ribbon cable. The motherboard also holds a DIN-5 connector which I presume to be for an AT keyboard. I could not find any serial or parallel ports even as pin headers, though they could be added on an ISA card.

The LED controller is a large custom board of DIP integrated circuits. Other than two 16kbit SRAM chips, all of the logic is provided by 74-series discrete logic ICs. There is not a processor or PLD to be found. This board connects to other boards attached to the front of the unit, which I did not investigate further.

Lacking a logic analyzer, I decided to investigate the software side.

Reverse-engineering the software

I acquired a copy of the official software, JVFF.EXE. The software runs fine in DOSBox. It even displays output: there's a fallback which draws CGA graphics if no LED board is found.

I enabled IO port logging in DOSBox, by setting #define ENABLE_PORTLOG in src/hardware/iohandler.cpp. I noticed a read from port 0x2F0, which is not listed as a standard port in RBIL. DOSBox helpfully logs the instruction pointer with each port access, and soon I was reading the executable's assembly code in the freeware version of IDA. I found the following interesting functions:

• 0x4050: Reads a configuration byte from the controller at port 0x2F0. This byte specifies which DMA channel to use, as well as the dimensions of the display.

• 0x3F02: The entry point for updating the display. Called from many places. Takes a range of lines to update (?) as arguments. Depending on some global variables, it calls 0x3FA9 and/or the CGA drawing routine.

• 0x3FA9: The "driver" for the LED controller. Calls all of the below.

• 0x410D: Sets up a DMA transfer to the controller, then writes the three bytes 0x8F, 0x0F, 0x07 to the controller at port 0x2F0.

• 0x417A: Checks whether the DMA transfer has completed.

• 0x4166: Writes the bytes 0x05, 0x07 to the controller at port 0x2F0, effectively strobing bit 1 low. This resets the controller's state, such that the next DMA transfer will set the first line of the display. Perhaps data line 1 is wired to the reset line of a counter IC.

• 0x403C: Writes the bytes 0x06, 0x07 to the controller at port 0x2F0, effectively strobing bit 0 low. This advances the controller's state to the next line. Perhaps data line 0 is wired to the clock line of a counter IC.

There is more detail to the protocol, but it's best explained by the C code linked below. It's well-commented, I promise.

Writing custom software

After staring at these functions for a bit, I understood the protocol well enough to mimic it in my own code. As a demo I coded a cellular automaton: specifically, HighLife on a projective plane. You can get the code here as a public-domain C program.

I've compiled this code with Open Watcom 1.9 inside DOSBox. With the provided makefile, wmake will build JVFLIFE.EXE. You can then copy this file to a DOS boot floppy, and set it to run automatically using AUTOEXEC.BAT.