Probably not, I like the green just fine. With only 150 of them there's a pretty limited market.

It'd be great, but I don't know who would actually want to make it.

Before Ben developed his full-color solution for RZ, he and I collaborated to adapt the SIGMA (single-color) display to work with AMH. I think he had the RGB interface tied into the game lighting so the display would change color with the game.

I'm not sure if it's working anymore but could be something resurrected (cool! a spooky reference!) if there's enough interest.

It wouldn't be full-color though. Just a single-color display (with scaling support) that can change color with game modes.

Randy

Probably not. I haven't bought them for any of my other games that could use them more. Besides that my white display looks awesome.

Hemi (Pinball Refinery) tried to make it work on a production game and did run into a sync issue. I'm guessing there was some change to the interface timing after we had it working. Probably not hard to fix if I can get a logic capture from the output of the board.

The SIGMA display accepts a simple RGB+ signal to set the color. My understanding is this is the same interface going to other playfield or backbox lighting.

I voted no but would change that to yes if Ben was involved and it fit the campy style of AMH. Right now I think the Xpin white board with color filters is pretty cool.

I'm resurrecting this thread to ask if there's something I can get for you. I don't have a logic analyzer, but I do have an oscilloscope.

I would likely put a Sigma display in mine if it worked. My original display has a pixel that's out, and the blocky looking grid drives me crazy. I've done the synchronization thing before with Tron and the ramp lighting, and it would be relatively easy to do similar with the AMH LED strips.

Been a long time since I worked on this so might take some time to clear the cobwebs. From what I recall, the data portion was working and it was showing a picture. It was just the alignment to the first byte of the frame that had become wonky.

Probably need to see something like the relationship between the Row Data, Row Clock, Display Enable, and Column Latch signals.

No rush though. I'm neck deep in projects.

Understood, and thanks for the response. I'll see what I can get for you. One of these days, when you're bored, maybe it will be useful.

Edit: I found the video that HemiOrange09 made that was referred to earlier. Just thought I'd link to it here.

OK, here's an attempt at showing those signals without knowing exactly what you're looking for. First, a description of the frequency of each.

1 - DE - steady high
3 - ROWDATA - 784 Hz
5 - ROWCLK - 25.09 kHz
7 - COLLATCH - 25.09 kHz
9 - PIXCLK - 3.2122 MHz
11 - SDATA - data aligned with PIXCLK

A few screengrabs with ROWDATA on CH1 and ROWCLK on CH2
pic_7_1 (resized).jpg
pic_7_2 (resized).jpg
pic_7_3 (resized).jpg

...and a couple of ROWDATA on CH1 and COLLATCH on CH2
pic_7_4 (resized).jpg
pic_7_5 (resized).jpg

Let me know if there's anything else in particular you need to see.

I'd be interested in a color AMH.

I can't seem to get this out of my head. It's to the point that I'm considering options.

1. Contact Randy about coloring AMH myself. Of course, the alignment issue would have to be solved first.
2. Research what Spooky did for RZ and see if it could be adapted.
3. Look into the homebrew options.

I keep telling myself that I don't need another project, and a green display is fine, but I can't shake the thoughts.

I vote for either #1 or #2 option, Herg.

easy enough to contact spooky about it, but if the process of colorization was easy enough, it would have already been done.

[email protected] would be the first place, then maybe have him reach out to benheck on your behalf (or contact Ben directly on here).

Oh, I agree those would yield the best end results. I am not sure I have the motivation to see them through, though. I know how much work coloring a game is, and I'm not exactly eager to take it on. I don't want to spin up those guys if I'm not sure I am dedicated to the project. The only benefit to #3 is that I could buy some parts, throw my own display together and play with colorization without any pressure to complete it.

I'm not saying it would be easy, but the groundwork has been laid, and I am capable. There are different motivations for these sorts of things, and from what I can tell, Ben is just not interested in putting any more work into AMH. I have spoken with him about a couple of other improvements, and while he has been courteous about it, I can tell he's not really interested.

I already tested AMH with PIN2DMD and after a small firmware modification it was working fine.
We were also testing a simple palette switch with pin2dmd editor (green to red)
Here is a small test video the AMH owner sent me

honestly i think all of the spooky games have just horrible displays. i really dont understand why. always blurry and is odd for a machine made with a modern display.

I had seen that. Beyond the disputes over legality, which I really don't want to get into, I am not in love with the RGB LED displays. They look harsh to me, and I can easily pick out the individual LED emitters.

The reason I see for this is that the graphics a converted and downsized to fit the DMD and not specifically drawn for it. As far as I remember it simply is a collection of GIF graphics in the table firmware.

O.K. LCD vs LED that is personal taste. Yes ColorDMD has been very successful in defending what they believe is their territory by threatening their competitors and asserting things. That is nothing but saber-rattling. I just wanted to inform in case you did´t know about pin2dmd and maybe others prefer LED.

