PDA

View Full Version : BYO Pinball Interface/Output Boards



dmworking247
10th October 2008, 11:40 PM
I can see this particular topic is going to warrant a lot of discussion, so I'm breaking it out into its own thread:


The output driver board for the high power devices was sourced from a run of boards designed to be used with pinmame emulating a CPU for a game where that CPU was no longer available. The project seems to have completely disappeared, and we managed to secure the last two of the driver boards. Having said that, there was a design error in the board and it would have been problematic but for nuggy's insight into the issue. Reproducing something similar (without the fault!) is not out of the question at all, just a bit of cost to have a very small run made. We haven't priced anything at all at this stage as we've got one each and it was always the intention that we were each going to make our "dream game" (I can't mention the theme of the next game which will remain hidden until completion, although the development will be public just like CI, just keeping the toys and artwork for the actual release), so there has not been any pressing need to think about making a board.

My brother in law (an electronics engineer) seems to think he could knock something up easily, and there has been discussion on RGP of some readily available devices that might be able to be adapted to the job as well. Nuggy might be able to pipe in tomorrow if he remembers to turn his PC on...

Interesting. Did you manage to source a circuit diagram of the original driver board? That, and Nuggys experience of the design error and any necessary enhancements would make it a lot easier to have reproduced than doing it from scratch.

Failing that, where would we find an 'plain english' description of what the board actually did and how it did it?

David, if an original circuit diagram was available, is pricing reproductions/design enhancements something in your domain?

David_AVD
11th October 2008, 12:15 PM
David, if an original circuit diagram was available, is pricing reproductions/design enhancements something in your domain?

Yes, that's right up my alley.

David_AVD
12th October 2008, 07:46 AM
I've been mulling it over some more (and talking with another AA member) and was thinking the output boards could be implemented as so:

A PC interface board. This board has the USB / serial / whatever PC connection and a small micro on it. It communicates to the PC, decodes the output commands and sends that raw data to one or more driver boards. It may or may not have functions for effects built in.

The driver board does the hard work of firing the solenoids. It just takes the raw data from the first board has almost no smarts on it. The only smart thing it does is disable all outputs if it looses contact with the interface board and maybe give an indication of any gross faults.

Different driver boards could be made to cater for LEDs, larger lamps, solenoids, etc and all looped from the interface board. Each driver board could have 16 outputs. (data works best in multiples of 8) This way, people could use whatever combination of driver boards they need.

