Remembering The Past

Needed the soundboard from the "old system", so I opened up the pinball machine for the first time in a while... And I was actually surprised to see what a mess it was/is! It's a wonder it even worked at all, haha. :D

Anyhow -
It was quite satisfactory to see that where the old setup used tons of different boards, two MCU's and a cabling from hell, the new setup is ultra neat in comparison. And despite having "only" one MCU, the performance is 4x in most cases, but 200x when it comes to I/O. Hardware stability is improved a lot as well! I'm also pleased with the new code library compared to the old, which will make game programming a breeze.

The maintenance mode is always enabled, which gives me detailed input on sounds running, scenes started, sound and input / output etc - so I can see right away if there's a problem. Love it!

1) The old....monstrosity. This is actually HW3.0, if we're counting revisions.
HW4 (current) is seen in the post below, which despite being in development "mode", still looks tons better. 

Mostly Behind The Scenes

What is up, Internet!?

Most of the work at the moment isn't very visually interesting, but I'd thought I'd share a little snapshot of the current (messy) state of the debug screen. What I'm verifying here is that the various conversion and positioning functions are functioning properly. Which they are.

On top of this, I've fleshed out the switch callback handling, which includes buffered and queued switch hits. This allows the best of both worlds; the interrupt routine can register switch hits as fast as it can detect ( 1000+ > Hz per switch) while the game loop is chugging along at 40Hz. So no switch hits are missed, and the response for each hit is a maximum of 25ms late. Certain switches such as flippers, slingshots and bumpers are allowed to trigger the corresponding solenoid immediately and allow the sound and gameplay events to happen "later". It might be possible to queue sounds right away since the serial out is asynchronous, but I have yet to test this. What ever decision is made has to manage up to 8 simultaneous switch presses so each response must be pretty tight. I don't want the machine to run fine during single ball and crash during multiball etc. :)

I've enabled printing a copy of the internal switch matrix and the current animations, lights and so on in the console maintenance mode, which is guaranteed to be correct at all times unlike an offline version in Excel, for instance. On top of that I have started work on the state machine for modes and various scenes, so things are progressing nicely, albeit slowly!

1) Development board with debug options enabled on the DMD. I've also created a "overflow" function for scores,
so that any score larger than 999 999 999 will be visually divided by 1000 and rendered correctly. I believe this is how newer tables by Stern work, unless I'm mistaken.