Zision Interactive

With my previous success programming a new rom/os for early williams pinball machines, I thought: why not do the same for their competitor, Bally? I've already got most of the code worked out, so it can't be that bad to adapt the I/O part to the other board, can it? They both use the same CPU, RAM, and IO chips as well. So today I dug into the schematics and started documenting what I'd need.

Memory Map

The first step for coding some basic I/O is to get the memory map:

Chip	Address	Purpose
U7	$00	128B of RAM
U10	$88	PIA (GPIO)
U11	$90	PIA (GPIO)
U8	$200	256 nibbles of RAM
U2	$1000	2KB Game ROM
U6	$1800	2KB OS ROM

What's notable here is how small it is. The Williams boards used 3 RAM chips instead of 2, 4 PIAs instead of 2, and 3 ROMs instead of 2 but, besides from an extra 128B of RAM (which I'll miss), the Bally boards have comparable capabilities to the Williams.

Williams took a very straightforward approach to their design: 16 solenoids? Well that will need 16 I/Os, so that's one PIA (each PIA has two banks of 8 I/O pins). An 8x8 switch matrix? Another 16 I/Os (and thus another PIA) obviously. This resulted in a system that was easy to program, but uses a ton of chips that can all go bad. Williams boards are notoriously unreliable, and reproductions aren't readily available.

Bally took the opposite approach here. 16 solenoids? That sounds like 4 bits of data. Why an 8x8 switch matrix when we probably won't need more than 5x8 switches? Lets use those other three bits for other unrelated things. We won't need to write to the lamp board and switch matrix at the same time, so lets connect both up to the same pins, and use another pin to select which one. And hey, the same logic works for the displays as well, right? Stuff like this allows Bally to make due with half the I/O lines, but I can imagine it'll be a pain to work with. Still, it worked out well, right? Bally boards are considered the most reliable and well designed of that era, they're easily repairable, and replacements are available with better, modern designs.

It took me a good few hours to decode the meanings of all the pins on the 2 PIA chips. Each has two banks (A and B) with eight lines each, and four extra lines (CA/B 1/2) with more limited functionality:

U10:
A0-4:  switch strobe ST0-4 (NH)
A5-7: dip switch 1-3 strobe (NH)
A0-3: lamp address
    selects lamps 0-14 for each of the four lamp chips
    all high (15) for no lamp
A4-7: lamp data
    low to enable any of the four lamp chips
A0-3: display 1-4 latch,  nored with CA2 J1-(20-24)
    bcd enabled when high
A4-7: display data
CA1: self test switch input (low = pressed)
CA2: nored with display latch: display blanking/enable (low -> high blanking)
    bcd blank when blanking high (signal low)
CB1: zero crossing input (NL)
CB2: dip switch 4 strobe (NH), lamp strobe 1 
    latches data for first lamp board on down signal
B0-7: switch return I0-I7

U11:
A0: display 5 (credit?) latch, nored with U10-CA2
A1: 'sound module address enable'? J1-7
A2-7: display digit enable #6-#1 (100k-1 or v.v?) J1-(6-1)
B0-3: solenoid/sound data A-D
    0-14 turns on that solenoid
    15 all solenoids off
    (only one solenoid can be on at a time!)
B4-7: 'continuous solenoid data' A4J4-(5-8) -> A3J4-[11,9,8,10]
    low=enable
    B4: A3J4-11: Cont 2 
    B5: A3J4- 9: Cont 4 coin door lock out
    B6: A3J4- 8: Cont 1 flipper disable (high=enable flippers?)
    B7: A3J4-10: Cont 3 
CA1: display interrupt input (NH)
CA2: LED (high turns on), lamp strobe 2
CB1: n/u?
CB2: solenoid (low) or sound (high) select

With this, I have a general idea of what my OS will need to do to run the peripherals, and most importantly, I know how to turn the diagnostic LED on the board on and off, which will be the simplest way of knowing whether my code is actually running. My next step will be to set up an entry point and toggle the LED via one of the PIAs