Having the interface board separate would mean that changes in the interface connection type (serial, parallel, USB) over time (or for different O/S's) would not affect the driver board designs.

I'm also thinking that optical isolation on the solenoid driver boards would be good and allow for use on systems where the solenoid power does not share a common ground with the logic, etc. Ground loops and high current do not make for a happy story so this may be essential IMO.

So, that's where I'm at so far. I welcome comments and suggestions as this solution could be used for other pinball / arcade projects too.

Nug
12th October 2008, 05:22 PM
:unsure
I've been mulling it over some more (and talking with another AA member) and was thinking the output boards could be implemented as so:

A PC interface board. This board has the USB / serial / whatever PC connection and a small micro on it. It communicates to the PC, decodes the output commands and sends that raw data to one or more driver boards. It may or may not have functions for effects built in.

The driver board does the hard work of firing the solenoids. It just takes the raw data from the first board has almost no smarts on it. The only smart thing it does is disable all outputs if it looses contact with the interface board and maybe give an indication of any gross faults.

Different driver boards could be made to cater for LEDs, larger lamps, solenoids, etc and all looped from the interface board. Each driver board could have 16 outputs. (data works best in multiples of 8) This way, people could use whatever ombination of driver boards they need.

Having the interface board separate would mean that changes in the interface connection type (serial, parallel, USB) over time (or for different O/S's) would not affect the driver board designs.

I'm also thinking that optical isolation on the solenoid driver boards would be good and allow for use on systems where the solenoid power does not share a common ground with the logic, etc. Ground loops and high current do not make for a happy story so this may be essential IMO.

So, that's where I'm at so far. I welcome comments and suggestions as this solution could be used for other pinball / arcade projects too.

thats an absolute shite load of boards there!!! noise, wiring complexity,expense $$, limitation of non programmable (pergame) special effects, protocol will be a nightmare or are you going to handshake with these/this board ?!!
i dunno :unsure


home guys got to be able to do it like he can fit mags or boost controllers etc, capable people but not needing a masters degree? maybe i missed the fundamental point ?

logistical (board count, interconnect,noise/psu requirements/supply splitting, back box space (!!!) etc) issues imo

David_AVD
12th October 2008, 05:47 PM
thats an absolute shite load of boards there!!! noise, wiring complexity,expense $$, limitation of non programmable (pergame) special effects, protocol will be a nightmare or are you going to handshake with these/this board ?!!

Shiteload? It's one USB interface and a small board per 8 or 16 solenoid outputs. Maybe the lamp board could have more outputs.
Wiring complexity? Each board loops to the next with a short 10 way ribbon.
Expense? I think it will be quite reasonable due to the modular design.
No special effects per game? Isn't that handled by the PC anyway?
Protocol? Serial (38400 baud?) over USB should be plenty fast enough.


home guys got to be able to do it like he can fit mags or boost controllers etc, capable people but not needing a masters degree? maybe i missed the fundamental point ?

A custom pinball is not a project for the masses. It will require ability. It's not in the same league as making a mame or 48-in-1 cab. Comparing it to fitting mags is just silly.



logistical (board count, interconnect,noise/psu requirements/supply splitting, back box space (!!!) etc) issues imo

Interconnects? Boards link via cheap crimped ribbon.
Noise issues? If you mean electrical noise, good design should take care of that.
PSU requirements? No different to any existing pinball machines.

I expect the boards to be quite compact so I doubt space will be an issue. The solenoid boards could be mounted under the playfield if you really wanted to.

tnpshow
12th October 2008, 08:09 PM
You guys have the technical side of things brewing here, so I won't interfere, but I will mention that I'm a PCB designer for a PCB manufacturer here in Adelaide.

I will be able to get some nice deals on bare PCBs when the time comes and perhaps a complementary run of prototypes...

Nug
13th October 2008, 06:55 AM
i have proposed a 1 boards solution, you have said/8/16 outputs per board, let me see, thats at least 2 X8's for solenoid control (and thats system 1 style ability!!) and at least 4 X8's for 32 lamps, hardly a comprehensive array of outputs for already 6X boards including master i presume(?), ribbon and loom (multiples of) do not make for an easy layout :unsure

lets not forget that there will need to be transistor upgrades for hi current stuff then the seperate looming to each of those "boards" !!!!
**** off,

that is going backwards and are you going to have seperate mcu's on each board as stated ?! then that is mega expensive compared too, so no worries you go make the world as complicated as you like, i prefer the fundamentally sound and obviously cheaper 'kiss' principle.... :lol

kiss my ass ! :D

[


A custom pinball is not a project for the masses. It will require ability. It's not in the same league as making a mame or 48-in-1 cab. Comparing it to fitting mags is just silly.

I beg to differ, it is not hard as per se, it requires technical organisation, something most are capable off :(

I expect the boards to be quite compact so I doubt space will be an issue. The solenoid boards could be mounted under the playfield if you really wanted to.[/QUOTE]


thats is poor mechanical engineering form right there, fine for prototype, no good long term.

David_AVD
13th October 2008, 07:09 AM
Each driver board is simple. It has no mcu, just shift registers and driver bits. I don't know where you read that each has an mcu. The whole idea of this driver board system is that it's mix and match to some extent.

The solenoid driver board has 16 outputs. It should drive any pinball solenoid. It's only about 3" x 4" so quite compact. No transistor upgrades should be needed as the logic FETs I've chosen are good for 14A. There's a slightly more expensive one that's good for 28A continuous.

The lamp board will be an 8 x 8 matrix. (64 lamps) Depending on how the PC interface board design goes it may be driven from a different port. At the moment it's being designed with the same input as the solenoid board.

Mounting the driver boards under the playfield is not necessarily a bad thing. It depends on a lot of factors but yes, first choice would be the back board area.

AskJacob
13th October 2008, 08:40 AM
If this is the style of board you are using nuggy:

http://membres.lycos.fr/regismalt/PCtoPinballinterfaceSchematics.gif

Then what David is suggesting is a very similar design, but with the option of a USB interface. There are no smarts on the pinmame HW board. The smarts David is proposing for the controller boards is primarily to handle the USB protocol. Some bonus features (with having a small controller on board) that may become part of the design could be a watchdog timer to prevent locked/burnt coils/flashers in case the host machine crashes...

If people don't want a PC running their pinball, then a small MCU could easily talk via high speed serial to the controller board, skipping the USB interface components.

If the high speed serial interface is a concern for reaction speed e.g. bumpers (not sure how fast these need to react!) then like the early days of SS machines they could be reflexive (switch themselves directly, but register a hit to the pinball controller).

Its all interesting to me...

Cheers
Jacob

stuba
13th October 2008, 08:43 AM
ummm (preparing to be shot down and flayed). do you need to build the highway to get from A to B? is it possible to just borrow a car and use an existing road?

I always thought a good way to tackle this is use an existing pinball driver board - like a pinled 'williams' 90's board. it would handle all of your driver and power management (you can just use an existing pinball transformer). all you got to do is talk to it with your own instruction set. given there is bench test equipment for these boards then the 5v logic that drives it would just become output from your controller (PC, micro-controller etc). :unsure HUO means no copyright issues..

your 'inputs' are direct to your controller anyway, if using a PC as the brain then it would be handling display and sound anyway. just a thought :unsure kill me quickly if need be. :tomato

AskJacob
13th October 2008, 08:48 AM
ummm (preparing to be shot down and flayed). do you need to build the highway to get from A to B? is it possible to just borrow a car and use an existing road?

I always thought a good way to tackle this is use an existing pinball driver board - like a pinled 'williams' 90's board. it would handle all of your driver and power management (you can just use an existing pinball transformer). all you got to do is talk to it with your own instruction set. given there is bench test equipment for these boards then the 5v logic that drives it would just become output from your controller (PC, micro-controller etc). :unsure HUO means no copyright issues..

your 'inputs' are direct to your controller anyway, if using a PC as the brain then it would be handling display and sound anyway. just a thought :unsure kill me quickly if need be. :tomato

The interface between the williams MCU and the driver board is pretty complex compared to the proposed design or the controller I think nuggy is using.... The replacement designs are not very complex, nor should they be very expensive. While HUO is the intent for now, what happens if other people want to play with one?

Nug
13th October 2008, 05:16 PM
i modded the board so the last lamp output is used to toggle the watchdog so as to avoid the lockon due to crash :D
is done as simply and still no usb interface! (i disenable the board, not reset the PC but)

David_AVD
13th October 2008, 07:02 PM
i modded the board so the last lamp output is used to toggle the watchdog so as to avoid the lockon due to crash

Can you elaborate on this please? I don't follow what you mean. Thanks.

David_AVD
13th October 2008, 10:07 PM
OK, here's something else to think about. There are two ways to drive the lamps:

1: Matrix (say 8 x 8)

Pro: Simpler and smaller PCB design
Pro: Less wires from lamp area to PCB
Con: One diode required on every lamp base
Con: Matrices can be confusing to wire and debug
Con: Wiring needs to be thicker


2: Dedicated output per lamp (say 64 outputs)

Pro: No diodes required
Pro: Easy to route wiring to individual lamps
Pro: No issues with flicker due to speed of data updates
Pro: No issues with blown lamps if a row or column gets stuck on
Pro: Wiring can be thinner (offsets more wires to some extent)
Con: Larger PCB design (biggest part is the connectors)
Con: More wires from lamp area to PCB


I'm leaning towards solution number two now, as I can see how a matrix would really confuse a lot of people in both the building and trouble shooting stages. Can I get some feedback on this please?

Nug
14th October 2008, 02:09 PM
im considering giving my system away or open sourcing to a certain degree, i cant believe you gonna go and reinvent the wheel...

can someone, nerdy or other, tell me what is wrong with the way ive implemented the driver solution?

david, its a watchdog, these need to be toggled otherwise the 'dog' is not watching, it is toggled on the last lamp drive, there is no transistor for that particular output, clearer?

oh now i think i know what u mean.. there is a defeat on startup until system is booted

AskJacob
14th October 2008, 02:41 PM
can someone, nerdy or other, tell me what is wrong with the way ive implemented the driver solution?


Absolutely nothing! As you have proved, what you are doing is fine, and is works in the real world already.

I realise you need to work out just how you are going to go about releasing your NPC, and I doubt this project in any way is meant to pressure you into releasing or doing anything you are not ready to do...

Nothing wrong with another one out there. I don't think it is re-inventing the wheel, just 2 choices of tread pattern :)

Personally, my only minor concern is if your current board relies on a printer port connection - that the computer industry seems to have dropped them and considers them obsolete. (which worries me on several fronts, as I have programmers and other items that need it too!).

Cheers,
Jacob

David_AVD
14th October 2008, 03:10 PM
david, its a watchdog, these need to be toggled otherwise the 'dog' is not watching, it is toggled on the last lamp drive, there is no transistor for that particular output, clearer?

Yes, I understand what it does but I was wanting to know how it does it! :)

What circuitry is connected to the wdt lamp output and how does it disable all of the other outputs?

Also, how do you bootstrap it seeing the wdt output is one of the outputs you keep disabled until the pc is booted? I must be missing something. :unsure

Nug
14th October 2008, 04:32 PM
Yes, I understand what it does but I was wanting to know how it does it! :)

i thought you would know?

What circuitry is connected to the wdt lamp output and how does it disable all of the other outputs?

via the output enable pin on the latches (i thought you would know this too when i mentioned i 'disenable' !

Also, how do you bootstrap it seeing the wdt output is one of the outputs you keep disabled until the pc is booted? I must be missing something. :unsure

indeed this is done on two fronts and i suppose is....unconventional in implementation!
think about it somemore :)

PS im using a 555 :D

David_AVD
14th October 2008, 04:35 PM
indeed this is done on two fronts and i suppose is....unconventional in implementation!
think about it some more :)

PS im using a 555 :D

OK, so that means you don't want to tell us. I understand and will prod you no more.

Nug
14th October 2008, 04:38 PM
Yes, I understand what it does but I was wanting to know how it does it! :)

