XTCPinball.com had to move on to a new hosting server.

Many many thanks to the old host for giving the bits a place to live for so long.

Now that I’ve got things up and running in the new digs, there should be some new posts on the way.

There may be a little kicking of the tires for awhile and I have to check on the images and links.

None the less, this exceeding slow paced project is still going.  Perhaps I should get those DSL Turtles to be a sponsor.

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.

Just learned about another pinball manufacturer.  These guys make a reproduction of a classic from the electromag days, Gottlieb’s Kind of Diamonds.

http://www.retropinball.net/index.html

Nice work!

• 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.

Trying not to think too far ahead though.  Need to read the switches first.

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.)

More photos and a details on code and stuff coming soon.

Nice to see a linux system running at the core.

http://arstechnica.com/gaming/news/2009/10/metal-on-metal-behind-the-scenes-on-a-custom-pinball-game.ars

Nice work!

Step mother visiting == house cleaning instead of hacking.

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.

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.

• 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.

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.