Designing an electronic toy — Wildfire Pinball

Part 1 of this series (Adventures in Toy Design) discussed my involvement in an effort to create a voice scrambling/descrambling helmet to be marketed as an electronic toy. You can read that story here. This story goes a little further back in time, to the very beginnings of my days in the electronic toy business.

As I discussed in that earlier series entry, Mattel had had great market success with the Mattel Football handheld electronic game (1977), motivating our engineering consulting company to try to break into the electronic toy business. As a four-person company with a tiny office over Glen Rock Liquors in Glen Rock, New Jersey, it was a long shot, but hey, what the heck.

The toy industry was incredibly competitive and breaking into the space as a toy inventor was not easy. In fact, just getting a meeting with a toy company was next to impossible. That said, we persisted. When I say “we,” I don’t mean me, as I was the peon in the back lab soldering boards, picking up lunch and maintaining a sufficient inventory of M&Ms and Coca Cola (the staples of any engineering lab worth its salt).

In this context, “we” meant Steve, our resident electronics genius and my older brother, and Jim, a brilliant industrial designer and our respectable businessman. Steve and Jim were partners in our burgeoning engineering firm, a company with great potential, brilliant engineers and lousy cash flow. I long ago lost count of how many times I had heard “here’s your paycheck, but please don’t cash it until the end of the month.” We all knew that getting into the toy business would be more fun than the engineering we had been doing, and could go a long way toward covering payroll.

Meanwhile, in Beverly, Massachusetts, while we were subsisting on M&Ms and Coca Cola, Parker Brothers, of Monopoly fame, had had a gangbusters year in 1978, led by their hit electronic game, Merlin. The concept for Merlin had been brought to them by a small Cambridge company called Micro-Cosmos, which consisted of the married couple of Bob and Holly Doyle (former astrophysicists and astronomers), and Holly’s brother Wendl (a computer science guy).

The Doyles had recently come into Parker Brothers to pitch their follow-up electronic toy idea for 1979, one which was technically much more complicated than Merlin. To pitch the concept, the Doyles had Wendl build an actual playing prototype, which consisted of a handheld unit (not unlike the Merlin pictured above) but attached through an umbilical cord to a briefcase. In the briefcase was a large circuit board sporting some serious computing power; a 16-bit microprocessor and its supporting components, including tons of RAM and ROM. The concept was for a handheld pinball machine — Wildfire, and the prototype played very well. Parker Brothers was duly impressed.

Here are two pictures of the prototype handheld unit, early in its evolution on the left, and further along, on the right.

I believe that the processor they had used was a 16-bit 8086 from Intel, with a software program that came in around 26K bytes. With that level of computing power, the prototype did a great job of simulating the physics, controls and gameplay of a pinball machine, but in the palm of your hand (if you couldn’t see the umbilical cord, that is). All that was absolutely fine when building a prototype to showcase the concept, but not so good if you wanted to put the game on a shelf in Toys ‘R Us at a retail price point under $50. At the time, we estimated that the electronics stuffed in the briefcase cost about $3,000.

Don’t get me wrong, there was absolutely nothing wrong with prototyping a toy concept in that manner. Micro-Cosmos had successfully sold Parker Brothers on the idea and the brilliant execution, but their company wasn’t in the business of engineering a production-ready version of the toy. That left Parker Brothers looking for an engineering solution that would enable them to bring the product to market.

As the clock ticked, Parker Brothers had a problem and they badly needed a solution. They were sitting on the concept of their next hit electronic toy, but they didn’t have an engineering firm to design the production unit. If they didn’t start engineering work soon, the product wouldn’t ship for the holiday selling season.

The Big Break

Somehow, we got an audience with Parker Brothers, which was meant to be an introductory meeting for Steve and Jim to impress them with our self-proclaimed brilliance. In fact, the meeting went so well that the folks at Parker Brothers had an engineering project that they were willing to offer to us. Imagine that! Timing is everything.

