I would actually like a breakdown on this also. I have the hardware, including the side channel stuff, but have been unsuccessful making it work with the macro for Met. I had no problems with my Tron install, but it's just a blue palette.

you dont need sidechannel hardware to have colors working. You can also select inframe coloring. The only thing with last option is that the first 8 pixels in left upper corner are than reserved for identifying which colorpalette to use in that frame and this is sometimes noticeable

With ACDC I use inframe coloring and I cant recall ever seeing these 8 dots. With MET I did see it sometimes so I switched to sidechannel. After all it was only a few dollars of hardware.

So if you dont have sidechannel hardware first try to get it working with inframe coloring. This can be selected in the PinballBrowser software and has to be prior to running the macro I believe

Yeah, i'm not able to get in-frame working yet.

I have mtl163.bin and smartdmd.txt.

I replaced smartdmd.txt with the same file on my pi sd card in the smartdmd folder. I'm able to open and edit on the browser.

From there, I presume we need to load the game code and run the macro? From there, do we reflash the code on to the machine?

This seems easy, but I think i'm doing things in the wrong order, or skipping a step. The colors are always a default template.

Got inframe working and it looked pretty good. Shooting for side channel now, and Can't get anything beyond the default b/w. Strange.

I load the macros, run them against a fresh image. They look good in pb browser.

Save and flash the met pro table, hook everything up, nothing. I'm curious if the comm119 file is loading correctly and if the signals are being sent to the TTL-RS232. There is an LED on the TTL-RS232 that is lit up when connected to the SmartDMD board, so I *think* I have that set up correctly.

Are there plans for compatibility with Pin2DMD palettes created with the goDMD editor?

WOW, so I was troubleshooting the fact that I might have a bad RS232 board, and I checked the reviews on amazon and found this:

"The order of the connection pins is different, ie. the Tx & Rx lines are swapped which means that the cables I had created will not readily work with these new boards."

So I swapped these two connections, and boom, working like a charm. So much troubleshooting and then to find out THIS was the problem

LOOKS GREAT THOUGH! Just need to frame it up a bit better. Thanks Olivier and Crash. This was a fun mod!

I'm having a bizarre behavior issue.

If I build from the smartdmd img file from scratch, make no configuration changes, enable broadcast, wireshark shows smartdmd broadcasting out to the specified address.

If I change the dmd type to Bally, which used to make the remote dmd viewer work, the broadcasts stop. I can't then get broadcasts to work again.

I'm figuring some setting is getting changed, but I can't find it.

I may have a clue. I think it's the temperature. Would triggering the temperature sensor stop broadcasts as well?

Yes, frames are coming out fine on the LCD screen.

No, it's running in full licensed mode.

I used a local IP on my network, which here was 192.168.168.245.

dmd_type=3
nice=1
broadcastenabled=1
broadcastaddress=192.168.168.245
broadcastport=9876

After letting my RPi rest the evening, and rebooting, it started broadcasting again, as you can see here:

wireshark_capture_(resized).jpg

Despite my machine receiving the packets, Pinball Browser's Remote SmartDMD Display continued to show a blank, yellow rectangle, even when the wireshark showed the packets continuing to hit port 9876.

The display stopped working and SmartDMD stopped sending packets after about five minutes. I had unplugged the HDMI to the LCD, and when I plugged it back in, discovered the "TEMPERATURE IS TOO HIGH!" message on the LCD, which explains what may have stopped it from working yesterday as well.

First question, is the temperature increasing as a result of adding the CPU load of broadcasting packets? I have the rPi in a well ventilated part of the backbox with no case. I'm using the built-in Ethernet (no wifi or USB dongles).

Second question, can I decrease the temperature sensitivity somehow?

Thanks.

This solves the mystery of not sending packets, but it doesn't solve the mystery of why the Remote SmartDMD Display doesn't show anything. I have confirmed my machine running Pinball Browser is receiving the packets, but it's not displaying anything.

FWIW, I tried disabling the Windows Firewall. I had already tried confirming the port was open (which it was), but this still had no impact.

Thanks!

The packet capture is on the virtual machine, which has its own IP address. The VM sees the packets, no need to change to a broadcast address. I've verified this and confirmed using other Internet applications in both directions, so the network config must be accurate.

I'll try the broadcast address just to be certain, but everything else checks out. I can even log into the virtual machine FROM the SmartDMD using the IP address I'm using.

Confirmed. The release corrected the problem. Thanks again!

Here's an example of SmartDMD on a WPC-S Theatre of Magic. Some notes:

I'm using a screen with a resolution of 1920x1080. However, to make the DMD larger, I dropped the resolution, then used -70 in the right and left overscan settings to fit my image the way I liked it.

I created the top and bottom framing by creating a single image that accommodated the space for the DMD screen, wrapping it in the speaker panel type graphics.

