...it's auto-launch time!
Finally fixed the broken auto-launch.
One step closer to an autonomous machine...
Tuesday, December 25, 2012
Tuesday, December 11, 2012
Cold Days of Sweden
Brrr.
It's minus a million degrees nowadays.
...and I've caught a cold.
So little or no work has been done on the BioShock pinball. That sucks.
It's minus a million degrees nowadays.
...and I've caught a cold.
So little or no work has been done on the BioShock pinball. That sucks.
Wednesday, November 28, 2012
Something bad happens, something good happens.
All right, I've also done a few minor fixes such as attaching switches to the playfield, a right loop spinner, protection for sharp edges etc. In some of the older pictures you could see that the center scoop (or Vent-entrance) had the metal edges unprotected. Being so close to flippers and a device screaming for attention, it basically means that over time both the scoop itself and the balls will be damaged.
I designed a protection part for the scoop which allows me to attach rubber pads to the side without touching the inside of the scoop. This part was laser cut alongside the rest of the pieces and is visible in a previous post.
But the screw was too short.
And it broke in half when I tried to unscrew it.
First I tried to unscrew it from the back, which of course didn't work. I started a mini excavation in order to grab the screw with a pair of pliers, but since there's VERY little room to maneuver that didn't go that well either. It may look like there's space in the picture, but believe me - there's not.
During night it came to me -
I'll simply screw the screw through the playfield using a pair of pliers.
Brilliant!
The only downside is that I had to remove the entire rail in that area in order to reach the screw.
But by doing so I also got my thumb out in fixing the blue rubber pad on said rail, since there was a gap between the rail, pad and ramp.
A quick bend and it looks perfect!
Back to the mini-post.
With the screw out, I could use a better one to securely fasten the mini post in position.
It came out great and with the bumper cap on it looks rather designed that way, actually...
Other than that I've also applied mylar to most areas that are exposed and in need of protection.
Hopefully it will keep the machine looking fresh a little longer!
1) Scoop protection and the right loop spinner. I'm thinking about making this spinner a "cash counter" in order to unlock new upgrades, but its final feature is not yet written in stone. |
But the screw was too short.
And it broke in half when I tried to unscrew it.
First I tried to unscrew it from the back, which of course didn't work. I started a mini excavation in order to grab the screw with a pair of pliers, but since there's VERY little room to maneuver that didn't go that well either. It may look like there's space in the picture, but believe me - there's not.
During night it came to me -
I'll simply screw the screw through the playfield using a pair of pliers.
Brilliant!
The only downside is that I had to remove the entire rail in that area in order to reach the screw.
But by doing so I also got my thumb out in fixing the blue rubber pad on said rail, since there was a gap between the rail, pad and ramp.
A quick bend and it looks perfect!
3) Left ramp entry with the blue rubber pad in its correct place. |
Back to the mini-post.
It came out great and with the bumper cap on it looks rather designed that way, actually...
Other than that I've also applied mylar to most areas that are exposed and in need of protection.
Hopefully it will keep the machine looking fresh a little longer!
Eject! Eject! Eject!
I've finally completed the ball-through.
I really took a long ball on this one, since I started out using an old ball-through from an old Bally game called "Night Rider". What I didn't know was that this game was a single ball one. Bummer.
Once I got the parts I was thinking about different ways of getting it to work like a newer machine's ball through, thinking I'd get away cheaper than investing in a new ball through.
I had to precisely tweak the solenoid strength of the drain kicker so that the balls are shot just hard enough to reliably land on the other end of the "hill", without getting kicked back by Mr Newton on the other end. This turned out to be a bit tricky since it could work just fine, but then be too weak in case there's multiple balls waiting to "drain". This would simply block the shot and the ball would require a couple of shots. But I got it right in the end.
For the entire assembly to function I needed to put a kicker solenoid in an angle (visible in the previous post) so that the balls would be shot out correctly.
In the end, it works and functions reliably - but if it breaks I'll probably buy a new ball through instead.
To sum it up:
Cheaper, yes.
Easier, no.
I really took a long ball on this one, since I started out using an old ball-through from an old Bally game called "Night Rider". What I didn't know was that this game was a single ball one. Bummer.
Once I got the parts I was thinking about different ways of getting it to work like a newer machine's ball through, thinking I'd get away cheaper than investing in a new ball through.
I had to precisely tweak the solenoid strength of the drain kicker so that the balls are shot just hard enough to reliably land on the other end of the "hill", without getting kicked back by Mr Newton on the other end. This turned out to be a bit tricky since it could work just fine, but then be too weak in case there's multiple balls waiting to "drain". This would simply block the shot and the ball would require a couple of shots. But I got it right in the end.
1) The fully loaded 4-ball through, including the roof which will further direct the balls. |
In the end, it works and functions reliably - but if it breaks I'll probably buy a new ball through instead.
To sum it up:
Cheaper, yes.
Easier, no.
Too Much POWER!
It's been a while since my last post, which is mainly because my focus has been partly elsewhere, and partly because I've been busy doing stuff on the machine.
First off -
I've received the parts from the welder and they look awesome!
From a user perspective it's almost impossible to detect any seams, which I was a little bit worried about. It turns out that 'tigging' is a technique used to melt two materials together using no external materials, meaning the weld will be 100% the same strength as the rest of the piece.
This would not have been the case if I would to pursue my blazing thing I had going there for a while...
Behold!
I had to modify the pieces slightly, most noticeably the VUK rail. The metal stop at the end was not wanted and had to go, and the loop had to be evened out to smooth out the trajectory of the ball.
I've also changed some of the solenoid coils since a couple of them were too weak. I may have to switch around the center VUK and top VUK since the top one has a bit too much power now.
Speaking of power...
I've replaced the autolaunch coil with a beefier one since the old one couldn't quite push the ball all the way up the ramp. I studied the manuals of the game I've shamefully borrowed the ramp from and found out that, as I already knew, I was using a too weak coil.
I did a couple of test shots and for some reason it didn't shoot the ball all the way up anyhow.
After a little detective work I noticed that the ball bounced ever so slightly against the edges of the shooter lane and lost momentum. So I tried to tweak the positions a little and all of a sudden the autolaunch simply gave up.
Tap. That's all the thunder it could bring.
Tap. I saw the kicker arm move but very weakly.
Crap. Did I just burn my new shiny coil?
I looked under the playfield and saw this...
As you can see, the reason for it not working very well is obvious.
The link had simply cracked...
This wasn't unexpected thou since the link was from an older game that I've modified to fit. Luckily for me I bought the correct link in the last shipment of parts so it's all just a matter of pulling the roll-pin, inserting the link and reinserting the roll-pin.
Phew.
First off -
I've received the parts from the welder and they look awesome!
From a user perspective it's almost impossible to detect any seams, which I was a little bit worried about. It turns out that 'tigging' is a technique used to melt two materials together using no external materials, meaning the weld will be 100% the same strength as the rest of the piece.
This would not have been the case if I would to pursue my blazing thing I had going there for a while...
Behold!
1) Habitrails welded together. I guess that was obvious by looking at the picture thou. |
I've also changed some of the solenoid coils since a couple of them were too weak. I may have to switch around the center VUK and top VUK since the top one has a bit too much power now.
Speaking of power...
I've replaced the autolaunch coil with a beefier one since the old one couldn't quite push the ball all the way up the ramp. I studied the manuals of the game I've shamefully borrowed the ramp from and found out that, as I already knew, I was using a too weak coil.
I did a couple of test shots and for some reason it didn't shoot the ball all the way up anyhow.
After a little detective work I noticed that the ball bounced ever so slightly against the edges of the shooter lane and lost momentum. So I tried to tweak the positions a little and all of a sudden the autolaunch simply gave up.
Tap. That's all the thunder it could bring.
Tap. I saw the kicker arm move but very weakly.
Crap. Did I just burn my new shiny coil?
I looked under the playfield and saw this...
2) Autolaunch...has become neverlaunch. Just behind it is the new ball eject solenoid, which is rather inconveniently placed. |
The link had simply cracked...
This wasn't unexpected thou since the link was from an older game that I've modified to fit. Luckily for me I bought the correct link in the last shipment of parts so it's all just a matter of pulling the roll-pin, inserting the link and reinserting the roll-pin.
Phew.
Saturday, November 10, 2012
Solenoid Madness!
Finally - the solenoids are in place and everyone of them working properly!
I've also remade the control cables for the power boards since several of the pins I planned on using for control didn't work since they were shared with other functions, such as the SD card loading etc. This is a drawback on the Chipkit-board since the actual PIC32 chip has a lot more I/O's than the board has, so some of them are shared.
I programmed a simple but effective diagnostics page as well in order to test each of the solenoids which has already proven very useful (I can't believe I originally thought I wouldn't need a diagnostics mode...) since I can properly diagnose how much power is needed for each coil, and of course - verify that they work.
Unfortunately I noticed that some of the coils are a bit too weak, while some are far too strong. So I'll probably switch around some of the solenoids to get the best power usage possible. Worst case scenario, I'll buy a couple of new ones.
Here's a short clip of the adjustments menu and, of course, the coil diagnostics page -
p.s
Dramatic music is dramatic!
I've also remade the control cables for the power boards since several of the pins I planned on using for control didn't work since they were shared with other functions, such as the SD card loading etc. This is a drawback on the Chipkit-board since the actual PIC32 chip has a lot more I/O's than the board has, so some of them are shared.
I programmed a simple but effective diagnostics page as well in order to test each of the solenoids which has already proven very useful (I can't believe I originally thought I wouldn't need a diagnostics mode...) since I can properly diagnose how much power is needed for each coil, and of course - verify that they work.
Unfortunately I noticed that some of the coils are a bit too weak, while some are far too strong. So I'll probably switch around some of the solenoids to get the best power usage possible. Worst case scenario, I'll buy a couple of new ones.
Here's a short clip of the adjustments menu and, of course, the coil diagnostics page -
Feels good to see some movement from the machine after all this time!
p.s
Dramatic music is dramatic!
Friday, November 9, 2012
Fight The Power!
Yes!
Got the magnet working.
When attempting to fasten the diode I noticed that I may have inserted the ground cable in a non-correct way (i.e tightening the screws around the plastic exterior instead of the copper directly), basically creating a current loop causing all the 48V to pass through the little tiny resistor instead of through the much beefier MOSFET. I say 'may' because I'm not sure how else the magnet would work, but a theory could be that the ground cable just barely made contact causing the resistor to become the least cost path.
I've added a diode now for safety as well, and hopefully the magnet will continue to work in production. In any case, I am not touching this now.
Another thought springs to mind - I haven't extensively tested the powerboards with 48V.
I've just noticed that they in fact work and that there has been zero problems shooting around for a while. But how will they stand running game after game?
Got the magnet working.
When attempting to fasten the diode I noticed that I may have inserted the ground cable in a non-correct way (i.e tightening the screws around the plastic exterior instead of the copper directly), basically creating a current loop causing all the 48V to pass through the little tiny resistor instead of through the much beefier MOSFET. I say 'may' because I'm not sure how else the magnet would work, but a theory could be that the ground cable just barely made contact causing the resistor to become the least cost path.
I've added a diode now for safety as well, and hopefully the magnet will continue to work in production. In any case, I am not touching this now.
Another thought springs to mind - I haven't extensively tested the powerboards with 48V.
I've just noticed that they in fact work and that there has been zero problems shooting around for a while. But how will they stand running game after game?
Thursday, November 8, 2012
Resistance is futile...
It was a bad resistor.
Or rather -
When voltage was applied to the control pin of the magnet MOSFET, the resistor was fried immediately. This caused the MOSFET to be always on.
I've tried moving the magnet cable around and so far I've fried two MOSFET's and four resistors.
The two regular solenoid's on the same board works perfect.
I have checked the resistance which is fine, and the magnet seems to function both ways, i.e there's no polarity or diode in there. I think, unless it's been fried as well. I'll try putting one of my spare N1001 diodes on the magnet to see if that makes any difference - that's the one difference I can see at least.
I'm running out of spare MOSFET's here...
Or rather -
When voltage was applied to the control pin of the magnet MOSFET, the resistor was fried immediately. This caused the MOSFET to be always on.
I've tried moving the magnet cable around and so far I've fried two MOSFET's and four resistors.
The two regular solenoid's on the same board works perfect.
I have checked the resistance which is fine, and the magnet seems to function both ways, i.e there's no polarity or diode in there. I think, unless it's been fried as well. I'll try putting one of my spare N1001 diodes on the magnet to see if that makes any difference - that's the one difference I can see at least.
I'm running out of spare MOSFET's here...
Electric magnetism...It burns.
So I hooked up the third and final powerboard today.
Then I finished creating the third powercord mini-harness for the three extra solenoids.
Finally I turned the power on and tested the coils - first one ok, second one ok and we got smoke. Smoke?
Turns out something wasn't right with the third (actually first) MOSFET so it was in a always-on state.
This of course caused the magnet it was connected to to be always on, causing it to get EXTREMELY hot! I mean, surface of the sun hot.
And then I accidentally touched it, just to be sure it really was hot. It was.
Tomorrow's another day and then I'll troubleshoot the board to see what's wrong with it. Most probably I'll switch the faulty MOSFET and the accompanying resistor to make sure it works.
I really, really, really wish I'd tested the board before mounting the harness and the board etc...
Anyway -
Thinking the MOSFET is toast anyway, I decided to videotape its last moment on this planet doing what it should do - grabbing balls.
Edit....
Now that I think of it - the MOSFET is probably fine since it does in fact work. Maybe it's just the resistor that needs changing. Does anyone know if a broken MOSFET leads current...?
Then I finished creating the third powercord mini-harness for the three extra solenoids.
Finally I turned the power on and tested the coils - first one ok, second one ok and we got smoke. Smoke?
Turns out something wasn't right with the third (actually first) MOSFET so it was in a always-on state.
This of course caused the magnet it was connected to to be always on, causing it to get EXTREMELY hot! I mean, surface of the sun hot.
And then I accidentally touched it, just to be sure it really was hot. It was.
Tomorrow's another day and then I'll troubleshoot the board to see what's wrong with it. Most probably I'll switch the faulty MOSFET and the accompanying resistor to make sure it works.
I really, really, really wish I'd tested the board before mounting the harness and the board etc...
Anyway -
Thinking the MOSFET is toast anyway, I decided to videotape its last moment on this planet doing what it should do - grabbing balls.
Edit....
Now that I think of it - the MOSFET is probably fine since it does in fact work. Maybe it's just the resistor that needs changing. Does anyone know if a broken MOSFET leads current...?
Gone International!
Found an online show called The 404 Show talking about a lot of things - and of my Bioshock pinball. Cool and interesting!
You can find the video here, and the part about me and my build is from around 4:44.
To the hosts -
Feel free to contact me in case you want to know more about the machine or anything! We'll have a virtual beer or something. ;)
Cheers!
You can find the video here, and the part about me and my build is from around 4:44.
To the hosts -
Feel free to contact me in case you want to know more about the machine or anything! We'll have a virtual beer or something. ;)
Cheers!
Wednesday, November 7, 2012
It's ALIVE!
Quickly hooked up the motorized targetbank just now, and here's the first test run:
As you can see, it's not perfect -
The rotation range on the servo was supposed to be a full 180 degrees, but this particular servo only has approximately 170 degrees of motion. This means I need to manufacture a better link between the servo and the sliding bracket in order for the target bank to fully rise.
Side note -
The clicking noise in the video is caused by one of the servo extensions hitting the frame itself.
The excess plastic have been cut off and the problem is no longer there.
As you can see, it's not perfect -
The rotation range on the servo was supposed to be a full 180 degrees, but this particular servo only has approximately 170 degrees of motion. This means I need to manufacture a better link between the servo and the sliding bracket in order for the target bank to fully rise.
Side note -
The clicking noise in the video is caused by one of the servo extensions hitting the frame itself.
The excess plastic have been cut off and the problem is no longer there.
Tuesday, November 6, 2012
Metal On Metal
I've left the habitrails for professional welding today, since my brazing didn't improve and the results were inferior. There were two major parts that needed welding, the right habitrail exit from the upper level and the transport from the center VUK onto the upper level.
Can't wait for the finished ones!
I've also gotten in touch with a a metalworker who've helped me "water-cut" the custom steel parts that I needed to have fabricated. Great guy, awesome quality and the results came out great!
The folding on the VUK bracket took quite some time to get right!
Now I'll have a couple of more hours in front of me bending and folding the pieces into their final shape!
Can't wait for the finished ones!
I've also gotten in touch with a a metalworker who've helped me "water-cut" the custom steel parts that I needed to have fabricated. Great guy, awesome quality and the results came out great!
2) A couple of (near completed) pieces. Folding stainless steel is too easy, that's for sure! Sure, a little touchups here and there are needed - but I think they look great! |
The folding on the VUK bracket took quite some time to get right!
Now I'll have a couple of more hours in front of me bending and folding the pieces into their final shape!
A Helping Hand!
While bolting the legs on with the new plastic protectors, I realized that the bolts were only just long enough to reach into the bracket on the other side. I double checked this with a couple of pinball experts online and they all said that there were two different bolts available - and of course I got the wrong ones...
But then I received a mail from a guy called Purre who was willing to send me a complete set of bolts free of charge! Awesome stuff!
Thank you, Purre!
The bolts made all the difference as you can imagine when compared side by side with a regular bolt...
Finally the legs are rock solid!
But then I received a mail from a guy called Purre who was willing to send me a complete set of bolts free of charge! Awesome stuff!
Thank you, Purre!
The bolts made all the difference as you can imagine when compared side by side with a regular bolt...
1) Top - old bolt. Compared to the new bolts there's almost 10 mm difference in length! |
Finally the legs are rock solid!
Sunday, November 4, 2012
Status update
The current alpha state of the gameflow and menu system is as follows...
I've done a couple of things that doesn't show in the video, such as - fixing the tilt blob, tidying the cables, soldered an additional powerboard, prepared the upper level so it's more or less complete...
Things are going forward!
I've done a couple of things that doesn't show in the video, such as - fixing the tilt blob, tidying the cables, soldered an additional powerboard, prepared the upper level so it's more or less complete...
Things are going forward!
Tuesday, October 30, 2012
Under The Knife
I have received the last shipment of parts now, but I've got sidetracked and created drawings for hinges, brackets and what not that needs to be completed. I've also decided that Mr Bubbles needed to have a little more surgery...
First - I needed to be able to move the drill-arm, but the old idea was to use an external servo and extensions. Not cool. So I decided to put the entire servo inside the Big Daddy. Guess what? It's a perfect fit!
Before assembling it for real, I need to replace the old multi-LED version of the helmet-light with a single LED that can show all colors. The reason for this is that the various colors shone with uneven brightness which the new one will hopefully remedy.
After that he's pretty much ready to roll - besides the angular motion from side to side, but that will be done using an external servo. I see no reason for Mr Bubbles to become fully mobile...
First - I needed to be able to move the drill-arm, but the old idea was to use an external servo and extensions. Not cool. So I decided to put the entire servo inside the Big Daddy. Guess what? It's a perfect fit!
2) Partly assembled and looking good! There are smaller servos, but this one pulls approximately 5Kg, which is plenty of power to throw the arm around! |
3) The new joint very closely resembles the old joint, meaning the seam will be invisible. |
Once that was done, I needed to fix the servo "head" in the arm itself, otherwise it would just rotate around its own axis instead of moving the arm around...
4) Part of the servo inserted and glued in place. The glue is just an extra precaution since I carved out a perfect hole before inserting the piece. |
5) Fully assembled (well, sort of) and ready to drill your balls out! |
Before assembling it for real, I need to replace the old multi-LED version of the helmet-light with a single LED that can show all colors. The reason for this is that the various colors shone with uneven brightness which the new one will hopefully remedy.
After that he's pretty much ready to roll - besides the angular motion from side to side, but that will be done using an external servo. I see no reason for Mr Bubbles to become fully mobile...
Tuesday, October 23, 2012
Slap some paint on it!
While waiting for my parts that are currently residing in customs-land, my girlfriend who works professionally applying decals helped me attach the last decals on the pinball machine - on the cabinet itself. It looks awesome!
Doing so also allowed me to mount the legs in their final mode including the plastic protector, fixing the cabinet head and attaching the "fold-lock" on the back. The plunger, buttons and cabinet door is now also attached properly.
As soon as the parts arrive I'll jump right in creating the harness!
1) The completed exterior - minus side rails and lockdown bar, but their time has not yet come. It's really starting to look like a proper pinball machine now! |
Doing so also allowed me to mount the legs in their final mode including the plastic protector, fixing the cabinet head and attaching the "fold-lock" on the back. The plunger, buttons and cabinet door is now also attached properly.
As soon as the parts arrive I'll jump right in creating the harness!
Sunday, October 14, 2012
The Harness...
...is NOT completed.
I had to order a couple of things in order to complete the harness. Should arrive in a week or so, so I'll focus on my family and music the coming week instead.
See you in a week!
I had to order a couple of things in order to complete the harness. Should arrive in a week or so, so I'll focus on my family and music the coming week instead.
See you in a week!
Thursday, October 11, 2012
The World's Longest Stairmaster!
I'm not dead, I've just been AFK a couple of weeks doing this...
... so not much has been done with the pinball machine. As in, nothing at all.
Hopefully that'll all change soon as I'm planing to continue making the wire harness.
With a little luck the light board will be finalized in a couple of days as well.
I noticed before my vacation that I'm a couple of solenoid drivers short. Those last minute changes in the playfield design somehow escaped my planning of the electronics so I'll have to add them now. Nothing major, a couple of cables and a driver board that needs to be ordered...but terribly inconvenient!
... so not much has been done with the pinball machine. As in, nothing at all.
Hopefully that'll all change soon as I'm planing to continue making the wire harness.
With a little luck the light board will be finalized in a couple of days as well.
I noticed before my vacation that I'm a couple of solenoid drivers short. Those last minute changes in the playfield design somehow escaped my planning of the electronics so I'll have to add them now. Nothing major, a couple of cables and a driver board that needs to be ordered...but terribly inconvenient!
Thursday, September 20, 2012
Time to harness the power...
Yeah, time to start figuring out the wire harness...
Turns out it's a little trickier than I thought it would be.
As you can see, quite a bit to do before the wire harness is completed - We'll see how it'll turn out once finished!
Turns out it's a little trickier than I thought it would be.
As you can see, quite a bit to do before the wire harness is completed - We'll see how it'll turn out once finished!
Sunday, September 9, 2012
Blazing Saddles!
Sometimes the simplest things are the best.
By doing a few simple changes to the SD card library, I've managed to squeeze out a whopping 3x performance out of the SD card reading! I learned that once the card has been initialized into SPI mode it's possible to raise the clock speed A LOT.
Currently I'm setting the clock speed after init to ten times the speed before init. This means a full frame loading in just 2.5 ms and by doing this, I've increased the overall refresh rate by 15 Hz! The card is now reading approximately 614KB/sec!
The card functions with higher speeds, but data gets corrupted along the way. This is probably because the rise/fall times of the resistors in the SD card circuit needs time to switch. With a faster circuit I'm pretty sure I could squeeze out more!
Nice!
By doing a few simple changes to the SD card library, I've managed to squeeze out a whopping 3x performance out of the SD card reading! I learned that once the card has been initialized into SPI mode it's possible to raise the clock speed A LOT.
Currently I'm setting the clock speed after init to ten times the speed before init. This means a full frame loading in just 2.5 ms and by doing this, I've increased the overall refresh rate by 15 Hz! The card is now reading approximately 614KB/sec!
The card functions with higher speeds, but data gets corrupted along the way. This is probably because the rise/fall times of the resistors in the SD card circuit needs time to switch. With a faster circuit I'm pretty sure I could squeeze out more!
Nice!
Friday, September 7, 2012
That "behind the scenes" stuff...
Been focusing on getting the codebase up to date and functioning as I would like.
Slowly getting there.
For one -
I've redesigned almost the entire code bank from scratch.
So what I've got now is a state machines for each player state along with separate states for the various maintenance views and idle loops. Works like a charm and VERY flexible. I've got most (if not all) of the player states pinned down including bonus, highscore, ball saved, match sequence etc. And of course - multiplayer.
It is at the moment entirely possible to "play" a complete single- or multiplayer game from inserted credit to game over (or highscore), but the actual gameplay logic is not yet started. I've still got some electrics and hardware things to do...
Here's a teaser pic of the current state -
Animated streamed video, multiple layers of text/images, transparency, transitions, effects...
In my humble opinion, I believe this easily matches the quality of commercial pinball DMD rendering!
One guideline I'm following is that there should never be a time where the graphics is just switched on and off - each transition should be handled fluently and text should not just pop into place, but rather fade (but fast) into place. That particular effect creates a modern feel to it and I hope that the overall impression will surpass most peoples expectations!
If there's RAM and flash available when logic is complete, I'm think about inserted some realtime generated water effects onto the display as well - staying true to the Bioshock realm.
I've also spent time creating the tools to burn and generate my SD disc image.
My tool simply recursively loops through all files in a folder and packs the DMD files together into one big file with a reserved 51200 byte space in front for machine settings and highscores. An "anims.h" header file is created and updated so all I need to do is to run a recompile of the Chipkit program and reseat the SD card and the animations are updated.
If only the actual data has changed and not the start/stop sectors no reprogram is needed. This allows for quick and easy previewing in the pinball machine since the SD card library has been recreated to support hot-swapping of cards as well.
I've also written a readdmd.py script that can read directly from the packed image (or a regular DMD file) and show the frame at that position. Really handy when debugging and developing.
Pretty neat!
To compare an older image with the current, you can see that it's much closer to the expected output compared to the old image - which I also commented on in the older entry.
Slowly getting there.
For one -
I've redesigned almost the entire code bank from scratch.
So what I've got now is a state machines for each player state along with separate states for the various maintenance views and idle loops. Works like a charm and VERY flexible. I've got most (if not all) of the player states pinned down including bonus, highscore, ball saved, match sequence etc. And of course - multiplayer.
It is at the moment entirely possible to "play" a complete single- or multiplayer game from inserted credit to game over (or highscore), but the actual gameplay logic is not yet started. I've still got some electrics and hardware things to do...
Here's a teaser pic of the current state -
Animated streamed video, multiple layers of text/images, transparency, transitions, effects...
In my humble opinion, I believe this easily matches the quality of commercial pinball DMD rendering!
One guideline I'm following is that there should never be a time where the graphics is just switched on and off - each transition should be handled fluently and text should not just pop into place, but rather fade (but fast) into place. That particular effect creates a modern feel to it and I hope that the overall impression will surpass most peoples expectations!
If there's RAM and flash available when logic is complete, I'm think about inserted some realtime generated water effects onto the display as well - staying true to the Bioshock realm.
I've also spent time creating the tools to burn and generate my SD disc image.
My tool simply recursively loops through all files in a folder and packs the DMD files together into one big file with a reserved 51200 byte space in front for machine settings and highscores. An "anims.h" header file is created and updated so all I need to do is to run a recompile of the Chipkit program and reseat the SD card and the animations are updated.
If only the actual data has changed and not the start/stop sectors no reprogram is needed. This allows for quick and easy previewing in the pinball machine since the SD card library has been recreated to support hot-swapping of cards as well.
I've also written a readdmd.py script that can read directly from the packed image (or a regular DMD file) and show the frame at that position. Really handy when debugging and developing.
Pretty neat!
To compare an older image with the current, you can see that it's much closer to the expected output compared to the old image - which I also commented on in the older entry.
2) Old version: All colors were to washed out, not enough contrast. |
3) New version: Nice contrast between high and lows. Taken at an angle, but with a nice red color and... |
4) ...when compared to the source image, pretty close. This means I get more or less an accurate preview on the file before 'burning' the SD-image. |
Saturday, September 1, 2012
Shaven Even!
I managed to shave off additional time from the rendering today.
Took a full rewrite of the display code, but nevertheless it gained a 13% increase in speed.
Now I'm down to almost exactly 7 ms per frame which gives us roughly 1 ms per color and around 4 microseconds per pixel.
For comparison - just toggling a pin with the Chipkit core library function digitalWrite() takes almost 16 microseconds!
If I could live with a less vivid display I could shave of an additional 3 ms per frame, but I need that time to allow the pixels to fully illuminate (exponential delay ranging from 0 to 42 microseconds between each row). So I think I've come as far as I can get without sacrificing quality!
Unless.... interrupts to the rescue?
I guess now's a good time to mention that the rendering is also looking better than ever with a nice big contrast between the different shades? I even avoided the recommended "1 microsecond delay" between the two row clock updates without adding any ghosting. Sweet!
Took a full rewrite of the display code, but nevertheless it gained a 13% increase in speed.
Now I'm down to almost exactly 7 ms per frame which gives us roughly 1 ms per color and around 4 microseconds per pixel.
For comparison - just toggling a pin with the Chipkit core library function digitalWrite() takes almost 16 microseconds!
If I could live with a less vivid display I could shave of an additional 3 ms per frame, but I need that time to allow the pixels to fully illuminate (exponential delay ranging from 0 to 42 microseconds between each row). So I think I've come as far as I can get without sacrificing quality!
Unless.... interrupts to the rescue?
I guess now's a good time to mention that the rendering is also looking better than ever with a nice big contrast between the different shades? I even avoided the recommended "1 microsecond delay" between the two row clock updates without adding any ghosting. Sweet!
Monday, August 27, 2012
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.
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 to9 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!
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
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!
Thursday, August 23, 2012
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!
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!
Wednesday, August 22, 2012
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...
... 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.
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!
I've finished soldering the switch board and started making the light board.
I probably shouldn't be showing you this...
... 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.
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!
Monday, August 20, 2012
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!
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!
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!
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!
Friday, August 17, 2012
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.
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.
Monday, August 6, 2012
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!
Hope we'll have some wicked new discoveries soon and that ESA will soon follow with their rover!
Saturday, August 4, 2012
State of the Machine
With less than six hours on familiar grounds, work continued on the pinball machine...
I've also started re-recording all animation data. But things are progressing slowly at the moment!
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! |
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)
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! |
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. |
Subscribe to:
Posts (Atom)