More pressing and blinking

I've decided to redesign the electronics inside the machine.

Basically, it's more trouble than it's worth having two different systems trying to handle the same thing - I'm talking about the serial communication between Arduino and Chipkit. It does work, but it's only a matter of time until it becomes unbearable sending information back and forth, not to mention the very limited RAM in the Arduino.

I'll most probably only use the Chipkit since it's got plenty of I/O, lots of RAM and overall a beefier MCU. After the converging of the boards I'll have to see how many inputs/outputs there are left, but most definitely I'll have a couple to spare. There will be some pretty nasty refactoring of the code thou...

I've also decided that I need to build a switchboard and a light board -

The switchboard will give me 64 switches instead of the old one with 32 inputs.
The new one will also feature cable connectors so that there's only two flat-cables to unplug instead of 32 independent ones. Much simpler and much less to keep track of. They will still be 64 independent switches and not a matrix, so each switch gets it's own connection. In theory I could matrix these switches to create 4096 (64*64) switches...

The lightboard gives me 96 independent digital outputs for lights.
The old MUX-shield I planned to use only gave me 48 outputs and for some reason I cannot explain - it does no longer work. I'm actually not sure if I've ever tested it in with the Chipkit (+3.3VDC vs +5VDC). Since it's an output board, each of these outputs could in turn trigger a MOSFET to turn on/off a series of lights, instead of just a single light. This board will also use two 50-port flat-cables for quick and easy disconnections. The two extra ports in each cable will be additional ground lines.

The main power output of the lightboard will be controlled via a relay, so no power is sent to the outputs unless it's told to by the MCU. Purely for safety, and not sure if needed - but I had a relay to spare. The increased number of outputs allows for much more lights, and that's a good thing! 

On top of that I will have a couple of PWM light-chains for the GI. PWM, pulse-width modulation, is basically a digital analog output that allows me to dim digital outputs by flickering them fast enough. Since I'll be using LED's for the GI I believe this is the only choice. With regular bulbs I figure I could use the analog outputs instead.

The best thing about these boards I'll be making (parts are ordered) is that I'll only trade 3 control pins for "any" number of inputs/outputs required. This means I could hook up another identical board to gain an additional 64/96 inputs/outputs. Sweet!

There are signs everywhere!

Half a million pieces are completed!

1) Cut signs and playfield plastics with decals partially applied. The large piece below everything else is the top loop piece - it's a bit rough in the edges because it's not yet completed. It didn't align perfectly with the loop rails so I'll have to redesign either to make them match.

Man, I need to clean my keyboard!

Starting to get pretty good at cutting, sanding and wet sanding now!

Note that most of the playfield plastics are missing their decals. It's simply because I haven't got the playfield/or drawings yet to mark the drill holes.

Downed Those Plastics!

Three hours and two aching hands later I've finished cutting (literally) the playfield plastics.
Cutting PVC with a pair of household scissors... But it's all about getting the job done, right?

Looking pretty good too.
Although I'm pretty sure I'll need to tweak them in the morning when my eyes and hands have rested.

To be done is drilling holes for the posts and cutting all the signs and billboards etc.

One down...

...about a million pieces to go. Phew!

Hinges of Steel

Finished the major elements of the backbox today!

I mounted the speakerpanel on a a piano hinge and it works and looks rather good actually. The downside is that it's a little too short so I'll probably need to cover up the edge with a rubber strip or similar.

1) The speakerpanel in a open position. What's not visible in this picture is that I've also
fixed the speaker cables so that they can be easily detached from the speakers if needed. 

I also (finally) got the backglass finished and put in its rightful place!
It's basically a high quality decal that is sandwiched in between two layers of crystal clear PVC. It gives me a nice surface that can be cleaned (with alcohol, if needed) and keeps the decal scratch free.

2) The plastic sandwich. Looking pretty sharp! 

The back glass lights up just enough so that the printing is visible, which was the goal. I was afraid the colors might become too washed out or not illuminated at all, but it turned out just right.

3) Illuminated backglass. There's a pretty strong reflection from the sun, but from the players point of view
it's looks perfect! There's also a slight light bleeding from the fluorescent tube shining through the edges
that needs to be corrected. 

4) Another angle of the completed backbox.

Now I'll just have to wait another week until the playfield is routed!

QR