Right now, I haven't messed with the palette much, but I'm trying to reproduce the orange of the original DMD (note I'm using a ColorDMD below). If anyone has any palette settings they think have come closer, please share them.

IMG_0735-1_(resized).jpg

This makes a good way for people to see the score when there is a crowd around the machine, which happens a lot (and a lot of tall people).

How did you make up the background where it wraps around the image?

In this case, my screen is a 1920x1080 native resolution. I set SmartDMD to 1280x768, as by doing that, it increases the size of the DMD part of the image to what I wanted. Then, I made a single 1280x768 image (Theatre of Magic at the top, and the lions/clock on the bottom). The location of the DMD part of the image you can choose (in this case, dmd_x0=130 and dmd_y0=304), so I put it roughly in the middle, slightly lower. The DMD "overlays" the image. By default, this would "pillbox" the image, leaving black bars on the right and left side of the image. (I could make a 1920x1080 image, but then the DMD part would be too small.) To correct the pillbox, I adjusted the overscan on the right and left by -70 each.

As for how I got the artwork right on the image, that is just me with photoshop, I guess! I took photos of the speaker panel art and touched it up appropriately. I was going to put curtains around it but I just got too impatient. It looks much less washed out in person.

Ok...I couldn't handle leaving it unfinished so I added the curtains (this is what OCD does to you):

theatre_smartdmd_(resized).jpg

Can the Raspberry be powered by the USB port on the SAM CPU/Sound board? I looked in the manual at the schematic and there's +5v there. If so, all it would require is a simple USB to micro USB cable.

I think it only consumes about 100mA, so I would definitely say yes.

Whoa, didn't consider this.

Smart idea but I think the Raspberyy consumes more than 100 mA, more like around 500 mA. I choose the safe route. With Stern you will find left of the coindoor a connector (black-white if I recall correctly) where you will have you 110 or 230 VAC depenadable on country. I connected a standard powersocket to this in which I put a (for me 230 VAC) poweradaptor for 12 VDC for the LCDdisplay and 5 VDC poweradaptor for the Raspberyy. Costs are I think 10-15 USD for them together and I have for sure no concerns in blowing up an expansive CPUboard.

That's an option I have been doing as well. I think the modern USB power standard supports something like 1.5A but I find that hard to believe.

Not forgetting the question how modern the usb on a SAM system is .......

Find the idea cool but to risky for me The port at the coindoor is also switched via the main switch so how more easy can it be?

OK, I'm going to be the guinea pig. If my CPU board blows up, oh well, people will know not to do that. Here is my logic on why this should be OK.
1. The 5V circuit is protected by a 4A fuse in the unregulated 8VAC line
2. The LM338 regulator is rated at 5A constant, 7A peak
3. Several people are running the Pi off from the J11 power input to the CPU/sound board
4. The L3 that is in series to the 5V on the USB port is rated at 1100ma
5. The Pi draws around 500ma with a max of 700ma
6. The coin or tix meter is run off the 5V. Although it's an intermittent load, the power circuit has to be designed to support it

I will take temp readings on the bridge and regulator for the 5V, before and after install. I will also take voltage readings at the 5V test point before and after. Although the LCD should still be run off a separate power supply, it just seams really simple, clean and cool to just plug the Pi into the USB port.

Good research. Hope it goes well for you and yep, cool to just run it from there

Good luck !!

Just as an FYI, you can get inline USB voltage/current meters pretty cheaply these days. Could throw one of those in to be sure of what the Pi is drawing if you wanted. Like this, and there are probably cheaper ones:

http://www.amazon.com/UEB-Digital-Multimeter-Capacity-Detector/dp/B0191EM01C/ref=sr_1_1

--Donnie

WooooHooo!!! It works!! Went for it and plugged into the USB port. It's been running for a couple hours. All temps are the same as before and the 5v is the same. The Pi powers off with the game and boots up properly on power up.

Great Idea. Via Ebay you can get them for < USD 4 so I bought one. Nice wannahave

I bumped the temperature limit on my JP to 70C. The game will be running 24/7 on location in a warm environment. Hopefully I won't have any issues. If I do I'll try removing the blinker GI bulbs from the bottom of the backbox and installing heat sinks.

By the way is it possible to lock in the screen resolution on boot-up? It's always either too small or a bit too large based on the resolution the LCD controller is receiving from the Pi. Looks like the res goes higher if I boot the system with HDMI connected. It's preventing me from fine tuning the border adjustments since I'm seeing two different results.

Hey all,
I have a Baywatch with a DMD extender in it and working. I am not real "techy" but would it be possible to switch to SmartDMD? Anyone know what's would be needed? I appreciate any input. Thanks.

I'll check that resolution adjustment. I haven't had any issues since changing the temperature limit.

Hmm can this be the solution for the following?

With my acdc I have like 20-30% of the time that when booting I have a to small resolution eg the letters are much to big and don't fit on the display . switch off-on and everything is fine

With my Met I have never had this issue

Any word on a bottom border adjustment fix?

Yes that's what I meant. It's been a while so hopefully it has been fixed on the Raspberry side.

Added that line for 1024x768 to the config file. I added it as a completely new line per the instructions. It's still switching to another resolution half the time which causes the image to shrink and creates black borders. If I connect power with HDMI disconnected it stays consistent and fills the screen. Anything I'm doing wrong?

any news if smartdmd will work in a Spike pinball?

i hope

This looks more like paging through the assets in pinball browser than a "SmartDMD Test" -- does SmartDMD even work in spike yet?

yes its pbbrowser

i hope it will work soon
i have a unit here and want to get it in GB as soon as possible

According to OGA's post couple days ago he hopes to have smartdmd running in Spike in a couple of weeks