Good morning,

Pinball browser colorization methods has a severe limitation with regards to rom size, I get loads of memory errors when trying to apply some of the macros (in this case for Star Trek).

This leads me to the following question: is there a fundamental reason why PIN2DMD cannot fully support Stern SAM using the traditional PIN2DMD colorization technique ? Is this completely impossible, or is this a SW development resource limitation ?

ColorDMD seems to be capable of supporting this without any change to the ROM, so I would assume PIN2DMD should be able to ? Unless there is a patent constraint ?

Regards

Yes, I was aware of that limitation. I'm just wondering if there is a technical roadblock, or if this down to purely development ressource constraint. I would think an implementation of PIN2DMD regular DMD structures (in .FSQ and .PAL) would not have any limitation related to rom size (plus would be more easy to transfer around).

I won't pretend that I understood fully the limitations you outlined regarding Stern SAM support, but... Does this new version imply that it's actually now possible?

Regards

Congratulation, if I'm not mistaken this is the first SAM game colorized using PIN2DMD updated tool and firmware, am I right ?

Exactly my point

Pretty cool, I'm glad I did not spend time on learning Pinball Browser... And oga83 should really really really allow to export DMD frames now, since if I understand correctly, with your method there is no rom size limit (as there is with PB method) ?

Lovely. Time to issue another PIN2DMD build for my SAM games

What's next ? May I suggest Star Trek Pro/Premium/LE (OK, I admit, I have one)
And maybe Tron (although I actually wonder if this makes sense for this one)

There was a Star Trek colorization done using Pinball Browser, I could never use the macro system to apply it to my premium rom, kept throwing out errors. I wish there was an easy way to convert that colorization to pin2dmd

The Walking Dead maybe?
Thinking of it, Tron would be nice, I'm sure there something to be done

Wow you're fast....

Indeed better, although it's hard to judge picture quality from this distance for the animated scenes.

You mention a Python script, would you mind to elaborate? Interested into how you use Python to automate colorization.

Regards

Ah cool, using optical flow is indeed a nice idea (yes I'm familiar with it).

Funny, looks like resistor in series, very likely to adjust input level to something lower than 5V... I would have thought they would have used at least a clean level shifter. Can't be bus termination, as it would need to be closer to the input.