Parker Brothers showed our guys the Wildfire prototype, explaining that they were looking for an engineering team that could design a production version of Wildfire with a target manufacturing cost of under $10. With huge quantities, the toy industry was incredibly conscious of per-unit cost, all the way down to a couple of cents. And they wanted it done on a very aggressive schedule, in time for the upcoming holiday season. Depending on who you were talking to, toy companies booked 50–75% of their annual sales in the weeks between Thanksgiving and Christmas. So, if you promised them that you would make the deadline, you had better find a way to do it. In this case, the deadline was less than 4 months away, leaving time for manufacturing and delivery to the stores.

Steve figured that the only way to do Wildfire at the target manufacturing cost was to use a 4-bit microcontroller chip, which was available in quantity at a per-unit cost of about $4.00. This was in contrast to the 16-bit 8086, which cost around $300.00 per device. The 4-bit microcontroller was (obviously) a much more limited capability processor with only 1.5K of ROM memory and 40 bytes of RAM memory. This was comparable to the device used in Merlin, though Merlin was rudimentary when compared to a simulation of the physics of a pinball machine.

Or, said another way, if someone were to take the project on, they would need to duplicate the gameplay of the $3,000 one-of-a-kind prototype with a microprocessor which cost about 1/75th the price of the one used in the briefcase and duplicate the gameplay in a program about 1/20th the size of the current software.

And, of course, there was one extra wrinkle to consider. The 4-bit microcontroller required a 1,500-byte program to be written, and, at the time, we did not have a software engineer on staff. While Steve was certainly capable of programming the game, he had other things on his plate. Gerry was a hardware engineer, Jim was an industrial designer, and me, I was still going to school at nights, and as I discussed at the outset of this story, I had no programming experience. And Dan, our newest employee and our younger brother, was even more green than me.

In summary, the project had an insane schedule and an overly aggressive cost target, especially when compared to the prototype hardware. And, from our standpoint, we were short a critical programming resource while facing a sure-to-be-grueling death march toward a 120-day deadline.

All in all, a piece of cake.

Looking back, I’d like to think that Steve and Jim took all of these factors into account as they sat in that office in Beverly, Massachusetts, deliberating whether or not to take the project. I’d also like to think that they took into account the enormous strain that such a project would put on their somewhat inexperienced, but enthusiastic group of employees. I’d like to think that stuff, but I don’t. What I actually think is they sat there staring at the prospect of working with one of the largest toy companies in the world (and being able to make payroll), and despite the fact that they knew the project was insane on so many levels, they just couldn’t help themselves.

They said “sure, we’ll do it.”

The Missing Link

The hardware engineering was going to be challenging enough in the time frame allotted, but the real question was, who was going to write this computer program that we needed?

The answer was, like all good tech companies, when you don’t have in-house expertise, you bring in an outside consultant. Seems that Jim had a friend or neighbor who was a software guru, currently employed at a major aerospace company as the head of software development. He (we’ll call him Val) was willing to moonlight after work to write the code. Thank God, problem solved! And not a moment too soon, as we had foolishly agreed to a schedule that gave us about two months to demonstrate a playable version of the game.

The Project Begins

From a hardware standpoint, the microprocessor that we chose to use for Wildfire was the AMI S2150,³ made by American Microsystems Inc. (AMI).⁴ It was a 4-bit microcontroller, with 1.5 KB of ROM for the program, and a robust 40 bytes of RAM.

For the “display,” the game used a circuit board with about 70 red LEDs (light emitting diodes) mounted on it, positioned to define all of the potential paths of the pinball as it moved around the playfield. The board also contained two buttons for the flippers, a few LEDs for other elements, such as flippers and knock down targets, a speaker for sound effects, and a four-digit LED display for the score.

