Back in the distant past, MAME started cataloguing programmable logic devices (PLDs) in addition to ROMs. This was met with considerable hostility from certain segments of the community, as it was seen as forcing them to obtain files they saw as unnecessary for emulation in order to run their precious games. However PLDs are programmable devices, and it’s important to preserve them. So far though, the PLD dumps have mainly been used by PCB owners looking to repair their games. The haven’t been used by MAME for emulation. However, PLDs are key to the operation of many arcade games, performing functions like address decoding and video mixing.
One such arcade board is Zaccaria’s Laser Battle, also released under license by Midway as Lazarian. This board uses complex video circuitry that was poorly understood. It includes:
- TTL logic for generating two symmetrical area effects, or one area effect and one point effect
- TTL logic for for generating an 8-colour background tilemap
- Three Signetics S2636 Programmable Video Interfaces (PVIs), drawing four 4×4 monochrome sprites each
- TTL logic for generating a single 32×32 4-colour sprite
- A Signetics 82S101 16×48×8 Programmable Logic Array (PLA) for mixing the video layers and mapping colours
On top of this, they decided it was a good idea to use some clever logic to divide the master clock by four when feeding the Signetics S2621 Universal Sync Generator (USG) that generates video timings, but to divide it by three to generate the pixel clock feeding the rest of the video hardware. This lets them get one third more horizontal resolution than the Signetics chips are designed to work with. They need additional logic to line up the pixel clock with the end of horizontal blanking, because the number of pixels in a line isn’t divisible by three, and some more logic for delaying the start of the visible portion of each frame and cutting it off early because they wanted less vertical resolution than the Signetics chips are designed for. It uses an GRBGRBGR colour scheme where the most significant bits are are in the middle of the byte and the missing least significant blue bit effectively always, so it can’t produce black, only a dark blue Was this design effort worth it? I guess they must’ve made some money off the Midway license at least.
Anyway, this game has never worked properly in MAME. It’s always been missing the area and point effects, the colours have always been completely wrong, and the mixing between layers hasn’t properly either. And that’s done inside the PLA. The PLA has 48 internal logic variables, each of which can be programmed to recognise an arbitrary combination of levels on the 16 input line. Each of the internal variables can drive any combination of the eight output lines. The outputs can be configured to be inverting or non-inverting.
In theory this sounds like a job for a ROM, so why use a PLA instead? Well a ROM with 16 input bits and eight output bits would need 64kB of space. Such a ROM would likely have been prohibitively expensive when this game was produced. I mean, its program ROMs are only 2kB each, so there’s no way they’d be sourcing a ROM 32 times that size just for video mixing. The PLA maps the same number of inputs to the same number of outputs with just 1,928 bit of storage, or a little less than one of the program ROMs. It can’t produce absolutely any arbitrary input to output mapping, but it’s more than enough for this application. In fact, it turns out they didn’t even need to use all the space in the PLA.
Read the rest of the post if you want to know more about the process of decoding the PLA bitstream and examining its contents.