OK, that means it worked for you?
I still cannot see my board.
When I click on the Gerber Viewer I get some strange error message about the tool not supporting files uploaded before July 
May be they didn't notice that it's 2020 by now and that at the moment it's difficult to upload files AFTER July.
I did the same. I checked with OSHPark, and they gave me the same dimensions. I then ordered from JCLPCB. I'll post the results once I get the boards.
So, if I am wiring up a custom game with 8x8 matrices like Sys3-WPC, I should be able to control them with APC, correct?
Also, for the SMD work, did you all use a reflow oven or hand solder them? Since there are parts on both sides, I'm not sure how the oven could work, unless you use an oven for one side and hand solder the other?
Quoted from ledbetter:i uploaded the files into a different program and got those measurments , so i just used them
So it seems just the preview is not working.
Like bontango wrote, you don't need the dimensions when everything works properly as the previewer determines them from the gerber data. Let's hope the rest of their software still works.
Quoted from ThatOneDude:So, if I am wiring up a custom game with 8x8 matrices like Sys3-WPC, I should be able to control them with APC, correct?
Correct, but do you really want to use a lamp matrix? Would probably be easier with an LED strip.
Quoted from ThatOneDude:Also, for the SMD work, did you all use a reflow oven or hand solder them?
I hand soldered everything, that's why I used large solder pads and components. The ICs still might require some practice, but you can buy a cheap hot air rework station if you don't want to solder them by hand.
Quoted from AmokSolderer:Would probably be easier with an LED strip.
Good point. I planned on using RGB serial LEDs for mine, and would be happy to stick with it.
Quoted from AmokSolderer:I hand soldered everything, that's why I used large solder pads and components.
Works for me. I've never done SMD soldering before, so I'm trying to make sure I've got the right equipment before I embark on this project.
Based on the specs and examples I have seen, I think that I'm going to swap in APC for my homebrew controllers.
Also, once the pinmame connection is working, I don't see why this wouldn't work with driving a WPC era machine, right? (assuming I wired it like a Sys11) This would speed up my Scared Stiff custom build by quite a bit.
Sorry for the flood. I'm gearing up for this project and so I've got a lot of questions popping up.
Who is working on the pinmame side? How does it tie into the audio emulation? On my setup, I'm using a DAC with the Pi to generate sound.
For the DMD, I'm planning on continuing with the SmartMatrix setup. How are they being driven in other scenarios?
It really depends on your combination of things. With LISY you get Pinmame. With MPF you can use Smartmatrix or other hardware. I fear Smartmatrix and Pinmame will not cooperate out of the box.
Quoted from jabdoa:I fear Smartmatrix and Pinmame will not cooperate out of the box
I've already hacked pinmame to draw to a dmd using the raspberry pi gpio pins. Swapping that out for smartmatrix shouldn't be much trouble. Should run faster, since I actually had to artificially slow down the gpio pin writes.
Quoted from ThatOneDude:Good point. I planned on using RGB serial LEDs for mine, and would be happy to stick with it.
That means you don't need the lamp matrix, so you can spare some SMD components.
Quoted from ThatOneDude:I don't see why this wouldn't work with driving a WPC era machine, right?
Right, but with P-ROC there is already a working solution. However there is someone in the german forum planning to do an open source controller for WPC, so something might come up in the future.
Quoted from ThatOneDude:Who is working on the pinmame side? How does it tie into the audio emulation?
Bontango is doing the PinMame stuff. At the moment we're planning to extract the WAV files from PinMame and put them on an SD Card. Then PinMame can just tell the APC when to play which file. This makes changing sounds an easy job, since you can just change the files. Of course they have to be extracted for every game, but this must only be done once and can be automated.
Actually we're going to try it this weekend with my Pinbot.
Quoted from AmokSolderer:Bontango is doing the PinMame stuff. At the moment we're planning to extract the WAV files from PinMame and put them on an SD Card. Then PinMame can just tell the APC when to play which file.
Wouldn't you have to also have a mapping of the memory locations of each sound for pinmame to "know" which sounds are which files? It also wouldn't work for sounds that are fully synthesized(like the Gorgar heart beat and such). It would seem to me that it would be easier to use the built in sound emulation from pinmame and just feed that into the board as input(or utilize an external DAC + amp for those machines).
Quoted from AmokSolderer:Right, but with P-ROC there is already a working solution.
In my case, I'm wiring up a Scared Stiff from scratch, so I don't need wiring compatibility with WPC per se.
Quoted from AmokSolderer:Bontango is doing the PinMame stuff. At the moment we're planning to extract the WAV files from PinMame and put them on an SD Card. Then PinMame can just tell the APC when to play which file. This makes changing sounds an easy job, since you can just change the files. Of course they have to be extracted for every game, but this must only be done once and can be automated.
Actually we're going to try it this weekend with my Pinbot.
I'm interested! I was planning to do something like that at some point when I was not able to repair my Firepower sound board. However I gave up when I found out sounds where "layered", and successive calls to the same sound address were not producing the same results (it tunes the sound differently, for repetitive background sound as an example, to change the pace).
Quoted from ThatOneDude:It would seem to me that it would be easier to use the built in sound emulation from pinmame and just feed that into the board as input(or utilize an external DAC + amp for those machines).
I had big problems with the (unix) sound drivers in pinmame. It works for windows but I never got a good sound output with Linux/Raspberry.
Looks like no one works on the Unix part of pinmame anymore, I did an update on the ALSA sounddrivers a year ago, but still poor sound.
If you are interested in the code, LISY is part of official pinmame code: https://sourceforge.net/p/pinmame/code/HEAD/tree/trunk/
Current coding you can find here: https://github.com/bontango/lisy-src-5.x
Once in a while I do an update of the LISY pinmame code on sourceforge
Quoted from ThatOneDude:It also wouldn't work for sounds that are fully synthesized(like the Gorgar heart beat and such
I know very little about PinMame, so I can just tell you how I understood it to work but I might be telling bullshit here.
As far as I know all the old pre WPC games had synthesized music and even the speech wasn't sampled in a format we could simply use nowadays (at least in machines up to System11). Memory was just too expensive to do that so they used synthesizer ICs which generated waveforms that sounded like music. Therefore PinMame has to emulate these old ICs and generate a WAV or whatever can be used with today's audio cards.
That means it's not enough to locate a certain sound in the ROM, but you must make PinMame play and record it as a WAV to be able to use it.
Quoted from ThatOneDude:It would seem to me that it would be easier to use the built in sound emulation from pinmame and just feed that into the board as input(or utilize an external DAC + amp for those machines).
True, the SW setup would be easier, but we'd loose flexibility in doing so. If we spend the (one time) effort to generate WAVs and let the APC use them, we can not only use these sounds with PinMame but also with MPF or the APC itself. The easiest would be to just replace certain files on the SD card to introduce your own music and effects. If you design your own game rules with MPF you could use the old sounds.
And as the APC features it's own pinball operating API you could even run your game in PinMame, but let the APC act as a man in the middle and introduce certain rule and effect changes and with the sound and music files at hand you have the full flexibility.
Quoted from ThatOneDude:In my case, I'm wiring up a Scared Stiff from scratch, so I don't need wiring compatibility with WPC per se.
Ouch that's a lot of work. May I ask why you'd wanna do that?
Quoted from matiou:However I gave up when I found out sounds where "layered", and successive calls to the same sound address were not producing the same results (it tunes the sound differently, for repetitive background sound as an example, to change the pace).
That's the reason why it might take hours to extract the audio from PinMame because you have to make it play every pitch and tune and record it as an own WAV. You end up with hundreds of files and still have to know which file belongs to which sound.
Like it wrote we're going to try it this weekend. I'll keep you posted about the result.
Quoted from AmokSolderer:Ouch that's a lot of work. May I ask why you'd wanna do that?
Lol, the current consensus seems to be insanity. I love that game, and by chance picked up a nice playfield about the same time someone gave me a cabinet. I was already doing a playfield up rebuild of a Williams Flash, so this seemed like an interesting project to take on. I do things like this precisely for the immense challenge.
Quoted from bontango:I had big problems with the (unix) sound drivers in pinmame. It works for windows but I never got a good sound output with Linux/Raspberry.
The sound hardware on the Pi is miserable. Have you tried a USB card? I had sound running on a pi emulation of Scared Stiff with the default unix compilation. It was slower, but I attributed that to the overhead of Xwindows and the dmd gpio operations on a pi 2. I've since moved to a pi 3(and I'm about to get a pi 4 with 4gb of ram) and compiled without X, which resolved a lot of the speed problems. I haven't tried audio on that setup yet, as I was concentrating on making the dmd driver threaded. I'm also moving away from the wiringPi library.
Quoted from ThatOneDude:The sound hardware on the Pi is miserable. Have you tried a USB card?
Yes, and also a PHAT soundcard, same result with pinmame, however soundquality in general ( playing wav & mp3 files) is good
LISY is using a 'fake' video driver, no X windows ..
I'm also looking to replace wiringPI library, as it is deprecated and does not support 100% PI4 in last version, which library are you going to use?
Quoted from bontango:I'm also looking to replace wiringPI library, as it is deprecated and does not support 100% PI4 in last version, which library are you going to use?
I haven't decided yet. I'm looking at pigpio right now.
Quoted from ThatOneDude:Lol, the current consensus seems to be insanity.
Well, insanity seems to be a common disease among pinball enthusiasts. 
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?
Quoted from Snux:For Windows only, there are hooks in Pinmame to use the Pinsound Studio
Sounds interisting, do you hae some details where to start? I did a quick search on the sources for 'Pinsound' but with no result 
Quoted from bontango:Yes, and also a PHAT soundcard, same result with pinmame, however soundquality in general ( playing wav & mp3 files) is good
What problems are you seeing with the unix sound? I had sound from the headphones that I thought was on par with 90s ROM samples, but maybe I missed something. My problem was that the sounds were pitch shifted and slow, which I attributed to too much overhead, with the whole X stack and dmd gpio running at the same time.
Quoted from bontango:I had big problems with the (unix) sound drivers in pinmame. It works for windows but I never got a good sound output with Linux/Raspberry.
Looks like no one works on the Unix part of pinmame anymore, I did an update on the ALSA sounddrivers a year ago, but still poor sound.
If you are interested in the code, LISY is part of official pinmame code: https://sourceforge.net/p/pinmame/code/HEAD/tree/trunk/
Current coding you can find here: https://github.com/bontango/lisy-src-5.x
Once in a while I do an update of the LISY pinmame code on sourceforge
Have you considered a DAC board to clean up the sound? Pi's are notorious for poor sound quality through the analog output.
Just put one into use here at the shop using volumio for music playback from my nas and the sound difference is night and day. Being as volumio src files are available on github you should be able to grab the audio conversion code you need to implement it in your project.
Quoted from zebulon:Have you considered a DAC board to clean up the sound?
Yes, I use a 'PHAT' DAC board with LISY, as said sound in general is good when playing wav or mp3 files, its just bad with pinmame.
Quoted from ThatOneDude:My problem was that the sounds were pitch shifted and slow
Same effect here, even with the LISY 'fake' video driver without X. I don't think its an performance/overhead problem but
more a timing problem from the pinmame code. From what I saw in the unix soundcode (which is different from the windows one and VERY old)
sound timing is somewhat dependent on the video timing.
I spend a week or so to clean that up, but gave up at the end ( I'm not a soundspecialist ..)
I would guess with another video driver ( not X and not the LISY fake one) it might be better, but I did not test that
The APC offers good sound quality without any additional sound HW, so if we manage to play the right wav at the right time we're done IMHO. The main problem appears to be the mapping, but according to Snux it must be feasible, because this Pinsound Studio seems to do exactly the same.
And as I already wrote we have the additional advantage that these sound files are accessible for MPF and APC games also. I think it's a great feature to run a game in PinMame and just add certain rules on the APC in C++.
Quoted from bontango:I don't think its an performance/overhead problem but
more a timing problem from the pinmame code. From what I saw in the unix soundcode (which is different from the windows one and VERY old)
sound timing is somewhat dependent on the video timing.
Interesting. I didn't even look at the sound code yet. I created another video driver called OPPA to drive the DMD and was starting work on the switches and solenoid driver. The timing on the DMD was a mess, and I finally decided to just use pthreading to try and decouple it from the main emulation.
Has anyone tried running pinmame on a more powerful Linux box to test the sound there? If the problem disappears, it could still be RAM contention or something of the like. Sound was also not a problem for Raspbian based MAME, so there has to be a fix for pinmame.
Got the boards in today. JCLPCB is insanely fast. I'll post some pics once I get a chance. They look good.
Quoted from ThatOneDude:If there any reason that an IRF540 couldn't be used in place of the IRF3808s?
Just looked up the specs on the IRF3808 - those things are BEASTS. Seems like overkill? I'm planning on using IRF9540 for the flipper drivers on my Gottlieb version.
I'd rather the MOSFET fry than even try to pass 140A of continuous current, I would think. Hopefully a fuse would pop before it hit that.
Quoted from ThatOneDude:If there any reason that an IRF540 couldn't be used in place of the IRF3808s?
Yeah, this is probably overdone, but these FETs are for the flipper fingers and I hate when those are weak. So I tried to keep the on resistance as small as possible, but I think the 540 will be enough.
The whole solenoid part is a bit overengineered, as I wanted to be able to conntect all kinds of fancy hardware to it without having to use a second driver stage as used in System11 for the high voltage coils.
Update: the first PinMame tests are very promising.
The lamps are working perfectly, displays and solenoids are having minor issues.
We still have to increase the emulation speed, but according to Bontango this is just a setting.
Navigating the test menu with the Advance and Up/Down switches doesn't work correctly. Do you know if the behaviour of these switches in PinMame is different from the original machines?
Except of that all switches are working fine.
We still have only partly implemented the sound handling. Up to now we just have 255 sound files which contain their their own numbers in speech, so Pinbot is telling me all the time which file he is playing at the moment. Mapping these file numbers to the correct sounds is one of the next tasks.
But all these are relatively small problems and I was already able to play some games. 
Something occurred to me. The MAME boxes I made from Pis had no issues with sound. Once I have some time this week, I'm going to diff the pinmame unix audio against the working mame code.
Quoted from AmokSolderer:Navigating the test menu with the Advance and Up/Down switches doesn't work correctly. Do you know if the behaviour of these switches in PinMame is different from the original machines?
Except of that all switches are working fine.
I'll try to figure that out at the same time I'm looking at the mame code.
Also, a full set of components from Mouser runs about $100 USD, in case someone else is looking at this project in the US. I swapped in IRF540s, and I have some headers from other projects, so I've got my order down to about $90 shipped.
Maybe this is the problem. I started tracing through the pinmame audio, and I noticed this:
=========
int updatescreen(void)
{
/* update sound */
sound_update();
/* if we're not skipping this frame, draw the screen */
if (osd_skip_this_frame() == 0)
{
profiler_mark(PROFILER_VIDEO);
draw_screen();
profiler_mark(PROFILER_END);
}
/* the user interface must be called between vh_update() and osd_update_video_and_audio(), */
/* to allow it to overlay things on the game display. We must call it even */
/* if the frame is skipped, to keep a consistent timing. */
if (handle_user_interface(artwork_get_ui_bitmap()))
/* quit if the user asked to */
return 1;
/* blit to the screen */
update_video_and_audio();
/* call the end-of-frame callback */
if (Machine->drv->video_eof)
{
profiler_mark(PROFILER_VIDEO);
(*Machine->drv->video_eof)();
profiler_mark(PROFILER_END);
}
return 0;
}
=========
I'm guessing that we could skip 100% of the overlay and UI code and speed this up quite a bit.
Quoted from ThatOneDude:Maybe this is the problem.
it's worth a try...
I experimented with a similar call "sound_stream_update" in unix/video.c but with no luck
Plwease let me know if you find something, happy to try it with my LISY image ...
Quoted from ThatOneDude:Also, a full set of components from Mouser runs about $100 USD
I'm surprised by the high component prices. Did you order an Arduino DUE from China or did you pay the whole 40 bucks?
Quoted from AmokSolderer:I'm surprised by the high component prices. Did you order an Arduino DUE from China or did you pay the whole 40 bucks?
Actually, that doesn't count the Due. I'm getting one for $18. That was the mouser price for the rest of the components. That's replacing the MOSFETs with cheaper IRF540s and the molex headers with cheaper ones that didn't have the directional latches. I haven't ordered yet, so I'll try digi key to see if they are cheaper.
Yeah, the Mouser prices seem very high to me. I checked some parts and almost everything is less than half the Mouser price here in Germany. A simple 1206 Resistor is almost 5 times the german price.
That means, if I ever pull myself together and do a board version that can be populated by the board manufacturer it would probably even save some money for you US guys.
I ordered my parts today. Once they come in, we'll be putting together 4 of them. I'll keep you posted as we progress.
Quoted from ThatOneDude:I'll keep you posted as we progress.
I'm curious about it.
Of course I'm especially interested to learn about missing or misleading parts of the documentation.
Quoted from ThatOneDude:Was R80 removed from the board?
Yes, R80 has been removed. Have to delete it from the Wiki also.
Is there a discussion of the hardware expansion system? I saw your video, but I can't find source code or a description of how you are communicating with the expansion boards.
Wanna join the discussion? Please sign in to reply to this topic.
Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!
This page was printed from https://pinside.com/pinball/forum/topic/arduino-pinball-controller/page/4?hl=thatonedude and we tried optimising it for printing. Some page elements may have been deliberately hidden.
Scan the QR code on the left to jump to the URL this document was printed from.
Solingen
Mackay
Maidstone
Whitby, ON