Once again I find myself up against the switch matrix. It seems that getting input from the pinball machine is going to be my biggest challenge from a hardware interface perspective once again. It took a bit of reading and a lot of digging around in code, but I have finally coded up a working system that appears to be driving the switch matrix properly. Not well. But functional.

This is pretty exciting for me. If you recall, when I was trying to get this working with the propeller chip it pretty much defeated me. I had too many variables in the equation. For those keeping score at home, it is really difficult to solve a problem when there are too many variables involved. I was up against: new hardware platform, new programming language, the unknown of trying to use the existing pinball CPU board "as-is", an ill-conceived attempt to use the same 8 pins on the chip for both input and output, an attempt to build and test the entire matrix in-toto (ie, drive columns read switches).

The new approach has been much more successful. First off, I have eliminated two big issues: I'm using C on an arm9 chip. Two things I am very familiar with. This alone has saved a lot of headache. It is no fun to try to debug something on hardware and using a programming language that you are just learning. Unless your goal is to learn that hardware and language, you are pretty much wasting time.

Second, I have a nice functioning simulation environment. This is a huge win. Being able to cross compile for either the simulator or the board has save a lot of grief. Yes I know that I have to validate the simulator and there may be bugs there, but at least I am able to rough out structure and code flow. With the propeller this was a lot harder.

Third and most important I am taking a baby-steps approach. I'm not sure what foolish notion caused me to think I could fully code the switch matrix driver and expect it to work, particularly in light of the fact that i really didn't understand the hardware. This time around I have been coding up small tests, checking in simulator and on hardware, then incorporating the working code into the game system or kernel drivers as appropriate. Funny thing is, I know better. At least now I'm acting like it.

This all brings me to where I am currently. I have code that can select a switch row. I decided to use a shift register (74HC595) to expand the IO so that 3 pins can select one of 8 columns. This is working very well and has the added benefit of being code I will reuse when driving the remaining components (solenoids, flash lamps and lamp matrix). Just last night I finished coding and testing reading of switch inputs on a dedicated set of 8 pins. This is working (not as well as I'd like, but it is working). The input was slightly more difficult due to a key misunderstand about setting up the GPIO pins on the s3c2410 board. But now it works and the knowlege is mine.

The next step should prove interesting. I have isolated and soldered a connector cable in to the Data East CPU board switch column and row hardware. All I need to do (in theory) is hook the cable from the protoboard to the CPU board and see what happens. If all goes well I expect to be able to read switches from the machine itself. Once that is working I can start addressing all of the other fun problems that come with reading hardware switches (missing switch closures and de-bouncing being the two biggies).

Not quite the speed at which I'd like to be progressing, but progress none the less.

Not nearly as exciting as the last update, but some small progress was made.

Re-arranged the driver code so that more work happens in driver. This should result in a lot less thunking from user space to kernel space, and honestly, it's just the right way to do it.

Roughed in some switch matrix handling code. Doing this is what precipitated the driver rework. Should be able to have a working switch matrix "simultation" early this week.

Made a trusty checklist of what needs to happen for "in machine" testing of switches. If all goes well, I could get to that this week (short week of work means more time to hack pinball!)

Did a little research on my display frame rate issues. Might be able to make some changes to thread priorities, but the rate I'm getting is actually just fine. In fact I have plenty of leeway while still being functional, which is good as there are a lot of mechanics still to code.

Set a simple roadmap to a minimal useable table. I think I should be able to reach that goal by the end of December. The roadmap, in short is: read switches, fire solenoids, code in simple game engine to hook switches to solenoids.

Great progress this week. I got my checklist of items completed and was able to hook the sbc2440 board to the dot matrix display in the Goldeneye machine. Success!

I want to write up some full details on this, but here is the quick version.

The new driver for bit banging the GPIO pins on the sbc2440 didn't work the first time. I had to dig a bit more into the driver code where I discovered actual documentation. Yes, I RTFM'd. And it helped. I had essentially configured the pins randomly. Once set properly to be output pins things worked much better.

The simulator I wrote for the DMD appears to be pretty darn accurate. Once I got the bit banging working and the cables hooked up properly, the driver worked without any modification. There are a handfull of issues that need to be worked out. I'm not happy with the refresh rate I'm getting. I'm also getting a touch of flicker (barely, you really have to stare at it to notice). It works well enough for now.

Needless to say I'm very excited about this progress.

The functioning display will make debugging the rest of the HW setup much easier. Next up will be getting the switch matrix functioning with the matrix states showing on the display (much like every standard pinball diagnostics works.)

Not complaining though. I found a lot of things I otherwise would have kept scratching my head and wondering just what the heck I did with.

I did two things of note:

I started some sketchbook work on a playfield toy that I want in the finished game. While some might say it is a bit premature to be working that far ahead, I say it speaks to my confidence that I'll get it working. The goal will be to replace the Satellite playfield toy with something more in line with the new theme: a volcano.

I made a very detailed list of the steps that will lead up to some in machine testing. It is not a long list. In fact, the list points out very clearly that the only thing that will keep me from in machine testing in the next couple of weeks will be my fear of in machine testing.

Unfortunately this weekend is lost and next weekend I will be out of town. I am still committed to making progress every week. It may just not be a lot.

Ye Olde Day Job occupied way more of my waking hours this week than it ever should.

I did manage to get a little bit done:

Added a new driver to the linux kernel for configuring and driving the GPIO pins needed to interface to the pinball machine. Removed a couple of the test drivers that come with the prebuilt kernel that conflict with the GPIO usage I need. The pinball driver is not complete, but it does allow me to reconfigure the GPIO registers to use the pins exactly how I want. Hopefully I will get to test it this weekend.

I have been doing a lot of scratch pad calculations on how many GPIO pins I actually need. For certain I will use 6 for the DMD and 11 for the switch matrix (3 for selecting and 8 inputs). For the lamp matrix I'm pretty sold on using an LED driver which would only require 3 pins. The final decision to make is exactly how to drive the solenoids and flash lamps. I'm thinking, if 3 pins loading and running the lamp matrix is fast enough, would a similar driver also work to drive the coils? At this point it will all be theoretical until I actually wire something up and test it.

That's it for this week, but under the circumstances at the "day job", I'll take it.

Once again, a small list of small accomplishments from last week. Keeping the project crawling along:

Finalized timer system and gave it a good testing. Should create a unit test for it just to make sure all corners are covered.

Reworked some of the simulated DMD code. I had frame rate calculations happening in the simulator code side which didn't make much sense. Started moving the frame rate calculations to the driver so that it will work for both simulator and hardware.

In a flashback homage to my late 1970's basic programming days, I hand coded a 5 x 7 dot matrix font for use on the DMD. Of course this time it is done in C.

Worked up a good prototype for the switch matrix driver. Next step is to create some kind of simulator input for the switches. As with all of my code, I may end up discarding this and rewriting it a few times.

Started spec'ing out how to program the various modes for the game. The current debate is whether to code directly in C, or to define a language for coding the game play. As one does not preclude the other, I will probably be coding a few modes directly in C for early testing while the debate rages on. I'll write this up in detail at some point as it is exceedingly important.

Started the process of wiring up some test circuits and getting the 2440 hooked up to the protoboard. Came to the realization that I really should fabricate a nice project box for this instead of housing the key components in an old cardboard box. I envision a trip to TAP plastics in my future. I hear the place is fantastic.

I'm trying hard to do at least a little bit of work on this project every day. Most of the progress is pretty mundane. Some simple coding, some schematic wrangling, some data sheet spelunking. The simple truth is that not everything going on is very exciting, so I don't feel compelled to post about it.

It did however dawn on me while reading one of the many project blogs I follow that these little advances made every day are what keep the project alive. If you skip too many days, you have to go back and remind/retrain/relearn things that should be second nature if you keep at it on a regular basis.

To that end here is a dump of the little things that kept me engaged this week:

Wrote the basics of the swtich matrix code. Still a lot of work to do including getting some kind of simulator switch matrix working.

Wrote, re-wrote, then threw out and wrote again the basics of the timer system. I'm still not quite happy with it.

Bought the correct 2mm pitch cables from ebay to wire the GPIO port to the protoboard (very, very exciting)

Identified the locations in the kernel drivers that need to be modified to use the available GPIO pins. Came to a fairly good understanding of how the GPIO pin settings work.

Spent a few hours understanding exactly what the Stern/Data East switch matrix hardware is doing. Made of list of components to order (probably from Digikey) to wire up a test circuit of my own.

Hopefully these will turn into some full and more interesting posts in the near future.

I have been staring at the schematics for the CPU board for a long time now. Months, if not years. I just noticed that there is a typo on page 3 of 3. They label both the send and return for the switch matrix as SWITCH ROWS.

The new version of the CPU board for Stern games (CPU Sound Board II) has a completely new design and properly labels the connectors.

This has absolutely no bearing on anything, but it just struck me as odd.

For the record, the top connector driven by the the swstb (switch strobe) signal should be SWITCH COLUMNS.

In other general rambling news, my procrastination with cables has paid off. I located the exact 2x20 2mm pitch connector with ribbon cable for the sbc2440 GPIO port on ebay! This brings me much joy.

I've been slowly adding core bits of key code into the pinball codebase. I have also been putting off making cables. Anyone who has read through the old posts in the blog know full well that making cables is not my strong suit. It is more like an ill fitting suit that my Dad handed down to me years ago for my first job interview. Somehow it did the job, but boy howdy, it sure wasn't going to win me any second looks for fashion sense. But I digress.

I do have all of the bits I need to make a small test cable which will allow me to do two things. Firstly I can verify that my device driver hacking is working as expected, namely that I am properly reassigning pinouts to the functions I want in the GPIO. Second, it will allow me to hook up said pinouts to the protoboard to test a variety of circuits. Third, and possibly most frightening, it will allow me to hook one of those circuits up to the Vishay Dale DMD display and find out if my DMD driver works on the actual hardware.

All I need to do is get the soldering iron out and spend the time to put it together. Hopefully that will happen soon.

On the coding front I am going through the self flip flopping debate over whether certain systems should be callback/event driven or whether a polling loop should be used. To that end, I have decided that the timer system will be handled with callbacks. That was a pretty simply choice actually. If every section of code that required accurate timers needed to be written with polling, every system would have to somehow manage on their own to be consistently reliably deterministic. By using a system that employs a central timer and callbacks, I can achieve a reasonable deterministic result for all timers in the system. Each callback will still have to make sure that a reasonable response is made on the timer callback and each callback will need to ensure that they are operating safely on data in a multithreaded environment. I'm not worried about either of those situations.

You see, coding suits me much more like the Men's Wearhouse. I'll like the results...I guarantee it.

Before I got too much further along writing code against my simulation enviroment (ok, right now it only simulates the DMD), I thought it would be a good idea to take the time to make sure the build environment actually built cross platform.

This is always a good exercise and avoids things like assuming certain libraries will be present on the target board and later finding out they have yet to be ported. Fortunately I don't seem to be running into any such problems. The other benefit was that I was already hacking exceptions for the simulator which had to be unwound and written properly to run on the arm board.

I also took the time to hook up an extra hub so that the board was visible to the network. This only took some minor tweaking of the board's net configuration (it was set up for a different subnet than I'm using at home), but I can now either use ftp to transfer code to the board or mount the dev build directory via NFS on the board. This saves a lot of time screwing with binary sending of files via minicom.