i thought you would know?

What circuitry is connected to the wdt lamp output and how does it disable all of the other outputs?

via the output enable pin on the latches (i thought you would know this too when i mentioned i 'disenable' !

Also, how do you bootstrap it seeing the wdt output is one of the outputs you keep disabled until the pc is booted? I must be missing something. :unsure

indeed this is done on two fronts and i suppose is....unconventional in implementation!
think about it somemore :)

PS im using a 555 :D

NO! i do not use it as a startup timer either!!!!
but this would work also !
:D

regards

Nug
14th October 2008, 05:19 PM
aw david... was little bit of technical fun...the 555 is the watchdog. the board and thus 'outputs are all we need to 'protect' so :
a) we are disabled on startup via port staus on said start up
b) the watchdog is too! (very largish hint here!!!)
c) once running the enableing includes the watchdog as a self running entity
- this will drive outputs low after 1 sec inactivity on wdt (lamp96!)
d)because npc software enables the driver board...it is also toggling wdt enable
e)board runs as per normal with 25 fps update at least to wdt/clk


other stuff we can do:
we can poll for watchdog via switch matrix?!
we could clear faults/set flags if determinate?! (and reset wdt?!)
we can have the coil power fuse monitored and a myriad of others (lets 'OR' a couple up as inputs(inhibit!!) to wdt?!

no need to take your bat home yet david :confused:

askjacob: indeed its a crock my good friend, the parallel port is the most direct method of controlling peripherals of this nature ,bar the 6822's X6 hanging off the bus or a dsp equivelent (wpc asic anyone?!)

luckily for ourselves an npc runs off a P2 running @ 400 mhz! plenty off parallel ports to go around yet (grab a couple of PIII all in one mobo's!!!:D)

regards

nug

David_AVD
14th October 2008, 05:31 PM
OK, here's something else to think about. There are two ways to drive the lamps:

1: Matrix (say 8 x 8)
2: Dedicated output per lamp (say 64 outputs)

I'm leaning towards solution number two now, as I can see how a matrix would really confuse a lot of people in both the building and trouble shooting stages. Can I get some feedback on this please?

:bump:

Nug
14th October 2008, 05:37 PM
aw david... was little bit of technical fun...the 555 is the watchdog. the board and thus 'outputs are all we need to 'protect' so :
a) we are disabled on startup via port staus on said start up
b) the watchdog is too! (very largish hint here!!!)
c) once running the enableing includes the watchdog as a self running entity
- this will drive outputs low after 1 sec inactivity on wdt (lamp96!)
d)because npc software enables the driver board...it is also toggling wdt enable
e)board runs as per normal with 25 fps update at least to wdt/clk


