Last fall, one of my friends accepted a job offer back east and needed to put his possessions on a diet. He called me up, and asked me if I wanted to take his Meteor.
Meteor, of course, being a pinball machine manufactured by Stern way back in 1979.
I drove to his house, picked up the machine (which had mysteriously gone from working to not working, apparently in the time it took me to drive across town), secured it in the back of the truck, and then took it up to the cabin, where I introduced it to Bad Cats.
And then it sunk in. When I only had two machines - one per house - I could deny it, but adding the third made it obvious.
I was a collector. Especially since the new machine didn't work.
A bit of debugging found the first fault - there was a break in where the line cord was attached (a substandard solder joint). A quick wire nut fix (no soldering iron with me), and the machine woke up. More or less - there were a few playing issues, but it mostly just needed some light bulbs. A whole-lotta light bulbs (note to readers - foreshadowing!!!)
So, I headed on over to Pinball Repair Section of Marvin's Marvelous Mechanical Museum for a repair guide, one of the sources of specialized information that makes the internet great.
Which leads to a brief aside. The Meteor is made by Stern, but the repair guide you need is for Bally machines.
When Stern started building machines, they needed a control system to use. They could have developed one from scratch, but that takes a lot of time and money. You could license it from another manufacturer, if they would do that, but they won't because they don't want the competition. So, Stern just stole the design, Bally sued, won, and got awarded... a license fee per machine. The same thing happened a few years later after Data East stole the design of the Williams control system.
I upgraded the woefully underdesigned power supply (which was apparently designed by the guys who took electronics with me in high school back in 1976), replaced all the bulbs (about 60 of them), turned on the machine and... None of the bulbs worked.
So, I re-replaced the bulbs, and then the fuse that supplies the power to the solenoids (bumpers, slingshots, drop target reset) started blowing. And the bulbs still didn't work.
I checked a bunch of things, but couldn't figure out what was going on.
Then I got lucky, like the program that finally crashes where the bug reports says it does. One of the power resistors on the power supply started smoking.
Generally, that sort of behavior isn't the kind of thing you'd prefer from an electrical device, since you risk losing the Magic Smoke. But in this case it was great. I grabbed my voltmeter, put it on the resistor, and found 47 volts. Which was great, because it told me what was happening.
There is a 47 volt supply that drives the solenoids, but I was reading that voltage on the 6 volt supply to the lights. That was enough to blow the fuse, and it was also enough to make the bulbs *really bright* for a very short period of time.
It only took about 5 minutes to find a wiring harness section that was really tight, and the voltage came back to normal. Now I just need to replace all 60 bulbs again...
I'm looking for help finding out the name of a card game. It's know to us as the "Bob and Sandy" game based on the couple that introduced it, but nobody - including Bob and Sandy - knows the real name of the game.
The basics are as follows:
There are some other rules about exchanging cards.
Anybody know what it's called?
When I set up my new xbox 360, I decided to create a new account.
You can find me as Triabolical.
I've been meaning to write a post about XNA for quite a while now. I mean, "XNA Game Studio Express", ably managed by ex-C#-PM Joe. I was waiting until I did something useful with it, but that apparently is going to be a while...
I've never written games professionally, but I've written a few hobby games or demos in my time. A lunar lander written in Apple II BASIC (with a custom controller box hooked to the paddle port...). A multi-user networked version of SpaceWar! that ran on VMS workstations. A gravity-based collision demos that has run on OS2, VMS, and various flavors of Windows.
But I've never gotten into DirectX, because of the learning curve.
XNA has changed that. While you still need to learn the way DirectX deals with things - a way that is very, very different from the way GDI and GDI+ view the world - the basic game framework is there, and it's fairly easy to get a 2D-based game up and running. 3D is going to require you to learn about textures, quads, shaders, and a bit more stuff, but it's still fairly straightforward.
XNA itself is free for download. Unfortunately, though, it's built on C# Express, which means if you already have VS installed on your system, you need a separate install. Luckily, it's not the size of VS.
Perhaps the coolest part of XNA is that you can build a game, download it to your Xbox 360, and run it. I expect that is going to change the gaming landscape in some interesting ways, since nobody has allowed that on a mainline console (there are some small console gaming systems where you can write your own games...)
If you've ever written - or considered writing - an application that needs to host add-ins, I recommend the CLR Add-In Team Blog, written by the team tasked to make your life easier.
I apologize for the timeliness of this post. I'll be returning to my usual practices of posting stale information promptly.
Have you ever wondered why "shut down" is on the "start" menu?
Has the dialog manager confused and annoyed you?
Do you want to know why registry keys are stored in a hive?
If you'd like to know the answers to these questions, you should pick up a copy of "The Old New Thing: Practical Development Throughout the Evolution of Windows" by Raymond Chen. It's very interesting - like most of his writing - with some practical tidbits, some nice stories, and some deep technical discussions.
Honesty requires me to note that 1) I know Ray, and 2) I help review his book chapters so his publisher set me a copy for free, but I should also note that I wouldn't say nice things about it if I didn't like it, and I've been reading Ray's blog for a long time.
We've been spending some time trying to figure out what our team can get accomplished in the next 6 months or so. We have a feature list that we're considering, and we need to apply some numbers to it.
So, I decided to try using Planning Poker. I made up some index cards with values in dev-weeks, in the values 1/4, 1/2, 1, 2, and 4.
It has taken a fair amount of time to get through this process, but the numbers we got are a lot better than we would get with other methods, and more importantly, the dev team has a much better idea about what and how they'll be building whatever we are building (I apologize for being evasive, but it's a bit of an organizational disease right now).
Note that I'm not recommending all-up estimating. In general, I don't think you should be costing more than a month or so worth of work at a time, as the quality of the estimates won't be great. In this case, we needed a go/no-go number, and the estimates that we got were good enough.