Rolling with the punches!

What's this... two post within a year? Yes - it actually happened! ;)

Been using my new found determination and time to keep working on the machine, finishing up bits and pieces all over. To start off - flashers, GI and playfield lights are now soldered up and working correctly.

Well, mostly at least.

I ran out of cables so I had to order more.
And I kind of ran out of output ports for the lights, so I'll have to hook up some of them to the AUX-ports I made on the board. (phew). But it's all good! 

1) All lights, switches and solenoids are wired/soldered!

2) It looks very messy, but the cables are actually measured and the "exact" length required.
I ran out of zip-ties, but will of course tie everything neatly when the new arrives.

As for input during menus, I've gone ahead and made the switch "box" that houses the menu buttons. It will be painted and/or covered with a left-over decal, but I'll do that once I've finished the building.

When not in maintenance mode, the red button will lower volume and the green button raise it. Pressing the white button enters maintenance mode. During maintenance mode red/green goes left/right (use can also use flipper buttons), while the white button confirms and start button cancel.

3) The early draft of a control-box inside/behind the coindoor.
Basically - menu buttons and volume etc.

I've also adjusted the syringe to be a little more reliable as a pinball toy and replaced the tiny LED with a proper pinball LED-bulb.

4) I replaced the standard LED with an actual pinball LED-lamp.
No more worrying about accidentally applying too much voltage!

Software-wise I've optimized loading and SD-buffer creation to utilize hardware interrupts for SD-card loading. I've used this a while for DMD rendering, but now I've managed to get it running on the SD-card as well.

So the loops are pretty tight now, which are very nice.
For instance - When sending new data to the DMD I process switches/solenoids etc in the small gap the display needs to stay blank. This is not uncommon among older games which did processing between scanlines (more or less). Works a treat and pretty much doubles the performance.

And now I've done the same for SD-loading, where I basically start loading 512 bytes, and as soon as they're done loading I schedule the next batch and start building the buffer with the 512 bytes just loaded. The unpacking is needed to convert 2K (half-byte per pixel) to a DMD buffer (byte per pixel). The SD card is slower than building the buffer, so that's the reasoning behind not loading the full frame from disk. Previously I built the buffer after all 2K was received, but now I've shaved of a few milliseconds by doing it while "idle". Very nice! 

I've also started the rather tedious task of converting away from Arduino/Chipkit's "String" class. It's ridden with bugs, memory intense and in fact - won't even run when compiled as O3 ("optimize for speed")... There seem to be a problem with the hardware watchdog resetting during optimized compilations, but I can't get my hands around why at the moment. Considering the standard/built-in libraries won't even run properly, I'm not terribly sure my code is the culprit here...

But first, back to the 80's we go; hello, C-string.