Square One?

Feels a bit like I'm back to square one doing these kind of things again... ;)
Only this time I actually know what I'm doing. Which sure is a plus!

I'm especially proud over the new code and setup.
The lights update at a very high refresh rate and gives a solid 3.01V when fed with 5V (duty cycled 1:8) and 5.04 at 9V. Presumably I'll get roughly steady 6V out of 12V too, which is perfect. Light rows and columns are all part of the same PIC32 port, thus the cost of updating all lights is the same as updating a single pin.

1) I/O expander MCP23S17 and micro SD in action. Super awesome toggle switch as input. 

2) Darlington transistor array ULN2308a driving TIP107 along with TIP102's.
Very nice combo, although not entirely logic level they are bipolar transistors
and react similarly to input. No "ramping up" here - and - no flickering at all! :)

I've also decided to give GI and flashers their own dedicated lines controlled by TIP102's and a MCP23S17. Flashers due to the voltage requirement to duty cycle them and GI for - worst comes to worst, a little flicker on a blinking light is no biggie, but flickering lights that shouldn't be, is.

I thought my old code was pretty optimized but take the old render routine, for instance. It performed a single row update in 100uS, and now I'm down to 50uS including updating all lights, all switches, all cabinet inputs and solenoids.... AND twice the amount of colors.
Overall, everything is high frequency SPI, direct port writes, updating other parts while one part is busy and maximizing use of hardware features and interrupts.

*pats himself on the back*

All Things Start Small

For the past days, I've been able to test most of my planned circuit board on a breadboard, along with some very basic rewrites of the libraries.

I'm happy to say that I've encountered no problems with the design or code so far, which is in no small part thanks to Majenko on the Chipkit forums for supplying a very readable overview of the I/O pins of the Max32. Of course, this information was available in the datasheet, but he simply presented it in a way the Digilent people really should have done from the start. Super awesome and did indeed explain why I had some trouble in the past! 

1) Image courtesy of Majenko, hopefully it's alright to post it here. Red/orange buttons with white labels are non-exclusive pins and will conflict with the others if used. Green are alternate names and purple ones are unique. Interrupts, SPI and I2C are shown as well.  

As for code, I've designed both DMD and SD reading to run via interrupts, meaning that while the DMD is receiving data or the SD card transmitting the MCU is free to process other stuff.

For me that means I can handle I/O and solenoids at the same time as a row is being rendered (most likely with a ratio/factor since there's no point in updating switches at 14KHz). It also means I can process SD card data simultaneously as I'm building the render buffer instead of waiting for data to be ready, locking the game loop until done, and then building the frame...

I'm thinking that since the hardware will most likely be rolling a lot of thumbs now, I've upped the artwork to use 16 colors instead of 8. I also did a few tweaks to the Python scripts that generates the artwork and found a lot that could be optimized, leading to some pretty nice results:

2) Top: Old generator.  Bottom: New generator.

The old version didn't really under perform here, but there are way more troublesome images in the library. Like this one:

3) Top: Old generator. Bottom: New generator.

Some videos and images will probably need to be handled separately (i.e with non-default options) but ultimately this means that material that was about to get removed might now be inserted instead.  It all depends on how it looks in the machine of course as previews are good and all, but if it looks like crap in the machine it's got to go. :) 

I haven't hooked up the screen to my breadboard, so I cannot test it for real just yet - but in theory it should run at very acceptable refresh rates since the SD card load only increased 25% (3bit -> 4bit and has been heavily optimized now) along with the fact that the rendering doesn't block the MCU anymore.  

Awesomesauce!

Status Machinima

Due to popular demand, here's a short update. ;)

I've more or less abandoned Fritzing.
For designing small circuits the program was fine, but the software became quite slow and unresponsive once the number of components increased. The program is nice, but needs maturing and it's officially not out of beta yet, so I'll hold no grudge. :)

I have since reached out to the good folks at Diptrace, who nicely enough supplied me with a non-profit license that allows me to build the board(s) I inteded. Very nice! I will most likely build a main board and a power board (I/O board, if you wish). That allows me to swap or update and avoid creating a totally new board in case of disasters...

On top of that, I've learned that the I/O pins on Chipkit Max32 are heavily shared, so I've needed to come up with some voodoo to make it all work out with the aid of I/O extenders. I've ordered a bunch of IC's to properly test this before designing the circuit based on the new circuits, including buffers, EEPROM, darlington transistor arrays and resistor networks. All fun and new components!