other stuff we can do:
we can poll for watchdog via switch matrix?!
we could clear faults/set flags if determinate?! (and reset wdt?!)
we can have the coil power fuse monitored and a myriad of others (lets 'OR' a couple up as inputs(inhibit!!) to wdt?!

no need to take your bat home yet david :confused:

askjacob: indeed its a crock my good friend, the parallel port is the most direct method of controlling peripherals of this nature ,bar the 6822's X6 hanging off the bus or a dsp equivelent (wpc asic anyone?!)

luckily for ourselves an npc runs off a P2 running @ 400 mhz! plenty off parallel ports to go around yet (grab a couple of PIII all in one mobo's!!!:D)

regards

nug

didnt like the answer? :unsure

pinnies4me
14th October 2008, 07:31 PM
a) we are disabled on startup via port staus on said start up
b) the watchdog is too! (very largish hint here!!!)
c) once running the enableing includes the watchdog as a self running entity
- this will drive outputs low after 1 sec inactivity on wdt (lamp96!)
d)because npc software enables the driver board...it is also toggling wdt enable
e)board runs as per normal with 25 fps update at least to wdt/clk

other stuff we can do:
we can poll for watchdog via switch matrix?!
we could clear faults/set flags if determinate?! (and reset wdt?!)
we can have the coil power fuse monitored and a myriad of others (lets 'OR' a couple up as inputs(inhibit!!) to wdt?!


I love it when you talk dirty! :cool:

David_AVD
14th October 2008, 07:44 PM
didnt like the answer? :unsure

Nuggy, this is getting silly. I asked about the watchdog and you gave your answer.

I must admit I didn't understand everything in your watchdog description but I'm certainly not disagreeing with it. It obviously works in your application.

I then bumped my post asking about the matrix vs individual lamp drives. How did you take that to mean I didn't like your answer? :unsure

Sure I'd like to go a different route, but when did this project become an opposition to you? Dale has done some fantastic projects and I'd like to be part of this one.

Is it such a problem for you (or anyone here) that I don't want to use the same hardware design as you? If Dale decides he doesn't want to go with my designs that that's ok too. I'm not ramming mine down anyone's throat! :rolleyes

David_AVD
14th October 2008, 08:22 PM
I always thought a good way to tackle this is use an existing pinball driver board - like a pinled 'williams' 90's board.

I think it's best to stay away from copying a commercial product. Even selling bare PCB's would be a copyright violation if it was a direct copy. Things progress and there's bound to be more appropriate solutions and parts these days.

Nug
15th October 2008, 09:05 AM
i want to take this opportunity to apologise unreservedly to david and anyone else i may have offended recently.

its all good david, i wish you the best with your endeavours.

:)

