I found 4 components, R88, Q8, R75 and Q6 which aren't shown on the instructions but tie into the display section.
(Topic ID: 239045)
Solingen
Quoted from ThatOneDude:Do I need to adjust the display type?
Yes, for some reason Williams changed the polarity of the display signals when they introduced the 2x16 alpha displays. That means all your characters are inverted (you can actually read it with a bit of training 
)
The display type can be changed blindly by doing the following:
- press the Advance button. This will make the display stop scrolling.
- slowly press the game start button repeatedly until the display becomes readable
- lock Up/Down in the down position and press Advance to get to „Exit Settings“
- press Game Start to confirm. If an SD card is iinstalled the new setting is stored
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.
First of all: did it work, can you read your displays now?
You're right I should probably state in the comments that DisplayType and so on are just pointers to APC_settings.
If a settings file has been found on the SD card then APC_settings is read from there, otherwise the values from APC_defaults are used.
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 ThatOneDude:(stuck at home for quarantine but still stuck in front of my computer, such is the life of the devops engineer).
Same here, but I think I wouldn't be able to resist. It's just some seconds and if no meetings are imminent 
Remember to change DisplayType back first or you might get some unexpected results.
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.
Algonquin, IL
Quoted from ThatOneDude:Well, the bigger problem is that I'm only part way through step 3, so no switches yet.
Of course I'm not trying to tempt you, but theoretically you could change the first byte of APC_defaults to 3 
Quoted from dudah:Love this project! Following! Keep up the good work guys!
Thanks. When are you going to populate you first APC board?
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
Thanks. When are you going to populate you first APC board?
When you find me a cheap local sys11 game!
Populating an APC board myself for use in a Space Shuttle. Love the build out so far. The pain was that I think I started half way through different APC versions, but after a few corrections to the BOM, I think I'll have my first board populated completely this week (just waiting on the appropriately sized tantalum cap and the 100n caps for the sound section and we're good to go).
I'm designing a mounting solution in CAD for the board now. Looking forward to digging into software. If you need any pinmame help or anything, let me know. I worked on the emulation stuff for Kingpin and it was a super fun project.
-- Jimmy
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.
Quoted from ThatOneDude:If you can help with the ongoing Unix sound problems on pinmame, that would be cool.
Ah yes, the turrible turrible DSP implementation. You *can* hack around it by using pulseaudio and running the application through pacmd so that the DSP device is emulated.
I can look into an up-to-date alsa solution if that's the biggest pain point.
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 ThatOneDude:Do you have a description of how to do that hack?
Assuming you're running pinmame in linux and *cant* get audio, do the following:
1. sudo apt install pulseaudio
2. padsp <pinmame command>
NOTE: make sure to add "-dp oss -smp oss" to the command line options so that it tries to fall back to the DSP (which pulse audio is emulating)
Example:
pacmd ./xpinmamed.x11 -rp <rompath> <rom> -skip_disclaimer -skip_gameinfo -dp oss -smp oss
(you may or may not have to tweak/add other options as you're currently doing)
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.
Quoted from Compy:If you need any pinmame help or anything, let me know.
The current challenge with PinMame is to extract the sound files automatically. We have decided to just extract the files, put them on the SD card and let the APC play them. The APC offers good sound quality and it's easy to replace the files with own sounds if desired.
If the files are stored on some internet server, then this work must only be done once for every machine. Bontango is currently extracting them for my PinBot. The results are very promising, but I think it's still mostly manual work. Up to know we have roughly half of the files for one of the two audio tracks.
Quoted from ThatOneDude:Alas, no love. I suspect I have a hardware problem now.
Hard to believe as it looks so familiar. Try to finish step 3 and press 'Advance'. If the result looks like the picture below than we know what it is. The other picture is the same with the right display setting.
Sys11c_display (resized).jpgSys11c_display2 (resized).jpgOk, 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.
Whitby, ON
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 ....
Quoted from AmokSolderer:The display type can be changed blindly by doing the following:
- press the Advance button. This will make the display stop scrolling.
- slowly press the game start button repeatedly until the display becomes readable
- lock Up/Down in the down position and press Advance to get to „Exit Settings“
- press Game Start to confirm. If an SD card is iinstalled the new setting is stored
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 ThatOneDude: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.
Take a break, get away from it all for an hour or so, and then keep at 'er! You guys are making good progress of a lot of impending, solveable issues.
Unfortunately my list of things to get done is pretty long, so I'm unable to help at this time..
Quoted from Compy:I can look into an up-to-date alsa solution if that's the biggest pain point.
Hi Jimmy,
thanks for offering your help, I did update the alsa driver already for my 'LISY' image but with no luck.
You can find my code here: https://github.com/bontango/lisy-src-5.x
Alsa code in /src/unix/sysdep/dsp-drivers/alsa.c
In general sound works, but it looks like it is a timing problem, sounds are sometimes veeeery slow.
From what I saw the sound queue is filled together with the refresh routine of the video driver,
so I assume that with X-Windows, and with my (ugly hacked) LISY fake video driver, timing is not optimal
any help appreciated
Update:
saw the post from Dude too late
Quoted from ThatOneDude:Interesting read: https://www.vpforums.org/index.php?showtopic=42220
sounds like there is a solution, will dig into that and let you know.
Ralf
Quoted from ThatOneDude:And here it is
This doesn't look like a bad solder joint. Then you would expect certain display segments or whole digits to be missing.
So let's look for the weird stuff:
Is your ribbon cable connected correctly? It's very easy to have it shifted by one row and the result could be similar.
Another idea would be to press the 'Highscore Reset' button after bootup (while the display is scrolling). This invokes the blanking which should make the display go blank. If this doesn't work and all segments are lit instead then check the jumper JP1. For your type of display the center pin of the jumper should be connected to +5V.
I'd like to track this problem down systematically, because any additional soldering might just further damage your board.
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.
Quoted from ThatOneDude:My fault for not checking the SIPP sockets first.
OK, but the damage is done so we have to make the best of it.
When I got you right, you don‘t want to use the display part anyway. It seemed like a low hanging fruit to put the board into the BK2K and test it, but you can still skip the display part and test your board via USB.
You could try to connect it to MPF or you could use a terminal program to send the USB commands directly.
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.
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.
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.
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 
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
You’d have to enter the switch test by pressing the game start button.
But WriteUpper/Lower is only one way to control the displays and the switch test is using another method to show the switch numbers.
If you want to control the APC via USB, you should use V0.13 as it comes up in USBcontrol mode, connect with a terminal program (I use HTerm) and use the Lisy protocol:
http://docs.missionpinball.org/en/dev/hardware/lisy/protocol.html
This way you have full access without having to bother with the APC code.
Command 0x29 for example returns the numbers Of switches which have changed their status recently.
Having a blast working on this. Curious if anyone has run into this issue before I dive into the code: I am only able to get sound out of the 'SOUND.BIN' track. 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.
Going to dig in more, but wasn't sure if I was missing something glaring!
-- Jimmy
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.
Quoted from ThatOneDude:Check each lead on TDA7496. Make sure you are getting a signal on the INR and INL leads.
Thanks for the suggestion! It turns out I'm an idiot though, I forgot that Space Shuttle only has one channel
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 Compy:I forgot that Space Shuttle only has one channel
But this is a limitation of your old sound hardware which you don't use at the moment.
When using the APC you have two independent sound channels, but it looks like your channel 1 is not working.
Quoted from ThatOneDude:Make sure you are getting a signal on the INR and INL leads.
That's correct. If you don't have the right measurement equipment to check the signals then check the solder joints of the pins 1, 2 and 3 of U20. This is the small SMD IC. I guess these joints are the hardest to solder and therefore have the highest probability to fail.
Quoted from ThatOneDude:29, however, gives me a ?
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.
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 ThatOneDude:Ah, of course. I was using hexlify to autoconvert it, but I wasn't thinking about the initial input. Danke!
Gern geschehen
Quoted from ThatOneDude: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.
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.
Quoted from ThatOneDude: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?
Exactly, when you receive 127 you know that your queue is empty.
Quoted from ThatOneDude: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.
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.
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.
Quoted from ThatOneDude:Saves a lot of typing
OK, got it - apparently you like coding more than using a terminal program.
Quoted from ThatOneDude:Ok, just wanted to make sure I wasn't seeing a weird version mismatch when I noticed the change.
The MPF link I posted is what I used as a reference when implementing the API and as everything works well we're not planning to change anything soon. If you start using MPF you should probably opt for the DEV version, just to be sure.
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.
Quoted from ThatOneDude: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.
Why are you wrapping values in hex()? That'll return hex strings, which is probably not what you want. Write hex byte values instead.
Try ser.write(0), or 0x0 if you want to keep things hex formatted.
Otherwise your code looks good.
Progress! Switch matrix driver is working and I'm able to start a game and score points.
MPF is losing connectivity after it advances to ball 2. Any ideas? MPF shows my game's splash screen in-between balls for a split second (it shouldn't), I am thinking it's re-initializing comms when this happens.
What's also weird is if I restart MPF after I lose comms then it's unable to communicate with the APC until I power cycle it. It's completely out to lunch.
20200327_015639 (resized).jpg
Upgrading to the v13 code resolved the issue of losing comms after each ball. I can now cycle through a whole game.
I'm having to modify the switch matrix code to make it work correctly and want to confirm I've got this wired right. It's using PC1-PC8 for the data bus, pins 33-40, correct? So arD0 & D0 are controlled by PC1 on pin 33.
The switch matrix code initializes SwDrvMask = 2, which is PC1. But it is left shifted before it's used for the first time, so the first pin toggled is PC2 and Sw_Sel0 is never toggled. If I use SwDrvMask = 1 I'm able to read the entire matrix.
The latest code from GitHub gave me compiler errors such as the one below. I resolved it by moving APC_setlist after setup().
APC:177:23: error: 'HandleTextSetting' was not declared in this scope
{"DISPLAY TYPE ",HandleTextSetting,&TxTDisplaySelect[0][0],0,6},
Quoted from RatShack:Switch matrix driver is working and I'm able to start a game and score points.
Congrats, I hope your breadboard won't fail you. Sometimes this stuff can get really nasty when it get's too complex.
Quoted from RatShack:It's using PC1-PC8 for the data bus, pins 33-40, correct? So arD0 & D0 are controlled by PC1 on pin 33.
Correct. On the Due board PC0 is not available as a GPIO, so I had to use PC1 - PC8.
Quoted from RatShack:The switch matrix code initializes SwDrvMask = 2, which is PC1. But it is left shifted before it's used for the first time
It is already used during setup:
REG_PIOC_SODR = AllData - SwDrvMask; // put select pattern on data bus
There Sw_Sel0 is selected which means it's set to low level (Williams uses a low level switch strobe).
The basic principle is as follows:
During the 1ms interrupt (TC7_handler) the switch rows (Sw_Sense) are queried first, before the next Sw_Sel is selected by shifting it to the left. This leaves 1ms for the switches to settle before the next interrupt occurs and the Sw_Sense pins are queried again.
Normally SwDrvMask is related to SwDrv. The latter is the number of the active switch driver and SwDrvMask is the pattern to select this driver. One exception is when SwDrv becomes 7, because Williams uses 8 additional direct switches which are not part of the switch matrix. The APC treats those as a 9th switch column which is not selected by SwDrvMask but by Sel13 which selects U19.
Quoted from RatShack:The latest code from GitHub gave me compiler errors such as the one below. I resolved it by moving APC_setlist after setup().
I also have this from time to time. In Eclipse it is sufficient to do a 'Clean project' and compile again. If you move APC_setlist back to it's original position and compile again it's probably going to work now. There must be a compiler option to avoid this, but I don't know which.
Quoted from AmokSolderer:Congrats, I hope your breadboard won't fail you. Sometimes this stuff can get really nasty when it get's too complex.
I am very thankful for my $10 USB Logic Analyzer.
Quoted from AmokSolderer:Normally SwDrvMask is related to SwDrv. The latter is the number of the active switch driver and SwDrvMask is the pattern to select this driver. One exception is when SwDrv becomes 7, because Williams uses 8 additional direct switches which are not part of the switch matrix. The APC treats those as a 9th switch column which is not selected by SwDrvMask but by Sel13 which selects U19.
Ah - I missed the pattern select at the very end. Gottlieb has everything on the matrix so I had to modify that section of code. Thanks for clarifying that.
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.
Reply
Wanna join the discussion? Please sign in to reply to this topic.
Hey there! Welcome to Pinside!
Donate to PinsideGreat 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+!
