Take the schematic from any first gen ss game, should be pretty straight forward.

Or an Atari pin...

A relay is on/off -- one bit.
Steppers require more bits:
10 needs 4 (2^4=16)
50 needs 6 (2^6=64)
Playfield switches are also bits of state.
It doesn't take a lot of bits to have a lot of unique states.
32 bits > 4 billion
EM wiring is the program that controls what happens for states of interest. Not all states are interesting or possible.

I honestly don't know how many bytes are in the most modern games, let alone what that translates in an EM. But a game like Capersville would probably have the most.

Each relay is one bit. steppers you've got to count the distinct steps up. Don't forget score motor has 5-7 steps to it. Also all the score reels?

I don't think the switches on the playfield should count...

Average single player EM, I'd bet around 50 bits?

Good question.

As mentioned above steppers, including things like score reels, roto targets and vari targets represent a few bits of state each.

Relays and switches though aren't necessarily all individual states. From a software perspective, the switches on a relay are really just copies (or inversions) of the state of the relay. If you had a boolean variable (X) to represent the state of the relay, all of the switches on the relay would represent either (X) or (not X). They wouldn't need their own memory. Many (most?) switches on relays are there to keep circuits electrically isolated, not because they represent something unique. Some relays too are used for electrical purposes and not to represent state. Consider the 10pt relay. It only fires momentarily to replicate the closing of a playfield or motor switch. It's more of a copy than a piece of state.