Just in case you want one - here's a QR code that takes you directly to this blog! You can easily create your own QR codes online at this webpage!

Great stuff!

Plastic Fantastic!

Got the plastic playfield decals printed today and they're looking every bit as good as the rest of the artwork! Sorry, no picture this time - I'll post a couple when they've dried up and been attached to their plastic counterparts!

1) Cut, but not applied, decals. Will look great when finished!

I also took a sample decal to a car-paintshop and had them clearcoat it to check for color discolorations and/or other problems before the final playfield is treated. Two samples were sprayed and one of them left to dry and the other was heated dry. The colors seem to handle the process but there were a little bubbling in the heated one. The painter told me it would probably disappear with another layer of lacquer so he's going to try that as well.

Hope for the best, since this allows me to have a really really really nice and durable finish on the playfield!

That's some wood news!

If everything goes as planed I'll have the final playfield routed and finished in about two weeks!

I have discussed and looked at the drawings together with the CNC-shop (a new one, the old one couldn't create the piece I wanted) and after a couple of trips back and forth it now looks as it should in the router software. Apparently the format I used earlier was too old to support some of the features I used in the drawing, while looking good in the CAD software they never became 'available' to process for routing.

But after a re-save in a newer format everything became routable in the final drawing, so we've booked a manufacturing date in early June.

Then I'll have a couple of exciting days of fitting inlays, sanding and painting the playfield before applying the final decal! Can't wait!

The Cold Days

Been filled with self-pity, anxiety and a sense of dying the last couple of days, in other words -
I've caught a cold. It sucks.

The good news is that I've managed to get a little metalwork done. I've more or less completed all the metal guides and rails now. Despite it being salvaged and reshaped pieces from another machine it looks quite good and sort of made for this machine.

When "manufacturing" the metal parts I solved a couple of things I've been thinking about, such as how the left ramp would be protected...

Stern's blue rubber pad to the rescue!
I drilled a couple of holes in the metal railing and attached the rubber pad on it. Then I simply aligned the ramp and rail so that the rubber extrudes beyond the edge of the ramp. As it is the left side of the left ramp it doesn't really matter if there's screws, since the ball cannot ever hit them due to the angle. The ramp is also by design a little shorter so there's plenty of room for another screw for the rail. It's almost as if they were designed to match this way!

I also created a couple of one-way gate wires so now I've got all the gates I need. I bought a DIY kit with steel wire and bent them myself. Really easy and extremely price worthy compared to buying each gate, especially since it's hard to guesstimate if the dimension are correct by looking at a picture on the web...

I did manufacture one piece (note the lack of quotes) that is at the end of the left ramp. It's basically a very simple protector and stopper that drops the ball dead to the floor below. Then the ball rolls down to a VUK that acts as a ball lock or relay depending on mode and if the lock is active etc. Similar to the sword catch/release in Lord of the Rings, for instance.

I also got the new toy/decoration that I ordered a while ago. It looks really cool and fits in very well with the rest of the playfield.

Have a look:

It will most probably not interact with the pinballs physically, but it will light up during certain modes and affect the game aesthetically in a very cool and mood-setting way.

I must do a quick rant on the shipping costs across the globe. Well, now that I wrote 'across the globe' it kinda seems lame to rant about it, but anyway -
I bought the toy itself for around $45.
When all shipping and customs were payed for it totaled for $150!

That's some serious expensive shipping and probably the most expensive toy I've ever bought...
Sucks to live in a country where all the cool stuff must be imported!

Heads up!

Finally got the backglass in place!

1) Backglass partly held in place by magnets (these things are a godsend!).
I figure I'm going to things a little different - I will allow unlocked access into the lighting-area of the
head, but the displayarea under it will be locked. So the lock won't be visible from the outside.

Weird angle thou - everything looks crooked!
And...

2) Decals applied to the sides (and speaker panel). Looking pretty sharp if I may say so!
The protective film is still somewhat attached to the backglass. I'll remove it on the very last moment, hehe.

Yepp, that's a couple of decals for you!
Or for me. I guess it's mostly for me.

What's up with the SD card libraries these days?

Spent a couple of hours decoding, recoding, errorchecking and retracing my steps on the bitpacking routine. It looked like a 4bit instead of 3bit compression worked, but then the animations started crashing...

