Brightness is actually an 8bit value so it goes from 0-255.

This was totally my fault. I forgot that he had ordered an assembled kit and so I had cut the trace that allows it to be powered over USB. This is a safety measure to ensure you'll never have your computer's USB port directly connected to an external power supply.

At very low brightness settings it can't do a good job on subtle color differences because the timing is less flexible.

Yeah, there are still refinements to do as it gets tested in more and more machines and issues show up. If you email me I can send you a new file to try or you can wait a day or two and I'll update the github code.

Pushed some updated code to github. If you're having update problems you should try it both with and without the define on line 11 of InputDMD.ino.

#define DMA_COMPLETION_ISR 1

There was also an extremely weird issue with getting a single solid color dot on the screen that showed up if you were compiling with the 96Mz (overclock) setting, but not with the 96MHz optimized (overclock). It's gone for now, but it's a weird compiler related thing of some kind so I'm not positive it's gone for good. Please let me know if you see that with the new code.

Still moving along, although I haven't been doing much for the last few weeks.

System 3 is weird, and I haven't spent much more time trying to decide how best to handle it. If anyone is interested in taking over some testing from winteriscoming let me know.

A couple people have also seen issues with it not using the colors they set on some startups. My best guess is that in these cases the system identification code is wrong and it's using the palette for something else (probably System 3 in fact). Trying to get some more data to squash this one.

Hah! Didn't mean to imply you were slacking, it's just not something I can work on by myself since it requires testing and feedback. I expect you'll be back in 16 years or so once that whole baby thing is under control.

It will run off the DMD output on the P-ROC although you might need to update the platform detection slightly (I've run it off mine, but I'm not positive the detection is active in the github code). I've also run it directly from PinMAME but you'd have to be building from source because that's just proof of concept code I did here, I haven't pushed the changes.

When using PinMAME with the P-ROC you can either talk to the DMD using the header on the P-ROC, which should work after you double check that the DMD signal gets recognized, since the P-ROC timing isn't the same as a regular pin, or you can talk directly from PinMAME to the RGB.DMD. I have written the code to do that, but it isn't integrated with official PinMAME or well tested.

Not sure how snux is getting full credit for the P-ROC PinMAME stuff, but that's a different issue.

agodfrey was having issues after upgrading to Arduino 1.6.8 because they changed some of the compiler defaults. Those have been fixed in my branch of SmartMatrix on github.

Is it consistent or does it shift back and forth between being correct and being off by a line?

Well that should make it easy to work around if nothing else. You could start by commenting out the WIP Premier code to make sure it isn't accidentally misidentifying the machine (lines 306-308 or so, shown at bottom of window in Arduino):

// else if (planeTimes[0] < 100) {
// dmdDataFormat = FORMAT_PREMIER;
// }

Sure, glad that fixed it!

Not sure why some people are having trouble with that Premier test code, but it's clearly not ready for prime time.

EDIT: I commented out that code on github, so hopefully people won't have this issue until we get some more testing in on the Gottlieb/Premier stuff.