You're currently viewing posts by Pinsider ThatOneDude.
Click here to go back to viewing the entire thread.
Awesome stuff! I went a similar route, with a Teensy 3.5 as the realtime controller. I added a hack to pinmame to drive a DMD to emulate Scared Stiff, and I've got another similar project running MPF with the Teensy controller. I just got a couple of RGB DMD panels from China, so I'm waiting on another Teensy and a SmartLED board to build an RGB DMD for that machine.
Rpi driving DMD:
The nice thing about the Teensy is that most of the work is already done for you: https://docs.pixelmatix.com/SmartMatrix/shield-v4.html
Quoted from AmokSolderer:Yes, but my setup was meant for the old DMDs from the WPC era as I was thinking about controlling the old WPC DMDs with the APC. I've found several projects dealing with RGB LEDs, but I didn't find a small controller for the old DMDs. May be because it's too simple - with the UNO you don't even need additional HW. Or just because there is no need.
The newer Stern monochrome DMDs seem to work fine with 3.3v, so any of the recent Teensy boards should be more than sufficient. WPC style displays are a compilation of 3 subframes, each 4k-bits long. You could feed this directly to a stock DMD. To drive an RGB pixel n with red as a the base color, multiply subframeX[n] by 85 and add the 3 results together. You will end up with #000000, #550000, #AA0000 or #FF0000 (assuming R is the first byte in your serial LED library) for the final pixel color. Should be easy to blast that out in real time with a Teensy. That was my plan if I end up using the color panels with my Scared Stiff project.
This is how I update a DMD right now. I need to finish converting it to a threaded model, but it works from a Raspberry Pi 3 with the WiringPi library. The Pi was too fast for the DMD, so I had to introduce delays during testing.
=========
/* Take in array and update the DMD directly */
void oppaUpdateDMD(UINT8 *dotData) {
//printf("In update DMD\n");
int row;
/* Row data - This signal is the first line marker for the scan.
This input should be held high to correspond to the first row
of pixel data
*/
digitalWrite(pinRowData, HIGH);
for(row = 0; row < OPPA_NUM_OF_ROWS; row++) {
int index;
/* From Vishay doc: Once each frame the ROW DATA must be asserted to synchronize the column serial data with the beginning row */
/* Latch the row of data */
digitalWrite(pinColLatch, LOW);
for(index = 0; index < 16; index++) {
shiftOutSlow(pinDotData,pinDotClock,LSBFIRST,dotData[(row*16) + index]);
//shiftOut(pinDotData,pinDotClock,LSBFIRST,3);
//delayMicroseconds(40);
}
if(row == 0) {
digitalWrite(pinRowData, HIGH);
} else {
digitalWrite(pinRowData, LOW);
}
/* Turn off the display while we latch in the this row */
digitalWrite(pinDisplayEnable, LOW);
digitalWrite(pinColLatch, HIGH);
/* Advance the row pointer */
digitalWrite(pinRowClock, LOW);
/* Minimum 1us dip */
delayMicroseconds(0);
digitalWrite(pinRowClock, HIGH);
/* Reenable display */
digitalWrite(pinDisplayEnable, HIGH);
delayMicroseconds(2);
}
}
void shiftOutSlow(uint8_t dataPin, uint8_t clockPin, uint8_t bitOrder, uint8_t val)
{
uint8_t i;
for (i = 0; i < 8; i++) {
if (bitOrder == LSBFIRST)
digitalWrite(dataPin, !!(val & (1 << i)));
else
digitalWrite(dataPin, !!(val & (1 << (7 - i))));
digitalWrite(clockPin, HIGH);
delayMicroseconds(1);
digitalWrite(clockPin, LOW);
}
}
Since I just discovered this project less than 2 weeks ago, I haven't had time to pull down the Gerber files and have a board made. I'm inclined to rework it slightly for a Teensy(since that's my main Arduino compatible board now). The Scared Stiff project mentioned above is meant to be driven from a Raspberry Pi connected to a Teeny via USB, so I may be able to help some with that part of the effort. I do have a Blackout that is currently under reconstruction(and a lead on a WCS with no boards), so I may be able to duplex some of the work for my projects. I opted to base my serial protocol on the LISY protocol in MPF. If you do the same, most of my work would be reusable on the pinmame side.
Quoted from Snux: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.
The 3.5 and 3.6 each have 62 I/O pins. For my OPPA project, I opted for i2c boards based on MCP23017 serial chips, since the 3.5 had 3 i2c buses(giving me 384 direct I/O pins, plus the rest of the Teensy pins for things like PWM). I used an i2c buffer chip on both sides and connected them via phone cord(RJ11 connectors).
I'm also one of those mostly software guys who hasn't made the jump to SMD.
Quoted from AmokSolderer:I see the main problem in the SW as you would have to change the HW driver. In order to speed it up it is accessing the DUE's registers directly instead of using the Arduino commands.
They are both Cortex ARM. M3 and M4. I think the conversion wouldn't be terribly hard.
Quoted from AmokSolderer:Help from PinMame developers would be welcome
When I started working on the code to run pinmame on a Pi and drive a physical DMD while talking to a Teensy running the playfield, I got zero responses from the core developers.
I'm trying to order a board from JLCPCB and they are asking for the dimensions of the board. Does someone have that? I haven't found it listed in the wiki so far.
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 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?
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 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: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 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 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 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.
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.
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 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.
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.
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.
Also, I noticed that C2 is listed under a different footprint than C19/C23/C25/C27, but has the same mouser order. Is that correct?
If you don't mind, I will create a list for ordering parts with a link to a mouser project for the wiki. That will make it easier for people to make an order.
Also, people should always order 10% more SMD parts, as my friend learned last night when a capacitor flew out of his tweezers to be lost forever.
On my machines, I'm using either pin2dmd or smart matrix boards for display, but for at least one I'll need to drive serial LEDs and a few extra solenoids. If you want to post the hardwired source in a branch, I could work on making it generic. Thanks!
Quoted from AmokSolderer:It is already included in the current branch. It's part of the lamp section in the HW driver (TC7_Handler in APC.ino) and that's part of the problem, because this driver does directly control the HW and it is therefore the most sensitive part of the SW. Any issues here may lead to very nasty consequences.
So, give me some time and I'm at least going to add a command to send raw bytes to the HW extension interface. By this you don't have to deal with the HW driver directly, but you still have the flexibility to implement additional functionality as you like.
Ok. So, you are using PIOC to write to the expansion bus, and then a select line(SEL5 - 7, correct?) to activate the board, which then does something with the bus data.
Are you using all three select lines as an address, or just 3 individual lines?
Do you have the code for Arduino Mini used in the board somewhere? I'd like to see how you interpret the data bus.
Instead of directly wiring the bus to a card or daisy chaining the bus between cards, I would suggest an interface card that multiple cards can connect to.
Quoted from AmokSolderer:Using it as an address is possible, but it would require additional logic on the receiver side.
You could add a 74x11 chip with some jumpers to do address lines without having to add logic to the Mini's loop. In fact, you could do that on the interface board I suggested and then the expansion boards would be defined by the connection location. Just a thought.
I'll pull .13 down tonight and check it out. Thanks!
Quoted from AmokSolderer:In my opinion Stern solved this problem in an elegant way by using shielded network cables as inter-board connections. So when we're thinking about an interface board it would probably be a good idea to plan for a parallel to serial converter which can then drive a network cable. The receiver would just need a shift register to get the parallel data back.
When I was designing my own system, I also opted for shielded cat6, which would lead to simple boards based on an mcp23017 i/o chip and a buffer under the playfield. So, no switch/ solenoid matrix, just direct drivers.
We're could adopt some of that methodology here. A microcontroller in the backbox to convert to spi or i2c across cat6.
I started with OPP, but I didn't like the microcontroller, so I replaced it with a Teensy arduino compatible unit and called it OPPA(OPP Arduino). Everything was connected to the 3 i2c buses and I used MCP2307 chips for i/o. I made a few mistakes with the first boards (my first custom design) and I wasn't making progress as fast as I wanted. So, the APC caught my attention. It has the features I need for my games, is open source and is already functional. In addition, you are already connecting it to MPF and pinmame. I had modeled my MPF platform on LISY for my completely homebrew machine and was hacking on the unix port of pinmame to have a Pi drive the rules, sound and the dmd for my custom built scared stiff. I'm also involved with helping two other people do custom machines. I'd much rather merge my efforts with a project that is already mostly done on the hardware side than continue to recreate the wheel.
The only change was moving back to a matrix design, which is acceptable to me.
The version of my boards in the picture are 4 wire rj45 versions.
20191113_234940 (resized).jpg
I can live with 64 switches for these projects.
For everything but my Scared Stiff, I can live with 24 solenoids. WPC supports 28 solenoids, so adding that opens up a new generation of machines.
For original sound, I can use APC. For pinmame based ROM emulation, I'm still trying to get decent sound from pinmame. I'm planning on testing a non-Pi configuration this week to see if it works better. Moving to a SmartMatrix or pin2dmd board frees me from having to deal with gpio interations on the Pi.
Fadecandy boards would be fine. I'll grab one to start experimenting with.
To save a few microseconds of loop, I suggest a variable which can skip the regular lamp matrix as part of the configuration for those cases that are not hybrid models.
Quoted from AmokSolderer:Are you planning to keep the APC in the backbox or do you want to place it in the cabinet? When you're doing a complete rewire anyway you have the choice and since you're not going to use the display part there's not much in the backbox to connect it to.
I haven't decided. Scared Stiff of course will have the spider mech and the DMD up top. Stranger Things(my homebrew version) will have a DMD and maybe a toy in the backbox, but I still have the original wiring harness from the donor playfield(it started life as a williams Flash), so I could have a head start on the matrix wiring.
Quoted from AmokSolderer:That means if you want to use the APC in a WPC or any homebrew machine you have to make sure to place them somewhere or your power driver transistors will fry eventually.
Good point. I'll make sure to include them.
Quoted from bontango:Hello, any feedback on that topic, were you able to do the testing?
I still think that it is because of the old soundcode in LINUX which need to be updated,
if it is the case, you should have same problems in your non PI configuration.
I was distracted by a Black Knight 2000 rebuild. Now that I'm working from home for a few weeks, I'll be able to slip in some testing.
bk2k (resized).jpgI just finished step 3. I was going to plug it into jokerz, but the jokerz display is fried. Which raises the question, if you are driving displays with MPF, how do you display messages? If I were to set up MPF with a dmd being driven by a smartmatrix, for example, how would that work, in your mind?
Ok, what I think now is that I'll set up MPF without using the built in display. If that works as expected, I can test lamps and switches on the bench.
EDIT: Nevermind, you posted the same link.
It allows MPF to drive an RGB DMD. I plan on using it for my custom projects(I'm also going to test a pin2DMD board for the same purpose). So, for games without a built in display(ie, games with only an LCD or DMD for display, which is driven directly by the CPU running MPF or pinmame), we will need some way to see the APC settings menu. I see two possible solutions:
1) Turn the display output into serial messages traveling upstream to MPF(not a solution for pinmame games).
2) Build a small LCD or alphanumeric display to display APC specific messages. Maybe just an arduino that translates the segment information, or a compact alphanumeric display based on something like these: ebay.com link: 54 INCH 14 SEGMENT DUEL DIGIT ALPHA NUMERIC STICK DISPLAY MDA6410C
I have some LCD backpacks, so I may work on that side of it.
Quoted from AmokSolderer:Did you populate the display related parts? If yes you might consider using your BK2K to make sure the board is working correctly before starting with MPF.
I'll probably do this as well. Low hanging fruit.
So, it's clearly scrolling and generating a pattern, but it's gibberish. I'll dig into the code and see if I can debug. Do I need to adjust the display type?
I found 4 components, R88, Q8, R75 and Q6 which aren't shown on the instructions but tie into the display section.
So, what setting can I use to get intelligible data? I'm a bit confused by DisplayType, which I thought should be set to 3. But, in the code, DisplayType instead is used as an array reference to APC_settings.
Quoted from AmokSolderer:First of all: did it work, can you read your displays now?
It's early morning here, and I'm at work(stuck at home for quarantine but still stuck in front of my computer, such is the life of the devops engineer). I'll test around lunch, which will probably be after bed for you
Quoted from AmokSolderer:Same here, but I think I wouldn't be able to resist. It's just some seconds and if no meetings are imminent
Well, the bigger problem is that I'm only part way through step 3, so no switches yet.
Quoted from Compy:If you need any pinmame help or anything, let me know.
If you can help with the ongoing Unix sound problems on pinmame, that would be cool.
Do you have a description of how to do that hack?
EDIT:
For me, that is the main problem I'm seeing. I was able to get the DMD working with a Pi and the wiringpi library(which is being deprecated). I'm planning on changing gears, dropping my OPPA stuff and just hacking in support for smartmatrix or pin2dmd(basically, stream subframe data across USB, grab it on the SM side and build a final frame).
Quoted from AmokSolderer:Of course I'm not trying to tempt you, but theoretically you could change the first byte of APC_defaults to 3
Alas, no love. I suspect I have a hardware problem now.
Ok, finished step 3. Stepping through with advance changes things, but nothing usable. I'll edit this with a YouTube post shortly.
And here it is
To be clear, I pulled down a clean copy of v0.12 to make sure I didn't have any residual code changes in place before this last test.
Quoted from zebulon:Not sure if you're doing it or not but from what I read the advance key stops the scrolling and you repeatedly press the start button to scroll through the different display modes ....
Yeah, I saw that afterwards and did it again.
I had to build an extension to get the full switch matrix going, hit advance and then start. No change.
So, I started pulling chips, and I found at least one that didn't seem to make a difference when it was pulled. That told me that it was likely not making a good connection. Moreover, I used SIPP strips to make the sockets, and some of the chips seemed to be popping up a bit. I suspect that I might have a bad batch of SIPPs.
Anyway, I pulled the chips and started removing the SIPP strips to directly solder the chips to the board. I should have them replaced tonight.
Well, after all that hard work, I just lifted a bunch of traces trying to clean up the mess I made with the SIPP sockets. I'm trying to maintain some positivity at this point. The display side of this particular board is hosed completely.
Quoted from AmokSolderer:I'd like to track this problem down systematically, because any additional soldering might just further damage your board.
Unfortunately, that already happened. The display doesn't work at all at this point. My fault for not checking the SIPP sockets first.
Alas, it looks like my initial plan for a display won't work. The Due can run as a host, but only for mice and keyboards at this point. I'm switching to a Pi zero. Basically, open a serial connection and feed a display from that system. For APC.ino, I just need to open a serial connection and in WriteUpper and WriteLower just serial print instead(basically, add a flag at the top, have a branch in setup that starts serial and then a branch at the top of WriteUpper/Lower that writes DisplayText directly to serial instead). This will be useful for any machine that lacks the normal displays, or corner cases like my hamfisted repairs.
Quoted from AmokSolderer:You‘re going to need a Pi or a PC to host MPF anyway, so it makes sense to let it control the DMD also.
Yeah, that's my direction.
Quoted from AmokSolderer:Since V0.13 the APC software comes up in USBcontrol mode, which means you won’t need to bother with the APC settings and therefore you don‘t need any feedback from the displays.
Good point. I'll move to v.13 and report back. I also discovered that Serial and SerialUSB don't appear to play nicely with each other, so I'm making some hacks to let me test the mess I made right now.
Quoted from AmokSolderer:BTW, I have decided to believe that alcohol is best suited to prevent Corona and I‘m determined to follow this principle, so pardon me if I didn‘t get the point
When I burnt those traces last night, I felt like I needed a few shots....
ok, I went ahead and added the following(with a proper closing bracket and of course defining SerialDisplay at the top) to WriteUpper and WriteLower:
if(SerialDisplay == 1) {
Serial.println(DisplayText);
} else {
So, I'm getting my messages on the serial monitor now. However, I am not getting the behavior I expect. I use a jumper on the 4 pin header to jump to switch edge testing, but I can't seem to get any reaction from any combination of the switch inputs/drivers after that.
90664882_670416317096916_7335818400859422720_n (resized).png
Quoted from Compy:If I copy my MUSIC.BIN to SOUND.BIN on the SD card, the appropriate file plays, but it doesn't seem like the "music" channel is actually getting populated. I can see the file reads happening, but I never get any sound from the music track itself. The copying of music.bin -> sound.bin and hearing the contents verifies that the file is at least ok.
Check each lead on TDA7496. Make sure you are getting a signal on the INR and INL leads.
What's the serial connection parameters for a Due? I've tried 2 Dues and I'm getting weird errors. I'm on OSX. I've used a screen session, SerialTools and Serial Assistant tonight. No luck with any of them. I know that the baud rate is 115200. But, when I connect, sometimes I get nothing. Other times, I have gotten APC printed over and over again.
Ok. Changed to the built in python minicom, and I'm getting information.
00 gives me APC
01 gives me 00.13
02 gives me these api version .9
29, however, gives me a ?
Quoted from AmokSolderer:It's 29 hex, so 41 decimal. It returns one byte. The value 127 means that no switch has been triggered since your last query. If a switch has been triggered then bit 7 indicates whether the switch has been set or cleared and the lower 7 bit hold the switch number. You have to repeat sending 41 until you receive 127.
Ah, of course. I was using hexlify to autoconvert it, but I wasn't thinking about the initial input. Danke!
I'll mess with it over lunch. My thought is to write a quick python script that spams 0x29 until it gets a change and then uses 0x28 to get the state. A couple of questions.
1) I assume that APC queues up switch changes and that subsequent calls to 0x29 should display those switch events until I empty the queue, correct?
2) Are there any significant differences in 0.08 and 0.09 of the LISY protocol? The MPF docs reference 0.08, but the board is replying with 0.09 on the API call.
Quoted from AmokSolderer:I’m not sure what you want to achieve. For a simple switch test it would be sufficient to poll the changed switches by using 0x29 and after testing MPF will handle everything.
I was just thinking about a quick and dirty way to do all of the row/column testing without having to manually enter anything. This way, I could use a jumper wire, verify that I got a response with a glance at the monitor and move to the next switch. Saves a lot of typing
Quoted from AmokSolderer:Yes, it‘s crucial for you to use 0.09. We changed a lot, so I do not expect the APC to work with 0.08. The link to the MPF docs I posted is dealing with 0.09. I know it states 0.08 at the beginning and the 0.09 part comes later, but this is only partly true. May be we should ask Jan to remove this.
I think that the latest MPF uses 0.09, but you should probably use the dev version just to be sure.
Ok, just wanted to make sure I wasn't seeing a weird version mismatch when I noticed the change. I'm still at the testing stage. I'm planning on setting up my Jokerz to do some simple machine testing once I get the rest built(probably this weekend), and I'll be loading up MPF shortly after.
Right now, I have a couple of old PCs that I can install Linux on for a controller. Since I'm not working on a direct DMD driver via gpio pins anymore, I can get away from the need to use SBCs with headers.
Can someone try the following python and tell me if it behaves for you?
$ cat poll_apc.py
import serial
ser = serial.Serial(
port='/dev/tty.usbmodem1411',
baudrate=115200,
parity=serial.PARITY_NONE,
stopbits=serial.STOPBITS_ONE,
bytesize=serial.EIGHTBITS,
timeout=1
)
while(1):
print("Writing out 00")
ser.write(hex(00))
ser.flush()
print("Reading")
readval = ser.read()
print("value is " + readval)
It borked the spacing, so make sure to indent.
Installed debian buster on an i5 laptop and tried to pull in the dev branch of MPF. It was all fubar. Since it was quick and I wanted to eliminate the possibility of an incompatible debian package, I re imaged the machine and used the debian installer. Worked fine the first time. I'll be working on setting it up with APC today.
ok, I have 2 Dues. I updated both and tried MPF with the generic APC config from the MPF site. This is what I get:
2020-04-02 14:29:18,717 : INFO : Machine : Mission Pinball Framework Core Engine v0.53.3
2020-04-02 14:29:18,717 : INFO : Machine : Command line arguments: {'no_load_cache': False, 'create_config_cache': True, 'bcp': True, 'configfile': ['config.yaml'], 'mpfconfigfile': '/usr/local/lib/python3.7/dist-packages/mpf/mpfconfig.yaml', 'force_assets_load': False, 'jsonlogging': False, 'logfile': 'logs/2020-04-02-14-29-18-mpf-Ares.log', 'pause': False, 'production': False, 'text_ui': True, 'loglevel': 15, 'consoleloglevel': 20, 'force_platform': None, 'syslog_address': None, 'mc_file_name': None, 'no_sound': False}
2020-04-02 14:29:18,717 : INFO : Machine : MPF path: /usr/local/lib/python3.7/dist-packages/mpf
2020-04-02 14:29:18,717 : INFO : Machine : Machine path: /home/mlatiolais/pinball/stranger_things
2020-04-02 14:29:18,717 : INFO : Machine : Platform: linux
2020-04-02 14:29:18,717 : INFO : Machine : Python executable location: /usr/bin/python3
2020-04-02 14:29:18,717 : INFO : Machine : Python version: 3.7.3 (64-bit)
2020-04-02 14:29:18,717 : INFO : Machine : Machine config file #1: config.yaml
2020-04-02 14:29:18,718 : INFO : ConfigProcessor : Loading config from cache: /tmp/d7568d6f98feaa7123aa03a54368bc0d.mpf_cache
2020-04-02 14:29:18,720 : INFO : Machine : Initialise MPF.
2020-04-02 14:29:18,790 : INFO : lisy : Connecting to /dev/apc_board at 115200bps
2020-04-02 14:29:19,397 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:19,899 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:20,401 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:20,904 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:21,406 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:21,908 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:22,410 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:22,912 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:23,414 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:23,916 : WARNING : lisy : Reset of LISY failed. Did not get a response in 500ms. Will retry.
2020-04-02 14:29:24,139 : INFO : EventManager : Event: ======'machine_var_lisy_hardware'====== Args={'value': b'', 'prev_value': None, 'change': True}
2020-04-02 14:29:24,140 : INFO : EventManager : Event: ======'machine_var_lisy_version'====== Args={'value': b'', 'prev_value': None, 'change': True}
2020-04-02 14:29:24,140 : INFO : EventManager : Event: ======'machine_var_lisy_api_version'====== Args={'value': b'', 'prev_value': None, 'change': True}
2020-04-02 14:29:24,142 : INFO : Machine : Shutting down...
2020-04-02 14:29:24,143 : INFO : EventManager : Event: ======'shutdown'====== Args={}
2020-04-02 14:29:24,183 : ERROR : Machine : Failed to initialise MPF
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 684, in initialise_mpf
raise init.exception()
File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 240, in initialise
await self.initialise_core_and_hardware()
File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 236, in initialise_core_and_hardware
await self._initialize_platforms()
File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 327, in initialize_platforms
result.result()
File "/usr/local/lib/python3.7/dist-packages/mpf/platforms/lisy/lisy.py", line 435, in initialize
if self.api_version >= StrictVersion("0.9"):
File "/usr/lib/python3.7/distutils/version.py", line 70, in _ge__
c = self._cmp(other)
File "/usr/lib/python3.7/distutils/version.py", line 170, in cmp
if self.version != other.version:
AttributeError: 'StrictVersion' object has no attribute 'version'
2020-04-02 14:29:24,185 : INFO : root : MPF run loop ended.
As far as I can tell, both boards respond the same. This is the config I used:
http://docs.missionpinball.org/en/latest/examples/apc/index.html
Interesting. I was using my mac to update until I set up this system. It seems to write faster and give me more debug info. I updated the code to V00.13, and it initialized, then failed with an exception:
Shutdown because of an exception:
Runtime Exception
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 765, in run_loop
raise self._exception['exception']
File "/usr/lib/python3.7/asyncio/events.py", line 88, in run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.7/dist-packages/mpf/core/events.py", line 102, in async_handler_done
future.result()
File "/usr/local/lib/python3.7/dist-packages/mpf/core/device_manager.py", line 113, in load_device_modules
self.load_devices_config(validate=True)
File "/usr/local/lib/python3.7/dist-packages/mpf/core/device_manager.py", line 177, in load_devices_config
config[device_name] = collection[device_name].validate_and_parse_config(config[device_name], False)
File "/usr/local/lib/python3.7/dist-packages/mpf/core/device.py", line 104, in validate_and_parse_config
self.config_section, config, self.name, "device", prefix=debug_prefix)
File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 292, in validate_config
validation_failure_info, k))
File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 320, in validate_config_item
validation_failure_info)
File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 757, in validate_item
return self.validator_list[validator](item, validation_failure_info=validation_failure_info, param=param)
File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 477, in validate_type_machine
6)
File "/usr/local/lib/python3.7/dist-packages/mpf/core/config_validator.py", line 776, in validation_error
item, msg), 5 if code is None else code, self.log.name)
mpf.exceptions.config_file_error.ConfigFileError: Config File Error in ConfigValidator: Config validation error: Entry autofire_coils:ac_slingshot:playfield = "playfield" is not valid. Device playfield of type playfields not defined Error Code: CFE-ConfigValidator-6 (https://docs.missionpinball.org/en/0.53/logs/CFE-ConfigValidator-6.html)
I'll dig into the config to see if something looks amiss. This is on a board unconnected to the APC yet. Is there a chance that this version of MPF(v0.53.3) isn't compatible with 00.13?
Found the playfield error by comparing Rollergames to the minimal one. Now, I'm back at the StrictVersion issue.
Shutting down...
Event: ======'shutdown'====== Args={}
Failed to initialise MPF
Traceback (most recent call last):
File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 684, in initialise_mpf
raise init.exception()
File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 240, in initialise
await self.initialise_core_and_hardware()
File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 236, in initialise_core_and_hardware
await self._initialize_platforms()
File "/usr/local/lib/python3.7/dist-packages/mpf/core/machine.py", line 327, in initialize_platforms
result.result()
File "/usr/local/lib/python3.7/dist-packages/mpf/platforms/lisy/lisy.py", line 435, in initialize
if self.api_version >= StrictVersion("0.9"):
File "/usr/lib/python3.7/distutils/version.py", line 70, in _ge__
c = self._cmp(other)
File "/usr/lib/python3.7/distutils/version.py", line 170, in cmp
if self.version != other.version:
AttributeError: 'StrictVersion' object has no attribute 'version'
Ok, so I figured out what I'm seeing, but I'm not sure why.
If I get the system to connect once, if it has a config issue, it will halt. And then any subsequent attempt to connect with MPF will fail. However, if I load the sketch again via the IDE, it will work again. Is there some flash or EEPROM being set that will stop the sketch from loading again?
Quoted from jabdoa:Hi guys,
That looks like an error in MPF. It might be caused by LISY but ultimately MPF should log something useful here. I will have a look and fix it.
Jan
Thank, Jan. I was the one posting about the debian buster problem on the mailing list.
So, this is what I have found. I have to unplug and replug the USB connection to allow MPF to communicate with the Due. Once I've done that, assuming that I have a valid config, the system will work. Not sure if it dies after the loss of the watchdog or something of that nature. It has to be something with the Due, since reprogramming it with the IDE also fixes the problem.
Regardless, now that I can get that working, I'll be able to properly test the switch matrix. Then, I'll finish populating this board. I also have to build a couple more APC boards, and my fellow homebrewers are getting excited.
EDIT: to clarify.
When I first plug in the board or reprogram it, I can connect MPF to it. After that, I have to unplug/replug or program it to get it to talk to MPF. Doing a ctrl-c to kill MPF and then attempting another run will fail every time. Hitting reset doesn't help, either.
I was able to find some time to test the switch matrix tonight. Everything looks good. Going to finish this board and start testing in game.
Quoted from lucky1:Would you share the source for that hack ?
Sure thing. My fork of pinmame is here: https://github.com/mikelatiolais/pinmame_fork
I update the dmd in wpc.c line 402. That's calling the code in src/oppa.
Keep in mind that this is fairly old and had issues. I was in the process of moving it out to a thread based model when I decided to drive it with a smart matrix instead. I may have committed some broken code, so you might want to check out other revisions if you have trouble. Also, this was still using wiringpi, and I planned on moving to another gpio library.
It's pretty straightforward. I just used the Vishay datasheet to make a quick function to take the DMD array and fill.
Quoted from AmokSolderer:If you face a problem during testing, please promise to keep your soldering iron holstered and give me a chance to guide you through the debugging process first
Sure. I'll be building another one shortly, too.
Ok, so when testing the switches I saw something odd.
I set up 64 switches in a generic manner:
s_00:
number: 00
s_01:
number: 1
...
s_64:
number: 64
I see a couple of problems. For example, s_00 is always showing as activated, and s_08 doesn't activate at all. The odd thing is, different combinations using those pins works, so this isn't a bad column or row.
Anything I should be looking for?
Quoted from AmokSolderer:I remember you had tested the switches successfully with this APC board. That means we can exclude any board related issues, right?
I'm not going to completely rule that out, but given the fact that other combinations work, I'm going to start with the assumption that I've messed up the config file somehow.
Update: I ordered some of the Siegecraft testing boards which are showing as "out for delivery" right now, so I'm going to do a more systematic switch testing this evening. This will also give me a chance to test the solenoids and lamps. I'll try to post my testing methodology for anyone that might need it going forward.
I've gotten the Smartmatrix to display with MPF now, so I will be setting up a simple config that uses both platforms. This is my expected configuration for the custom games(though I am now thinking about using another APC board to control Jokerz! instead of repairing the original MPU. The problem is that I've never played Jokerz!, so I don't actually know the rules...). The second thing I'm doing is going back to my pinmame work and moving from a direct gpio based DMD drive to the Smartmatrix, so that I can migrate that into the pinmame->APC project.
Ok, quick escape to the project during lunch. Since the switch matrix responded to s_01 where I expected it to activate s_00, I went ahead and deleted s_00 and added s_64. Then, I tested each combo. Again, switch 8 is unresponsive, but all other switches seem to be working. I would expect to see every eighth switch be unresponsive if it were an entire column or row. So, this is a slight mystery. I'll do a more in-depth test tonight. @jabdoa, is there something in MPF or the APC platform that could explain this?
I also have the special solenoid driver and a solenoid tester, so I'll be testing all of the solenoids tonight. I'll take some pictures of the setup, and maybe a video. Depends on how ambitious I get tonight.
No, I rewrote it and even copied s_07 and just changed the name and switch number with no change.
Nevermind on the other stuff. That's the watchdog. I'll dig in more.
---
Ok, took a few minutes to look at it more closely. I see no activity from the MPF side when I hit s_08.
Actually, I just looked up the USB_SwitchHandler. It's basically a switch statement.
It looks to me like switch 8 can't be activated as a normal switch:
case 8: // high score reset
digitalWrite(Blanking, LOW); // invoke the blanking
break;
Unless there is a reason not to, shouldn't this be treated as a normal switch in addition to the blanking? Catch the 8 in the default case and just add an if to do the blanking? I could fork it and send in a pull request if that sounds sane.
I tried out the special solenoid tester after adding switches 65 - 72, and it seemed weird. So, I pulled it off and ran a ground jumper on each pin. Not all of the pins responded. I believe 65 - 69, and they weren't in order(65 on first pin, 66 on next, etc). What's the expected pinout of the special solenoid switches?"
Also, shouldn't these be causing the special solenoid pins to ground? I put the LED tester on the special solenoids, and none of them lit up. I thought that this should happen without MPF intervention.
I'll add all of the solenoid outputs to the MPF config today and see if I can some responses.
Quoted from AmokSolderer:I have attached the corresponding part of a Williams Sys7 manual.
I'm sorry, I should have thought to look that up. In my defence, I didn't get a chance to test until after midnight, so I was a bit foggy.
All of the expected switches work. For some reason I had it in my head that 71 and 72 were on there are well.
Quoted from AmokSolderer:No, the APC treats them as normal switches, so you have to define a 'Hardware Rule' in MPF to make the special solenoids respond to them.
This clears up a lot. I'll set up rules for the solenoids to start testing.
I also need to build a lamp matrix. Siegecraft was out of stock. EDIT: Nevermind, my idea about the 16 LED version wouldn't work.
Working on testing the solenoids. I used a simple setup on MPF:
hardware:
lisy:
switches:
coils:
playfields:
flippers:
I expect to see one of my test LEDs light up, but I get nothing. The switches activate and deactivate as expected. Any ideas?
#config_version=5
platform: lisy
connection: serial
port: /dev/ttyACM1
baud: 115200
s_left_flipper:
number: 1
s_right_flipper:
number: 2
c_flipper_left_main:
number: 1
c_flipper_left_hold:
number: 2
allow_enable: true
c_flipper_right_main:
number: 3
c_flipper_right_hold:
number: 4
allow_enable: yes
playfield:
tags: default
default_source_device: None # use None in steps before 8
left_flipper:
main_coil: c_flipper_left_main
hold_coil: c_flipper_left_hold
activation_switch: s_left_flipper
enable_events: machine_reset_phase_3
right_flipper:
main_coil: c_flipper_right_main
hold_coil: c_flipper_right_hold
activation_switch: s_right_flipper
enable_events: machine_reset_phase_3
(pinside mangles the spacing, but it's correct on the original)
This is still bench testing, so there is no machine. I wanted to verify that each solenoid output will pulse with an LED prior to plugging this into a machine.
So, what I'm wanting to do is enable a bank of 8 solenoids that I can then activate with 8 switch events. Barring that, tying a single solenoid firing to a single button will do.
I'll experiment with pulse_events today. Are these defined somewhere? I don't see balldevice_bd_lock_ejecting_ball being defined in your configs, so I assume that the naming convention is defined by MPF.
Quoted from AmokSolderer:Oh, right. If you want to see the corresponding config you have to look into the V0.13 branch.
I hope it's only a few days before I can do the new release. The current master branch is rather outdated.
I pulled V00.13 and this is the only reference I find:
$ grep -R balldevice *
Rollergames/config/config.yaml: balldevice_bd_lock_ejecting_ball: 0.5s
How does MPF know what balldevice_bd_lock_ejecting_ball is? Does it parse the string and figure out that this is referring to the bd_lock ball device?
AHA! That's what I was missing!
http://docs.missionpinball.org/en/latest/events/index.html
I searched through that page for a while and couldn't find that index. Weird.
ok, I'll spend some time today trying different things. I don't expect to see any weirdness with the solenoids, but I want to doublecheck before I start using it in my first custom machine. I am using Fadecandy for the inserts and Smartmatrix for the DMD, so my board will work fine as long as I have switches and solenoids working properly with MPF(and, eventually, pinmame. But I need to add smartmatrix support into it first).
Ok, something must be wrong with the outputs. I changed the switch handler for switch 8 to pulse each solenoid:
void USB_SwitchHandler(byte Switch) {
byte i = 0;
switch (Switch) {
case 8: // high score reset
//digitalWrite(Blanking, LOW); // invoke the blanking
for(int i = 0; i < 24; i++) {
USB_FireSolenoid(255, i);
}
break;
I expect to see a flash on each solenoid output, and I still get nothing.
EDIt: Yeah, I see my stupid mistake. I reused i. Let me fix it. Still, the redefinition in the for loop should take precedence.
I pulled the lisy pinmame code and started working on a smartmatrix DMD connection. If I get it working well, I'll share the code.
In other news, I think my early damage might be hampering some of my work now, so I'm making 2 more boards and I'll check those. I gutted APC.ino to make a very simple solenoid activation, and none of it worked. Once I have another system built(without those oxidized SIP modules that caused me problems before), I'll be more sure of my testing. I'm almost done with the first step on the new boards, so I expect to be doing sound tests tonight.
Quoted from AmokSolderer:Actually, we're collecting ideas for the new APC board at the moment, but up to now adding the PI is our only functional upgrade.
For my work, a Pi is somewhat underpowered(even a Pi 4) compared to, say, an ITX board. When converting DMD frame information generated by pinmame into RGB information for Smartmatrix, for example, a Pi will lag where a cheap ITX will shine. Lisy uses the GPIO(and my previous DMD work did as well), but that doesn't have to be the case for all pinmame->APC connections.
My preferred system, based on my needs:
PC running pinmame or MPF
(USB)
|
|------> APC for playfield control
|------> Fadecandy for inserts
|------> Smartmatrix for RGB DMD
Quoted from AmokSolderer:Well, let's put it this way: you're probably not the typical user.
Indeed, I am typically atypical
I'll share my code shortly. I'm working on the Smartmatrix display first, but I plan on adding a direct connection to APC to pinmame, based on the lisy code(unless a simple way to use the existing code occurs to me).
My new APC builds are going nicely. I'm planning on going back over the first board and repairing once I have the new ones up.
You can run MPF-MC on a Pi. You'll run into I/O speed if you are pulling data from an SD card. If you are doing simple stuff, it should be fine. Look at the previous discussions on this thread to see more.
My projects are on a standstill for a moment. I have to get a Flintstones and Lost World Jurassic Park cleaned up for next month, so my attention is sapped. 
Quoted from RatShack:The PI probably doesn't have enough power for my MPF game, it uses a 1080p display and has a very large music library.
My hope here is since the PI is communicating using serial-over-USB that the code is easily adaptable to the Windows build. If there's a PinMAME repo with these changes I'd like to check it out.
Why not ditch the Pi for an ITX or micro ATX motherboard with a Debian install? No need to adapt to Windows at that point.
I would prefer all of the smd parts to be on one side. I'm ambivalent about the ICs being smd or not, if I'm getting them prepopulated.
Quoted from lucky1:I implemented a routine to send the raw frame data of pinmame to my PIN2DMD. That way there is only the USB transfer to be handled by the Pi and the frame calculation is done by pin2dmd
Where is this code? I'll happily switch to pin2dmd.
They aren't hard to build(ignore my travails, I was the victim of my own hair trigger choices). I haven't heard of anyone selling completed boards.
Well, there are lots of smd stuff on the driver side, too. But none of it is particularly bad. I even use the same solder tip for smd.
Quoted from AmokSolderer:The SMD version of the 3.0 hardware is ready.
Alas, during the ordering process I had to learn that the SOIC version of the IC I used most on the board has run out of stock at JLCPCB. They still have it in TSSOP, but while SOIC can still be soldered by hand quite well, this is much more difficult with TSSOP. So in the end it would mean that most people could not service their board in case of a defect.
That was not my intention, so I just ordered 5 boards and I now have to solder the missing ICs by hand. Let's hope they're back in stock soon as this somehow betrays the idea of easing the assembly by letting the manufacturer do the job.
But there's also good news, as the price for the SMD components and the assembly fee is below 10€ per board, which is a very good price IMHO.
Will the code change significantly between the older version and 3.0?
Quoted from AmokSolderer:BTW any updates from your projects?
Well, my life is hectic right now. Had a niece move in with us, half the state is thick with wildfire smoke and most of my attention has been on getting some games repaired and out of the door to either be sold or brought to an arcade. So, I haven't made much progress since I last checked in. The other project I was helping on is progressing. She's getting the artwork done.
I actually have another opportunity to use the APC. My homebrew project is waiting on art, but I have the opportunity to buy a Strange Science populated playfield. I haven't got a chance to see it yet, but it appears to be complete. My thought was to wire it into an APC and write new rules in MPF while I wait for art on my other projects.
Quoted from AmokSolderer:If you don't want to use the WPC power driver board, you could theoretically wire your playfield to the APC, but there're some differences that you have to take care about.
Strange Science is a pre-WPC Bally system. It has an odd, direct drive lamp setup, but the switch matrix looks normal(I haven't actually got to dig into it). I'm hoping to go take a look this weekend and see if it's worth saving.
Quoted from AmokSolderer:Oh, sorry I somehow confused Strange Science with Scared Stiff.
Strange Science is from the generation that Bally built shortly before they were bought by Williams, right?
No problem. You were correct in that I was previously thinking of doing a 1 off Scared Stiff based on APC. However, that machine is likely to be delayed, as I have an original SS coming in from Italy. The parts I collected will likely be used to do a restoration on it. If the parts I have left are good enough, I would still like to do the pinmame->APC work.
I was originally doing a custom Stranger Things machine, but the Stern version has frankly killed a lot of my momentum. And my artist is knee deep in college work. :/
So, if I were to switch to Strange Science, I
a) don't need to come up with the original artwork
b) don't need the extra solenoids, etc, that a WPC would require
So, I am picking up a Stern Whitestar system tomorrow. It would be a convenient way to rectify and fuse the power for my system. Of course, the power i/o board in the Whitestar has its own driver section, which i think is driven by data bus of sorts. Piecing together some docs from the P-ROC and the partial schematics i have, it looks like there are 8 data lines and 7 enable lines. Think it would make sense to be able to drive that from the expansion bus?
I've done some investigation, and this is my findings so far: https://pinside.com/pinball/forum/topic/question-about-whitestar-sam-mpu-to-power-i-o-#post-5887009
So, practical upshot:
There are 8 data lines(Dx) and 4 address lines(Ax). The first three address lines(A0-A2) are fed into 2 demuxs as address lines. A3 is used as an enable signal for the demuxs, giving us a total of 16 possible 8 bit banks(several of which aren't used and are disconnected on the 2nd demux). There are two other important signals, RESET and IOSTB(IO Strobe). IOSTB is used to indicated that the current address on A0-A2 is viable(not an indeterminate value during an MPU reset or the like).
So, my idea is to have an Arduino sitting on the expansion bus. Once enabled, it will watch the blanking line to kill things, and put the board into reset if need be. Then, it will watch for commands to fire a solenoid. I could add lamps, too. I'm on the fence, but if I'm already controlling solenoids, might as well have all normal output getting caught and sent here.
If I am not using it for lamps, I'll just have it do the lamp polling that needs to happen for the watchdog.
The question I have is speed. I'm thinking that plugging in a Teensy will obviate that concern. I see that there is a 600Mhz Teensy now. It should be 3.3v. I may have to level shift the output.
It's not that it offers anything better. I decided to use it to rectify and fuse the stern transformer I'm using, but I already have to poll the lamp matrix to keep the watchdog chip from resetting. If I have to drive that anyway, why not use it for the other drivers? I was planning to build a simple rectifier board originally, but i worry about making a mistake and frying something. Or worse, starting a fire.
If i get this working, it also expands the possible uses of the APC to also drive Whitestar and SAM Stern machines. And, for homebrew games, you could run two lamp matrices and a second bank of solenoids.
RE: #3 - I use JLB. Fast and priced well. I ordered 5x boards when I did mine. I think I have 1 that is mostly unpopulated(I just started adding some of the extra components to it with the expectation that I will eventually finish it). I had to switch to rebuilding some machines, so I'll have to dig it up and find out how far I went.
#4 - The OP made a board to control neopixels: https://github.com/AmokSolderer/APC/tree/master/DOC/Hardware/APC_LED_exp
Quoted from aaronhmorris:Does that plug into the main APC board?
Yes. If you look back through the discussion, he mentions how it works. The .ino file is also there in the github repo. I'm currently building an interface to control Stern Whitestar/SAM power I/O driver boards.
Quoted from aaronhmorris:How much did JLB cost you?
I misspoke. I used JLCPCB. Is that what you meant?
I think it was about $35 for the bare boards. I haven't tried to price the new surface mount version.
Quoted from aaronhmorris:Wish we could get the BOM cost down a bit.
The biggest savings would be to wait until JCLPCB gets the missing parts in stock again. Then, you could get all of the SMD work done for you for cheap. Other than that, I was able to drop the price by a few bucks by getting 4 sets of parts ordered at once.
Quoted from AmokSolderer:Instead you'd have to change the HW_driver on APC.ino to support the addressing via the display signals.
My plan is a bit simpler. I'm not going to directly drive the i/o bus. Instead, I'm going to send it 2 bytes of data along with the select line. My teensy will catch the 2 bytes, interpret the bottom bits of the first as the address lines and the second as data and pass those signals to the stern board. It will also use the blanking signal to force a reset of the i/o board.
I'm completely ignoring the bi directional part of the i/o bus. Rather than alter the hw_ext bus. I would be more inclined to have the teensy catch that and use SPI or I2C to feed that data back to the arduino. But so far, i haven't found an example of the board where the aux_in is even populated, so I suspect that leaving this capability out won't affect much.
Quoted from AmokSolderer:This is also possible and you don't even need a Teensy for that - two 8 bit latches should do the job.
I'll use a Teensy for 2 reasons:
1) I don't have any latches in my box, but I do have a spare Teensy
2) I may need to do some more complex work. The I/O board also has a watchdog chip on it, and if someone opts to use the lamps on the APC board, there still has to be a lamp strobe. The Teensy can do this in the background, even in the case that the I/O board is used for nothing but feeding voltages to the APC.
Very nice! I've been working on the interface for the Stern boards. Hopefully I will make enough headway during an upcoming break to get the code posted.
What are the dimensions of the new board? JCLPCB won't let me do a quote without them. Same as the previous version?
EDIT: using the original size, I was able to get it to work. For me, it's $85 shipped to the US, populated. Is there a BOM for the remaining required parts for an SMT populated board?
Quoted from bigfoot53:Have the same issue but i don't know what the original dimensions were .
237 mm* 200 mm according to my jclpcb order history.
So, I have 4 other people wanting a board. That's all 5. For those interested, that's $25/board shipped to me, populated with the SMD parts. You would need:
- pay for the shipping from my place to yours(or, pick it up locally if you are in the Bay area). I'm thinking $10-15 is likely anywhere in the US.
- the through hole parts(https://github.com/AmokSolderer/APC/blob/master/DOC/Hardware/Assembly/APC_BOMnonSMD.pdf)
- Arduino Due
- An micro SD card + adapter(they are usually sold as a pair)
- (optional) A raspberry Pi zero
I'm going to see what a batch of the non-SMD parts would cost to include in the box, leaving you to source the Due.
Pricing it at 10x boards, it would be about $17/board, plus the above. I imagine that the shipping for 1 or 2 boards would be the same, so you are looking at $50 or less to get a couple of boards.
Assembly, it looks like 2 ICs(the 74BCT760 and the TDA7496, some assorted parts like LEDs and switches, and the normal complement of connectors and headers: https://github.com/AmokSolderer/APC/blob/master/DOC/Hardware/Assembly/APC_components.pdf
If I get enough interest to order 10, I'll do that.
Thanks again for your hard work, @AmokSolderer!
Tentatively, it looks like, for a 5x purchase, each batch of non-SMD parts would be $57. But some of it is backordered at Mouser, so you are probably looking at a bit more to get it sourced from multiple spots. Mouser also has Arduino Due's for $36/each.
So, you are looking at a kit board capable of running anything from a Sys3-Sys11, or a homebrew, for:
$40 (populated board shipped to you)
$36 (Due)
$57 (through hole parts)
-----
$133 shipped.
That's at the 5x board order. 10x would be less per board and per Mouser part(they usually have price breaks at 10x and 100x parts).
Let me know what you think, or if I'm missing anything egregious.
Ok, this is the list I have so far
1. waveman x 2
2. Cheddar x 2
3. truemagoo102
4. Grangeomatic
5. 
mwiz
6. polishedball x 2
7. Me x 2
8. bigfoot53 x 2
That's 13 of the boards with the SMD parts populated.
Now, who would want to be part of a group buy for through hole parts?
Also, let me know if I need to make this a separate thread.
Edit: up to 12 now, so we're going for 15 or 20.
Through Hole Parts
1. polishedball
2. bigfoot53 (x 2?)
3. mwiz
4. Grangeomatic
Looks like 4 or 5 sets of through hole parts. I'm ok with setting this up, but if someone else can find a better price, I'm ok with that as well.
Please let me know if you want to get in on the parts order(or want to organize that part).
I will try to export one and share it today. I went to mouser, since amoksolderer added part numbers for their site to his BOM. If we can get a better price for those parts, I'm all for it.
Also, I've had a couple of other people ask about boards, but not commit at this point. So, I priced them at 15x and 20x. Comes out to $15 and $14 per board before shipping from my house.
Moved the discussion over here: https://pinside.com/pinball/forum/topic/arduino-pinball-controller-group-purchase#post-6044822
The Sys7 boards are close enough to the previous generations that it shouldn't be an issue, IMO.
I can report back on a Sys3 as soon as the boards come in, as one I am getting for a friend is going into a World Cup.
I've started a page for APC on the pinball makers wiki: https://pinballmakers.com/wiki/index.php?title=APC
Given the context, it will mostly be used to describe how to use the APC with a homebrew or semi-homebrew system.
Note: I literally just created it, so there nothing there but a blurb for now.
I just got an email from JLCPCB that there was an error with the boards I ordered. The holes circled in red are not drilled, as you can see. They have asked for my guidance on what to do(whether they can simply be drilled out or if they need to be plated). AmokSolderer what are your thoughts?
undrilled_apc (resized).jpgQuoted from AmokSolderer:Did you understand what the problem is? Did they make a mistake or is something wrong with my data?
I will try to get to the bottom of it and report back.
This is the reply. It is a bit garbled in translation:
So finally we use the non-plated hole for these holes.
It's better that you could move these holes from the current Layer into the Outline Layer.
So next time it will be drilled directly without being plated.
Quoted from AmokSolderer:Basically, I'd prefer to have these holes plated, because you can never have too many ground connections. However, it doesn't really matter and I think you were right to agree having them non-plated in this case, as from your shot it looks like they simply forgot to drill them. This means they probably would have started from scratch, because they cannot add the plating at this stage. So in the end insisting on having the holes plated might have caused a week of delay for no real benefit.
Those were my thoughts as well. I thought that steel screws would provide some measure of grounding as well.
Quoted from AmokSolderer:Good ideal BTW.
I've been meaning to create this for a while. Just haven't gotten around to it until now.
Do you mind if I pull pictures from your github repo? I will do a blanket attribution on the page and of course a lot of links back to your repo.
Quoted from AmokSolderer:Yeah, but you wont even need it. My boards are mounted on wooden slats so no ground connection for the screws at all and they work anyway.
Duly noted. I'm still investigating possibilities for making clean looking offsets for custom panels.
Quoted from AmokSolderer:No objections from my side. Feel free to use the stuff from my repo.
Will do. Thanks!
These look good. Thanks, AmokSolderer !!
140188661_205600937955211_4993392817857496397_n (resized).jpgAmokSolderer Did something change with the new version in regards to the extension bus? I see a change in the select signals, but it might just reflect a name change.
Quoted from Edy_Wang:Hi everyone, new to APC, have a Firepower and wish to rebuild using this board
By any chance has another member used APC in a Firepower ?
Starting to code in C++ looks very different from just plain C.
So I was looking for another member who might have already programmed
one for their Firepower ?? give me some help or tips where to start
Are you wanting to do the code in C++ or Python? I would suggest using MPF for this instead. It will require another board to run the MPF code, but then you can just define the system in YAML to get most of the functionality. https://docs.missionpinball.org/en/latest/tutorial/
If not, I would think that the Black Knight code that AmokSolderer posted would be a good place to look.
Quoted from matiou:I guess you can also just use lisy to get the pinmame emulation of Firepower, and not code any line...
I think you will still need to set up the YAML file describing the game.
At the moment, I'm using it in three homebrew projects, one of my own and two friends. One of those is a Sys3 World Cup. One is based on a Lethal Weapon playfield that's being rethemed. And mine is a new version of Strange Science.
EDIT: It occurs to me that 2/3 of those aren't really homebrew at all.
Quoted from AmokSolderer:You're doing everything in MPF, right?
At this point, yes. My Scared Stiff project lost steam when one landed in my garage. So:
- a populated Strange Science machine, where I am removing the SCR based lamps(may go with serial LEDs, since I need 90). Switch and solenoid connections should be easily adapted. I'll be driving a pin2dmd display from MPF instead of individual display boards.
My friends' projects:
- a populated Lethal Weapon 3 that is being rethemed. Again,should be fairly easy to adapt.
- a complete Sys3 World Cup. No mods to the physical playfield, just deeper rules. Maybe a slight mod to make it a multiball game if he gets ambitious after the initial conversion.
Those three are all MPF driven.
That being said, I will have most of a Scared Stiff left over once I'm done with a rebuild on mine. If my previous DMD experiments work with a Pi4 and we get the LISY pinmame to work with WPC-95, I may still tinker with building one as a proof of concept.
I could just feed the display output into an Arduino mega, use a lookup table to match the input pattern with an ASCII character and then use a 2 row I2C LCD(I have one sitting around anyway) for a fairly compact bench display.
Quoted from AmokSolderer:You'd need a 3.3V device for that. When I remember right then the mega runs on 5V.
Fair point. I will switch to a Teensy 3.5(works with 3.3v but is 5v tolerant). Now I want to make a board that would work with sys 3-11, since I have often worked on Williams projects with dodgy displays. But it will likely be a more long term project.
I've got 3 of the v2.4 boards, each with some surface mount parts installed. If anyone wants them, $10/each plus shipping obo.
I also have a stash of the surface mount parts. Won't make any guarantees, but there should be enough to finish 1 or 2 of those parts of the boards. I'll add those for $5.
20210425_124218 (resized).jpg20210425_124220 (resized).jpg20210425_124407 (resized).jpg20210425_124411 (resized).jpg
Quoted from brovreizh:The problem is that I can not solder smc component by myself, it's too small for me.
There is kind of a trick to it. Basically, you put a smear of paste across all of the leads on both sides, and then melt it with a normal iron. Surface tension will make the solder stick to the pads and the leads. You can use a little solder braid to clean up any remaining bridges.
Here's another simple technique:
You can order them from mouser or digikey. An example: https://www.mouser.com/ProductDetail/ON-Semiconductor/MC74HCT273ADTR2G?qs=qg33o%252B8vzFqkTJ38xfgz%252BQ%3D%3D (@amoksolderer, please correct my part link if I'm wrong).
System 6 power supplies are pretty cheap to fix and buy. Grab a spare
ebay.com link: itm
Quoted from matiou:the one you linked is missing the big capacitor though
I always change all the caps out regardless.
If you use a separate 5v source, i would imagine that the main concern would be to tie the grounds together. I've done that with switching power supplies but never a transformer and a switching ps.
While this is likely not the fix for @matiou, you can use a board like this to buffer the high voltage current and safely ground multiple power supplies: https://www.multimorphic.com/store/circuit-boards/power-entry/
Very cool! When I was going to try this with Scared Stiff, I was thinking of a similar approach to enabling the kicker for "Saved by the Spell." Basically, if saved by the spell is active and the left outlane switch activates, fire the kickback and catch the next trough launch and ignore it.
There are a lot of people who have asked me for spare boards. Is there enough interest for another run?
OK, so I posted this because of all of the PMs I was getting recently. I would be happy to help someone with getting an order done, but I don't think I have time to do it myself right now.
Looks like it would be problematic right now anyway. Just for kicks, I tried to do a board reorder, and I see this now:
["C55887","C5983"]out of stock
Not sure if they will be back in stock.
Quoted from HighVoltage:I just had a run of PIN2DMD boards done, and can get a quote for APC boards. Can you give me an idea of the number of people that showed interest?
I think I've gotten requests from around 10 people so far since I ran out of extra boards. Not sure I kept the message threads, so probably just advertise here, and you will get a bunch of them.
Quoted from HighVoltage:IRF7316 is not currently available. Is this APM4953 a compatible replacement? Click on images for full datasheet.
Looks good. Do they have a replacement for the 74hct273?
Quoted from HighVoltage:Looks like the DUE I ordered for my board doesn't have headers. Was wondering if it would be a problem just to solder it to the board. What inconveniences will that create?
I would solder the headers on. Same pain in the ass of soldering it to the board, but you can remove it afterwards. I've fried arduino boards before, and I would always opt to be able to easily replace it.
I might have a v2.4 and a v3 board for sale soon. It is coming in as a trade from someone who bought one of the previous boards from me. I think that the v2.4 build was started, then he bought the v3 board and then ran out of time. So, it should have all of the parts for the 2.4 build, which would include the parts needed for the v3. You could order the v3 through hole parts and build both. Or, I could sell them separate. Anyway, PM me if interested. I'm still waiting for the trade to finalize.
Quoted from Apex:I would appreciate this info. I have dabbled with a Fast board and getting that going was pretty easy. I second that the documentation on how to bridge mpf to the APC board is either over my head or skipped.
It's basically the same as any other MPF platform. You can see an example here: https://github.com/AmokSolderer/APC/tree/master/DOC/Software/MPF
I also had a basic config set up while I was last testing(before the unmentionable desoldering ruination which killed me). I'll post it shortly, once I get a chance to boot up my old laptop. I have since moved to a small Chromebox reinstalled with GalliumOS for control, so it doesn't have my old code.
EDIT:
I checked my old code. It's nothing very different from the one in Github. I would start there.
I'm about to start work on a High Speed rework with @cheddar, which will have new art, rules, a display, etc. Eventually, I have a fully populated F-14 that is begging to come back to life, preferably as a Top Gun rework(I use rework instead of retheme as it is more than just changing the theme out).
Quoted from AmokSolderer:Would be great if you could post the progress either here or in a new thread. Doesn't have to be some detailed documentation, just some pics and the basics of what you're doing.
I'll start up a new thread and link it here.
I have a jokerz, but no oscilloscope to display it on. I would note that the same board is also used on scared stiff for the spider.
I would look at two things to start.
1) Pull the Pi out and see if it boots with a monitor. It may be failing to boot. Could be a dodgy or loose SD card or something like that.
2) If the pi boots fine independently, check the solder joints on the connectors.
Yeah, I'm thinking it's a typo.
For System 3, you will need something that can drive 12x8 lamp and switch matrices. Nothing I know of off the shelf is doing that right now.
That being said, if I were going to do something of this nature, I would start with a cobrapin board and see if I couldn't use 2 more of the switch pins to expand the switch matrix, then build a new version of the Xpansion board to drive the lamps. Contact cobra18t here on pinside to see if it's feasible.
I've driven a 5v stern dmd from pinmame running on a pi:
So it's likely possible. You would need to be running pinmame on an external machine. I think there's a way to drive input to pin2dmd via the USB port.
Quoted from Zigzagzag:So APC can be controlled by an external machine running Pinmame?
I couldn't find anything about this in the documentation, only about MPF running on a PC.
But if Pinmame can do the same and control APC by USB I might be closer to a solution.
Not at this point that I know of. It only runs from the lisy system driven by gpio pins. If you have some pins free on the pi, you could drive a display, and add hooks like I did into the pinmame code. Probably won't be terribly fast.
The alternative(imo) is to use the MPF interface as a template to drive the APC via USB, and then drive the pin2dmd from that same machine using something like a Teensy(pinmame -> usb -> teensy -> pin2dmd). Both projects all on their own, but most of the work could be cobbled together from the existing projects.
Why not hack pinmame to stream dmd frame data to another microcontroller to drive the dmd? I was able to capture it and write directly to the dmd via the gpio pins. Opening a serial connection and streaming frame data to a teensy seems pretty reasonable, and wouldn't need anything hacked on the lisy side, AFAICT.
#ifdef PROC_SUPPORT
if (coreGlobals.p_rocEn) {
/* looks like P-ROC uses the last 3 subframes sent rather than the first 3 */
procFillDMDSubFrame(dmdlocals.nextDMDFrame+1, dmdlocals.DMDFrames[dmdlocals.nextDMDFrame], 0x200);
}/* Don't explicitly update the DMD from here. The P-ROC code
will update after the next DMD event. */
#endif
#ifdef OPPA
oppaUpdateDMD(dmdlocals.DMDFrames[dmdlocals.nextDMDFrame]);
//oppaBlankDMD();
#endif
dmdlocals.nextDMDFrame = (dmdlocals.nextDMDFrame + 1) % DMD_FRAMES;
}
}
That's from wpc.c in pinmame. I grab the frame data from there. Then, I write it out via gpio with this function:
/* Take in array and update the DMD directly */
void oppaUpdateDMD(UINT8 *dotData) {
//printf("In update DMD\n");int row;
/* Row data - This signal is the first line marker for the scan.
This input should be held high to correspond to the first row
of pixel data
*/
digitalWrite(pinRowData, HIGH);
for(row = 0; row < OPPA_NUM_OF_ROWS; row++) {
int index;
/* From Vishay doc: Once each frame the ROW DATA must be asserted to synchronize the column serial data with the beginning row */
/* Latch the row of data */
digitalWrite(pinColLatch, LOW);
for(index = 0; index < 16; index++) {
shiftOutSlow(pinDotData,pinDotClock,LSBFIRST,dotData[(row*16) + index]);
//shiftOut(pinDotData,pinDotClock,LSBFIRST,3);
//delayMicroseconds(40);
}
if(row == 0) {
digitalWrite(pinRowData, HIGH);
} else {
digitalWrite(pinRowData, LOW);
}/* Turn off the display while we latch in the this row */
digitalWrite(pinDisplayEnable, LOW);
digitalWrite(pinColLatch, HIGH);/* Advance the row pointer */
digitalWrite(pinRowClock, LOW);
/* Minimum 1us dip */
delayMicroseconds(0);
digitalWrite(pinRowClock, HIGH);/* Reenable display */
digitalWrite(pinDisplayEnable, HIGH);
delayMicroseconds(2);}
}
This was experimental code from years ago. That was what was driving the dmd video I linked earlier. So, if I were going to attempt this, I would just add code to open a USB connection to a teensy, then write that array( dmdlocals.DMDFrames[dmdlocals.nextDMDFrame] ) out. Read it in on the teensy using the standard serial library and drive the physical display from there. You could use the wpc mode of pin2dmd, or drive any other compatible dmd.
The code in this case is in dedmd.c. There is p-roc code in there for the 128x32 variant. You would want to tie in similarly with the serial output on the 128x16 side.
You'll have to experiment with the teensy driver. I'd bet money that it uses the same protocol as the 128x32 version, but you will need to look at the datasheet or talk to the pin2dmd guys to verify.
My pinmame fork is here: https://github.com/mikelatiolais/pinmame_fork
Look for the oppa display code. You can ignore the rest of the oppa stuff(it was a weird attempt to adapt the OPP project to pinmame), and I hadn't gotten to the point of doing any speed optimizations.
Is there any incompatibility with the current firmware and the first 3.0 smd boards? How about the 2.4?
You're currently viewing posts by Pinsider ThatOneDude.
Click here to go back to viewing the entire thread.
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?tu=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.
