When I got it, it was a clean board that worked a few months ago. Game stopped booting, so owner had rom and 5101 sockets replaced. Repairer says board booted on bench (LEDs turned off), but when installed in game it still didn't reach attract mode.
- I replaced the (still original) CPU and RAM (IC13 only) sockets, but that made no difference
- Installed Leon's test rom (flashes LEDs without using RAM, etc), but it didn't boot either
- Tried Andre's test rom (tests all chips without using RAM, etc), also didn't boot.
- Checked all the inputs of the ROM and PIA chips with logic probe, none were stuck.
- Replaced data line buffers (IC9+10) with jumpers in case they were a problem, but no difference.
- Found out Andre's test rom also strobes A15 line along with LEDs (in case the PIA outputs or LED chip are broken), so I checked that but it also wasn't working. At this point I reason that the problem must be between the CPU and ROM (both known good).
- Although all the address and data lines are strobing, it's still not working, so one must be strobing wrong somehow.
- I write up a quick test rom comprising nothing but infinite loops, reasoning that this will keep the program counter (and thus the address lines since no other accesses are happening) constant. Installed in a known good board, it works as expected. Reading off the address lines one by one reports the address $7800, which is the first byte of the rom.
- When installed in the problem board, A9-11 are low (as expected) but every line below them is strobing. I can't really explain this, why would the CPU be jumping all through a 512 byte subset of memory?
- I Remove the remaining RAM (IC16) and PIA, but nothing changes
- Since the data on the data lines should now be predictable (just reading the entry address, and then that address itself repeatedly), I reason that I should be able to pick it up with a logic analyzer. With mine hooked up to the 8 data lines, I record them at 24MHz (for overkill), and examine them, but I don't see any of that data. # - What I do note though is that at the beginning of the boot, D6 seems to wobble a bit while the rest don't. I don't know if that wobble is normal, but the one reliable thing about any pinball related troubleshooting, I've found, is that if there's 8 of a thing they tend to act the same, so I suspect something is up with the D6 line
- I take out the CPU and rom, meaning that, per my look over the schematics, nothing should be attached to any of the data lines now (and thus they should all be floating), but when I apply power, I still read a signal on D6.
- Something must be shorted somewhere, so I begin checking the resistance between D6 and every other signal on the board, eventually finding that it has continuity to A6. All that's left now is to actually find it
- I begin at the source of D6 (IC9), and visually follow the trace all around the board, looking for any potential problems, but am unable to find any. Usually a short is between two adjacent pads of a chip, but looking at the various chips, none have A6 and D6 near each other. What I do realize though, is that the RAM chips have them directly across from each other. The chips are too wide to have a short that way, but the way these boards are routed with both chips next to each other, they squeezed the signals from the left side of the chip between the right side pads to reach the next chip over, which means the trace gets awfully close to the pads. To make matters worse, due to their cheap board manufacturing process, instead of masking off individual pads for soldering, they just did the whole strip of pads, which includes the traces running between the pads.
- Although I'm unable to see a problem, this area seems suspect, so I desolder the sockets and confirm my theory: there's a tiny bit of solder bridging the pad of D6 to the A6 trace running next to it.
- After removing the solder, the board boots fine
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
Many older games from the dawn of computer based ('solid state') pinball have some pretty basic rules, and I've often pondered hacking the roms to improve them, but reverse engineering assembly from scratch isn't really my idea of fun so I never really got into it. Driving home one night though, I got to thinking: the hardware for these machines is pretty simple, the schematics are available (and even have memory addresses!), would it really be that hard to just write a brand new rom from scratch? Sure, I didn't know assembly or anything, but it couldn't be that hard!
So I sat down with a copy of the Motorola 6800 reference manual, some data sheets, the schematics, and a copy of PinMAME to debug my code in, found where the entry point/address was, and started coding.
Long story short, it actually was pretty easy! The williams hardware was designed for simplicity from a programming standpoint (though that ended up making the boards overly complicated and unreliable), all the I/O was easy to work with and within a few days I had simple drivers written for all the different peripherals and a basic 'OS' for a game that could control lights, display scores, and jump into a callback table when a switch was hit by the ball.
Programming a game itself using this would prove a bit more complicated of course, due mostly to timing/threading issues (of course, I just had to write a custom threading system for this 1MHz processor), but nothing extreme. A few months later, and I had a brand new rom for my Hot Tip, with many fancy new features which I showed off in a video here
I didn't document the whole process very much, but if you'd like to know more, or would like to try to write your own new game rom using this as a basis, drop me a line!
The full source code and roms are available at http://github.com/zacaj/williams-sys-3-6
Some ugly Spring Break artwork wouldn't do, so I spray-painted the cabinet black:
The same went for the head:
I've never understood pinball machines that couldn't think of a use for more buttons, so I put a second set in:
I picked up a sheet of 0.5" MDF at Home Depot, and lightly drew out my layout
I also used leftover scraps from cutting it to the right size to experiment with mounting components
Using a small router and an 1/8" bit, I found that, as long as you go slowly, it can produce workable light insert holes
Since I couldn't find any launchers, I made one myself by welding a scoop to a piece of 0.5" iron stock and attaching some plastic to the front to guide it
When you power the coil, it pulls the iron stock in, and the plastic guides it through
After two trips to the Allentown PinFest, I've managed to get together pretty much all the components I'll need for the build.
I got two boxes of assorted used parts for $20, and a ruined, half populated Spiderman playfield for $30, yielding an assortment of playfield parts:
I also bought a head from a mysterious 4 player EM for $20:
I really wasn't looking forward to the thought of trying to assemble a cabinet from scratch that would work with regular parts, but luckily I found this slightly beaten Spring Break cabinet for $15
(the legs were separate, another $20)
It even came with a working power supply, so I didn't need to worry about finding a 25-50V power supply. I was able to find a combination of taps that put out 28VDC after recification. Most non-EM pinball aficionados seem to think that 50V+ is the way to go, but honestly the flippers seem just as strong on my 25V games as my 50V.
I put in an order to Digikey for $70 (!) of electronics, including some high power MOSFETs for the solenoid drivers:
, some parts for making molex connectors,
, three CPU boards (basically cheaper, more powerful, lower level Arduinos),
...and a ton of stuff for audio output, including this surface mount op-amp, which turned out to be *really tiny*
I made some nice compact solenoid driver boards
Looking at schematics for actual machines they've got all kinds of weird stuff, however just a MOSFET, two resistors, and a line to the CPU were enough to fire the solenoids just fine. I wish I had some way to turn them off in case the CPU locks up while one is turned on, but I don't know what that would be, and as far as I can tell 'professional' machines don't do it either.