Tour of Duty

I'm thinking about the lights outputs -

They will take quite a lot of amperage if they're all lit at the same time, so I'm thinking about having a 25% duty cycle or similar. That way only 24 lights can be active at the same time, consuming around 6A - unless my calculations are way off.

I should mention, this is using bulbs. Using LED's it will consume far less power.
The biggest problem is that I only got 8A fuses but hopefully there's larger fuses available.
Either that or I'll need to put the +5 VDC through multiple fuses, which requires a little work.

Codename Revised

Spinning further with the idea of writing to the sdbuffer-array directly instead of first cache'ing the data, I decided to completely redesign the loading.

I did a couple of major changes -

1) The SD card is now raw sectors. No filesystem, just packed bytes one after the other.
2) Ditched the Arduino based SPI library and went with Digilent's DSPI library.
3) Streamlined the DMD rendering to use Chipkit specific latch-registers instead.

Using raw sectors I have immediate access to whatever sector I need. The sectors of the SD card is conveniently stored in 512B-chunks and three chunks make up one frame of animation. The FAT filesystem requires me to find filenames first and is really made for non-static data. By letting a script generating the SD card file for me I know exactly where each file is placed on the card, allowing me to access it directly. There's also no cache, so if I ask for a byte - I get it. Besides direct access when needed, this allows me to pause, rewind and speed up animations on demand, for example.

By leaving the rather limited SPI library, I've managed to increase the speed of both SD card reading and the time it takes to update the DMD. They're now also on two independent SPI-channels allowing them to be run at the "same" time, that's is - being active at the same time. The DSPI-library also allows me to do interrupt-transfers. That means I could download data from the card in the background while the program continues execution, kind of like multithreading on a PC. I have not yet enabled this feature, but I'm looking in to it.

The DMD rendering was pretty tight previously, but by using the latch-registers (LATxINV, LATxSET, LATxCLR) together with a higher speed I got an extremely nice performance boost. I did a little restructuring as well so that I could perform multiple operations at the same time, for instance - toggling the latch and row-clock directly after each other instead of having to wait for the first one to finish entirely. As each of these calls are done 28 672 times, each nanosecond quickly builds up! I've also done a little manual loop unrolling to further maximize performance. I've spent quite a while reading the spec-sheet for the display to make sure that I don't delay more than absolutely necessary. I've also added an exponential delay between each row update so that the overall image looks much better. By having a fixed delay, the low end was represented in a non-visually pleasing manner, since the low end was very sharp. It simply looks better to have smaller differences in brightness in the low end and bigger differences in the brighter areas.

With these major changes I've pushed the performance of the SD card reading a full frame from around 14 ms/frame to 9 ms/frame 7.5 ms, and the DMD refresh from 8 ms/frame to 4 ms/frame 7 ms (I've inserted a larger delay as well to increase the contrast) . These are done interleaved so I get a rock solid ~70Hz and streaming video at 30 fps.

The nice thing about this is that I got 5 milliseconds of reserved space that can be used for any processor heavy calculating, such as transitions, layer handling, transparency etc - without it affecting the frame rate at all. As long as the total time is 5 ms or less, that is.

I could push the number of frames further, but the game logic and SD card reading must take exactly the same amount of time to execute, otherwise the display will change in brightness as soon as the SD card reading takes place. This is highly unwanted, but I've seen this behavior in "proper" pinball machines and it's nothing that I want in my machine.

If the SD card reading gets further pushed down the overall refresh rate will only increase, until a breaking point is reached when the game logic takes longer to perform.

I'm quite satisfied with the progress so far!

SD card library ... revisited!

For some reason the SD card library seem to ignore all my requests for unbuffered reads (or maybe the SD card I'm using doesn't normally allow this?) so yesterday I took the liberty of further customizing it to read into my own buffer directly, instead of first reading to an internal buffer and then copying the information byte-by-byte into the destination buffer.

I believe this bypassed a lot of the delay in the SD card reading, but I have not yet confirmed this with any actual numbers - but at the very least it certainly runs faster now. By the looks of the new animation speed, I'm figuring it's close to 40-45 FPS streaming video now instead of the previous 30-35 FPS.

I hope this can be further improved even though it's more than acceptable at the moment!

Those Dirty Secrets...

...exposed for the world to see - ain't that nice!

I've finished soldering the switch board and started making the light board.
I probably shouldn't be showing you this...

1) The flip side of the switchboard. It's a mess, but it works reliably!
After soldering the IC's I said "f€#k it" and just went bonanza with the solder iron.
I reused most of the soldering points for the IC's to attach cables directly,
probably should rename the blog to 'Lazy Man's Pinball'...

... but amazingly I only had two cables that needed to be switched - the rest of it worked out of the "box". The extremely crappy soldering on this one does not make anyone proud thou...

But as I said before -
These are prototype production units. If they break or needs replacement they will be better made (as in, custom PCB's and possibly even pro-soldered in a shop).

The motherboard is a nicer story thou. I've fixed all cards onto a piece of plywood with custom connectors for power as well as proper display, switch and light connectors.

2) The revised motherboard. Larger, better and much much easier to handle and connect stuff to.
Going clockwise, starting top right - (unfinished) lights/outputs, switches, SD reader, display and servos (but has room for more features if needed), Chipkit Max32 (single MCU design, remember), soundboards x 3 and finally, in the center, there's a powerboard that distributes power to all boards except for the chipkit itself (which runs at a higher voltage).

The plug & play design has already proven to be useful while debugging and even adding features as it allows to be picked up and placed in a more convenient position. All cables that needs to be removed in any way when servicing has got a connector so it's impossible to put them back wrong. A nice side effect of going single MCU is that I can now (finally) update the code of the board via USB without having to manually reset the boards first. This was due to a limitation of the Arduino/Chipkit boards when something was connected to the first serial port, which had to be used for serial communication between the boards. 

