Holy optimizations, Batman!

Spent a "little" time optimizing the code base, along with actually trying to work out the kinks of why optimized mode doesn't work. I'm not all the way there yet, but the results so far are very nice! 

Note: The flickering apparent in both videos is mostly picked up by the camera only and isn't really noticeable IRL, and the refresh rate can be pushed up further. Just keeping it a bit "low" to avoid confusing myself while debugging the rest of the code in case it causes crashes/erratic behavior etc.

For instance - 

Here's a clip of SD-card videos running as fast as possible in the old code. 

Notice the slow motion (faked by frame-skipping previously, removed here). 

And here's the same clip after optimization. 

Compared to the old version, it's a lot smoother and I'm actually running the videos at 40fps here (faster than original 30). Notice the long blank space between the videos, where the old version barely finished rendering the first one when the second one was timed to start. :) 

Some crude counter increments:

Previous one-second count: 28402

New one-second count: 91857

Quite the improvement! 

Very satisfied with the results so far!

In case you didn't notice, I used two simultaneously running SD-animations (background & fx) during the second video. Works great and allows me to spice things up. #thumbsup 

And the cable mess have been mostly corrected now, all lights tested and working. :) 

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.