To create the illusion of a pinball machine (rather than just a field of red dots), a number of elements sat on top of the circuit board, starting with a custom piece of bakelite plastic that fit over the pattern of LEDs. At each light position, an opening was drilled into the bakelite, defining the “shape” of the light image to be displayed for that particular LED position; for example, round for a ball, elongated for a flipper. These shaped holes were referred to as light pipes, which focused and channeled the light from the LED to a red filter which sat on top of the bakelite. The red filter dispersed the light source from the light pipe, filling in the shape. Finally, a graphic overlay was placed on top of the red filter, as shown below.

The image below, on the left (labeled FIG. 4, as taken from the Wildfire patent), shows the layout of the various LEDs as positioned on the circuit board. The image on the right shows the circuit board of LEDs with the other components mounted on top (as discussed above), demonstrating how the positioning of the LEDs and the backlight holes matched with the design of the playfield art.

The images below show the final product; the left image is from U.S. Patent 4,334,679, awarded to Holly Doyle, Bob Doyle and Wendl Thomis, for the Wildfire pinball game. The right image is a photograph of the actual production game.

The Game Software — Release the Kraken

We designed and built a hardware prototype while Val worked on the software. Since we had only one development system for this particular microprocessor, we decided to keep it at our office. Val would come in at the end of his business day with stacks of paper on which he was writing the code by hand. I was drafted to transcribe his code from handwritten scribble into the editor of the development system.

Night after night, Val delivered reams of handwritten code to me, which I dutifully typed into the system. I was incredible impressed that someone could spend weeks writing thousands of lines of computer code on paper and it would just work. Obviously, this programming stuff was a black art and you had to be a crazy genius to do it.

Finally, after about a month, Val came in with his last stack of papers, announcing that the program was done. Hallelujah! I typed in the last bit of code, assembled the program, burned the resulting binary file onto an EPROM, and plugged in into our circuit board. We couldn’t wait to try the game out!

Drum roll please…………

I turned on the power as the five of us leaned over the unit with bated breath. Nothing. No LEDs turned on; no sound played. We tried pushing the buttons. Nothing. Val asked if we were sure that the prototype board worked; maybe it wasn’t wired properly? Nope, said Steve, we had tested all that.

Suddenly Val jumped back, exclaiming “I know what it is.” He combed through the stash of yellow-lined paper and finally found the page he was looking for. Scratching something out, and adding a line or two, he shoved the page back in my face and said, “make that change.” I ran to the system, typed in the change, reassembled, and we waited the 10 minutes it took to program a new EPROM. The anticipation once again grew as we anxiously watched the EPROM burn.

Finally, the ROM was done. I grabbed the second chip, plugged it in, and turned on the power. Still nothing. No LEDs turned on; no sound played. We tried pushing the buttons. Nothing.

Once again, Val exclaimed “I know what it is.” He feverishly combed through the stash of yellow lined paper, scratched out another change, shoved the page in my direction, and said “make THAT change, this time it’ll work.” I typed in the change, reassembled, and we waited another 10 minutes for a new EPROM. I plugged the new chip in and turned on the power. Still nothing. No LEDs, no sound, no nothing. You could hear the New Jersey crickets through the open window of the office.

We replayed that same scene over and over again for a few fateful hours, pausing only to put the used EPROMs in the UV light chamber so that they could be cleaned and reused. “Now I’ve got it.” Burn a new ROM. Plug it in, turn it on. Always nothing. Rinse and repeat. It was beginning to feel like “Groundhog Day,” the movie.⁵

During this futile exercise, time slowed down, like I was watching a major car pileup in slow motion. My mind began to wander. I certainly didn’t know how to program a computer, but at this point, I began to wonder why someone would write a computer program in this manner. Wouldn’t it make more sense to try to light one LED (yes, just ONE), before you tried to light 70 LEDs in rapid succession based on a complex physics algorithm reacting to user input? And once you knew you could light one LED, maybe you could try to make the speaker buzz, or test if you could read a button push, or maybe put a number up on the score display? Given the enormity, and complexity, of the task of simulating a pinball machine, was it really advisable to write the entire computer program on paper and expect it to work in one shot? But what did I know?

Back to reality.

