How did I miss this thread? Really nice work!

If the support for this does get to MPF and latency isn't a problem, then this should be a *much* cheaper solution than the current choice of P-ROC with my Sys11 driver board. You support a wider range of machines, and can also drive the segment displays which we can't currently do without another interface board.

Watching this with interest. For Pinmame control, take a look at the P_ROC code in there at the moment. It basically looks for changes in the pinmame state of lamps and coils and just passes those through to the P-ROC, and for changes in switch states on the P-ROC which it updates the pinmame switch states with. I guess a similar approach would work with your APC.

Mark

Can you send me the link for the German forum? I could join there and follow...

Ich kann Deutsch lesen und schreiben, obwohl ich Englaender bin. Meine Frau kommt aus Koblenz

So, I'm building one of these APC boards too. If this works well with MPF it'll be a much cheaper solution than the current option of a P-ROC with one of my Sys11 driver boards. So far the sound section is working and yesterday I got the display driver working. At the moment the system isn't configured for the F-14 display so the bottom row looks odd, but it's fine. Next step is to get the switches interfaced then I can change the settings to get the display sorted. Documentation is great for building the board (it does assume you have some basic skills) and I'm overcoming my fear of soldering SMD components. Big magnifying glass, little soldering iron tip
IMG_20190701_162857 (resized).jpg

Yup, I ordered from Reichelt. Even with the shipping it was indeed cheaper than Farnell, Mouser, Digikey and the rest.

If you didn't do SMD soldering before, I can also recommend something like this...

https://www.amazon.co.uk/gp/product/B01HPSRXJ0/

I bought one and it was good to have. It's basically a throwaway practice board with a bunch of components - it doesn't build anything useful, but you can perfect your skills on that before wrecking an APC board.

I've now populated the switch matrix section of the board. Although it's not in the actual machine yet, I can bench test this board. I have a Pinitech switch matrix tester (has momentary and permanent for each of the 64 on the matrix). Makes testing the matrix on this APC a breeze. I could also update the APC settings so it knows what kind of display board I'm using. Looking good so far! Now to build the lamp matrix and test that.

IMG_20190706_134344 (resized).jpg

So far everything is looking good. I had to make a small number of MPF config changes, mainly related to the special solenoids. Normally in F-14 and the other earlier Sys11 (and earlier generation) machines, the CPU doesn't get involved in firing coils for things like jet bumpers and slings. For those kind of devices you want the coil to fire as soon as the switch closes, otherwise it appears to lag. Williams were concerned that the CPU wouldn't be able to react quick enough to the switch closure, so they set up these "special" solenoids to fire immediately the switch closed, without any action from the CPU. Nice and snappy.

APC is quick enough to not need that, so instead all the special solenoids need to be activated by the CPU. So I needed to add an "autofire rule" into the MPF config. This basically says "if switch x closes, fire coil y". Instead of MPF handling this, it's then sent to the controller to handle itself. Here is an example from my code for the jet bumper