I always got the impression they were going for an 8-bit look for those of us nostalgic about the 80’s. Not to mention the humor...

I spent some time investigating this weekend.

First, I tried simply connecting the ColorDMD from my TZ (flash with Sigma, or course) to my AMH. When I did that, I got no display other than the built-in ColorDMD menus. I looked at the old source code for the AMH Propeller that drives the DMD, and it hasn't changed at all since at least AMH v9 code. I am still not sure how HemiOrange09 has it partially working in the video above.

Then, I decided to try rewrite the Propeller code to match a Stern SAM output. I had some partial success. The biggest issue I still have remaining is that I can only send 4 brightness levels or a row of pixels end up wrapping to the next row, effectively stretching the picture vertically. If I only send 4 brightness levels, it does work, and it is aligned properly.

I guess I need to research the Stern SAM DMD timing a bit more to find out what I'm doing wrong. I do not fully understand how the COL LATCH and ROW CLK signals relate the the brightness values. I've looked a scope traces and used some trial and error to get this working as well as it is.

Fyi, the visual pinball table (which uses code and assets from Ben Heck) can be full color or color of your choice. Uses a program called UltraDMD. Not sure how any of that stuff works on a code level, just putting the info out.

IIRC, Ben sends the data serially as 8 frames instead of binary encoding like SAM and PROC. Ben provided me with a board (I still have it somewhere with the old code) and I had built a special ROM and sent it to Ben and Charlie to test and they confirmed it was working at the time.

One issue for full colorization was that the framing for the 8 serial frames is currently defined and Ben and I talked about making a change to support that. He also had a different idea for sending color directly which I think ultimately made it into RZ.

Somewhere before production, the DMD signalling interface changed slightly and the frame alignment by the ColorDMD was no longer locked. It would still make a picture but the frame alignment was off. I can send you the ROM if you want to play with it.

Ben and I have gone back and forth over identifying/fixing whatever went wrong. I think we've just both been too busy to follow up and get it done. For full video colorization, I think it would probably come out better if Ben did it natively similar to RZ.

Looks great. Just needs colorizing now? (easy for me to say, I know)

Yes, serially, though as 16 frames. I did not realize that SAM was binary encoded, which would explain what I was seeing with it only accepting 4 bits before moving to the next row. I can give it another attempt with that nugget and probably get the full brightness range working in SAM mode.

If it was rewritten to act like SAM, that would address that, correct?

Hmmm... It sounds like one end would need to change anyway. I feel like I'm really close with the SAM mimic, and from what I understand, that would avoid any changes that would be needed for the serial framing, I think.

I believe you're right in that the coloring would come out better if it was done like RZ. You wouldn't get the same dot mode options, like HiRes, that ColorDMD gets you, though.

I know that Ben has said he's moving on, and I feel like for me, there are more unknowns in the RZ approach. It would also depend on whether Spooky wanted to sell display hardware. If I had documentation, and maybe example code, I would be willing to work on getting the interface to work for either RZ or ColorDMD. That's the part I find fun. The coloring, not so much, and I'm not sure if I want to sign up for that.

Maybe it's worth contacting Ben again. I have a couple of other enhancements (knocker support, a fix for the Dr Ghost fuse, etc.) working in v22 (old open-source version), but I don't have a way to get them into the new code.

You're better off using binary encoding wth the PROC setting on the ColorDMD than SAM (I can explain why in a PM), but yes that would solve the problem.

I respect your opinion as an owner of AMH and agree the green looks fine. On the other hand, the vast majority of these went straight into the game rooms of fairly wealthy individuals(which is fine). IMO those are the people who would be interested in a color DMD upgrade(bc let's be honest, it's the best mod in the history of pinball) so I think they could sell more than a few.

Thanks You can find my modified propeller code with source which uses binary encoding here.
https://github.com/lucky01/PIN2DMD/tree/master/integration/Spooky%20Pinball

Yeah, I made the change this evening, and it's working well. I wish I had known that P-ROC was a better target, but I've proved to myself that it works, one way or another. I can tweak later if needed. I guess it's time to ask Ben what he thinks about releasing Chroma-color info and make a choice on which approach to take.

I haven't heard back from Ben, but I did dig into what information I had available and started some work on it. I have a good start, but there are some significant challenges.

1. The Chroma-Color interface supports 256 colors total, and they are chosen ahead of time. It is a RGB332 format, meaning 3 bits of red, 3 bits of green, and 2 bits of blue. Coming from 16 shades of gray, it's difficult to map into smooth images since blue especially, only has 4 distinct values, one of which is black.