Motors represent several states of a state machine. Each of the bars in a score motor timing diagram is essentially a state that is true for a brief period while the motor is running. The states are all sequential (they're always in the same order) but they're nonetheless unique.

Playfield features like drop targets and captured balls also represent state.

I bet there's more state too.

This is exactly right. The wiring is the program. When your game isn't working you're essentially debugging the program to find the faulty switch or bad solder joint. They're like typos that crop up spontaneously.

Paging Nick Baldridge!

Probably equal or less than what a 4 bit or 8 bit cpu could do in the 70's.

4 bits 16 values or steps
8 bit 256 values or program steps.

Somewhere in between.
http://www.instructables.com/id/How-to-Build-an-8-Bit-Computer/

MarkG has said it better than I could! The point about relays is particularly poignant - think of what the relay does, let's take a trip relay, for example... as part of a sequence there will be a couple of switches, but each switch is going to do something like light a lamp, notify the next-in-sequence relay that it's ok to fire, etc. Truly that's a single bit. 0/1 on/off.

OK, I promise, very soon, you will see a new thread. And you will see it all. This project was interrupted by life events but I have gone back into it and everything is just about complete. What I can tell you is this: Bon Voyage has just over 300 switches in total. This does not include stepper positions. Note that BV is a single player game, so a 4-player would have a fair number more.

Another complication to counting bits in an EM game is the interlocking relay. These have two relays mounted to the same frame where the armatures mechanically interlock to hold the pair in one position or the other. These two relays together only represent one bit or piece of state. They're essentially a mechanical Set/Reset flip flop that can hold its state indefinitely without consuming any power.

Similar mechanisms that use two coils to hold one bit of state are disappearing posts and zipper flippers. (see funwithpinball.com/small-boards#DisappearingPost for the visuals.)

There are 3 interlocking relays as you describe on the BV: Tilt, Game, and 100,000 Points. They are as you describe, but also, one coil is a Trip and one is a Latch. The Trip just has the mechanical functional of holding or releasing the Latch. So that is one bit. But each Latch also has a number of switches on it in the usual fashion (the number varies depending on functions), so there are actually several more control bits within that as well.

However, the mechanical action wouldn't count as a bit. In a solid state environment, you wouldn't care about the mechanical action of a trip/latch. You still have 0/1 on/off for a trip/latch, and the only thing that matters are the switches involved.

Switches aren't separate bits.

There probably are not exact rules for logically converting an EM to computer logic, so this is only my $0.02. Its an interesting discussion either way.

I would call the action of the Trip relay 1 bit, because something happens to trigger it. It needs to have that control defined. For example, closing a tilt switch causes the tilt trip relay to go. But, there is just one bit there from sort of 2 places - one from the tilt switch and one at the tilt relay. So this may take more thinking to do it all logically.

I see the logic in this, in relation to what I just wrote. I need to think on it some more.

Take for example a 10 point score. The ball hits a rebound switch. That could be called a bit, its normally off and when the ball hits it it closes or turns on. Yes it causes one action which is to activate the 10 point relay. But that relay in turn triggers several actions. These including sounding the 10s chime, advancing the score reel, advancing the match reel and advancing the 100s reel if the 10s score reel is on 9. It seems each of those would be a one-bit action. Each of those is controlled by a switch on the 10-point relay. So would you call each of those switches a bit? Or, call the bit the action at the other end? Either way, I would call that 5 bits of logic. I think.

For those of us old enough to remember...

376E1EFB-900D-4561-9988-25C827ECE97B-10941-000008BB1D5EE01A (resized).png

Alright, let's think about this another way.

Let's take a generic four player game with four reels.

Each reel is comprised of 10 separate states. Each state within the reel is a bit. It is not necessary to calculate the total score, only the state of each reel. 4 bits per reel.
Therefore, the same amount of memory would be used for 9999 as it would be for 0001. Calculating the total score is a heckuva lot easier than tracking multiple states.

We also have a player unit - four separate states. If a two player, you could use a signaling bit to represent the player, but things have to be complex here and use a total of 2 bits to track the player up. Each score needs the 2 bits added to provide the player info in memory.

And a coin unit - how many players even matter? Another 2 bits.

Now, a bonus unit - let's say 10 positions. Well, that's 4 bits.

A credit unit - single bit - 1/0 for if you have them or not.

Next, individual state switches (that matter to the overall state of the game). There are a handful or two. Tilt, Sequence, Outhole, Lane or qualifying switch, and independent scoring switches (one per value). Treating each of these as ones/zeroes makes these all single bits.

As score is never subtracted, there's no need for a signing bit.

This is on a flipper game. Simple creatures, really.

Now, let's look at a bingo pinball machine...

You have some of the above.

Credit unit (replay register) - single bit
Tilt trip - single bit
Playfield switches 1-25 - each a single bit and each distinct.
Ball gate switch - another bit
Shooter lane switch - another bit
5 or more trough switches - one bit per.

Now we get into the meat of the matter: moving numbers and other incredibly complex EM calculations:

Score unit - 4 bits per color (the most popular games had three). 12 bits
Replay counter - depending on the number of steps - many had dozens and dozens. Let's give it a full 8 bits. Multiply by the number of colors.

Let's use the Magic Screen, as it's a popular feature.

There are a total of 13 positions in the most popular games. Well, you need 4 bits for the screen state.

In brief: Winners are scored based on number of balls in particular holes within each position.

During a winner search, different sets of logic are used in EM to determine if you have a winner. A counter is implemented to see the number of balls you have in each colored section. Otherwise, scoring is based on contiguous position of balls on the bingo card.

So you'll need a count. Let's say you can recycle this counter, since you definitely can, and that's how it works mechanically. Since the max number you will ever need in a Magic Screen game is 5, let's use that. 3 bits.

Then, you need some way to end the game. If you don't have a winner, but didn't tilt, how does the game know it's done? Mechanically, there's a timer involved. Let's implement that bitwise. 40 steps providing 6 bits. Of course, there's easier ways to handle this in purely solid state.

Then you have various trip relays. Let's say one of them spots a number on the playfield? Well, you have the state of the trip relay, and you have the state of the playfield hole. Every playfield hole would need an OR operation performed...

It gets complicated.

I have had to think about this, and recently. I implemented all 138 bingos produced (or not!) in the US in a single solid-state game. https://pinside.com/pinball/forum/topic/multi-bingo-machine. I used a much higher-level language, so didn't need to really think on 'bitness' too much. But, I did have to think about things like Steppers, Motors, Relays, etc. All of these boil down to either one bit or a few depending on the number of -unique- positions.

The action of the relay tripping is triggered by a combination of other state bits. Since it's dependant on those, and can be expressed as just a logical combination of various other relay states, I'd argue it isn't a bit

I think in general, each coil ends up being a bit. So the chime and the reel being energized is each one 'output' bit? However, the chime has no other logic to it. Whenever that relay energizes, the chime does too, so is that really a separate bit? Similarly for the reel, it only energizes when the score or reset relay energizes. In fact, I might even argue that any plain relay that doesn't hold itself in isn't in fact a bit, they're just there due to the mechanical limitations of the number of switches you can fit in a stack. So the 500 point relay is a bit, but the match unit relay isn't?

Of course, there's no real right answer here, but...

All of these posts are great, this is a somewhat interesting exercise. Not sure it matters for much or if many people care, but still, its interesting to me.

When I was going through the BV schematic, as I was writing out the descriptions of all of the circuits, or subcircuits if you will, I also thought that this could be supplemented with a series of logic diagrams, or flowchart-style diagrams, to show a bigger-picture view of the logic flow. But that would take even more work to put together, and I put a LOT of work into this project. Its not all that hard to figure everything out and write it down, but getting the supplemental graphics put together to go with it takes more work.

State elements (or bits) typically reflect something that has happened in the past, but you can't know when just by looking at other state. A drop target, trip relay or any relay with a hold circuit for example triggers on an event, and holds that information indefinitely. You know something happened but don't know when it happened because whatever caused it has changed. That's state.

Stuff that can be derived from other state is more a control signal, or sequential logic, than state. A chime doesn't really hold state because it only fires when some other switches close in the right combination.

Many more control signals (like firing the chime) can be generated from a set of state bits because the state bits can be used in combinations. So for example the four state bits that represent the score shown on a score reel could generate 16 unique control signals (the score is 0, the score is 1, the score is 2, etc...). That's not really state information though since they're all derived from the same four state bits. You could have state bit for each of those 16 control signals, but that generally isn't done since the same information can be contained in four state elements rather than 16.

If you use this definition then things like playfield switches aren't really state since they don't hold information beyond the time when they're active. Playfield switches, flipper buttons, coin mechs, etc. are more like inputs to the program or state machine of the EM game. Similarly, chimes, lights, scores etc. are the outputs, along with the adrenaline, emotion and generally good vibe that probably belong in another discussion.

Here is another take on it. A typical switch on a pinball schematic we view as NC or NO. In an assumed default condition, such as "game started then power shut off" then we have a defined off or on state for all of the switches. Is that not the very definition of a bit? 0 or 1?

Of course you also have those pesky MBB switches. Those would break down to 2 bits maybe.

Right the 10 point chime isn't a bit, it's just a solenoid that does something. But the switch mounted on the 10 point relay controls it. If it's open there is no chime. When it closes there is a chime. 1 bit of control logic?

Another NO switch on the 10 point relay causes another action. That is to advance the 10s score reel. Another logic bit?

It's semi-true that there is no state awareness for the score reel. The system doesn't track or know if it is on 2, or 5, or 7 for example. However, it does know if it is on 9, or "not 9" via switch mounted on the score reel. That is another bit of logic used to determine if the 100s reel is going to get a pulse also.

I've had too much coffee...

Except that the relay itself is the control, and it can do multiple things based on that 1 bit state. Define a function that checks the value of that state (of the 10 pt relay) and perform an action. No additional storage is required.

Depends on the game and what it's doing - but yes, for most games, that's correct. I was conflating displaying a score with handling a specific score.

0/9/other three states per reel that are needed. Matching reels require more.

So how many bytes in the average bingo game?

A bunch.

The number of bytes is more complex. Do we assume 8 bit?

I'm up over 100 bits in a count in my head for a magic screen game without factoring in the mixers or reflex. With them, we're looking at something more in the range of 130-140 depending on the game. Then you have the control unit which is essentially a single bit for the alternator.

Between 130-150 is a safe estimate on bit-ness. Assuming 8 bit bytes, something around 16.25.

But that would essentially be garbage. Some of the states can be combined into bytes. Some cannot.

Now, if we were factoring a single bit per active switch on a motor, as has been noted above, that number increases exponentially. But the reality is that the rotation of the motor can be factored down to - is the motor moving? Then this will happen. Is it in X or Y coin cycle? This will happen.

A typical flipper game, using my (probably faulty) math above, would be more in the realm of 35-50 bits... give or take. Depends on the game, obviously.

Again, I'm factoring out the motors as they are a means-to-an-end. I guess you could add a x5 pulse bit. 36-51.

I think there is some confusion between state and the program logic of the EM as represented by wiring and switches.
To replicate an EM machine's behaviour requires state and logic -- both of which would take up bits in a computer.
Another way to think about it: state you store in RAM; the logic (program) can be stored in ROM.

I am discounting the logic in my counts. Logic would inflate those counts immensely.

It is confusing since there's no good direct correlation between bits/bytes and signals and state. Another way to distinguish between state (that requires memory or storage) and signals (that don't necessarily) is what you would need to save if you wanted to turn the game off in the middle of a game and restore it to the same place later on.

You could write down the position of every single switch, relay, stepper, target, etc. and then turn off the game. In theory you could then turn the game on and put every single switch, relay, stepper, target, etc. back in its place and you would have restored the game to the same place.

But as it turns out, most of what you wrote down isn't really necessary. You should be able to write down just the state of the steppers, some of the relays, drop targets, etc. and shut off the game. Then, when you turn the game back on, as you restore the steppers and relays to their saved state, the wiring, or program of the game, will figure out the values of all the other signals (switches and such) that you didn't write down.

And yeah, no contest. Bingos have to do way more math than EM games. There's more state, more signals, more program, more of just about everything.

I've been just thinking memory.

For logic, it's going to depend on what architecture of cpu you're talking

Each switch can be though of as an AND, OR, or NOT. How many bytes do those take up in the target architecture? I think that question may be beyond answering though. State can at least be quantified like MarkG says. Maybe you could liken each switch to a single transistor and compare transistor counts?

Maybe a better way to quantify it would be to think about the game in terms of lines of code. The state elements would be the minimum number of variables you need to keep track of things and the wires and switches represent assignments or equations in the program. There's actually a very close correlation between the switches that control the relays and Boolean logic equations. Switches in series represent terms that are ANDed together; switches in parallel represent terms that are ORed together. From there most everything can be thought of as a Boolean equation:

Add_100_points = (100_point_target_hit) OR ((10_point_relay_fires AND 10s_score_reel_is_9));

In this case Add_100_points wouldn't need to be a state bit since it can be derived from other signals and state.

Well, you could look at the rom files for an early SS that has an EM version. I think all the EM equivilant Hot Tip code is probably between 500B and 1KB.

I think ROMs typically include everything the game needs including the (assembly language) code for the game rules and interrupts, bookkeeping functions, diagnostics, configurations, attract modes etc. Some small number of kbytes is probably about right for an EM.

The 50-200 bits discussed earlier would only cover the state bits described in this thread, not all the code.

The ROM files are always the full size of the chip, even if not all of it is used. Hot Tip has three 2KB files but most of that is os stuff for bookkeeping, tests, etc. Only one of those three is the game ROM, and last time I looked at it I think it was less than 1/4 full