Eventually, we all ran out of gas as it was getting really late (both in terms of the earth spinning on its axis, as well as in terms of our asses spinning on a barbecue spit if we failed to deliver on the deadline). Val left for the night, leaving us sufficiently freaked out about the upcoming deadline (emphasis on dead).

Cue the Fat Lady

We convened in the conference room to assess the situation. We had a program, but we no longer had a programmer. We had no idea what was right, or wrong, with the possibly random list of words that I had typed in. We were faced with the prospect of figuring out where the problem was with Val’s code, fix it if possible, and if that wasn’t possible, toss the yellow-lined stack of paper into a bonfire and start over. And we had all of four weeks (28 days) to do it (the deadline for the playable demo). None of us were in a conversational mood as we sat silently in the conference room, staring into the abyss of hell which was our future.

The first question uttered by the group was “does anyone know how to program?” followed by the sound of crickets.

The second question was “does anyone have any ideas?” followed by yet more crickets.

Eventually, I felt the need to toss out the following pearl of wisdom-

“I don’t know how to program, but when I was typing Val’s stuff in, there were things that I saw that I thought didn’t look right.”

In a nanosecond, the team grabbed onto that slightest glimmer of optimism as they bolted for the door.

Sprinting down the hallway and almost out of sight, I heard an echo of “great Garry, why don’t you take a crack at it and see what you can do?” The die had been cast. The savior had been chosen, and it was I.

As I sat there stunned, I was reminded of that age old poker adage — If you’re sitting at a poker table, and you can’t identify which one of the players is the sucker, you’re the sucker.

The first thing I did was start reading what I had typed in. Reading the code (as it was) served two purposes; first, if I found something that was clearly not right, I made a note to figure it out at some later point, and second, in reviewing what was there, I began to get familiar with the instruction set of the microprocessor.

The AMI S2150 assembly language instruction set consisted of about 50 instructions, including basic arithmetic, load and store, and input/output and control functions. The only conditional test was a skip instruction, which skipped the next instruction based on the result of a test. If you used skip followed with a jump instruction, you essentially created a conditional branch. There was only a three-level stack, so while subroutines were available, they weren’t used often. There was no interrupt capability in the processor. Lastly, it was a barn burner in terms of computing speed, running at a brisk 1.8 MHz. [NOTE for non-engineers, that was sarcasm. The processor in the latest iPhone has 6 CPU cores, running at an average speed of 2.99 GHz. That processor is (very) conservatively 12,000 times faster than the S2150, and probably a million times more powerful.]

But there was a bright side. While the S2150 microcontroller certainly wasn’t a “barn burner” in terms of computing power, it was a great platform for me to learn to program on because the instruction set was limited in scope, and simple to understand (At the time, I thought about thanking Parker Brothers for the opportunity to learn how to program but I decided to hold off).

The bigger issue for me was the amount of time I had left on the schedule to #1) learn how to program (period), #2) learn how to program the S2150, and #3) design and write my first commercially released software program.

I would have preferred to start with “HELLO WORLD,” but that wasn’t in the cards.

Fortunately, I wasn’t completely alone. Steve was able to contribute enough time for guidance, tutelage, and questions. He also wrote certain parts of the code to handle aspects of the software/hardware interface; for example, scanning the array of LEDs. The gameplay code was up to me.

Real-time Programming

The type of software program that was needed was what is referred to as real-time programming, meaning that the program would run continuously in a loop, at high speed, repetitively performing a series of tasks many times per second. The tasks formed what was called the “main loop” of the program. For Wildfire, the tasks included checking the buttons for closure, calculating the physics of the ball movement, correlating that ball movement to the lighting of the matrix of LEDs, determining ball collisions (including any resulting sound effects), generating the sounds, calculating and displaying the score, keeping track of the players (up to 4 could play at once, taking turns), etc.