regards
Christian (nug)

David_AVD
15th October 2008, 09:18 AM
i want to take this opportunity to apologise unreservedly to david and anyone else i may have offended recently.

its all good david, i wish you the best with your endeavours.

:)

regards
Christian (nug)

It's all good. There's room on AA for everyone and lots of homebrew projects! :lol

spacies
15th October 2008, 09:22 AM
I dont know how complicated Dale wants this machine but I think David you are on the right track. I don't think you are reinventing the wheel as said earlier. Obviously there are many ways this could be done and coming up with something different is always going to attract attention. Keep focused mate.

Dale, I suggest you get stuck in with the playfield design and features etc to determine what is going to be needed as in terms of what, and how far, David and co needs to go with the PCB design and control system.

spot
15th October 2008, 09:37 AM
i agree spacies - a modular expandable design (which i think the gist of david's design) would be required for any homebrew pinball.

while being a little complicated, the main focus of the punter at home, will be the design of the playfield and sounds/ gfx etc.

the bulk of hard work needs to come via good design and usability.

i know i have a little knowledge in most computer/ electronics/ woodworking - but i would like the technical hard yards done for me,
so i can get down to choosing a theme and designing my machine.

i know this isn't aiming to be a commercial project - but more of a niche hobbist pursuit.
but a measure of professionalism/ commercialism is needed to produce a high end product that will encourage people to use the system.

and if people want to use it - the numbers should help offset the costs of small production runs.

i wish everyone participating in this venture good luck,
because i want a fkn Transformers Pinball goddamnit!!

AskJacob
15th October 2008, 09:56 AM
because i want a fkn Transformers Pinball goddamnit!!

good theme!

Oh, and on track:

I vote non-matrixed. Less fuss for wiring, and easier to wrap your head around. If you can wire up a control panel, you can wire up the feature lights. Some other technical benefits include no strobing lines which makes calculating resistor values for LEDs much easier (or can punch 12v directly, and use coloured LEDs that are flooding the after market car part places).

Cheers
Jacob

spacies
15th October 2008, 10:06 AM
good theme!

Oh, and on track:

I vote non-matrixed. Less fuss for wiring, and easier to wrap your head around. If you can wire up a control panel, you can wire up the feature lights. Some other technical benefits include no strobing lines which makes calculating resistor values for LEDs much easier (or can punch 12v directly, and use coloured LEDs that are flooding the after market car part places).

Cheers
Jacob

Yes it is a good theme but see my post in the original ideas thread.

Good thinking about the LEDs Jacob. There certainly a shiteload of options out there now.

TheYellowDart
15th October 2008, 09:27 PM
I tend to think David's idea of a modular PCB design is more appropriate here. With a modular design you have less technical restrictions placed upon your eventual designs. Design the table, allocate your switches and outputs, then mix and match the boards to meet your requirements. This seems to me to be a far better solution than an all-in-one board that restricts you to a fixed number of inputs/outputs and that isn't expandable.

In regards to input/output matrices, while the utilisation of them would introduce component cost savings and less physical wiring I think that homebrew users would find it easier to deal with dedicated input/output wiring as well as negating possible issues with large amounts of inputs/outputs being triggered at once (eg. ghosting with matrix based keyboard encoders).

Keep up the discussion guys, I'm enjoying this thread.

David_AVD
15th October 2008, 09:50 PM
In regards to input/output matrices, while the utilisation of them would introduce component cost savings and less physical wiring I think that homebrew users would find it easier to deal with dedicated input/output wiring as well as negating possible issues with large amounts of inputs/outputs being triggered at once (eg. ghosting with matrix based keyboard encoders).

A switch matrix with no ghosting is easy to do as long as you put a diode in series with every switch. That said, I think a dedicated input per switch will be much easier for the homebrew crowd to follow. No diodes to add (and screw up the orientation) and easy to trace wiring. Just like an ipac or keywiz. Maybe just use one of those anyway?

stuba
16th October 2008, 09:08 AM
I now understand that you guys are aiming at something replicable so it can be used in other similar projects as opposed to a one-off solution. on that basis dedicated switch and lamp wiring much easier than a matrix as per jacobs comments. its a good approach because it could provide a generic plug and play solution for all home brewers. notwithstanding nuggy's solution and what he decides to do with it which will achieve the same aim (i think) - but don't know how generic/plug and play the NPC is :unsure regardless of the flavour its good to have solutions and options. :)

