(Click any tag to remove it)
Many months later I have picked up a nice Stern Dracula pinball machine, which allowed me to actually go and start testing this code in a game and get working on the I/O support.
Bally has an interesting system for driving their lamps. Unlike Gottlieb (who just had one transistor for each lamp and banks of latches to remember their state) or Williams (who used an 8x8 switch matrix), Bally opted to use 60 individual SCRs. SCRs have an interesting property to them: unlike transistors, which allow current through when there's voltage at their input and then cut it off when the input turns off, SCRs will keep letting current through until the input turns off, and the current drops to zero. This has a cool effect in that, you can hook a lamp up to an SCR, give it a quick pulse on its input, and then just leave it and the lamp will stay on. Of course, you don't want your lamps to stay on forever, so Bally powered all its lamps via raw rectified DC, which follows the same 120Hz sine wave the 110VAC coming from the wall has.
You can see the DC in purple here compared to the AC in blue. Effectively a rectifier just inverts the negative half of the AC signal, which means the DC still looks like an AC wave. Because of this, the power source for the lamps is dropping down to 0VDC 120 times a second, stopping current from flowing through the SCR, allowing the light to turn off. So what Bally does is, 120 times a second, the MPU pulses any lights it wants to be on, and then they stay on until the next 'zero crossing'. As long as the MPU pulses the lamp again right as the SCR turns off, the lamp appears to stay on. If it wants to turn a lamp off, it just doesn't pulse it any more. Pretty nifty, but it also means timing is going to matter a lot here, since there's factors beyond the MPU's control at work.
Of course, this complicated system wouldn't be very useful unless you could also pulse all your lamps simply, so Bally hooks up each bank of 15 lamps to a 4 to 16 decoder. This chip has 16 outputs, and turns only one on at a time depending on which 4 bit binary number is sent into it. Unlike Gottlieb, who needed a dedicated output on each chip for every light (limiting them to 4 lights per chip), Bally could use one chip for 16 lights. But I said 15 earlier, right? That's because one of those 16 outputs isn't connected to anything. Since the same data lines that the MPU uses to control the lamp board also go to the displays, they use one output as a 'safe' output to leave the lamp board on while the MPU does other stuff. (The same is done with their solenoid board, which can control 15 solenoids from its decoder).
15 lamps per decoder means we need four decoders to control 60 lamps, and four also is a nice round computery number. All four decoders are hooked up in parallel, so another set of 4 bits, one per decoder, is used to enable/disable each one while all 15 outputs are run through. 4 bits happens to be the size of the 5101 RAM chip on the MPU, so 15 bytes of that RAM will go to storing the state of all the lamps.
With that in mind, I feel like I have a pretty good idea of how to interface with the lamp board:
Each time the lamp voltages crosses zero, the MPU gets an interrupt signal and starts the lamp update sequence Load up each 'row' of four lamps Combine this with the 4 bit 'column' address for the decoder Send them out as one 8 bit byte to the lamp board 'strobe' the decoders to tell them to latch in the data Repeat for the rest of the rows
Nice, simple code, aided by the four 'data' bits of the lamp board inputs being mapped to the top 4 bits of the MPU PIA's 8 bit output port, which coincidentally matches which four bits of RAM the data is stored in. Almost like they planned all this! Too bad it didn't work. The lamp I wanted to turn on did turn on, but so did another in the same column.
After some thought, I realized that the decoder chips only 'latch' the address. The enable/disable data signal takes effect immediately. So when I sent out the next combined byte containing both the 4 data signals and 4 address signals, the new data for the next row must be affecting the previous row.
So now I had another step. Instead of sending them both out at once, first I'd have to disable all four encoders. Then, I'd send out the new address and latch it in. Finally, I'd enable to encoders again. A bit slower, but much safer than relying on the timing of the two signals to work out. Of course, this also didn't work.
After tearing my hair out for a few days reading and rereading data sheets for the decoder chips, staring at schematics, and scrutinizing my code, I finally discovered that my data sheets were wrong! The part number on the schematic was 14514CP, but my data sheet was for 14514B. Very similar chips, but with one important difference: for the 14514B the way to latch a new address was to drop the latch signal from high to low. That transition was what triggered the latching of new data. With the 14514CP, when the latch pin was high, it was instantly passing the address data through. Dropping the latch pin low just made it stop passing the data and remember whatever it had last. So I rearranged my code to quickly pulse the latch pin high for a few microseconds, instead of leaving it in one state or another, and finally my issues were solved
The code for all this is available on my github, if you want to check it out
With I/O figured out, I theoretically know everything necessary to start writing code, so I want to start with the simplest possible thing: getting an infinite loop to run in pinMAME. The CPU (Motorola 6800) is fairly basic, it only needs to know one thing to run code: where to start. You do this by putting the address of your starting code at the highest location available in memory, so I wrote a quick assembly file:
.orq $1800 ; start of U6 main: jmp main .orq $1FFF-1 ; two bytes before end of U6 .dw main ; address of main
It doesn't get much simpler! And besides from a classic off-by-one error (I did $1FFF-2 instead of -1), it worked on the first (heh) try. Loading this up in PinMAME I was able to open the debugger and see it dutifully running around its tiny loop, forever.
U10 Bank A: control: |self test irq|n/u|1|1|!blanking 0|D|0|1| direction: out (1) data: 11110000 - bits 0-3 go to display latches, start low - bits 4-7 go to display data, start high (1111 = blank) Bank B: control: |zero crossing irq|n/u|1|1|lamp strobe 1|D|1|1| direction: in (0) U11 Bank A: control: |display irq|n/u|1|1|led 0|D|0|1| direction: out (1) data: 00000000 - bit 0: credit display latch, start low - but 1: not used - bits 2-7: digits 1 thru 100k, start low Bank B: control: |n/u|n/u|1|1|solenoid0|D|0|0| direction: out (1) data: 10011111 - bits 0-3: number of solenoid to fire, use 1111 to fire none - bits 4-8: continuous solenoid data (turn flippers off, coin lockout on)
Configuring the PIAs is a bit of a pain as they have three bytes of memory internally (the control byte, the direction byte, and the data byte) per bank, but you can only access two at a time. Therefore, one bit (2) of the control byte chooses which (direction or data) the other byte goes to. Fully configuring a PIA involves first initializing the control byte so that you can access the direction byte, then initializing the direction byte (read or write), then changing the control byte to let you access the data byte so you can actually do some I/O:
ldaA 00110001b ; irq state | n/u | CA2 output | ...mode | CA2 value 0 = blank displays | enable direction register | irq on | ...self test ->low staA u10AControl ldaA 11111111b ; all outputs staA u10A ldaA 00000100b ; toggle DDRA (3rd) bit to write to ports oraA >u10AControl staA u10AControl ldaA 11110000b ; blanking means any outputs here will affect displays staA u10A ; 0-3 set all display latches low, 4-7 blank disp data
Finally, I can use the PIA to start controlling the LED, toggling it on and off repeatedly:
inc counter ifeq ; counter = 0, it wrapped around from 255 ldaA 00001000b ; led bit bitA >u11AControl ifne ; led on? ; turn led off ldaA 11110111b andA >u11AControl staA u11AControl else ; turn led on oraA >u11AControl staA u11AControl endif endif
and it works! At least in PinMAME. I don't have any Bally/Stern machines on hand and configured correctly to easily test it in game right now, but that's alright. PinMAME isn't perfect but you can at least get most of the logic ironed out when it's easily debuggable before throwing it on the black box of a real machine.
The code for all this is available on my github, if you want to check it out
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.
The first step for coding some basic I/O is to get the memory map:
|U7||$00||128B of RAM|
|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