When developing a real-time programming loop, you had to make sure that the code executed fast enough that the program stayed ahead of a user’s reactions. Let me explain with an example. Every time through the loop, the program would test to see if (at that moment), a button was being pressed. If it was not, the program would go on with the rest of the tasks, eventually starting the loop over, and arriving again at the button test. If the time between button tests was a full second (for example), that won’t work. The button could have been pressed after the first test and released before the second test, meaning that the button press would have been missed by the code. And every game player knows that a game that misses the press of a button in the heat of action is begging to be thrown across the room.

The speed of the main loop in Wildfire was 30 times per second. We referred to each one of those passes through the loop as a “frame.” Consequently, there were 30 frames per second, which the program kept track with a frame counter.

With this understanding, I began tackling the tasks that needed to be done.

First, and most obviously, I needed to get my head around a system to control the LEDs, based logically on where they were placed on the circuit board and what their function was. In the next section, I’ll talk about ball movement, but first, I had to learn and document the usage of LEDs on the circuit board that were not ball positions. Those non-ball LEDs had specific uses which I needed to take into account in the program.

The Flippers

Referring to the above, LEDs L61, L62, L63, and L64 represented the upper and lower flippers when activated. Note that when the flippers are not activated, they are represented in the graphic overlay image rather than as a lit LED in the “flipper off” position. This was a cost cutting measure to save 4 LEDs; I’ve seen more than one comment online from players who wished that the flippers were always lit up. Just another example of saving every penny in manufacturing cost.

The Bumpers

LEDs L18, L25 and L29 are lights in the three (3) bumpers at the top half of the playfield. When the ball hits a bumper, a sound effect is made, and the player scores 1,000 points, unless lit, at which point the bumper is worth 3,000 points. The ball then kicks off of the bumper in a random direction, and with increased velocity.

The Knock-Out Targets

LEDs L50, L51 and L52 represent lit knock-out targets which the player can hit with a good shot, turning off the LED. L52, when knocked out, opens up a way for the ball to go back into the firing chute and roll down to the plunger, allowing the player to start the ball over (see L3, L2 and L1 in the left image).

L50 opens up an avenue for the ball to roll into the top arch. If L20 is lit (as shown in the left image), the player earns bonus points for knocking out L50.

Finally, L51 is the target associated with the CAVE. If L34 is lit (inside the cave, see left image), knocking out L51 earns bonus points.

The Ball Movement Routine

I needed to make the ball roll around. To do that, I had to write code that would sequentially light up LEDs in the logical order in which they were placed on the circuit board. In this way, the code would create the illusion of a moving ball. Referring again to Fig. 4, which shows the LED layout, most of the LEDs represent positions of a rolling ball. For example, a ball could come down through the center rollover lane starting at position L19, and take a path down the table directly to the drain using L17, L24, L28, L39, L43, L46, and L84.

If you think about it, no matter how fast the ball moved during play, it could never move to a new position on every frame of the program, as it would be changing positions 30 times per second, certainly too fast to interact with. In fact, for realism, the ball needed to be able to move at different speeds. To accomplish that, I created a variable called the ball counter, and a second variable called ball speed. The ball counter was set to zero at the instant the ball moved to a new position and counted up by 1 each frame it stayed at that position. The ball speed value told the program when to move the ball. For example, if the ball speed was set to 3, the ball would stay at a position on the table for 3 frames, or 1/10th of a second. If the ball speed was set to 30, the ball would stay at a position on the table for 30 frames, or 1 second [note in this example a higher ball speed number translated to a slower speed]. By changing the ball speed value, the code could make the ball move faster or slower. For example, if the ball landed in the kicker (to the left of the lower flippers), and the kicker was lit, the ball shot out at high speed. All the code needed to do when the ball reached the kicker position was to subtract some amount from the ball speed, speeding it up; for example, if the ball rolled in a speed of 6, the code could cut the speed value in half, increasing the ball by 2x.

The ball movement code needed to move the ball realistically, meaning it also had to take gravity into account. When you play the game, you will notice that if you don’t give the “plunger” enough power when launching the ball, it will go up the chute, slow down, stop, and fall back to the plunger position, increasing in speed as it fell. That’s gravity at work.

