In January I noticed that you could get RGB (full color) LED panels for building outdoor display screens that were almost small enough for pinball DMD replacements and started a thread over on the Pinball Controllers forum as a potential DMD like screen for home-brew projects.

KrustyDMD.jpg

Last month I saw that you can finally get them directly from China in 2.5mm spacing which is practically identical to a regular DMD so I started working on getting a board going for them. Today a new user, lucky1 arrived here looking for colorized ROMs for testing his very similar project, so I decided it was time to let the cat out of the bag and start getting some information out there even though I won't have an actual 2.5mm screen to show until this weekend.

My project is using a Teensy 3.2 (Arduino like, but much more powerful) microcontroller on a custom carrier board, and lucky1 is using a Discovery STM32F4 Board (similar processor, but a little faster and larger). Not sure what the final results of these two efforts will be at this point, but either way this is going to be an option soon, both for homebrew and DMD replacement, and they should be very cost effective either as a DIY or simple kit.

No idea if it will end up as a "product", but I'd say <$200. The parts will probably set you back something like $110 if you're willing to source from China and DIY on all the soldering and cables.

WPC is probably best limited to shades of 1 color, although in theory I guess you could use a palette. On Stern it should be easy to use side channel or embedded SmartDMD data for full colorization for those with a PinballBrowser or SmartDMD license (I'm not sure exactly how Oga deals with those.) For homebrew you can send full color data from a host computer over USB.

There's really not enough data in WPC to do full colorization. The ColorDMD guys get around that by looking up the frame and merging it with appropriate full frame color data they've stored separately, but they've patented that and this hardware probably wouldn't be up to that task anyway. If ColorDMD wanted to offer the LED panels as an alternative to the LCD screen they probably could, but I don't see any easy way to do full color on WPC without additional hardware.

The palette thing is easy, it's currently using a palette that's just 4 shades of gray. However I'm a little bit worried you'd get some color bleed on the current system, which is just summing the previous 3 frames to get each dot value. It would only last 120th of a second each time though, so maybe it wouldn't be an issue in practice, I'll give it a try.

EDIT: These caveats are all WPC of course, Stern varies the frame time so it's possible to determine which parts correspond to each intensity, but WPC is just a stream of identical on/off bitmaps all with the same timing.

It actually isn't quite synchronized between input and output at this point (I think the WPC signal is 122Hz and the screen update is 124Hz) but you really can't tell. I have a scheme about how to fix that, but if it continues to be invisible it may be pretty far down the list.

The plasmas are clocked externally as part of the signal from the CPU. As I said it looks like the TZ is running at 122Hz (according to my crappy Chinese knockoff logic analyzer). There may be some hardware differences from the manufactures that vary the actual display times or something, but I think they're pretty simple hardware wise, so these are probably minor.

My poor little Teensy is about at its limit with 2, so you'd need some beefier hardware driving them. Also they eat a lot of 5v so you'd want a serious power supply. You could maybe manage on/off for a single color depending on what the original refresh rate was like. Are they divided up somehow or is it all one monolithic signal?

But that worked so well on the TRON ramps.

Does the Pi have enough GPIO pins to handle the input and output? The RGB panels require 13 in additional to the DMD input.

As far as I know the only current source for the panels in direct from China via AliExpress or similar.

The output code in my version is branched from SmartMatrix, which uses extremely clever and efficient DMA for the pixel output. It's doing 12bit with the WPC example because that's all it needed and WPC is 120Hz, but it has support for 24 and 36 bit pixels as well.

It already supports streaming over USB for homebrew applications at 24bit color and 30fps, but it would be easy to modify PinMAME to provide screens if you wanted it for that.

DON'T use lucky1's search above if you want panels that will fit for a direct DMD replacement, you need the (brand new AFAIK) 2.5mm panels NOT the 3mm panels. "P2.5" often shows up in the description and the boards should be 32x64 pixels and 80x160mm. But unless you know C and like reading microcontroller datasheets it might be a little early to be buying panels anyway.

Also, the bug Crash pointed out in the SmartDMD thread is going to be a big, annoying pain in the ass to fix, so everyone be sure to thank him for noticing it.

Yeah, but it actually looks like it might not be a problem and we can use a pin I thought was off limits. Sometimes it's better to be lucky than good.

Looking at his project those are smaller panels, so I think even with the extra CPU you're going to have a hard time pushing enough data for one of the big Sega displays. I haven't looked at the datasheet for one of them though, so there may be some tricks to help.

Oops, I was confused by the description which seems to be talking about two different displays (it has conflicting info in the title and description). Did you order from those guys and get the 2.5mm panels? I'd be nervous about the weird description.

It was a timing issue between the WPC DMD signal and the serial interface on the microcontroller that's reading it. The microcontroller has some requirements for what counts as a valid input that the display panel doesn't. Basically I need to take one of the DMD inputs and delay it so the microcontroller accepts the last bit of the message / last dot of the display.

Yeah, they take a lot of juice. I think if it was stuck on full white it would be like 7Amps although these are driven way below 100% duty. You definitely don't want to hook them to your pin's 5v supply.

There's no flicker, the LEDs are being strobed insanely quickly. In the TZ example the DMD information is coming in at 120Hz, and that's the rate it's outputting as well. It works a little like a huge lamp matrix in that the lines are strobed, so only 2 are actually active at any time, and it's outputting 12bit color, so there are 4 updates of varying length each row before it moves on. So a dim pixel is actually only on for 1/(120 * 16 * 16) = ~0.000033s at a time (1/256 of each frame). A fully on pixel would theoretically be on 1/16 of the time but in practice it's less than that.

Updated video with the final column bug fixed and a hideous palette applied by request of winteriscoming and Crash.

You can send pixel data to it directly from the host computer over USB, even from disgusting Python code (I'm working with Brian and Gabe to get MPF support in, but the Python code is totally generic).

The board and software are designed to be easy to use for DIY machines as well as DMD replacement. You can talk to it directly from the computer running a DIY machine for full color output (or they could just use the DMD signal from the PROC and get a limited palette of colors).

Cool. By "inframe palette switching" do you mean SmartDMD style marking of the frames with a palette index?

Here you go.

SizeComparison.jpg

That's easy to support, you just need to have the palettes defined and some sort of license from Oga. Side channel should be possible as well, I made sure to leave a couple of serial pins open...

Since the pinball manufacturers were all constrained to the same input specs for the DMD we should be able to support all of them. Right now there are a few WPC specific hacks in the code while I was getting it working, but it should be possible to scan at startup and have slight variations of the code if needed.

Original DMD cable to custom carrier board with a Teensy 3.2 on it and all the connectors. Signal to the DMD is read by the Teensy, processed, and the frames are combined (equally weighted last 3 frames for WPC, Stern uses 4 unequal frames to get their 16 shades) then look up the pixel color from that index. The output is done with a slightly modified version of the SmartMatrix library. Output to 2 of the 2.5mm 32x64 matrices driven by an external 5v power supply (which I'm currently taking down to 3.5v because otherwise the Teensy can't talk to it without converters) it sounds as if something like 4.2v would by ideal as anything over that is pretty much waste heat.

It can definitely be done DIY quite reasonably. I'll probably offer the boards myself at a small profit for the DIY crowd but also encourage one or more of the standard suppliers to offer complete turnkey kits with panels, power, mounting, cables etc. Sourcing everything separately in QTY 1 adds up fast, so I think they could offer something that's still affordable but provides the peace of mind of knowing you can get support or a replacement part.

I'll try to get a current reading from the all on display test tonight. I suspect it will be high.

... or maybe I'll test on the bench for a few days until I fix whatever I just blew on my Power Board with my totally sketchy setup.

Yes, once the hardware is done and it's been tested in enough machine types to be confident it won't need more board revisions. The code isn't all that big or complex, but it uses a lot of microprocessor features so it's kind of hard to follow if you aren't used to that. Most of the effort is in figuring out why something doesn't work when you seem to be following the chip docs exactly...

RGB_DMD_Beta2.png

Maybe. It's 3 times as much data going in and going out. It depends on how fancy you want to get with the coding. The Teensy version is actually currently capable of better color depth than the Discovery one because the Teensy is using DMA to output the pixels, but if the Discovery code was optimized more it would have better throughput. It also depends on how they were driven. If it only updates 60 times a second that's a lot different than if it's doing 200+. Do you have a data sheet for the big DMD?

EDIT: Never mind, I found the data sheet. Dot pitch is wrong, the large displays are 2mm, so unless they start making panels in that size you'll have to stick with the LCD replacement systems.

Stern style 16 color display with a "custom" palette (well, I made 15 green). Unfortunately I still don't have both versions running on the same code / hardware setup, but it's getting closer.

Test_16_Color.jpg

I've never seen them on eBay. I only discovered them by searching for them on AliBaba once a month or so since the original testing with the 3mm panels. I haven't tried to post an "official" supplier, since as you've seen the prices and descriptions are basically random. You just need to do the searching right when you want to buy and make sure you have the pixel count and panel size right. 32x64 and 80mmx160mm.

I might be willing to sacrifice one of my panels to the God of curiosity. I'll check if they are just attached with those machine screws or if they're screwed and epoxied (I suspect that).

I was wrong, at least for the 3mm and 2.5mm panels I have, which seem to be from different manufacturers, are both just screwed to the frame. The frames are super rigid and sturdy though, and provide most of the stability to the panel. If you were going to disassemble a larger panel I'd make sure your new frame was really solid.

Chatting with oga83 about support for PinballBrowser colorized frames. Is there anyone who has strong objections to that version of the code being closed source if it meant it was more convenient for regular users to install and use?

Oga83 is justifiably concerned about people directly sharing ROMs which have been modified with his tool rather than macros. If anything is hidden in closed source it will be to help with that. It would be easy to recreate that small part of the code if I get hit by a bus, and Oga will have it as well.

After some serious mucking about I think I have a way to keep everything simple and working in the Arduino IDE for people who want to mess with the base code, but still able to lock the colorization data to a single board so you can't just use a random ROM you got off the net.

The first 3 boards (with a known issue, but easy to jumper around) should be here by the weekend, as I just got the email from OSHPark that they were back from fabrication. So while all of you are off enjoying Expo I can do some good ol' surface mount soldering.

I don't think of combining a plain text file of palette information with the totally open source STM32 code as providing any barrier to making the two line change to ignore the check. However if it's good enough for oga's peace of mind that's great. It was interesting to figure out how to call arbitrary ARM data as code anyway so I'll probably continue down the path of having PinballBrowser patch the file directly before upload.

I've actually had to do real copy protection stuff. Believe me, it's no fun from either side. But I think this system will be enough to discourage casual ROM sharing without any extra burden on the user, since they'd have to write the color data onto the board anyway.

Looks like no boards until Friday, so I'll have to work on the boring software until then.

Mmmm, solder fumes...

RGB_DMD_b1.jpg

No, that would still be sent through the matrix header (if it turns out that the big Sega DMDs have huge throughput you could theoretically double up the output and drive two sections at once, but there aren't enough pins currently hooked up for that.) The Extra I/O is for playing with the PinballBrowser side-channel color, or hooking up buttons or pots for adjusting the screen, or ???.

I removed the power headers in the updated design, there wasn't really any reason to run the power for the panels through this board instead of directly to them.

I'm working on the software while I wait for things in the mail. I have the SMT stuff on the 3 boards from my original OSHPark order and am sending 2 of those on to the MPF guys, I'll have 3 more slightly updated boards by the end of the week.

I need dumps of the DMD signals from as many machines as possible, so I ordered a few cheap Logic Analyzers to mail around to people to collect those, but they seem to be on the slow boat from China, even though I made sure to order from a "USA" seller.

That, and I was able to sucker him into ordering the panels for us to experiment with.

I actually think it might be a (minor) hardware issue with the panels, since I get some very dim green pixels at times as well, and my code is completely different. It shouldn't be at all visible from playing distance / brightness.

The stock frames are nice and sturdy and they have a (presumably) standard mounting pattern, which I doubt is true with the raw panels, so if they fit well, which I'll have to double check, there's no reason to remove them.

The panels with frames are 15mm deep. Per the datasheet the Cherry DMDs are only 10mm deep, but that doesn't seem to correspond with how they're mounted in the game, so they must have a pretty large gap between the front of the display and the speaker panel.

Hasn't been tested yet, but if anybody has access to a laser cutter or wants to order from Ponoko. https://dl.dropboxusercontent.com/u/8494826/DMD_Frame_P2.svg

MatrixDMDMount.jpg

Is it changing palettes for Sherman? I thought Data East was 4 color, but it's been a while since I played R&B.

I'm sure there will be a plug and play option for those less inclined toward hacking.

What about @ 5:16? Looks like they've got pink in there for Sherman's skin. It's emulation, so who knows what they could have hacked in for changing colors, but I'm curious. Doing 4 for the whole game is trivial, presumably DE used the Williams DMD timings, but I won't know 100% until I can get a Logic Analyzer to somebody with a game to test.

Ah, that's easy then, I didn't realize it was your video.

You really don't want to mess with that display code, do you?

Yeah, but I'm not sure how far you could run one of those ribbon cables before you'd want to switch to something with some shielding.

13 data lines plus ground for the RGB panels.

The logic analyzers I ordered finally arrived on the slow boat from "USA Seller". Anyone who has access to a number of DMD machines, especially anything oddball, and a Mac or Windows laptop who wants to help out let me know. You'd get the logic analyzer in the mail, install a piece of software, plug the dmd cable into the connector, record the signals and email them to me. Then drop the logic analyzer into the mail for the next person.

Added the code last night to detect the weird case that probably only happens on the P-ROC when the DMD timings change when it switches from the startup splash to the game display. Hopefully that will also allow me to respond to brightness changes from the pin menus rather than having to add extra configuration to the panel as well.

The software is getting to be in pretty decent shape, so if you have already ordered panels and are interested in testing my version, PM me about getting a carrier board from my next OSHPark order. We're still talking beta testing, so not for those who don't want to deal with potential problems.

Just think of it as fancy GPU assisted computation!

The panel prices are super variable. I assume somebody will start importing them in bulk and the price will stabilize at something in the range we're seeing, but I'd still guess maybe $75 for two in hand. I also think you'd want to spend more than that on a power supply. On the upside, there's no commercial use fee, at least for my software, and the boards will be less than that. You'll also want a mounting plate of some sort, the laser cut one's I ordered from Ponoko were $38 for 3. That's all assuming you want to go the DIY route, I know there are vendors looking into these as well.

I'm remembering some tricks for doing SMT with my setup, and only had to fix one solder bridge this time.

However I'm also getting senile and installed a chip backwards on the third board.

P1000602.jpg

If you turn on the color correction that reduces the brightness for most colors as well as being more "accurate", but it's probably better to do those calculations on the PC (although I haven't actually checked the overhead of color correcting the streaming data, it might be fine on the Teensy).

Just switch to the 5mm panels and you can have a combination DMD, backbox, and tanning bed all in one.

Yes, only 4 colors, unless PinballBrowser was extended, or somebody made similar software to support DE ROMS, and somebody did colorization for it.

There's currently no way I'm aware of to get any per frame palette information into a Data East game. That's the issue, not switching palettes. Snux is playing 24bit video at 64x128 on the Teensy, but that doesn't mean it's coming from the F-14s ROMS...

Finally starting to get the code base into decent shape. The DMD input for WPC, Stern, and USB streaming are now all working in the same project, and there are even some comments.

Does the STM32 have 5v outputs? Some of the panels don't work reliably with 3.3v signals.

I personally have in my possession a pair of 3mm panels from Adafruit that don't work with 3.3v, and there are other reports of it on the forum. That's why my board has the bus transceivers on it.

EDIT: Maybe it's not worth the precaution though, removing them would simplify the board and get rid of the SMT parts...

Did a version with no level shifters for those who like to live dangerously.

f0f9d580f2ddb04b159066e4a567f69e.png847b674206c404095fa411b5870151cc.png

In theory you could have a unique palette for every single frame, but in practice it probably isn't required.

lucky1 is using a hash function on the frames to determine the content and thus which palette to use with the data. As a US citizen I'm reluctant to do that on my version without talking to a lawyer. The other option for manipulating the palettes is modifying the ROMS as in SmartDMD, which is trivial to support from the display side, but not currently possible from the ROM side on all systems.

Palette information can be stored on the controller, they have a decent amount of program space.

Nope, there's no information in the frames about how they relate to each other unless you've used a tool like PinballBrowser to mark the source data.

I could probably do a brief technical writeup about how the DMD works if people are really interested, but it isn't super exciting.

Speaking of which I'm still looking for a few people who might have some stuff from smaller manufacturers and would be willing to make some recordings of the DMD signal from their machines. And thanks to those who've already contacted me.

Common sense has exactly zero to do with US patent law. And while I personally agree with your reading I'm not a patent attorney and I assume you aren't either. However I could theoretically get hauled into the United States District Court for the Eastern District of Texas and you couldn't, so why give myself headaches?

You're using a 3 color display rather than a 1 color display, as you know the shades are an illusion from the refresh rate. Are you positive an LCD panel is different from an LED matrix under the Doctrine of Equivalents? If you're going to provide the hashing code for frame detection I'm sure any enterprising user who happened to be using my hardware could merge that bit in themselves.

The laser cut mounting frames arrived from Ponoko. They fit perfectly for my panels, but you should obviously compare the layout with your own panels before you consider ordering. The front side is matte black, very Batman.

https://dl.dropboxusercontent.com/u/8494826/DMD_Frame_P2.svg

P1000610.jpg
P1000613.jpg

Nope, it's just on the existing standoffs that were there for my Cherry DMD. I obviously don't have a lot of machines to test on, and I haven't tried to figure out how far it is from the front window, but there's room on the screw posts to move it back at least another 1/4 inch if you wanted to, and I can't imagine those mounts vary much.

Anybody in the US who has already ordered panels and is interested in getting a beta board can contact me. I'm pretty sure there won't be any more revisions at this point. I have versions with and without the level shifter in the pipeline at both OSHPark and SeeedStudio, but won't have either in hand until at least the end of the week.

You may have to try one of the Virtual Pinball boards.

Still working on features and bug fixes while I'm waiting for more boards (should be this week). I got a little sidetracked by the absolute train wreck that is the PinMAME keyboard input code.

EDIT: Ugh, that was seriously unpleasant, but PinMAME keyboard input works again under SDL and I can get back to looking at whatever it was I started on 6 hours ago.

3mm black acrylic, with matte surface for the front.

http://www.ponoko.com/make-and-sell/show-material/341-acrylic-black-matte-1-side-

Today's good news: After spending all that time getting the keyboard input working in PinMAME getting it to send out the DMD images went pretty fast.

Today's annoying news: I just got my first data dump from a WhiteStar system game and they're going to be another big pain in the butt because the DMD timing is all sorts of crazy.

WARNING: I've now heard from two people who tried to order the 64x64 panels and got a monolithic single panel. If you're going to try that you need to be VERY careful you know what you're getting. 1/16th scan, and obviously 80mm are important keywords to look for.

Just finishing up the PinMAME stuff. Should the dots for the 16x128 Data East DMD go in the middle or the bottom half?

In some sense of the term PWM is the only way to control brightness on an LED, so yes, they are sort of using PWM. Just like with a Stern "16 color" DMD there are 4 or more updates of each line of data, varying in duration during which each individual red, green, and blue LED can be either on or off. Because of some very clever coding (not all by me) the controller is able to do those updates incredibly quickly. It can keep up with the 120Hz refresh rate that WPC uses for its single color refresh and still fit 8 subframes into every update.

EDIT: Changed the subframe count, as it's actually doing 8 bits per channel color / 8 subframes.

They are only RGB, not RGBW, but they are individually controlled. They have pretty good color characteristics, if you'd like to send me a 32x128 color image I'd be happy to get a photo, but of course it's not quite the same as seeing them in person.

Not available in this form factor, but as I've said the color fidelity is surprisingly good once you gamma correct.

I got the "mini" version of the carrier boards back from OSHPark and I'm ready to provide brains for testing once Aaron or anyone else gets their hands on more panels.

There's an API you just feed an array of colors. I really doubt there will be RGBW versions, since these panels are pretty standardized, they just haven't been previously available in the exact size we needed. If there ever were it would require hardware changes to support the extra channel, but both the hardware and software changes would be trivial.

I've been using my TZ with a black and white palette as testing the whole time. Looks good to me, but different people are bothered by different things.

If you were REALLY going for the black and white television look on a Twilight Zone you'd want to use a light gray gel on whatever you were using anyway. It's not very productive to worry about the color accuracy without some sort of goal in mind for what you're trying to achieve. From my testing the biggest issue won't be decent looking white but getting really dark colors, as even the minimal LED on time produces somewhat bright dots.

It's 0.542 uS running at 8bits per channel color and 120Hz update.

EDIT: And 25% brightness, so if for some reason you were running at 100% brightness it would presumably be closer to 2.2uS, but I didn't reconnect it and measure.

Yeah, at some point you're going to want some way to attach it to the cabinet anyway so the two panels don't actually need to be connected to each other. I did temporarily hot glue my frames together at the edge for testing while I waited for my laser cut holder to arrive and that worked fine and peeled off easily when I was done.

Been doing some other stuff, but got back to this today. Starting to work on automatic game detection.

CRC rows 12 to 18, bytes 0 to 6
.*****..***...***...***...***...................
.*.....*...*.*...*.*...*.*...*..................
.****..*...*.*...*.....*.*...*..................
.....*.*...*.*...*...**..*...*..................
.....*.*...*.*...*..*....*...*..................
.*...*.*...*.*...*.*.....*...*..................
..***...***...***..*****..***...................
CRC: 0x0c9d37c3

CRC rows 12 to 18, bytes 0 to 6
.*****..***...***....**....**...................
.*.....*...*.*...*..*.....*.....................
.****..*...*.*...*.*.....*......................
.....*.*...*.*...*.****..****...................
.....*.*...*.*...*.*...*.*...*..................
.*...*.*...*.*...*.*...*.*...*..................
..***...***...***...***...***...................
CRC: 0x31341563

Yeah, sorry to be obscure. Crash has it. WPC games conveniently have a standard boot screen that displays the game ID. By building a checksum of that portion of the DMD we can look the game up in a table and have a predefined set of colors that work well for each game. Unfortunately other manufacturers are less consistent in their boot screens, but many of them do match a few basic patterns:

CRC rows 3 to 9, bytes 2 to 13
......................*****.****...***..**....**.....***........**...***........................
......................**..*.**..*.**..*.**....**....**..*......***..*..**.......................
......................**..*.**..*.**..*.**....**....**..*.......**.....**.......................
......................*****.**..*.**..*.**....**....**..*.......**...***........................
......................**..*.****..**..*.**....**....**..*.......**.....**.......................
......................**..*.**....**..*.**....**....**..*.......**..*..**.......................
......................**..*.**.....***..*****.*****..***.......****..***........................
CRC: 0xa0264089

CRC rows 3 to 9, bytes 2 to 13
...****..***..*...*.****...****..***..*...*..****.....****...***..*...*.....****..*****.*...*...
..*.......*...**.**.*...*.*.....*...*.**..*.*.........*...*...*...**..*.....*...*...*...*...*...
..*.......*...*.*.*.*...*.*.....*...*.*.*.*.*.........*...*...*...*.*.*.....*...*...*....*.*....
...***....*...*...*.****...***..*...*.*..**..***......****....*...*..**.....****....*.....*.....
......*...*...*...*.*.........*.*...*.*...*.....*.....*.......*...*...*.....*.......*.....*.....
......*...*...*...*.*.........*.*...*.*...*.....*.....*.......*...*...*.....*.......*.....*.....
..****...***..*...*.*.....****...***..*...*.****......*......***..*...*.....*.......*.....*.....
CRC: 0x6d088b1d

CRC rows 3 to 9, bytes 2 to 13
....................*****..***..*...*.*****.*.....*...*.....****.*...*.*...*....................
....................*.....*...*.**.**...*...*.....*...*....*.....*...*.*...*....................
....................*.....*...*.*.*.*...*...*.....*...*....*.....*...*.*...*....................
....................****..*****.*.*.*...*...*......*.*.....*..**.*...*..*.*.....................
....................*.....*...*.*...*...*...*.......*......*...*.*...*...*......................
....................*.....*...*.*...*...*...*.......*......*...*.*...*...*......................
....................*.....*...*.*...*.*****.*****...*.......****..***....*......................
CRC: 0x4dce375c

There's a split between those who like to adjust everything just perfectly and those who want to put stuff in a game and forget about it, just trying to support everyone. Plus I can at least imagine cases where knowing the game might help the code with timing or something. Also, I needed something to work on while I wait for people to get panels.

There's going to be a lot of variation depending on how you're doing the palette assignment, but there would always be a default palette that gets used if it doesn't know what else to do with a screen. In general, if you're doing palette swapping rather than color merging (this is the difference between SmartDMD and ColorDMD) scores will be displayed in whatever the matching color from the palette is, which is usually 100% on.

I think I've got the Whitestar issue worked out finally.

Good news is I've been able to optimize the board some while I was working on that, so it's looking pretty good at this point.

P1000618_(resized).jpg

OSHPark (which is a place is the US that combines small run PCB orders and is really popular with hobbyist designers) uses purple for all their boards. Usually you'd switch to somebody else when done prototyping, since they are kind of expensive for larger orders.

So you're saying you're in for the OSHPark LE?

You can't hook it into the 5v supply on a WPC machine. The panels take too much current and you'll get resets or a blown 5v fuse. You'll either need to provide an additional supply of some kind or step down one of the other voltages.

If the controller is hooked into the pin's 5v the screen will go dark when that loses power and there's no enable signal, so the service outlet may still be a viable option. Power supply is the thing I've looked at the least though, and it may end up being something that varies from system to system.

Full brightness: 6.8A @ 5.00v
75% brightness: 5.7A
50% brightness: 4.3A
25% brightness: 2.4A

That's 100% white on both panels. In real world testing of actual game display at reasonable brightness it's more like 2A.

Anything above about 50% you can't look directly at it without wearing sunglasses, so that will probably be the max in the software. I think that ~2A gameplay number was at 25%, which I feel is about traditional DMD brightness (for white dots, other colors you'd probably want brighter.)

I'll have to take more measurements, but it will probably be higher than that just for some overhead and odd cases like the inverted DMD tests.

Yeah, there aren't any blocks. You might possibly want to hide the edges of the panel itself, since it's "deeper" than a regular DMD, but you could do that with a cutout border around the panel.

I've been having a major trying to get all the versions of Whitestar display boards to play nice with my hardware. I was planning to have all the major systems ready to go before trying to do any more general release, but I know it's been a while. If I don't make any traction on my issue the rest of this week I'll reevaluate what the dev priorities are, since I certainly want people to be able to play with them ASAP.

Sorry to be AWOL, I've been down with a head cold this week.

Significant progress on the Whitestar issue, so I'm fairly confident on that front now.

I've just put in the order for more boards, so people who are interested in using my stuff will be able to get a controller in the same package if you're getting panels from Aaron. It's still officially "beta" and I can't 100% guarantee that they'll work in every machine, but I'll be posting the code at that point as well, and will work on bug fixes or take them back if you have issues on any particular HW. The only thing they definitely don't support is Spooky, who use a non-standard protocol to control their DMD.

If there's a signal at all it's probably standard. But you wouldn't have the color data that they're using for the LCD display.

It's cheaper to get them from Aaron than Ponoko, but if you have access to your own laser cutter I did post my design file for a similar mount earlier in the thread.

It will depend a bit on what people think is most important once they begin using them I guess. To start I'll be happy if it just identifies the system and displays the dots correctly on every WPC, Whitestar, and SAM game.

The first two obvious post release things, which I've at least thought about a bit and set aside storage for in the code are: Identifying the game from the boot screen and providing a custom default color palette for each game. Working with Oga to use SmartDMD data for palette switching on SAM games. I've done proof of concept work on the hard bits of both of those and don't think there will be issues with either.

There's an interface in place for streaming video to it over USB for people doing home-brew machines who want full color, but that also has some methods for setting persistent preferences such as the default color palette, so there should probably be a little app to talk to those for people who don't want to look at any code.

There are various methods for doing palette switching. You can modify the ROM in the same way SmartDMD does SAM stuff, or you can identify frames (or portions of frames) as they are displayed using a checksum, which is what ColorDMD does and what's happening in that CV video. The Teensy has hardware support for various checksum methods, but md5 which is what pin2dmd is using isn't one of them so the Teensy can't use the same data files. I don't know if their palette editor is open source? If it is I'd be happy to add output of the alternate checksum calculation. I've put it into PinMAME locally, just as debug output, but that isn't necessarily a convenient way to do anything.

The original SmartDMD method writes a palette id into the first 8 dots of images in the ROM, which you could use for WPC.

I don't mean to dampen your enthusiasm, it just isn't necessarily trivial to do in a way that's clean and works everywhere. If you're focusing on any one particular game there is almost certainly a way to do it. Watching that CV video most WPC games don't really have all that much animation, so frame checksums probably would work in lots of places.

Checksums / hashes are one way. If they weren't you could use them for super efficient compression. Doesn't look like the clock tool and the pin2dmd tool are the same. Getting the hashes directly from PinMAME is sort of convenient in some ways, but interacting with the simulation is annoying. I'll think about whether there's a better way to do that. It would also be possible to attach a button or something and dump them directly from the Teensy while it was running...

Ah, there you go then. I'll add the alternate version that the Teensy needs and they'll be able to share the same checksum based palette switches.

You can't currently get panels with the right dot size to match them.

Yeah. It might delay your shipping a day or two depending on my Mouser order. I wasn't expecting international shipping to beat the USPS.