AskJacob
16th October 2008, 09:16 AM
Next question for the IO boards:

Coil diodes (back emf suppression) on the driver PCB, or on the coil?

On the PCB means:

No diodes under the playfield to vibrate off the coils
No need to worry about putting a diode the right way round on a coil, just wire it up

On the coil means:

Like Williams used to do. Not 100% sure why they persisted when others put them on the driver board, but may have had something to do with passing FCC regs (as the wiring back to a PCB with diodes could act as an antenna)

Cheers
Jacob

stuba
16th October 2008, 11:05 AM
Next question for the IO boards:

Coil diodes (back emf suppression) on the driver PCB, or on the coil?

On the PCB means:

No diodes under the playfield to vibrate off the coils
No need to worry about putting a diode the right way round on a coil, just wire it up

On the coil means:

Like Williams used to do. Not 100% sure why they persisted when others put them on the driver board, but may have had something to do with passing FCC regs (as the wiring back to a PCB with diodes could act as an antenna)

Cheers
Jacob

on the board definitely, if the solution is provide generic plug and play then the punter shouldn't have to worry about soldering diodes to coils.

David_AVD
16th October 2008, 12:36 PM
Next question for the IO boards:

Coil diodes (back emf suppression) on the driver PCB, or on the coil?


Electrically, the best place for them is on the coils. This is to prevent the back emf radiating from the wiring and also possibly glitching the switch inputs. It's the same reason DC motors have the capacitor (and sometimes two inductors) right on the motor terminals. You really want to stop the noise at the source.

