When developing software for the Out Run arcade board, the turnaround time is not so great if you have to repeatedly unsocket, erase, write and resocket EPROMs for both CPUs. Also, it would be nice to send over some debug information to a development PC, or even possivly interface with other hardware (internet multiplayer!).
To remedy the problem I've built two iterations of this fairly simple device, and written some startup code and a small utility that allows code and data to be transferred and executed from a (now probably vintage) PC with a parallel port and the Out Run board set.
This page is somewhat maintained for the odd event that someone has built this interface. If you're new to this, you may want to build the forthcoming, new and much improved OutRun-USB interface.
Version 0.9D of orboot.exe now supports uncommon port ranges as seen in some PCIe LPT cards. Any USB 'virtual printer port' cable will not work at all (it's not exposed as a LPT port to the OS and thus can't be controlled per individual pin).
The interface itself is no more than a few connectors and some TTL/CMOS buffers. I have deliberately tried to keep it as simple as possible (and even single sided so it's easier to home etch). The first revision had a lot of flashy LEDs, but those were mainly for my own debugging of the thing.
Basically it connects to the digital inputs and outputs of connector G (normally used for the buttons, and brake/start lights). As much as possible the unused pins.
To send data over, it implements a loose interpretation of the IEEE 1284 Compatibility and Nibble modes. The major deviation from the specifications is in that the input pins do not trigger interrupts and the 68000 CPU is too slow to guarantee the needed 500ns response time, so there are some additional transition guards in place. This also means it won't work with USB to LPT cables that only implement a virtual printer port. PCI cards may work, as long as they expose a real LPT port.
It can upload data at speeds up to approximately 50kb/s, the limiting factor being the opto-couplers used on the Out Run PCB. But given the very limited amount of RAM, this should not be a big problem.
The bootloader consists of hardware initialization code, interrupt/exception rerouting and a loop waiting for bytes to be sent over.
It halts the secondary CPU to prevent modification of its memory, and uses only registers (no stack!) on the primary CPU in order to not corrupt the upload.
It's possible to only use the roms of the main CPU, if you're not going to use the secondary one anyway (but you should probably blank out the palette). The bootloader will show a grey background instead of blue if it doesn't detect the secondary ROMs.
This small utility transfers the binary images for the main and secondary CPU to the board when the bootloader is running. Additionally, it can function as a debug console, printing any nibble-mode output sent back from the Out Run PCB.
It uses the InpOut32 LPT driver/dll for driving the parallel port.
Out Run Bootloader 0.9D.Usage: orboot [-options] main.bin [sub.bin]
Options: -port Set the LPT port number (default: 0x378).
-txdelay Sets the strobe delay in nanoseconds (default: 50000).
-debugdelay Sets a debug delay in milliseconds between transitions.
-txtimeout Sets a timeout delay in milliseconds (0=disabled).
-console Keeps the console open and prints nibble mode output.
The 0.9D version of orboot.exe uses a newer version of inpout32 that may require a separate driver install (InstallDriver.exe). It is more compatible with newer versions of Windows (7, 10), and orboot.exe will now attempt to detect the LPT base port address (useful for PCIe LPT cards with unconventional ranges).