2. The memory in the propeller available for the fonts is very limited. You will see in the video that I don't have them working yet. Going to 8-bit RGB from 4-bit grayscale using the same method would require 2x the RAM, which I don't have available. Storing it as a lower bit depth and expanding to RGB when needed works, but is slow.

Anyway, I'm having fun trying to get it working, and I wanted to share a bit of progress.

Not sure I followed what you mean by the "Chroma-Color interface". Are you hacking the source on a pinHeck board to add the color?

Yes. What's in the most recent video is rewritten AV code running on an AMH with the display jumped over to my RZ display. Chroma-Color is the fancy name that Ben gave his color system.

Looks awesome Herg!

Actually, it looks like a mess, but it's getting there. People are telling me it can't be done, but I'm stubborn enough to try anyway.

This looks cool Herg. I want an AMH (some day) and color dots would be a great addition.

There are still some bugs, but this is coming together. Once the AV firmware is solid, it's going to need some seriously meticulous work to color it well. I'm losing a lot of detail with the automatic tinting scripts I'm using now. It gives me new appreciation for how good RZ looks given the restrictions of colors that are available.

I'm just going to say this now.. you guys are thinking about this way to hard.

Since V22 is the base you can start from, you need to rewrite AV from scratch, then you have to rewrite parts of AMH to account for timing differences. Oh and something else.. you will also need to worry about the sound system due to the limited program space on the propeller.

AV will need to be highly optimized and you'll need to write it in propeller ASM.

As much as I would love to do this myself, I have too many other things going on. Unless of course all 150 owners wanted color

I would have purchased a color solution, had it been available. Since it was not, and I caught a severe case of motivation, I used what was available. I tried to contact Ben, but he didn't respond.

It IS based on v22 AV code, but I'm still using v23 PIC code. I am not noticing any issues due to that mismatch, but if you feel like pointing anything out, I'd certainly take a look at it. Yes, I had to rewrite part of the AV code, some of it in ASM , but I would not say from scratch. This brings up a good point.

Since I am using Ben's v22 code as a base, and he has decided to retract it, I will not be able (or willing) to distribute any of this. Assuming I can get Charlie to sell me a display, my game will be the only one running this unless it goes through official channels. That doesn't mean FawzmaGames would have to write it, only that it would have to be approved by Spooky and/or Ben.

So, I saw that Ben was on a podcast a couple days ago, and listened to it for the first time. It explains a lot. He also mentioned the bug fix I sent him, and it sounds like it might still get included. I'm hopeful that knocker support can be included as well.

Still following and enjoy reading your progress.
-Mike

Just to let you know I'm following, and would be willing to pay for a color solution. What you already have Herg looks way better than a monotone display to me. Great fun watching you make progress on it too!

It's getting to the point that I want color displays on all of my games (what an expensive proposition), but it really feels a game is lacking when it doesn't have a color dmd anymore.

I tracked down the UltraDMD GIF package, and there are definitely some good colored files in there. It's weird, though, because it's only a small portion that's actually colored. For example, the Hellavator, Ball 1 Locked video with the camera girl is not colored, but I sense the Ball 2 Locked video is in full color. I would guess that Ben's source files are the same, since Shoopity (I think that was his handle) used them to create the UltraDMD files. Maybe I'll be deemed worthy of access to the original files and find out for myself.

I haven't tried to convert the UltraDMD files yet, but it should be relatively easy. The results may vary due to the limited bit depth, though.

Also, I do have a display on the way so that I can stop borrowing from RZ. Thanks, Spooky!

A couple of significant milestones:

I think I squashed the last major bug in the firmware last night. It still needs a bunch of play testing, but I played about a half hour last night with no noticable issues.

Next, I received the new display from Spooky, and was able to power it up with some custom cables.

20171031_190416 (resized).jpg

The biggest issue I have now is that I realized the RZ backbox is notched for the display, while the AMH one isn't. I have to decide whether to take a router to the cabinet or to mount it higher and adjust in software.

20171031_185812 (resized).jpg
20171031_185802 (resized).jpg

I decided to mount the display a little higher (not cut a groove) and adjusted the screen position in software. It's installed, but I still need to get a piece of clear plexiglass for the cover.

I'm finished with the software. It is working well enough that I think it's silly to put more effort into a v22 derivative when I might have v23 from Ben to work with later.

All that's left is to color a bunch of scenes. I'm finding this to be quite tedious and boring. I'm not artistic by nature, and the technical challenge is what interested me.

Anyway, here's what I have now.

nice job. let me know when you are ready to sell. it's the only game i have that is not colorized at this time.

That will be up to Charlie. It's a standard display as used in RZ, a new power cable, and new software on the SD card. Oh, and a new display cover.

You would need to buy the display from Spooky, and I don't feel it's right to distribute the software without their blessing. I won't be selling anything.

Nice job.