So I spent a little more time, and surprise surprise - the SD card library still has flaws.
The last byte of every block was conveniently skipped for reasons unknown to mankind and two (?!) extra bytes has been added to be read when trying to read the end of a block...

I removed the extra two bytes and took the liberty to allow the SD card to read the last byte as well (I'm THAT bad!), and presto - the SD card library started to behave like it should.
Rather annoying that the customer have to troubleshoot the libraries that the company who sold the product relies on...

I just have to ask - how the heck did they come up with the brilliant idea to load 514 bytes from the last 512-byte sector and 511 out of 512 from the rest....

DMD progress so far

Revised the DMD code a little today and thought it would be fun to see how far I've come the past months. The current DMD state is as follows:

* Streaming fullscreen animations with up to 40 fps from the SD card
* Graphics library with two types of texts and box/line drawing
* Multilayered - combine several layers of graphics before drawing
* Runs at 110-130 Hz, 8 shades of color

Again - the cellphone camera does not do the screen or animation justice. Also, the example animation in the video is a little messy and runs a little too fast to be pleasant. When making the final animations each needs to be tailored so that each animation looks good on the DMD, regardless if the movement becomes too slow or fast in comparison to the original clip. It's all about the end results! 

I've prepared around 80 shots of animations not counting static images and custom menus etc. I have not yet created any final DMD animations. The process is slow and tedious, that's for sure!

For comparison - this is how the DMD rendering looked a couple of months ago (on a PinLED display):



Although the framerate was pretty solid at around 100-150 frames at that time, there was no loading of images or multishading. It was all just one frame prebuilt and displayed in a single shade as fast as possible.

The new DMD-code is a LOT faster - if I would have the same setup with the new code, the display would potentially update at far above 1000 Hz. (The screen caps at around 200 Hz according to the specs). It's the SD card loading and, to a point, the frame rebuilding that takes time.


The annoying bit-packing bug is still apparent, to my dismay. I can't seem to figure out what the problem is, since the packing/unpacking looks fine on the computer, and the correct amount of bits and bytes are there. It shouldn't be a problem with the SD card library either, since the same code works fine when loading an unpacked DMD-file.

SuperMax32 returns!

The good folks at Digilent has now finally released a SD-card library that is useful, so I can now read more than ten frames of data before the Max32 crashes. This means I'm good to go with animations!
I have already loaded up a quick animation that runs rather nicely (shots from it in the previous post) but my cellphone once again lets me down so you'll have to do without video evidence...

The downside is (unrelated to animations) is that there's some bit-packing (or unpacking) artifacts going on so that every 1000'nd pixels or so remains unlit. I've not investigated this but I believe it's probably a typo somewhere in the bit-unpacking code as it is not apparent in the unpacked files.
But the unpacked animations run at 14 fps compared to around 35 fps of the packed, so unpacked data is not an option.

Once you go 35 - you never go .... back.

Image formats and whatnots

I reprogrammed my converter for the DMD animation to only support PNG-series instead of animated GIF's for several reasons, including -
* Each image is independently adjustable
* I have a lot of trouble finding software for Mac that can create animated GIF's
* The GIF-files can only have 256 colors, which means inevitable dithering of the source files

I believe this is also the way the P-Roc handles its conversion. It would be cool to know if they choose this path as well for the reasons I mentioned above.

Basically you enter "python convert.py foldername" and it reads all files in that folder, bakes it into a custom DMD format and stores a debug image of each frame in a debug folder inside the same dir. Very clean and a lot more flexible than animated GIF's.

I also added a brightness filter before each conversion so that the rather dark images will be pushed up into a more suitable range for the DMD to display. It could mean loss of the finer details, but I guess I'll have to experiment on this.

For example, this is with added brightness:

And this is the same image without:

A lot better, right?

However - compare these two...

There's clearly some unwanted artifacts caused from the brightness pushing, but the actual movie data looks a lot better with it activated. Oh, the decisions!

The speakers has spoken!

Placed, but not fastened in the cabinet head. As I wrote before I have not yet decided to hinge or not to hinge, so I'm leaving open doors here (ha.ha...). I'd like to find some fancy beveled edges to apply on the edges of the head. Preferably chrome since the lockdown bar and side rails are chromed as well.

P.S
I really need to get a better camera. The colors are looking a lot better in reality and not washed out like in the picture.