I'm still thinking about if it's a good idea to have unique MOSFET's for each output, but we'll see!

With the new motherboard almost complete, I can now begin to focus on the new programming. I've got switches, SD-reading and DMD in place (although not in their final form) and I've already managed to improve video streaming and rendering speed. With a little luck I'll find the time to start on the proper   code anytime soon - probably the maintenance menu since that makes most sense at the moment.

Going single MCU was a good choice!

If it breaks, it breaks!

As I've previously stated, I am remaking the electronics of the machine.
Going from two to one MCU eliminates the need for synchronization between the two boards and vastly simplifies the programming and updating of the code.

Unfortunately this also means I've lost almost half of my input/output pins.
To bypass this I've started using 74HC595 and CD4021B shift-registers which only require three pins each for any number (within reason) of input/output pins. The new boards will therefore handle 64 inputs and 96 outputs, with additional pins just being another daisy chained card after the first.

But the work behind these cards is immense!

Since I'm using regular experiment solderboards I need to solder wires or components from each pin to the next, causing the the switch-board alone to have around 500 solderpoints!

1) The top side of the unfinished switch board. The board connects to the playfield
using two 34 pin flat cables, leaving two pins reserved for future use.
As you can see on some of the cables,  I accidentally reversed the IC's so I had to resolder the wires again.
(What's up with having duplicate markings on a IC anyway, shouldn't a single marker pointing towards pin 1 suffice...?)

If I would be using an online service known as Pad2Pad or BatchPCB I could have made custom PCB's instead, but I'm currently going about it this in a "I'll do that if these boards break"-kind of way...

Hopefully I won't live to regret this!

To baldly go where no one's gone before...

Did some pretty major stuff on the machine today.
Actually, not that major - but I got things done that needed to be done before I could continue assembling it.

I installed a couple of protectors for the ball drain, which hopefully will keep this area looking neat for a while.









I also restructured the "design" of the rail so that the balls are locked physically at the end of the rail instead of relying on a stopper to prevent the ball from escaping into the shooter lane. Now all I need is something that pushes the ball up and over the edge.


I've also installed the somewhat-final posts that will make the captive ball stay captive. I might cut and reshape the metal guides in case they don't flow well enough in-game. At the moment they don't align 100% which causes the ball to bounce slightly instead of having a Newton-effect.






I installed the final post arrangement for the Little Sister-vent plastic part. I'm still not perfectly happy with the plastic part, but it will have to do for now.








I did the holes needed in the background-piece so that I could properly test the upper playfield. It allowed me to decide where to put the screws, bolts and cutaways.


Next came The Dreaded area of The Dreaded!

The problem with designing a board without having the proper pieces is painfully obvious in this picture. I made the board too long so I had to pull the plunger everytime I needed to lift the playfield, and the plunger and autolauncher fork did not align.

But with a little luck and care, this...




...became this.

The autolauncher is now assembled and functioning. The plunger will require a couple of spacers before it aligns up perfectly with the autolauncher fork, but that can easily be fixed with a shorter plunger later on. This can be seen to the right where the plunger protrudes beyond the fork causing the ball to be off-center.

With the upper playfield "in place" I could also start planning the exit from the right VUK. 

The two pieces will need to be fixed together obviously, but I still haven't perfected my brazing-skills so this will have to wait (along with the lower right wireform). There's no real rush here anyway.

And finally, this is how it's looking at the moment.

I'm Curious!

Congratulations NASA on successfully landing the Curiosity rover on Mars!
Hope we'll have some wicked new discoveries soon and that ESA will soon follow with their rover!

State of the Machine

With less than six hours on familiar grounds, work continued on the pinball machine...

1) Almost all bulb holders and assemblies are in place now. Still talking about the lower level, the upper level is still miles away.

2) It's basically a completed machine, more or less!

I've also started re-recording all animation data. But things are progressing slowly at the moment!

About being a tourist...

Spent a week in Sweden's capitol Stockholm with my two favorite girls.
Quite nice being a tourist in your own country actually - there's a lot to see!

(This post contains possibly disturbing images later on, just so you know)

1) Idyllic is the word here! 

2) In swedish these animals say "Bääääää". Don't know what they say in other languages thou.

3) A little too cold in the water (still!) for my daughter, so she took a little suntime on solid ground instead...

4) ...after which it's obligatory to take a nap. 

5) Visited a big game hall and played some pinball (of course), arcade games and my new favorite game - In the Groove 2! But it became painfully obvious I need to exercise more!  

6) We got some pretty neat buildings here as well!

7) In the 17th century, Sweden was in war with Poland and decided to build a big-ass warship. Unfortunately/fortunately the ship sunk less than a nautical mile away from the docks!
The ship was made too narrow and the ship simply got flooded when a light wind hit the side of the ship.
The shipbuilders knew this would happen but didn't have the courage to tell their king... 

8) But nevertheless - A pretty awesome ship! And more than a little reminiscent of The Black Pearl in the Pirates of the Caribbean movies, isn't it? 

9) One of the diver suits that were used in the salvaging work. The Big Daddies in Bioshock are subjects in Deep Sea-diving suits as well, similar to this.

10) One of the numerous excellent meals we had during our visit!

11) We also visited a kids adventure land to see the Body Worlds exhibit. A pretty weird place to host a collection of real dead people frozen in time, if you ask me! All objects were real humans with their skin removed, posed and exposed for our viewing pleasure. Morbid, to say the least!

12) The place got me reminded of the work of Sander Cohen in the Bioshock series, with the major difference being his  victims didn't volunteer.