So, that's that for now...
Until next time - game on! 

Big plans for this year!

Happy New Year!

This year will be about finishing the machine.
It's so close I can basically taste the highscores already!

But...  (unexpected, huh?)  ...I will also be remaking the motherboard.

I feel I've finalized all functions enough to create a proper PCB of the features needed. I will also add a few backup functions such as additional ports and other features that aren't necessarily used for this game. You never know...

I've tried several (trial versions of) different PCB softwares, including Eagle, PCB Express, DipTrace and one other I can't remember the name of - but the one that got my interest is Fritzing. Very easy to use, and perfectly fine for my purposes. It even has a breadboard and code layout in addition to the standard schematic and PCB-layout features. The production prices aren't the cheapest, but neither are any of the other software's license costs...

Read more about Fritzing here.

While creating the new motherboard, I will also transplant the location of the board into the head instead of the body. This is common practice in consumer pinball machines, and I can see why. It's basically impossible to service the machine without moving the glass, board and what not. It's also more or less impossible to troubleshoot hardware errors. On top of that, I'll rewrite most of the code as I now have a better understanding of the programmatic requirements of a pinball machine (which wasn't there to begin with - never seen the innards of one before starting this project! ).

I've played quite a few games now, and man - it's a difficult game! No risk of completing the game without proper practice, that's for sure...

1) State of the machine as of 2017-01-01. There are a few plastic signs missing here though, that have been broken in half during the years. But overall - it's looking very good! :)

Big D vs Big S

Hi ya'll. 

Been moving my programming environment from Windows XP and an old laptop to OS X and a modern computer, and that sh#t turned out to be a lot more difficult than I anticipated. Moving from MPIDE 0023 to Arduino 1.6.13 sure didn't help either and even basic serial communication and switches stopped working...

Anyhow - after a hefty troubleshooting session that lasted a week or two; I'm back in business.

And despite some issues, I can now work a lot more easily on the programming for both boards and the newer computer allows for more optimized compiling and thus faster code. This means the display and servos run more smoothly.

So during the coming months I'll get started in the code refactoring and game mode creation. But for now; here's a short snippet of Mr B in action. (very much beta, obviously). :) 

Oh, almost forgot -
I've got myself a Big Sister that stands nicely next to the "evil" little sister and the vent, just above the "SISTERS FOREVER" mode light. She will probably not be animated or lit, but a LED-eye would probably be possible in the future... 

1) Big Sister. Had her on the cover, would be rather weird not to have her on the playfield as well. I have temporarily fixed her to the VUK-habitrail without the backpack, but I'm thinking about making the backpack "wrap around" the habitrail, making the ball go through it. That would probably mean I have to break the toy though, which I refrain somewhat from... 

Are we there yet?

Not quite, but at least the machine is done enough to be moved into the living room. :)

1) Close, but no cigar. But at least the scotch is cooling, awaiting the cigar!

Double polarity LED's... who knew?

Oh boi. I'll just say it.
Shame on me - I missed a couple of diodes.

The bumpers and flashers were still "unprotected" and on top of that, the LED's I had installed were double polarity meaning they worked in both directions....  Who could have known, right?

The good news are that lights are now working somewhat properly (we'll get to that) and I've updated the main board with the correct lights and what not. This means I'm kinda back where I was before recreating the light board. And that's a good thing! I've also fixed sound and music, which had a few bugs that has stayed uncorrected since moving to the new system and board. Tried a couple of quick games too. 8-)


The bad news is that there is a slight flickering when a couple of lights are active at the same time. This flickering occurs on the light board itself as well, so it may be due to lack of power in the board or shift registers. I'm currently using a row/col based approach, which lights up to 12 lights per channel. I will try converting to col/row so that each row only ever power a single light at once. Hopefully that solves things.
 
I've also noticed that the servo handling the target bank was dead.
So I replaced it, only to find out that that servo too died after a few on/off's. The servos are beefy ones and are moving up to 5kgs, which is more than enough for the purpose, but somehow they die anyway. This last one has frozen in place, unable to turn, but it sounds like it's working. I'll have to investigate this further.

On top of that, the captive ball lane captures balls despite having no ball lock. The irony...

Code revision on the game will have to wait until the servo is corrected, as well as the captive lane.

But yeah, progress! \m/