The Address Decoder

Where were we? Oh yes.

The CPU and SOUND board Theory of Operation writeup tells us that U213 and U214 comprise the address decoder for the cpu board. We've been able to trace the data bus to a variety of sections (or systems) on the CPU board, discovered signal leads that are used to enable the systems, and traced those signals back to the address decoder.

We can now take a slightly more detailed look at the decoder section and muse about what the CPU must be doing to drive the game. Read on...

U214 is a 74LS138 chip, or a 1 of 8 demultiplexer. Its job is to take as input a number between 0 and 7 and in turn enable a single output pin. The input is in the form of a 3 bit binary number. Hence, it demultiplexes the 3 bit signal, enabling one of eight system as a result. This means that of all the system enable signals emanating from the chip, only 1 will ever be on at any given moment. This should make logical sense, as all of these systems share a common data bus (remember the D0-D7 lines go to all of these and are all connected), so only one system should have access to the data on the bus at any time. That one is the easy part.

U213 is a PAL16V8Q, or a 16 input, 8 output, quarter power Programmable Array Logic chip. This is a little package of logic gates that can be programmed by a special device to provide a wide range of routings between the input and output pins. This programming is done at the factory before installing. Yep, that means we can't tell by simply reading a datasheet what the chip is doing. Best thing to do now is to ask a whole bunch of questions.

Take a look at the inputs and outputs from this chip. What do we know about all of the enable signals? Well, they all share the same data bus, so only one can be enabled at any time AND none of the signals from U214 can be enabled when a signal from U213 is on (and vice-versa.) That actually helps a lot. It tells us that this chip largely acts like the demultiplexer chip, but it must have some more complicated job or it wouldn't be on the board. Pinball manufacturers really don't like to waste any money and to use a PAL chip where a 1of8 would fit would just not happen.

Next question. Do we care about anything else associated with this chip? To accomplish driving the machine, not really. We have no intension of driving the sound system, ROM chips and RAM chips from this location, so we really don't care about those enablements. We only have interest in two signals, the IO Strobe and the IO Port enable.

Next question. Really? What are all these barred E, Q, RW, VMA, MPIN lines? Why are A10 and A9 connected here? What about XA0? Ok, that was more than one question. My contention is that, while these are compelling questions, we really don't need to know how all of these inputs are related to the outputs. In fact, I will answer these questions with another more interesting question: What would happen if we pull this chip off the board completely?

Well, that is a big hint as to what the plan of attack will be. Can we remove this chip and a whole bunch of other chips on the CPU board and still make use of the key systems that live on it. The answer is yes. The CPU on this board is running a program that progresses through a big loop, enabling each of the interesting systems in the machine one after the other, either sending data to them, or reading data back via the data bus. To spin through the systems, it uses address lines A9 through A15 connected to the PAL chip, and A7, A8, A9, A10 and A12 connected to the 1of8 demultiplexer. A12 is clearly used as an enable signal selecting between either the PAL or the 1of8 decoder. A8, 9 and 10 are the 3 bit input to the 1 of 8 decoder. I can't say for sure how the other address lines are used. We do know that they would somehow decode to enable the systems that are hooked up to the PAL chip.

To take control from the main CPU, we will hook up a separate controller that has the ability to mimic this main program loop. Our loop will leave out everything hooked to the PAL chip except for the IOStrobe and IOPort signals. In other words, we can bypass that chip completely, leverage the 1 of 8 demultiplexer, and still run the system. The big gap will be finding a way to drive sound, but be assured that we have a plan for that as well.

Well, now we have let slip the plan, so next time we'll discuss how to strip down the CPU board and wire up some connectors so that we can take control. Oh, and a little detail about reset states and watchdog timers. There is always something.