Flippers

To make the game fun, I had to program the operation of the flippers in a way that felt “right,” while allowing the player to be able to learn how to “aim” their shots off of the flippers. To do this, I devised a method that involved counting the number of frames from the instant that the ball arrived at its “hittable” location next to the flipper to the instant at which the player activated the flipper button. In this way, the direction of the shot was determined based on how fast the player reacted. See the image below and the following explanation.

Consider the lower left flipper, shown above. The ball is moving down and arrives at position 0. The flipper has not yet been activated.

As soon as the ball arrives at the position marked 0, the program starts counting up from 0. If the flipper isn’t activated by 31 counts, the ball is going to drain, down to the right. If the flipper is activated anytime before 30, the ball will be hit, meaning that it will instantly move from position 0 to positions 1, 2, 3 or 4, as explained below. The direction of the hit ball is going to be determined by the value of the count at the moment the flipper hits the ball. If the player hits the flipper very quickly, say count is less than or equal to 7, the ball goes to position #1. If the player hits the flipper at a count of from 8 to 15, the ball goes to position #2, from 16 to 23, position #3, and from 24 to 30, position #4. In this way the player learns to flip early to “pull” the ball in the direction of the rotation of the flipper and flip late to hit the ball away from the rotational movement of the flipper (just like hitting a baseball).

The Event Logic

The game of pinball was all about hitting the ball to a particular point on the playfield in order to make something happen. You could score points by hitting targets and bumpers. You could set up bonuses by having the ball roll through each of the three rollover lanes (at the top). You could score points by landing the ball in the center kick-out hole.

To enable this gameplay, I had to write a system to trigger events, based on what position the ball arrived at, what direction the ball was going when it got there, and other conditions. For example, if the ball arrived at a knock-out target, while moving toward that target, the code needed to turn off the target, make the appropriate sound, and add points to the score. However, the code wouldn’t perform those tasks if, #1) the target was already gone, or #2) the ball was moving away from, rather than moving toward the target.

If you look at the game board, there are dozens of events that need to be sensed, and coded. If the ball hit a bumper, it made a sound, got a score, bounced off in a random direction, and gained a bit of speed. If the ball drained down the middle, in between the lower flippers, the ball ended. If it was the last ball that drained, the game ended. Those are just some examples of the events that my code had to detect and execute.

The sequence of images below gives you a sense of about 10 seconds of gameplay, pointing out some of the event logic that the program needed to handle in real-time.

#1 and #2

Referring to the above images, the sequence picks up the action at #1 (on the left) with the ball at the lower right flipper position. If the player doesn’t activate the flipper immediately, the ball will drain.

At #2, the player activates the right flipper. At that moment, the program has to perform three tasks simultaneously. The program turns on the vertical LED showing the right flipper in its “up” position. At that exact same moment, a flipper sound is played. Also, at the same moment, as the ball has just been hit by the flipper, the ball vacates its previous position and shoots up toward the kick-out hole.

#3 and #4

Again referring to the above images, at #3, as the ball continues in the upward direction, it lands in the kick-out hole, at the center of the table, surrounded by the flame graphic. If the player successfully shoots the ball into the kick-out hole (as they did here), the ball stays in that position for a random period of time, adding points to the player’s score. A sound effect accompanies each score addition.

At #4, after the final count, the ball pops out in a random direction, accompanied by a “pop” sound. In this instance, the ball shoots down toward the lower left flipper.

#5 and #6

At #5, the ball reaches the position of the lower left flipper. As before, if the player doesn’t activate the flipper, the ball with drain.

At #6, the player activates the left flipper. Once again, the program performs three tasks simultaneously, turning on the vertical LED showing the right flipper in its up position, playing the flipper sound, and moving the ball up to its next position, in this position, traveling toward the upper right.

#7 and #8

At #7, as the ball continues in the upper right direction.