That said, in reality I am putting them on the board. No harm will be done by having them in both places if people choose to fir them to the coils. The diodes also protect the driver transistors from the large back emf spike when the coil is switched off.

White_Spot?
11th April 2009, 02:32 AM
Hi guys, i?m new in this forum and i discover this because i?m owning a America 1492 (http://www.ipdb.org/machine.cgi?id=5013) from Juegos Populares (Spain) with no boards (i have only power and display board).
Searching the entire web to find a solution to turn alive this pin leave-me to this "project" and others similar.
So my question is, this project are dead / discontinued (like the other i find) or were i can find more information?
My knowledge in this matters are quite few but i have no problem in put my head at work :redface if this is the unique way to "repair" my pin.
Thanks and sorry for my poor English.

David_AVD
11th April 2009, 08:11 AM
This project is a long term one. I've done some PCB designs for it already. I suspect it will get rolling again later this year when we all get some free time! In the meantime, feel free to contribute to the thread as discussion is good. :)

White_Spot?
16th April 2009, 07:35 AM
I?m reading the blog of pohos and is text are quite simples to understand all the concept of a project like this. In the same time im reading others sites with information of pinmame-hw to know what i need before jump in this project.

Ill try to put some info?s for my project (how many lamps, coils, etc., i have to control) this week.

White_Spot?
25th April 2009, 07:28 AM
Let me ask a question, maybe a dumb question hehe.

You are controling the GI (general illumination) by the computer?

I'm asking this because in my pinball, if i fired it up i got some GI on. So if they work and the "only" function / purpose of them are to be always on, i think is not necessary to use the computer for that, and with that i need less output.

Attention in my pinball i have the power PCB so i could use it to fired up the GI?

David_AVD
25th April 2009, 07:33 AM
AFAIK, in most pinball machines GI is permanently on. There's only a few that do some dimming effects.

White_Spot?
25th April 2009, 07:51 AM
Ok thanks for the info. Sometime when we think in the things without seeing them we make some confusion hehe.

gstellenberg
13th May 2009, 05:13 AM
The first revision of my custom controller board (P-ROC) is complete. It's an FPGA-based board enabling PC-based control of a pinball machine over USB. It's able to connect to many of the more recent commercial power driver boards. I designed this board to control a homebrew machine I plan to build. It can also be used to write new (from scratch) software for many existing machines (think re-theme).

Details at www.pinballcontrollers.com

- Gerry

Redback
13th May 2009, 05:58 AM
Excellent work Gerry!

Where abouts are you located?

I'm planning a home brew project (change good playing game to a better theme HUO)

Regards,
Red

gstellenberg
13th May 2009, 06:06 AM
Ahh yes, definitely should have posted my location, especially given the location of this forum.

I'm in Texas, US.

- Gerry