Arcade Game

Vampire is a rare arcade game released in 1983 by Entertainment Enterprise Ltd., a U.S.-based developer. In this game, the player takes on the role of a Dracula-like vampire who prowls a town at night in search of women to bite and drink their blood. The gameplay involves navigating with a 4-way joystick and using a single action button to “neck” victims. This game is extremely rare, with only one known instance owned by a collector.

Screenshots

The screenshots come from emulation (MAME). The graphics emulation still has some imperfections (colors are not entirely accurate, and there are minor graphical artifacts). There are also issues with the sound.

Hardware

The Vampire hardware consists of two PCBs – main and video. It is based on a primary 6809P CPU and a 6502 sound sub-processor (the socket on the PCB is empty, but analysis showed that the 6502 is missing), working in conjunction with an AY-3-8910 sound chip. The video board features a custom blitter. It’s not a specialized graphics chip, but rather a solution built from standard logic gates and a RAM.

Main PCB

(Empty) Place for debug connector (?)
Main CPU: 6809P
Ribbon cable connectors
Sound generator: AY 3-8910
PIT 8253
DIP Switches
Main RAM
Main ROMs
GFX ROMS
Sound ROM and RAM
Empty socket for sound CPU

Video PCB

Framebuffer RAM ( tons of 64k x 1 DRAMs )
Blitter (commands) RAM
Color PROMs
Color DAC (resistor ladder)
Ribbon cable connectors
60MHz XTAL

Interrupts / Debugging

The currently known Vampire PCB set appears to be a prototype. The board includes an unpopulated socket area, likely intended for a debug interface or expansion header. Furthermore, the interrupt vector table references routines that resemble diagnostic or error-handling code, indicating potential communication with an external terminal or device for debugging purposes. To force the game to run, it was necessary to modify the interrupt vectors in the ROM. Unfortunately, the exact hardware implementation of this workaround remains unclear, as I do not have (and never had … whole emulation is based on guessing / software analysis)access to the PCB.

Main CPU

Main CPU (6809) memory map includes ROM (32KB), RAM (8KB), blitter RAM, and also mapped I/O regions. There’s also probably some debug I/O stuff in there too, but not 100% confirmed (terminal - like comms active only in error handler code).

The I/O area is used for reading data from two input ports (game controls and coin inputs) and two dipswicthes ( 8 bit). Plus there’s a sound latch and sound ack bit for “talking” to the sound CPU. There’s also some I/O lines used to communicate with the blitter (see below).

Sound CPU

Sound hardware is based on the AY-3-8910 chip and a separate CPU, probably a 6502 (the socket on the PCB is empty, but code analysis points to a 6502). Besides the CPU and sound chip, there’s also a PIT 8253 timer, which is likely used for sound timing. The sound CPU talks to the main CPU through a latch and some extra I/O lines for handshaking. It only uses 1KB of RAM and 4KB of ROM. Timing and communication between the CPUs isn’t fully figured out yet. Still kinda unclear how it all works exactly.

Blitter

At the core of the Vampire hardware is a custom blitter, built from (many) common logic chips. Blitter commands (see the pic below) - each 8 bytes long - are stored in 4KB RAM area (mapped at address 0x1000 in the main CPU memory space) and organized into lists that can be executed on demand at any time. The main (and only…) function of the blitter is to copy rectangular areas (the source address, rectangle size, and destination coordinates are defined in the blitter command) from ROM ( where the graphics are arranged as a single large bitmap of 512×256 pixels in 1bpp mode) into a double-buffered (?) framebuffer with a resolution 256×256 pixels. Each data bit (in 8-bit sets) is copied to up to 4 layers (four 64K x 1 single-bit DRAM units), which allows for a maximum of 16 (2^4) colors (R,G and B valeus are hardcoded for each colro in the PROMs). The specific target DRAM chips where the data is written are selected by the fifth byte of the blitter data (pen). Each blit uses a base offset (x, y), set in the blitter flags area at $07FA–$07FB. When you write to that address, the blitter starts copying graphics from the last used blitter command. It keeps going until it hits a command with the ‘END OF LIST’ bit set. Blitter is also controlled by flags set at address $07F8 of the main CPU. You can select the framebuffer (front or back), enable global gfx flip (cocktail mode), and (possibly…) lock the blitter RAM so it can’t be accessed by main cpu. All of this info comes from guesswork and digging through the game code. Some bits in the blitter data don’t seem to be used-or maybe we just don’t know what they do yet. Also, turns out there’s more RAM on the video board than we thought or calculated before.