At #8, the ball reaches the right knock-out target. Since the ball is traveling with some amount of motion to the right, it hits, and knocks out the right target. At that moment, the program once again has to perform three tasks simultaneously. The program turns off the vertical LED telling the player that they successfully knocked out the target. At that exact moment, a reward sound is played, signifying that the player has hit a target. Also, at the same moment, points are added to the player’s score for the successful hit of the target.

The Postmortem

In the end, believe it or not, we successfully finished the product, and it shipped in 1979. To my knowledge, it was another hit for the Doyles and Wendl Thomis. Good for them, it was a brilliant concept.

While I wouldn’t have wanted to do it over again, a lot of good came out of that 120 days of hell:

• I learned how to write code, and I published my first commercial program. Looking back, ignorance is highly underrated. If I had any idea how difficult the task was that I was trying to do, I could have never pulled it off.
• For the time Val worked with us, he did introduce a new snack to the night shift hours at the lab. Believe it or not, I had never had Doritos, and I quickly became hooked. Unfortunately, when I eat them now, I break into a cold sweat and start writing 4-bit assembly language.
• Wildfire was our (and my) entrance into the electronic toy industry. That, and my newfound love of assembly language, eventually led me on the path to the Atari 2600 and beyond.
• Finally, I can’t say enough about those early years with Steve and Jim. The education and experience that I received there through trial-by-fire was worth more than any PhD I could ever hope to achieve.
• Finally, while I didn’t make any significant money for my heroics, I did get this nifty paperweight from AMI. For in the end, despite my heroics, I was still the guy in the back lab soldering boards, picking up lunch and maintaining a sufficient inventory of M&Ms, Coca Cola, and now Doritos. If you look closely, you can see the S2150 chip floating in space.

Postscript

A few months later, Parker Brothers invited us to pitch electronic toy ideas to them. While our company management was polishing up a number of their very best toy concepts in anticipation of the presentation, I was busy in the back lab hand soldering a new matrix of LEDs and writing a new ball movement algorithm.

On the day of the presentation to Parker Brothers, after hours of concept pitches from our senior management, I got a few minutes to emerge from the lab to present an idea that I had been working on. Using much of the game hardware and software from my work on Wildfire, I had built a rectangular array of LEDs and written a demonstration of electronic billiards.

Without the spit and polish of the management presentations, I brought my in-progress prototype into the conference room. With 6 balls in the rack, I rotated the cue stick, pulled it back (with variable power), and cleared the table while the Parker Brothers’ folks watched with interest.

At the end of a long day of pitches, only one concept had caught the toy company’s attention, and it wasn’t any of the ones from management. Imagine that.

Bank Shot, marketed by Parker Brothers in 1980, was my first toy invention, for which I was awarded U.S. Patent #4346892A.

And to this day, I still do my best work accompanied by an ice cold Coca Cola and a jar of M&Ms. Some things never change.

Footnotes

[1] http://www.datamath.org/Sci/WEDGE/TI-59_Programming.htm

[2] OOP = object-oriented programming is believed by many to be God’s gift to the world of programming. The principles of OOP were pioneered in the 1960s and have advanced (or retreated, depending on your perspective) over the years. While I’m sure the concept was wonderful in its earliest form, I have to admit that I’m not a fan of OOP as it is currently used. I prefer languages that simplify the art of programming, rather than inviting coders to write unreadable programs, obfuscated in a web of encapsulation and polymorphism. Sorry, that’s just me, guilty as charged.

[3] https://www.cpu-world.com/CPUs/S2000/index.html

[4] According to wikichip.org, AMI has eventually renamed AMI Semiconductor (AMIS), and subsequently bought by the Francisco Partners. In March of 2008 it was bought by ON Semiconductor for close to $1B. see https://en.wikichip.org/wiki/american_microsystems

[5] Yeah, yeah, I know, Groundhog Day the movie hadn’t come out yet, as of 1979. But the metaphor was too good to pass up, so I took a little bit of creative license; sue me.