autofire_coils:


  jet_bumper:


    coil: c_jetBumper


    switch: s_jetBumper


    enable_events: mode_base_started


    debug: false


    ball_search_order: 0 # ball can't get stuck here


    disable_events: mode_base_ended`

So adding those in only took a few minutes. I had some concerns over the latency, but as you can see from the video (not the best quality, sorry) it works really well. APC also has individual enables for the flippers, so that opens some interesting game play options where I could disable just the left or right flipper from software.

I also spent some time getting the original F-14 display connected. We had to fix a couple of lines of code in MPF to get the segments mapped properly and now that works really well too. I added some simple attract mode text, and during the game it displays the score of player 1. I'm undecided at the moment what displays to put where. Maybe I'll the little matrix displays on the apron and keep the segment displays for the old school look, not sure yet.

Mounting the APC board was a little time consuming. A lot of the connectors are in different places compared to the original MPU board (plus the board is only one third of the size) so I needed to cut open some cable ties to loosen off some of the wires. Still a little work to do to make that tidy, but no big issue.

Anyway, here is a quick video. Starts in attract mode. You can see that MPF is running the show. On my F-14 the white inserts have RGB lamps behind them and are controlled from MPF via a small FadeCandy board. All the other lamps are regular matrix lamps and run via the Arduino Pinball Controller. They all stay in sync just fine. During the game you can see MPF with APC is controlling all the coils just fine, including the slings/jet, switches are reading fine. All looking good so far

A huge thanks to Jan for the work in MPF and to "Black Knight" aka "AmokSolderer" for support on the hardware side.

I guess I'm one of the two

There are a few things which might make it more "user friendly", but I know for you this was never intended for "mass market", so these are just my thoughts and not intended as criticism. Your board is actually awesome, driving the original displays and being able to run game code locally is really cool.

- The often discussed self-build with SMD. I'd done a lot of soldering before, but never SMD, but watched some videos and gave it a try. It is actually easier than it looks. But many people are "just software folks" and the thought of building something with through-hole is already scary. SMD adds a new dimension for them. I initially sold my Sys11 board just as a kit, but in the end support was so high that I used to spend a day building and testing maybe 6 of them and then sold them ready. I added a little "beer money" to the price. Those 6 would normally last a year, they never sold huge numbers.
- Connector positioning and board mounting. On the board I developed for Sys11 that connected to the P-ROC, I tried hard to make it mountable on the positions that the Sys11 MPU had used. It was half the size, so used the right and centre mountings from the original board - see the photo below. That's the P-ROC on the left and my board in the middle. I also tried to get the connector positions "more or less" in the same position as the original, to avoid so much cable-binder removal and replacement. With your board this is harder I guess as it works with so may generations, although maybe the various WMS generations have their connectors in the same place? I can also see that moving the connectors on the board is quite a lot of work, although if the board was a little bigger (to fit the Sys11 mounts) there would be more space for tracks. To fit your board in my F-14 I had to do a lot of cable re-routing and it still looks messy.
- Maybe add a few LEDs? My board has them for 5v,12v and 18v and also from the P-ROC enable line. The latter made it quite easy to see that software was running and connected. Maybe if you have a spare Due pin, connect that to a LED and just blink it when the code is running.
- Pinmame is nice. When I started P-ROC with Sys11, someone has already built the link to P-ROC from Pinmame and I added the missing Sys11 support. It is then nice to play the original game code when you get frustrated with the ongoing development. I don't have time at the moment (which is why I've been really quiet lately) but once Ralf gets it working for LISY, it should be almost "plug and play" to build for Windows. Then you can either run MPF on the windows machine, or Pinmame, or run the local game code on the Arduino.

DSCN4998 (resized).JPG

You might find that the Teensy doesn't have enough pins - the Due has 54 of them and I think (but haven't checked) that they're fairly heavily used. The Teensy has 40 or thereabouts I think, depending on which version.

This I understand 120%. Life is already too busy.

For Windows only, there are hooks in Pinmame to use the Pinsound Studio - so instead of emulating the sounds, the "sound command" is passed to the Pinsound Studio. The Studio has the original .wav files which it then plays.
I've got this working for BOP 2.0 and this will hopefully make it into a future update of that software, however for your use case looking at how Pinsound is integrated might be useful?

I answered on Flippertreff too, but this might be the most useful link to some code in the FreeWPC repo...

https://github.com/bcd/freewpc/blob/v1.2/include/system/sound.h#L30

Hi, does anyone have a spare v3 board they would sell and ship to me in the UK? Ideally with at least the SMD components on?

#--Edit - found one!--#

AmokSolderer , jabdoa , bontango

I'm finally (again) coming back to my F14 and am switching over completely to MPF / APC. I have a question on my RGB lamps and am trying to work out the best way to set it up.

At the moment, all of the GI and around 12 insert lamps in my F14 (the clear ones) have RGB LEDs connected to a Fadecandy. The remaining insert lamps are on the regular lamp matrix. So far I've been running MPF from a host machine which also runs the fadecandy server and so the "hybrid" of lamp matrix and Fadecandy is fine.

My question is how to best to bring pinmame into the system and drive these LEDs (just to a single colour). I know that Lisy has some Fadecandy compatibility, but the Fadecandy board is connected to my host computer, not to Lisy. If I connect the Fadecandy board direct to Lisy, then MPF/APC won't be able to find it. If I connect the Lisy board to my host computer over USB (or WiFi, but horrible latency I guess) will it be able to find the fadecandy server there somehow?

I know the APC has an option via the HW interface to control these LEDs (instead of Fadecandy) but at the moment the APC software is only thinking "all LED" or "all matrix" and from the MPF side there would be no colour control anyway (unless I've misread things).

Suggestions welcome. I don't want to make work for people, so trying to think about the best way to do this with what is currently available.

Actually first I have to build my APC board and get that working, I have one (2 actually) with SMD parts populated coming in the post this week

From my side absolutely no hurry with this, but I have a couple of comments.....
- Ideally pinmame on the Lisy should not care about what kind a specific lamp is. It just knows about the 64 lamps that can be on the matrix and will want to switch them on or off. It would be good if APC then takes care of handling an actual matrix lamp, or doing an LED instead. In this instance the LED I would think needs no colour control, just switch it on (white) or off. In the same way, if MPF "just" switches a lamp on or off without taking care of "nice" LED things, I would suggest it works the same way.
- I know the LED_exp board does the heaving lifting (I was running an Arduino for my RGBs before I moved to Fadecandy) but is there a risk that the Due onboard the APC is going to run out of bandwidth? All the support for Lisy / MPF etc is great, but is it eating into capacity (CPU or storage) for your original design of running games just with Arduino .ino code?

RatShack Awesome! Is the MPF source for this published somewhere? I think folks looking to start the MPF/APC journey would appreciate taking a look at other code. I know the MPF docs could do with some extra examples (will do some when I have time).

For people using the APC with MPF, I think the MPF documentation needs some improvement in terms of connecting them together (I'm planning to put some updates in for that). However once it's working, MPF is fairly platform independent so I think the existing Google Group for MPF is enough "community".
What is probably missing is some kind of forum for people that are using the APC natively, coding games "the .ino way". But I'm not sure how many people that is, so not sure if the effort is worth it. Maybe for now just start a new APC programming thread here and see how much it gets used? If lots of folks using it, maybe a new Google Group?

Yeah, I was reading about the pinmame exceptions stuff in your documentation, it's clever and as you suggest for my use case probably the best way forward.

I'll get my APC built over the next week or so and then probably put the LED_exp on a breadboard. Will keep you posted. Thanks so far!

But for the moment the LEDs are low priority - I need to spend time on the actual game code and rules, if a few inserts don't work for the moment that's no big deal

I've seen this issue with some WPC machines and pinmame, where some mechanism or other is controlled by what look to be solenoids but are used in some other way.

In BOP, the helmet lamps are driven by a shift register. This is controlled by 2 "solenoids" - one is used for the clock signal and the other for the data. In addition the motor which turns the head is not driven at 100%, the "solenoid" which controls the motor drive is run with PWM at about 50% which requires that output to be driven fairly consistently.

Capturing the data from pinmame at that low level was OK, but getting the really fine control over the output wasn't possible with the normal solenoid drive logic for the P-ROC. Fortunately the P-ROC has what's termed an "auxilliary bus" which permits microsecond accurate control over a limited set of outputs and I was able to use that in the most recent update for Dutch Pinball with their "BOP 1.0".

Something else which the P-ROC can do which might be worth looking at here is the concept of a "patter" instead of a simple on/off for an output. Normally you drive an output either on or off. However from the pyprocgame documentation -

-method:: driver_patter(number, milliseconds_on, milliseconds_off, original_on_time)
-
- Drives the specified driver *number* with an indefinite pitter-patter sequence, where the driver is repeatedly turned on for *milliseconds_on* and the -off for *milliseconds_off*, each with a max of 127.
-
- If *original_on_time* is non-zero, the driver is first pulsed for that number of milliseconds before the pitter-patter sequence begins, with a max 255.-
-
- Pitter-patter sequences are commonly used for duty cycle control of driver circuits. A case where *original_on_time* might be non-zero would be for a -single coil flipper circuit that needs to be driven to activate the flipper before the pitter-patter sequence is used to hold the flipper up.

I did spend some time trying to get Pinmame and P-ROC to run an Indy 500 - it has a kind of turbo mechanism which is controlled by PWM to control the speed, but there is also an opto on it which measures the current speed and increases or decreases the PWM to speed up and down. I could never get the control fine enough, so there are possibly some circumstances where it's just not possible to do.

I guess the patter request wouldn't be something that pinmame would send to APC, it is probably more something that the APC would handle via a pinmame exception.

I know that DE inverted *some* of the signals on their 2x16 displays compared to Williams, but I can't find any documentation on what. I guess staring at the schematics might help.

I found that sometimes after applying updates to apc.ino, especially when configuration settings get added/updated, it's best to delete the settings file stored on the SD card (or at least rename it so you have a backup). It's called APC_SET.BIN - just delete the file, put it back in and start APC again. You'll need to set the display type up again as everything will be reset to default.

Looking forward to blowing the cobwebs off my F14 next Spring. My wife and I are both retiring in April so hoping to have lots more "hobby time"