All excellent progress toward a reasonably professional setup for cross platform developing. And the pinball code actually runs on the board!

Next up will be to dive in and write a proper driver for the GPIO as it will be used for the pinball machine.

Lest everyone wonder if I completed faded away, I thought I should drop a post in here.

I have been working on getting my SBC2440 working in a good clean development setup. Over the last few weeks I found the time to find all of the cables (the new laptop doesn't have a serial port, go figure) I needed to get a good workspace set up. Once everything was in place I was able to get the linux kernel configured so that I can reflash the board to a working state when I inevitably blotch something. I'm happy to report that everything is working properly and I can rebuild the kernel and rootfs from source and reflash the board to a working state when needed. Another point of drudgery behind me.

Next up will be working on drivers to control the GPIO pins on the board. This should be pretty straightforward as the board (not to mention that interweb thing) come with lots of examples. I still need to find the exact precise cables to get from the GPIO pinouts on the sbc to my protoboard. I am precisely horrible at sourcing the correct cables and connectors, but a few more trips to HSC electronic supply should do the trick. Maybe I should actually bring the board with me next time. (insert eye roll graphic here)

Ok, yes, that's not exactly the physical display, but I'm pretty excited about it none the less. I wrote a pin compatible simulator that (in theory) reacts to the display driver just like the physical board will. This has allowed me to put together a display driver and a get to work on a simple screen UI package.

I still have a bit of work to do to simulate the signal timing tolerances (minimum times between rising and falling edge transitions, etc), but the basic concept is in place. Next step will be to get my sbc's linux image rebuilt and reflash the board (to prove to myself I can accurately do it). At that point I'll just need to hook up a few wires and see how my driver fares against the actual hardware.

While it may not seem like such a big deal, it will actually consititute a huge milestone and free up the coding of drivers and simulators for the switch matrix, lamp matrix and coils. I will make a ton more progress in my few hours between work and sleep if I can work on with simulated code that I know is working.

I discovered some very cool details about creating images for the dot matrix display (GIMP save-as C file is very helpful) which we'll cover at some other time. I'm also pleased to report that I actually took the time to set up a CVS archive for the code, which lends a bit of seriousness to the effort. So there you have it. I'm still snail pacing along, but there is progress and I'm right happy about it.

Just got back from a two week vacataion on the fabulous East Coast of the USA. I love New York.

Good thing about having a shiny new laptop was that even though I was away from the hardware, I could still crank out some code. After a bit of a ponder, I decided that the first thing to get running would be the Dot Matrix Display. Of course, being the way that I am, I can't just start hacking away at direct HW interface code. Rather I decided to set up a framework and design the code so that I can swap devices in and out and be able to run either live hardware or a simulation. I'm not ready to start explaining the framework yet (I'm still arguing with myself over how it will work). Instead, here is an attempt to explain my DMD concept.

Just back from two weeks of definitely needed vacation. Made some progress on some code which I'll try to get written up in the next day or two.

In the meantime...

If you are anywhere near San Jose on July 11th and 12th, I highly recommend dropping in on California Extreme 2009. This is a fantastic Pinball and classic arcade game show. I'm planning to attend and I'm particularly looking forward to the Speakers Series including a talk by Steve Richie!

I read a lot of DIY hardware blogs. A common thread is how best to run an LED matrix with the best balance between performance and pinouts.

The lamp matrix of the pinball machine is the exact same problem. Traditionally the lamps in the machine would be a bunch of #555s, #44s,#906s etc. Being a greenie at heart, I'm going to replace the lamps with leds. There are a lot of nice writeups out there discussing the retrofit of existing machines, and vendors have even started to produce LED plug in replacements for the old standard bulbs.

I haven't completely decided quite how to take this on. The choices boil down to:

Use the I/O driver board and drive the lamps.

Wire up our own LED driver board as a lamp matrix replacement

For a project like the re-skinning of my Goldeneye the plan all along was to use the already in place I/O driver board for all of the lamps, flash lamps and solenoids. Thing is, these cost $300 (in the wild) and have significant limitations that really beg the question of whether we should be just fabricating our own. Now that I have evicted the Sega CPU board from the mix I have been running through a bunch of scenarios for the pinouts of the new CPU board. I am leaning more and more away from driving the lamps through the Sega I/O driver.

Here is my favorite answer to running a 64 bit lamp matrix with the best balance of pins and power. The MAX6951. With this one chip, you can drive a constant current 2.7V-5.5V to 64 discrete LEDs with just 3 pinouts from your controller. Yes, it costs $15, but this chip does exactly what I need it to do without me needing to monkey together a bunch of additional chips and components (which is not my strong suit). I recommend spending time with the data sheet for this chip even if you don't decide to use it just to see how they solved the problem of driving a 64 bit matrix with 9 pins.

For the pinball application, I will be ordering and playing with the MAX7221CNG which is a 24 bin DIP version of the driver that will be easier to prototype with and a bit cheaper. I'll be ordering up some 555 and 44 LED replacement bulbs as well.

I'm very pleased to announce that I am the proud owner of an SCB2440-IV. In fact, I've been the proud owner of it for well over a month. So where is all the cool progress?

From the nothing is easy dept

I thought that I'd be able to just fire up my old HP laptop, hook everything up and get cranking. And indeed, that is exactly what I was doing. It was fantastic. I can't tell you how happy I was to be able to fire up the GCC cross compiler and simply ftp code over to the board and run it. Then the laptop just consumed itself. Minor setback.

As fate would have it, tax season was good to me. I'm now extremely pleased to have not only a cool new SBC to play with, but I have a new flashy fast, memory packed laptop from with to play.

The new computer has been here a few days now and I'm still getting the dev environment up and running. I have already reconfigured and rebuilt the linux kernel for the 2440 and I'm well on the way to getting all those GPIO ports working just the way I need them to. It's going to be fantastic fun deep kernel hacking goodness.

Over the last two months, besides being completely buried with the "day job", I have become enamored of the SBC2440.

Seriously. For reasonable cost here is what you get:

arm290t processor running at 400MHZ

64MB memory + 64MB flash

Runs linux 2.6 kernel with all drivers

Built in audio

LCD driver

lots of GPIO

SD/MMC card socket with driver (supports 1GB)

USB

ETH0

This completely eliminates any need to hack on the CPU board of the pinball machine. It allows the use real tools, removes all memory constraints (ok, not all, but compared to the prop chip...) removes the need for fabricating an audio setup and fits the criteria I set out for:

all hardware and software needs to be available such that if I want to build another machine just like this one I can. This means that using a PC "found laying around" will not do.

all of the hardware needs to fit in the standard pinball form factor.

In short, this board could easily replace the entire existing the CPU board. There is still need of some additional hardware fidgeting, but using this SBC will allow a lot more progress on things I want to work on.

Now I just need to come up with a little spending cash for XTCPinball. That and dust things off around here.

A. It is unlawful for any person to keep or use in any public place any pinball machine equipped with any device which cancels and records the cancellation of free games won without the actual playing of said free games by the player.

B. It is unlawful for any person to keep or use in any public place any pinball machine game which permits the insertion of more than one coin per game. (Prior code §§ 3-5.17, 3-5.18)

It turns out that building a pinball machine is a big job. We knew this all along, in fact I'm pretty sure I wrote something along those lines quite a few times. What I didn't realize was that working on "the Pinball" would be quite so daunting.

In addition, there are some nagging little voices whispering from some deviant brain cells telling me that this whole thing will be a whole heck of a lot easier if I just give in and order a TS 7360 from embeddedarm.com and quit monkeying around with the propeller chip.

What is that? Doubt creeping in?!? I tell you, I have no room for doubt around here. Thus we hatch new plans.

I left off trying to get the switch matrix to read properly by patching into the CPU board. I'm picking up again by getting a switch matrix to read properly, but I'm going to work on it as a separate component. If you really look at what I was trying to do, the only real functionality I want from the CPU board is the switch matrix. Why the heck should I put so many hurdles in my way by trying to patch into it? Let's just tackle getting switches to read, then we can take a look at what we need to do for the other key systems. Maybe we leverage the I/O power board, maybe we dont.

So the plan is to work off-machine on some smaller self contained systems. This has a few benefits. First, a lot of what I need to do with the pinball can be applied directly to a bunch of other keen projects rattling around in my head (particularly the lamp matrix.) Second, I'm due for a sense of accomplishment and tackling a smaller project will not only get me working again, but will in all likelihood let me bathe in the (brief, possibly dim) glow of some small success.

Well I didn't get nearly the progress I would have like to in 2008. I'm not disappointed, that's just what the past year had in me for pinball. I'm actually (believe it or not) working on the machine again and new ideas are kicking around my brain, so there is hope for 2009 for XTCPinball.

I keep regular tabs on Coconut Island's progress. It sure looks like they will have their machine rocking in 2009!

Also, Snow Mountain Pinball looks like they will be rolling out a rather impressive Creepy Crypt machine in 2009. The website says Halloween 2009.

Snow Mountain is doing extremely cool things. Read the news page. This is definitely not your grandad's pinball. If we all follow along, maybe we can get them to post more about their progress.

For me? Well I'm dedicated to writing more in 2009, so I'll have to have some progress to write about. I feel good about my chances.

I just finished up writing a reply to what is a fairly common question.

I was wondering how well the propeller chip is going for you? I've just got started with the prop chip myself and was really kinda questioning the ability of the chip to handle all the power and complexity of a fairly advanced machine.

Truth be told, I ask myself this question frequently, so I thought I'd share the answer with anyone else who might be following along.

Q: So, how's that Propeller chip working for you?

A: I'm not one for short answers, even where they might be warranted...

Even though I really like the chip, in all honestly I think the Propeller will eventually fall short. It is a rather powerful chip, however it is really restricting to have to live within the hub and cog memory constraints.

Speed wise I have not had any issues and I'm pretty sure that the Propeller can easily handle the lamp matrix and switches. It is really easy to work with the 32 general purpose I/O. I have also enjoyed remembering that efficient programming is important even in this world of unlimited memory and CPU power.

What I am getting from the chip, is the ability to tinker with the machine using a simple prototyping board that cost under $25. Hard to beat that. I've been able to learn a lot about the pinball machine using this setup.

Finishing a complete playable game with just the Propeller is an interesting challenge. I need to decide if it is the challenge I want to tackle. I do think it can be done.

What it will come down to for me with the Propeller is: Do I want to spend a lot of my time writing page swapping code (to and from an SD card) and hand tuning asm code (to fit game play mechanics in 512 Longs), or would I rather get myself a nice embedded ARM board that frees me from restrictions and lets me actually make the pinball machine go. IE: is this about tinkering with the propeller, or making a pinball machine.

I spent a lot of time considering Technologic Systems SBC's and I think you could go a long way with one of these running linux: Technologic Systems TS-7260 [

I really wish I had some progress to post, but I don't. If I manage to set up the workroom by the end of the year I will be happy. There is good reason to believe that will happen as well. I'm really itching to get back on this project.

Fancy new USB oscilloscope in hand, I approached the now slightly charred CPU board in its sad and disconnected and kind of neglected state and promptly realized: I know arse-all about how to use this thing.

So I tapped on my chin a bit and hrm'd and harumph'd.

Then, not one to be stopped by something so trivial as not knowing what I'm doing, I started woking on the perfect project to learn the scope with.

It's not pinball, but what the heck... read on.

I make little gadgets. Cobbled together with various bits of electronics I've collected over the years. Knowing this, a friend asked if I could make a simple blinking red LED heartbeat for her halloween costume. Well if that doesn't sound like a job for the 555 timer chip, then I don't know what does. And if the 555 timer chip doesn't sound like the perfect thing to hook my scope to, I don't know what will.

The hearbeat I'm shooting for is a THUMP THUMP PAUSE THUMP THUMP PAUSE. Each THUMP lights an LED, one for each half of the heart. To get the exact timing for the duration of the lights and the pause I elected to use a 3 stage cycling timer circuit. I based my work on this sample circuit.

Output A and Output B are hooked up to red LEDs, and Output C is used only to restart timer A. All that was needed was to determine the correct values for all of the resistors and capacitors to make the lights blink at the correct rate. In the schematic, the 100K resistors should be considered variables R2A R2B andR2C. So along with R1A and C1A, R2A will determine the the amount of time that Output A is high, then how much time elapses before timer B is triggered.

Determining the values of the components is a simple matter of math. And while I recommend that you be able to do the math, we can also rely an any number of timer circuit calculators to help us pick our values.

I knew that I wanted each LED to be on for about 1/4 second, or 250ms. Then the pause before blinking again would be about 1/2 second (500ms) to give about 60 beats per minute. A bit of work showed that 3000K and 1000K resistors with .1 uF capicitor would be pretty close to what I'm looking for, and low and behold, I also happen to have those components in my box of stuff. (double the 3000K to get the 1/2 second pause for timer 3). Also, I elected not to add any extra circuitry for reseting the timers, instead when the batter is applied, we get all timers starting then the circuit corrects itself due to the longer duration of timer C. This keeps things smaller and simpler.

All wired up with a handy 9V battery and we have a nice blinking hearbeat. And we have three timer circuits creating some very simple and accurate square waves for us to hook our scope up to.

Next step, a quick stop at parallax.com to download and install the scope software. Then we are ready to see how this thing works. Our goal is to get the two probes to show the square wave generated at the output pins for timer A and timer B.

While waiting for my USB scope to arrive I thought I'd poke around the board a bit more with my woefully inadequate tool: the multimeter. Things didn't go so well.

Read on.

<!--more--> I thought perhaps something was going on with the plasma controller or the sound section which, while in theory should be off, might fall into the category of "Scott missed something."

Well, I must have shorted something when looking to see what was happening on the sound outputs because, well, it actually caught on fire. Actual flames. I stared at it for a moment, then realized I'd best turn it off. The fire snuffed itself out quickly, but goodness does it smell bad.

What seemed horrible at first turns out to be just a fried chip in the amp section. Possibly a few fried 1K resistors and a couple of diodes. Not a show stopper.

I needed to make a Jameco or Digikey order anyway, so I'll just throw a few more component in the bag.

It was a bit disheartening. The scope arrived the very next day. Now I'm left wondering if I should just remove the fried components and proceed (I don't need the sound section working), or if by removing the bad components I render the board unsafe to operate.

Time to stare at the schematics for awhile and make a decision. Meanwhile, order going in for replacements. Might as well keep the CPU board properly functioning.

There are 12 discrete items that sit on the main data bus which are now, in theory, properly hooked up to the propeller chip. The theory is clearly standing on shaky legs for, as we have discussed, there is just too much noise on the D0-D7 data lines which cannot be explained away if everything is actually properly hooked up.

Here then, we go on a walking tour of the data bus and discover that we really weren't paying attention.

Read on!

The problem: when the entire data bus is set to be disabled from the controller chip, I am reading wildly random voltages on the D0-D7 data lines.

Conjecture: Something is either not actually getting disabled or I'm missing a component completely.

This should be pretty simple to test out. I set the machine controller code to put all of the bus components to a disabled state, set all of the data lines to output, pulled them to low output, then entered a loop. At this point I measured the voltage on each of the data lines, first at the propeller chip just before hitting the inline serial register voltage divider, then at the main CPU chip socket on the CPU board.

Everything measured zero at the propeller chip, and all of the control lines measured at 3.3V (high output) which is correct as coded. This should cause all of the enable pins of along the data bus to be set as disabled.

Measuring the data lines at the CPU socket, I read a variety of values from .4V up to 4.84V.

Next I made a handy list of everything on the data bus, what kind of chip it is, which pin on the chip is the chip enable and which control line should be hooked up to the enable pin.

I was going to include the chart here, but it appears to be in my other suit. I'll try to update this later with the details.

This helped a lot. Immediately a few things jumped out at me. First off, the RAM and ROM chips have been pulled from the CPU board. This leaves the D0-D7 lines at those chips floating. Floating inputs are bad. Second, a few of the data bus components have control signals that are not hooked up. This means we have no way to tell what the chip is doing. See, paying attention helps.

For the ROM and RAM chips, I decided to just re-socket the chips and hook their enable lines to +5 volts to permanently set them to disabled. A similar hook up was made to temporarily set the I/O driver board bus transceiver to be disabled.

At this point, I carefully went to each chip enable pin and verified that everything on the bus was finally actually disabled.

A re-measuring of the data lines shows that we now have a steady ~ +.4V at each data line when measured at the CPU socket.

On one hand, steady is good. On the other hand, why +.4V? This value is well within the valid range of logic low for everything on the bus, but I don't know why there would be any + Voltage at all. When presented with something that we don't understand there are a lot of ways to react. I ran quickly through frustrated, then passed by a lament that I didn't pay more attention in high school physics, and finally landed at the inevitable realization that I need to study more.

Fine I'll study more, but why not put the main program back in and see what happens? The results are rewarding, but not successful. There is now zero flicker on the data line. The dedicated switches get a solid signal when enabled and can clearly be processed more than fast enough. The switch matrix carries the exact same problem that it did before. Once a column is latched, it stays latched.

One thing is abundantly clear here. I'm using the wrong tool for the job. There is no way I'm going to be able to determine what is happening with a chip that is enable for just a few dozen nano seconds, 100's of times a second, using just a multi meter.

Thus did I put an order in for a simple inexpensive USB oscilloscope. And thus did I hit the books again while keeping a wistful eye on the mailbox.

After far too long we got the debug display, main loop and machine loop all cranking. Not necessarily working, but cranking. The code is just a small snippet from the machine interface. I'm not going to dive into code details just yet as that's just not quite important to the story. You'll have to trust me that the assembly version of the machine loop is functioning properly without actually looking at the code.

On to what is important. Paying attention is important. Particularly with electronics.

First lets catch you up. I rewrote the code so that we have a nice tight loop that

enables the dedicated switches on the data bus and reads the input

for each of 8 columns in the switch matrix

enable a single column by setting the column data on the data bus and clocking the switch column strobe. This causes one column to be latched and held low (input enabled)

enable the switch rows on the data bus and read the input for the enable column

writes the dedicated switch (8 bits) and switch matrix (64 bits) of data to the HUB memory so that other systems (in this case the debug monitor) can work with it

pulses the watchdog timer circuit to keep the system RESET line from pulling low and causing many items on the data bus from functioning

This revealed several issues with the overall plan. First, I was trying to run my prototype board with a separate power supply from the CPU board. This was just dumb. What this essentially created was a single circuit with multiple unconnected grounds. This causes all kinds of potential problems, one of which is noise. The video output signals suffered from this. Also, the data bus basically carried random noise. When data was driven high everything was OK, but reference signals pulled to ground were not. As a result the video could not sync and there was a lot of cross talk and random flickering of data from the dedicated switches and the switch matrix. Basically it didn't work.

I decided to pull the +12 signal and ground from the I/O power board, the same ground and power that drive the CPU board. This required a simple rework of the voltage regulator on the prototype circuit and the results were immediate. The video output snapped into crisp focus. The dedicated switches worked flawlessly.

The matrix on the other hand was still not working. In fact, the switch matrix code is still not functioning properly. At this point you are caught up to where I was about two weeks ago. So as not to build up andy unwarranted expectation: The switch matrix is still not fully functioning. I do however know a lot more about the data bus than I did lo so many weeks ago.

Next up: My frustrating and illuminating investigation of the operation of the data bus.

Not a huge leap of reasoning here, but it became very clear to me that we won't make any show-off level progress until we get the basic machine interface in place. The goal is to get some response from the main hardware players: dedicated switches, switch matrix, lamp matrix, flash lamps and coils. Our first proof of concept touched the dedicate switches and was done in the Propeller's high level programming language (spin). In order to push past this stage there was a bit of a ramp up required. Read on as we go on a search for software tools and retrain our brain to think in way it hasn't for quite awhile.

I've been trying to recall the last time I did any significant work in any assembly language. I'm exposed to it every day (controllers and drivers for embedded systems on PowerPC, XScale, MIPs), but the last time I set out to design a system largely in assembly was, well...hmm...for the Apple ][. So yes, it has been awhile. Do those old cobwebby brain cells still fire? Apparently they do. At least enough to make good sense of the propeller assembly language guides, tutorials and examples.

The chip being used is the Parallax Propeller, a 32 bit multi core microcontroller. It is designed to run either asm or an interpreted byte code language called Spin. Spin is adequate for a lot of tasks, but it does not lend itself toward fine tuned small fast sections of code. That and I simply don't like it. I see little gain in learning a new language that applies only to one niche controller. For what we are doing, the code needs to be small, fast and (for the most part) deterministic. The propeller assembly code lends itself to these needs very well. And it is assembly code which, with a few notable exceptions, is just like coding assembly for any other chip (even the 6502).

I spent a lot of my free time reading the propeller assembly docs, a wide assortment of propeller assembly tutorials and pawing through as many propeller assembly examples as I could find. There is no short cut for this. You will need to *gasp* study. All of the information needed is linked from the Parallax Propeller forums.

I also searched out some tools to help with the coding process and found that there is a decent Propeller emulator available. GEAR allows you to load binary images created with the Parallax Propeller tool (IDE) and run the code on an emulated chip. This is exceptionally useful and is well worth the time to install and learn how to use.

The results? Great. My asm chops are coming back pretty well. In fact I have made some significant progress on the interface code which I'll share next time.

I find that one of the best ways to know if you understand something is to see if you are able to explain it to someone else.

To that end, I'm going to see if the plan knocking around in my head can be written up in anything near a coherent fashion. Now that I know that the controller can successfully talk to the pinball's CPU board, it is time to focus on writing more code. This then is the first pass at describing the software system structure. I guarantee it will change, but you have to start somewhere. Read on!

I hinted at the system structure previously. It is largely influenced by the hardware we are replacing and the hardware we are using to replace it. Here is a high level view of the major components.

Mode Engine |

Sound System |

Dot-Matrix Video Driver |

Mass Storage |

Physical Machine Interface

This component monitors the pinball switches and drives the pinball lamps and solenoids. Switch input is queued to be processed by the Mode Engine. Data for driving lamps and solenoids is provided from the Mode Engine and synchronized with the Sound System and Video Driver via cross component data modules and timers.

Mode Engine

Pinball games operate through a set of modes. In each mode, target goals and objectives and scores differ. Generally, the game progresses through a set of modes and once they are completed, a final wizard mode is played after which the main modes are played again, possibly with different rules.

The Mode Engine is an event based system which allows for the tracking of states, switches, timers and ball paths. The Engine provides the ability to control lamps, solenoids, sound and video and to award scoring. This control is managed by interpreting a compiled Mode Engine Control Language byte code. More than one mode may be in operation at a time (the key reason is to have a basic operation mode and the current game mode overlap). I will describe the control language, compiler and byte code later.

Sound

The sound system is essentially a sound driver. It will play sounds as indicated by the Mode Engine, pulling the data from mass storage via the Mass Storage driver. The basics of the sound playing is well understood, however I anticipate interesting problems around the need for quick reaction to events. Synchronization with lamps and video as well as caching techniques will be interesting problems to solve.

Dot-Matrix Display Driver

I fully believe that a pinball machine must have a dot matrix display. I appreciate the ease of use of video screens, but it just doesn't feel right to me. A core within the processor will be dedicated to driving the dot matrix display. I'm rather confident that the display can be driven at an adequate rate. Synchronizing with sounds and events will be challenging. In addition, I would like to have more than just on/off for each pixel, so some method of pulse width modulation on a per pixel bases will be required. Interesting challenges. As with the sound system, video data is pulled via the mass storage driver.

Mass Storage

There needs to be a place where we get mode data, sound and video from. Also we will want to be able to store high score information and game settings. Currently we are looking at using a Secure Data card. This is easy to interface with the controller with only a few I/O pins and, according to our initial calculations, we will be able to read data from the card quick enough for both sound and video applications.

Cross Component Data

Not really a component here, but worth noting. The propeller is a very memory restricted chip. At any time, only 32k of memory is available for all cores. Each core is granted access to the memory in sequence. Each of the components will likely be operating independently in its own core, thus the Hub memory will be used to pass critical data between cores. There are a set of synchronization objects built into the chip for the express purpose of keeping critical sections safe. Initial investigation shows that 32k will be plenty of memory provided we can buffer the video and audio data efficiently. Only experimentation will tell for sure.

That's the initial look at the system. The first component being coded is the Machine Interface. For that (and all of the code) we will be using Propeller assembly language. I know, I know, I said I didn't want to hack asm code. I'm definitely not hacking 68B09E assembly and burning roms. I guess the promise of such a small, inexpensive and elegant solution is too compelling for me to pass by. Even if I end up using 2 propeller chips, this is still a small and inexpensive setup.

I'm rather pleased to be able to report that the new propeller board has been wired up and our problems with questionable connector cables can be relegated to the bad memories pile. The new cabling setup was largely prompted by the fact that, sitting a prototype board and laptop on the glass of the pinball machine you are working on is not only ergonomically horrifying, but, well, its just silly. Read on for a bit of a walk through of the current hardware and cable setup and philosophy.

The Parallax Propeller chip is a very interesting micro controller. It is an 8 core 32 bit processor that has some severe limitations with memory balanced with 32 independently controllable general I/O pins, a simple small instruction set and some very powerful built in bit streaming capability (mainly for video).

I picked the processor as a prototyping tool for several reasons.

It is cheap. The prototype board direct from Parallax is a mere $20.

It has plenty of GPIO pins and my initial calculations showed we needed a lot.

We can use a single microprocessor to replace the several distributed processors in the original Sega system. Each of the dedicated processors (for sound, video, game control) really don't do a very complex job. I should be able to at least proof of concept each of these systems using a single core in the propeller chip.

The propeller community is very active and helpful. There are lots of code samples and useful objects readily available.

Here is the current setup with the Parallax propeller board paired up with my solder-less breadboard, routing many of the I/O pins from the propeller to our new connector sockets.

I realized that I was going to need several feet of separation from the pinball CPU board. Looking around in my pile of electronics, I spotted a container of RJ-45 cable sockets. Perfect. If I can manage to wire the sockets to the prototype board and the CPU board, we can just use nice long CAT5 cable to drive the system. Here you can see three RJ-45 sockets lined up on the breadboard ready to be used as I/O.

And here is the CPU board with two of the sockets in place. These are a little delicate, but by routing the cables up to the conveniently placed cable holder in the back box, there is no chance of accidentally pulling the cables loose.

For anyone wondering just how long the cables can be without losing signal, the answer is pretty darned long. For the 24 gauge CAT5e, at 10 foot, we get a voltage drop of .125 at 300mA. This means our 3.3 volt signal will easily land withing the input voltage minimum for the components we are sending signals to AND any signals coming from the CPU board will easily still hit the Vin minimums for the propeller itself.

The current wire-up has 8 I/O pins dedicated to the 8 Data bits D0-D8 from the CPU board. Another 4 I/O are being used to drive the 1 of 8 multiplexer. 4 additional pins are driving our Debug output to a composite video circuit (very handy). That's a total of 16 pins consumed. I have wired up 8 additional pins to a third RJ-45 on the breadboard, but these are as yet unassigned. The intention is that this connector will be for the data communication lines needed to drive the I/O Power board. Finally, we will need to dedicate some output lines for audio and and Dot Matrix display and some lines for hooking up a mass storage device such as a SD card.

If it sounds like we are beginning to think about getting the entire system hooked up to one propeller chip, you'd be right. If it sounds like I haven't quite figured out how everything will hook up, you'd be right. If it sounds like I'm running out of I/O pins, you may be right, but I've got some tricks up my sleeve.

Before we get into those details, lets hook it all back up to the machine and make sure the new wiring works.

Success! And Comfort. It is much nicer having the computer and microprocessor on a solid table. There is one problem. The circuit driving the composite monitor has a glitch and I'm not getting sync'd properly. Best guess is that I swapped the resistors around. I'll patch that up and let you know next time. And I'll try to get a snap of the workspace.

I think it may be time to draw up a bit more formal diagram for all the I/O as well.

Terry from Pinnovations dropped an email about Project Solar Ride, a custom pinball project that mixes a computer master control with dedicated microcontrollers for key subsystems. The writeup on the project has some really nice details.

Terry mentions that a complete "from scratch" game is in the works, but it is being kept under wraps until it gets a bit further along.

We'll be keeping an eye out for it.

As for our project? I've been soldering. You all know how much I love soldering. Details in a few days.

We broke our Propeller propstick usb. As it is the only one we have, things have kind of slowed up until I can get a couple new ones ordered. Maybe we were too clumsy, maybe it was just not well built, but the surface mounted usb jack popped right off. We tried re-affixing it a few different ways, but to no avail. The chip will still be useful, but we just can't talk to it.

On a positive note we redid the cable situation. Unfortunately until we get the new propeller chip connector in the mail, we won't be able to test things out. We are so close to making big progress. This has been frustrating, hence the lack of posts.

After essentially rushing to try to get something hooked up on our first go around, we took a little extra time to figure out what was going on. In the process Kevin worked up a much better debugging solution and Scott proved an age old truth...always check the cables.

Cables are a nasty little lot. They wiggle loose, they simply stop working for no good reason. And, unless you took the time to insure they can't be, you can hook them up all wrong. Here is the photo evidence, exhibits #1, #2 and #3

The first exhibit shows the prototype board end of the cable, carefully labeled. Note that it says, on the very right end, D7 RED.

Exhibit 2 shows the cable end hooked up to the 68B09E socket. It sockets into pins 24 through 31.

Exhibit 3 is the pinout chart for the 68B09E. We see from this that pins 24 through 31 are indeed the Data bus pins. Pin 24 in particular is D7.

Check out Exhibit 2 again. It clearly shows the Green wire going to pin 24. The D0 Green wire. That's right. Backwards. There you have it. There was zero chance that pushing the buttons for D7 D6 and D5 would have any chance to register on the correct pins on our proto board. Easy enough to fix though. Presented to you to prove the point that, even though I double and triple checked those cables, I still got it wrong. Dastardly cables.

Debugging. Anyone who has written any code or put together, well anything, has probably needed to debug it. Given that our first test was not successful and things will only get more complicated from here, we decided to look for something we can trust more than hooking up a bunch of blinking LEDs to debug the system.

The Propeller chip is a powerful little tool. Each of the 8 independent cores has a complete video processor built in. Using just 3 output pins, we were able to hook up an old school composite monitor to use for debug output. Using the sample code provided as a head start, Kevin was able to work up a nice on screen matrix for showing the status of things. We have far more confidence in this setup than we did in our little LED light. In fact we event tested it with a button on the protoboard.

Back to the machine. With cables, laptop, protoboard and composite monitor in tow, we made our way back to the pinball. This time with the data cable hooked up in the correct orientation, and the monitor perched nicely on top of the backbox. This picture is unfortunately blurry, but it shows the debug screen. It is showing a matrix for all of the switches, top row for the dedicated switches, and the 8x8 matrix below. We'll try to get better snapshots up at some point.

That's Kevin in the photo btw. I'll show up at some other time I'm sure, but I tend to be the one taking photos.

Plugged back in and turned on. Once again no smoke. And, pressing the three buttons on the coin door, the controller accurately displayed the status of the switches on the new debug output. Fantastic!

At the end of the day all we did was hook up a switch, but this is our proof of concept. We are able to patch into the CPU board at a few key locations and read at least one of the pinball subsystems. We have gained a better grasp on the propeller chip itself, and we have a decent debugging setup. Now we need to work on controlling some more complicated systems, starting with the switch matrix. Before we can do that, we really need to replace that ribbon cable with something both more reliable and longer. Just the fun I was looking for, wiring up more cables.

Ok. Enough of this soldering and coding. Lets put the machine back together and see what happens. At this point we have quite a lot of confidence that our little proof of concept hookup will work. What's the worst thing that could happen? Ok, electrocution, but besides that?

We took our CPU board, prototype breadboard, home brew cables and a Laptop over to the Pinball machine and started putting it all together. If all goes well, we will turn on the machine, push the credits button and a little LED on the breadboard will light up. With a few shrugs of shoulders and very little fanfare, the following took place.

First we hooked up the cable to the protoboard and the CPU board. After carefully checking and double checking the connections here is the cable hooked to the CPU board.

Then we carefully refit the CPU board into the pinball machine. Now, we really didn't think a few things out here. For example..how long the cable needs to be. A little creative grabbing of a box laying nearby and viola...ready to run.

We elected to leave the speakers and the plasma display disconnected. Mostly because random data flowing to the speakers could be really unpleasant. I've heard amplified random signals blaring from a speaker. Not fun. And why destroy a perfectly good plasma display? Those things are expensive. It shouldn't come into play at all for this test. Besides, we'll have ample opportunity to mess it up later on.

I should now reiterate that we are playing with high voltage here. We don't intend to go anywhere near it, but we could very well have screwed up. So disclaimer time again.

So, not much left but to see what happens. We plugged the machine back in and turned it on. It didn't blow up. No smoke, no noise. In fact everything looked downright correct. Nothing happened. Only the indicator LEDs on the CPU board lit. In addition, our "test lamp" LED started to flicker. Hmm. Getting some kind of signal. Looking kinda random, but clearly getting something from the pinball circuits. Not however the resounding success we were looking for.

After staring at things for a bit, we started checking some values with our handy multimeter. We were clearly getting a +5V read at the D7 data line input, which flickered as the SWLO bank was disabled and enabled. No matter of pushing any of the buttons made any difference to the value getting to our board. When measured at the input connector from the switch itself (on the upper edge of the CPU board) we clearly saw that the switch value is +5V in open position and gets pulled to ~0V when pressed.

Ok, not successful. We decided to leave the CPU board in the machine, and pulled our cables and protoboard back to the worktable. We had little faith that the way we hooked up our little LED test light was correct. In fact, we were pretty sure we needed to find a better way to test things, particularly as we move forward with more complicated tasks.

That put and end to our workday, sending us off to ponder code and connections. A bit of rest would lead us to a few keen insights. I'll save that for next time.

After a bit of tinkering and struggling with the Propeller tools (yeaaargh!) Kevin was able to work up some code for enabling the dedicated switch bank and reading the state of the switches. If we can accurately detect the state of these switches, we have gone a long way toward showing that our interface concept will work.

This is a pretty nerdy post. Some things are just nerdy. Enjoy it for what it is.

Our prototype circuit is pretty simple. Here is a simplified schematic leaving out power connections. Pardon my messy schematic here, I'm learning how to use the GEDA projects gschem tool. Clearly my new sym definition for the propeller chip has a few glitches.

The propeller chip is set to drive the 1 of 8 demultiplexer, and 8 I/O pins are wired up through 1.5K resistors in serial to the D0-D7 lines on our adapter cable. The 8 lines of output from the 74LS138 are wired directly to the adapter cable patched in where we removed the same chip from the CPU board.

The serial resistors are used to drop the voltage coming back from the CPU board into an acceptable range for the propeller chip. The CPU board circuitry is designed to drive 5V signals whereas the propeller chip is rated at a 3.3V max for logic high. I really should be using 10K resistors here, but I had a string of 1.5K's handy and the resulting voltage is a bit under 4Vs. According to the folks at Parallax, this will be ok for short tests as the chip has internal regulation to manage overdriven input, but I'm at risk of overheating or destroying the safety latch. In other words, use 10K resistors, I'll be switching mine out shortly.

While I was soldering cables, desoldering and pulling chips, and wiring up the protoboard with the wrong resistors, Kevin has been working up some code for the propeller chip to do three key tasks:

Keep the CPU watchdog system from pulling the board into reset

Enable the dedicated switch inputs on the data bus

read the state of the switches

The CPU board is designed with some circuitry to protect itself in the event that certain systems fail. Mainly this pulls a set of key chips into reset, preventing random and potentially damaging signals from driving the system. This is accomplished with a watchdog timer chip at U218 (lower right corner of page 2 of the schematic). This is a DS1232 chip which simply has a configurable threshold time before it pulls the value of two reset lines, one for the IO system and one for the CPU board. To keep the reset from triggering the chip must be pinged within the threshold time by stimulating a strobe input pin. Yes the datasheet actually says stimulated.

If you are wondering what I'm talking about with "pull chips into reset", it is really not complicated. All that is happening is that some of the chips have enable pins that are generally always held in the enabled state unless the system goes into reset, in which case the chips enable pins are set to disable. You can trace the RESET line from U218 and see that it hits quite a few other components.

Looking at U218, the strobe input pin #7, we see it is driven using the BSEL signal. You should recognize this from our earlier exercises as the Bank Select signal (one of the 1 of 8 from the address decoder). The watchdog is set to reset after 250ms unless triggered. Even though we have no use for the BSEL signal anymore, I think it is a very good idea to keep the reset circuit in place, so part of our code simply needs to toggle the BSEL signal as part of the main execution loop. If it turns out to be a complete waste of cpu cycles toggling this signal, we can always bridge another signal to the watchdog. This works for now.

Enabling the dedicated switch inputs is achieved by enabling the 74LS138 and setting the three input pins to the proper value to enable the SWLO pin. Once enabled, checking the values of the D5 D6 and D7 data lines will let us know if any of the three hooked up dedicated switches are being pressed. These switch inputs are hooked up to the reset and volume switches located inside the coin door. The lines are low enable, meaning that they will read at +5V until the button is pressed, then read at 0. The other 5 dedicated switches are currently not used.

That's it for the code for now, time to put everything back in the machine and see what happens.

We left off with our CPU board stripped of no-longer-needed chips. It dawns on me that I didn't play "one last game" before dismantling things. Too late for that I guess. Oh well, on to the task at hand. We need to make a few decisions, add a few connectors and rig up some cables and see if our "theory of operation" holds any water.

Quick review. We want to wire up some kind of new controller to this CPU board, leverage the Data Bus and the addressing lines and try to make something happen. First decision is where to patch into the data bus. Not too many choices here, it has to be the CPU socket U209. This already has a socket, so we can use a pin rail to connect and we know that everything of interest is designed to run data from this point. We just need to run 8 lines for D0-D7 from our new controller to pins 13 - 21 on the CPU socket.

Next up, we need to wire up our new controller to perform the function of the address decoder. We could have left the 74LS138 in place and run 3 lines from our controller to the board mimicking the selection values for the different sections. Well, clearly we didn't do this, or I wouldn't have pulled the chips off the circuit board. Instead I decided to move the 1of8 to my prototype breadboard and run the 8 lines of output from that chip to the output pins of the now missing socket. The main reason for this is that I can solder a connector in place where the chip used to be and use the connector to receive a cable from the protoboard which seemed cleaner to me than soldering to the inputs of an in place chip.

This leaves only a few interesting connections than can be made on the output side of the now removed PAL chip. We will drop a connector rail down on the CPU board to accept a cable for these lines as well.

Ok, step back and consider what we have. The CPU board is now setup up to accept cables for the data lines D0-D7, the 8 address lines decoded by the 1 of 8 decoder: SWLO, DPSW, BSEL, SWSTB, SW, PLIN, POUT and two important lines from the PAL chip position: IO PORT and IO STB.

To control things, we need to put together a cable that allows us to interface on these 17 signals. For lack of a better solution at the moment, I soldered up a ribbon cable that I had "on hand" with two separate connectors on one end (along with two free wires) to run to the three key locations on the CPU board, and one long rail connector at the other end, carefully labeled, that can be used from a prototyping breadboard.

This cable is not very good, but it works. We will have to replace it with something a bit more robust fairly quickly, but we should be able to hit a proof of concept using it. With the the cpu board socketed and cable done, we need to pick a way of controlling things. My initial thought was to prototype and do proof of concept work using a PC, running the system via a parallel port. This might work, but gosh it sounds so pedestrian. Also, there is no way possible that running from a parallel port will be the final solution. I'll want to have a either an SBC or microcontroller that I can package up into the back box.

A bit of a look about and I came across another fine product from Parallax, the propeller chip. It is an inexpensive powerhouse of a microcontroller with plenty of easy to use I/O pins. It even has 8 independently running cores which will come in handy. I'm not sure if this little chip can end up as the final controller for the machine, but it is more than capable of working into our proof of concept. I got myself a PropStick USB and dropped it onto a protoboard for a little testing and I'm pretty happy with it.

That's the tale of Cables, Connectors and Controllers for now. Next up we hook all these things together and see what we can do.

In our schematic exercise, we took a good look at how the CPU board routed the data bus using two chips for address decoding. Given this good look at how the hardware is wired together, we should be able to throw a bunch of stuff out and wire in a new controller. Time to dive in and start taking things apart.

First things first. A disclaimer...

Ok, now that we have that behind us....to the machine!

The unplugged machine! Unplug it. You read the disclaimer right? high voltage, zap, danger, bad. Once unplugged (you unplugged it right?), remove the backglass, and swing open the upper panel to reveal the CPU and I/O driver boards. We recommend removing the upper panel to provide better access to the machine. All you need to do is disconnect two sets of wires, then lift the panel up, the hinges simply slide apart. Much thanks to whoever thought of that. In fact, we wish we thought of it earlier.

Now you can disconnect all of the wires to the CPU board. Be gentle with it, the board is actually pretty easy to break. Once all of the wires are pulled, loosen the screws holding it in place and lift the board out. Once removed, take it over to your nice cleared off workspace (you did clear off workspace right?) and prepare for pulling off chips.

There is a bunch of stuff on this board that we simply don't need. Most of the chips are fortunately slotted into chip sockets and can be pulled with a chip puller or very very carefully pried up. If you have any delusions of doing something with the chips we are pulling out, you will want to keep the pins straight. Someone out there may want those Goldeneye ROMs. Oh who am I kidding, I keep every removed chip. There has to be something I can do with it. Lets start by pulling all of these socketed chips

Rather unfortunately, I also want to take out a few chips that are not socketed. Delsoldering chips is really no fun and I discovered that I'm not particularly good at it. Well, I'm much better at it now than when I started. Be smarter than I am and buy a desoldering bulb. I did my work with only desoldering braid. Also, ventilate! For some reason in the time between projects I seem to forget how nasty soldering is and I fail to run a fan on the first day. The headache is simply not worth it.

The two chips of interest are the two that make up the address decoder. If you don't have an extra 74LS138 in your spare parts kit, you will want to be very careful when pulling the one off the board so you can reuse it for prototyping. Also, try to be careful with the contacts on the board itself. I wasn't and ended up ruining the trace for one of the pins. These things can be worked around, but it is a whole heck of a lot easier if you don't have to.

Fantastic! One stripped down and ready to hack CPU board. Next up, adding some connector rails, making a cable or two and preparing our prototyping board.

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.

To understand what we are trying to accomplish, everyone will need to learn a bit about how the electronics in the pinball machine work. So I now present to you my low budget tour around the electronics.

It's a Computer

There you have it, nothing complicated. The pinball is just a main CPU with a bunch of peripherals all wired together on a few different circuit boards. The machine operates by running a program out of its rom chips and exchanging data with various systems: Lamps, Switches, Sound, Plasma Display and so on. A basic understanding of how a computer works is helpful here, but not 100% necessary. After all you are all smart people, right? (the correct thing to do here is to say, "Darn right!")

Schematic time. Looking at the CPU and sound board schematic, on page one, find U209. This is the main 68B09E processor and is the core brain of this machine. Naturally, we will want to replace it (remember...I don't like burning roms and writing 68B09E asm code.) From this chip you will see a bunch of pinouts labelled D0-D7 and A0-A15. These are the data and address pinouts from the CPU and it is through these that it communicates with the various other subsystems. If you spend a little time tracing the dark lines from the address and data pins you will find that they connect to several other places on the CPU board. Our primary job is to work out how this data bus and address bus are used so that we can drive it, replace it, or ignore it all together.

We do have a clue to deciphering some important parts of the address decoder from reading the CPU and Sound Board Theory of Operation. It tells us that the address decoding is managed by a 1of8 demultiplexer and a PAL chip slotted in locations U213 and U214. These show up on the schematic just under U209, the main CPU. Take a bit of time and familiarize yourself with the names given to the pinouts on these chips. You will see that these map to many of the systems that we are interested in. Well, perhaps it is not immediately obvious, but trust me, you will see it.

I find that tracking things back from the end of the line to the CPU makes the job a bit easier. Take a look in the upper left hand corner of page 1 of the CPU schematic. This section details the dedicated switch system. The data bus tracks to U206, a 74HC245 chip. This is a bus tranceiver, depending on whether it is enabled or not, it allows the signals at its B0-B7 pins to replicate at the A0-A7 pins. For the CPU to read the dedicated switches, it must enable this bus tranceiver, then read the values of D0-D7 to determine the state of the switches. The enable pin is the barred G pin 19 which is labelled SWLO. We can reasonably call this SWitches, LOw voltage. Trace the SWLO line back and you will find that it originates at U214 on pin 15, the Y0 signal. Similarly by spending some quality time with the schematics, we can determine that the other signals eminating from U214 and U213 are used to enable and disable the various components on the data bus.

Here is a run down of the signal trace names and what I generally refer to them as

U213

the main system ROM chip select |

the main system RAM chip select |

enables the port that connects to the I/O Driver board, allowing certain address bits to flow to and from the high power board. |

The sound system "strobe" |

The I/O driver "strobe" |

U214

the dedicated switches (SWitches, LOw voltage) |

the dip switches |

memory bank select |

switch matrix "strobe" |

switch matrix row enable |

input from the plasma display controller |

output to the plasma display |

status signals from the plasma display |

Next time a little conjecturing about what the CPU is doing and a plan of attack for driving these signals with our own controller.

Before we set out hacking, let us first check the lay of the land, beginning with a ten cent description of what a pinball machine is.

A Pinball Machine consists of a set of circuit boards comprising the computer and specific electronics required to drive the lights, switches, solenoids, displays and sounds. These boards are connected by many many feet of wiring through the cabinet to the playfield where all the action happens. The switches, sensors, lights and fun gadgets (like our Satellite dish) are arranged on the playfield along with inanimate objects like posts, rails and ramps to create the unique flow of the game. ROM chips on the CPU board are programmed with the rules that govern the game, detailing the cause and effect of various shots (commonly referred to as Game Rules and Shot Charts). Additional chips carry the sounds and graphics unique to the game.

We will begin by focusing on the electronics. Read on for a breakdown....

For this project it helps to consider the machine as a set of discrete systems, each to be tackled individually:

Dedicated Switches , or switches that are wired direct to the CPU board as they warrant special treatment. (On our machine these are the service switches found just inside the coin door.)

The Switch Matrix , comprising all of the other switches on the machine. Anywhere a ball contact is required to affect game play, there is a switch or sensor of some type that will trigger an action. I'll describe why it is a "matrix" a bit later.

The Lamp Matrix , drives all of the lights that are required to turn on and off reflecting actions and states in the game. This matrix drives all of the lights in the game except the flash lamps and general illumination.

The general term of Coils is given to all of the items that require quick and generally higher voltage bursts of electricity (the slingshots, jet bumpers, kick ups, any playfield gadgets and high current flash lamps) . In practice, Coils fall into three categories: High Current (50V), Low Current (20V) and Flash Lamps (20V). Basically anything that needs fast switching of greater than 18V. When we get to breaking down the wiring on the I/O driver board, you will see why this collection makes sense.

Flipper Control requires some interesting electronics. Historically, flipper control electronics have caused some of the most detested problems with pins.

The Dot Matrx Display (or segmented LED display on older CPU driven games) is probably going to be the trickiest bit for us to take control over.

Sound generation consumes a large part of one of the major circuit boards. Currently, I have no plans to attempt to use the on-board sound generator. Instead I plan on dropping in a complete new sound system.

That's basically it. We will come across some other items of note as we progress, but if we can take over the Dedicated Switches, Switch Matrix, Lamp Matrix, Coils, Display and Sound, we will be in complete control of the pinball game.

I'm going to start collecting up files and links that I reference in posts and putting them on the Resources page. I've added the Goldeneye Manual and copies of the Stern pinball schematics for the CPU and the I/O boards.

For those who aren't aware, there were once over 100 pinball game manufacturers and they were slowly consolidated to just a few, with Williams and Sega being the big two survivors. Gary Stern launched Data East Pinball in 1986, which was later snapped up by Sega in 1994. Stern bought the company back in 1999 and renamed it Stern Pinball. He is now the lone surviving major pinball machine manufacturer (although there are some recent upstarts who may yet prove themselves.)

The Point? Pinball electronics and hardware didn't much change over the years. The boards running the early Data East games lived on through the Sega years and into the Stern years largely unchanged (with some notable exceptions.) This means that instead of straining to read the schematics posted in the back of our Goldeneye Manual (or worse, the scanned copy) we can make use of the very nice quality pdf copies posted on the Stern support site.

So thanks go to Gary Stern for nice schematics and for keeping pinball alive.

In general, if you are setting out to do something, there is a very good chance that someone has already taken a trip down that same road before you. I recommend looking for their tracks, it often helps you avoid a landmine.

A little googling and I've come across a few pioneers. One of particular interest is a Masters Thesis by a fellow name John Bork that hits fairly square on what we want to accomplish.

The best part about finding this work is that my heretofore unfounded hopes for a successful outcome have been (a wee bit) validated. John's work had a different goal in mind, but it clearly demonstrates that with a little persistence, we will be able to build a new (dare I say better?) controller and leverage the existing I/O driver board of the machine. He also validates that we will be able to successfully drive the Lamp and Switch Matrices.

Don't worry, there is still bountiful opportunity for spectacular failures along the way. This may be a fine time for everyone to pop in a DVD of Meet the Robinsons.

Time to sketch out a plan of action because, darn it, this project clearly needs a little action....

For this conversion, we will be focusing on a full re-theming of the machine. The basic playfield layout will remain the same with only some minor changes to a couple of the playfield toys. Almost every other aspect will be changed in some way. Read on for the full gritty details of The Plan.

I happen to enjoy the flow of this machine (which is why I picked it), but I want to remove all traces of 007. To that end we will be

providing complete new programming, including Dot Matrix animations and game rules (Yikes!)

creating some new electronics and mechanics to replace the Satellite playfield toy with something more suitable to the new theme.

creating new playfield plastics and shells for the playfield Toy designed to fit the new theme

providing all new game sounds including background music and sound effects

A rather important decision I've made is that I have absolutely no intention of reprogramming this thing based on an ancient 16bit processor and related technology. I will not be hacking 68B09E asm code. I will not be reverse engineering sound and graphics formats and packing the entire works onto two tiny eproms. If I wanted to do that I'd hop on the pinmame in a box bandwagon.

Instead we will be creatively leveraging the existing electronics while replacing the brain. We will start by using some off the shelf electronics to hijack the existing I/O electronics and eventually end up creating our own custom control boards. Hey, nobody said this was going to be some quick little weekend hack did they?

I have no intention of doing all of this single handed. I know plenty of talented folks who own PCs and MACs and are rather savvy with Photoshop and creating wav and mp3 files. I fully intend to build the core of the system so that I can leverage this. Along the way, some custom tools will be created. My GPL loving, open source addled brain would like me to release all of the tools and software under GPL. I'll say that is my plan, but I'm going to reserve the right to change my mind.

Finally, it is imperative that everything done to create the final machine be reproducible. This means that I'll be creating molds and creating parts instead of using one-offs. I will be using stock parts where possible, and using standard design formats to create new ones when needed. If I'm going to build one of these, I damn well want to be able to build a second copy. Of course, one of the parts for this model will be an original Goldeneye.

This is not a project for the impatient. Slowsky's may pull up a chair grab a tasty beverage and enjoy.

Oh, and by the way... I do know the theme, I'm just saving it for a big reveal when its actually needed. Yep, I can be that way.

Ah, vacation time. What better time to get started on our little pinball project.

I've been walking by the soon-to-be-converted pinball machine for several months now thinking, "Hey I should get started on that." No excuses other than just being a lazy git, so I'm kicking myself in the rear and getting the ball rolling.

First order of business: The Machine

Many years ago now, we dropped in on the Super Auctions stop in San Jose and carted home a lovely Goldeneye Pinball. I was specifically looking for a pinball machine to take apart and tinker with and this machine fits the bill perfectly. It has a great flow to the playfield, some fantastic playfield toys and what just might be the best ball save ever. To top it all off it has a theme that is, well, forgettable. Unless you are a huge 007 fan or have a mad crush on Pierce Brosnan, I don't think you'll be losing sleep over me hacking up this pin.

Bizarre to me is the current going rate for this pin on ebay. Three auctions running at time of this post with $2000+ price tags. I guess there is no explaining some things. Trust me, I didn't spend anywhere near that on the box we have.

So grab the manual (8MB PDF), complete with Data East schematics and study up...we'll be digging in soon.

Specifically, it is about tinkering with pinball machines. Lifting up the playfield, cracking open the backbox and poking fingers at the wiry innards. Learning what makes the machine tick, and how to make it tick different.

Follow along as I take a perfectly functioning, well designed Pinball machine from the mid 1990's and attempt to transform it. That's right: solid state electronics, computers, dot matrix displays. I appreciate those who are wizards with electromagnetic machines, but that just doesn't blow my ears back.

I'm a software guy with just enough hardware background to think I know what I'm doing. I have lots of power tools and I love using them. Along the way I'll be pulling in hardware experts, artists, fabricators, painters, people with opinions, you name it. Whatever it takes to get the result I want. I'm sure I'll be doing things that will make an electrical engineer cringe. But hey that's half the fun.