propecia one year results


29

Jan

New year New host server

Posted by Scott in Rambles

Hi folks.

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.



13

Dec

Reading Switches

Posted by Scott in Rambles

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.



11

Dec

Retro Pinball LLC

Posted by Scott in Rambles

I’ll have an update on my project later this weekend, but I thought I’d share a quick link.

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!



23

Nov

Week in review Nov 22 edition

Posted by Scott in Rambles

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.

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