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).
Lets just say that the approach used previously was, euphemism needed, lets see...ah yes, overly optimistic.
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.