Alright, so it's not exactly a *binary* clock, but @Benchoff's project does look awesome...
If you like blinky-lights, click here: http://hackaday.io/project/5156-rgb-seven-segment-clock
(UPDATE: See more conceptual-pictures below)
So.... a brief brainstorm...
It might be darn-near plausible, if not probable, to accomplish this sorta look with the system driving this LCD-binary-clock...
Again, it's absurd, maybe, to use something like an LCD with such high-resolution potential for something that could be done with LEDs designed for the job... but therein lies a challenge that appeals, a bit... Not only does it look cool because it's colorful, but also because it has that very clear 7-segment feel *while* being colorful; the angled edges, whatnot... I dig it. (Also, I kinda dig the brighter glow in the middle of the segments, but that's not realistic with this system).
Attempting something like this with this LCD thingamajig?
Well, first... masking,... that'd take care of some of it. But with the huge square pixels used in *this* system, as-configured, I don't think it'd be able to handle the angles of a seven-segger where three segments meet.
- (Row-segment buffer, for high-resolution)
- ROTATION (for those 3-segment corners!)
This is *VERY* quick and rough... But maybe the idea can be gotten from this:
("Mask" generated via Gimp from an image at the link, above. @Benchoff, hope you don't mind!).
Some work, obviously, would have to be done to align things better (I really only focussed on the '9'). Don't forget that 7-seggers generally have a *slant* toward the upper-right, slightly italic. Apparently that's quite a bit more complicated to work into square-pixels. Also, note the verticals are shorter than the horizontals... Another consideration, which makes square lighting a bit more difficult...
And, some vague idea that the mask would be intentionally movable, so that it just looks like a random color-pattern except when the mask is positioned properly...? (I guess there'd have to be lots of black pixels in that pattern)
Some finagling could be done, as well, with changing the number of pixels in either direction (within reason, there's only 512B of RAM!)... even, possibly changing the heights of *certain* rows... (And then, of course, there's always the possibility of the "row-seg buffer"... which could pretty much handle all this, with a bit of work... Maybe it could be used with roughly-random polygons and a movable-mask... intriguing)
Here's some more Gimp-Experimentation...
Key Concept: There's absolutely no reason whatsoever why the pixels have to be square... Nor even consistent in height (though, width is quite a bit harder to mess-width, *especially* if not in columns).
The (majority of the) black blob,, again, is a mask... it could be laser-cut or something....
(The gridlines show the potential shapes of the pixels on the screen, they obviously vary dramatically, mostly in height. Width is harder to vary, as it's generally handled by Assembly-instructions for the fastest possible refresh-rate. But there're ways to tweak it a little bit, if necessary.
I think it's *just under* 16 pixels in *both* directions, so, no memory problems, even with a full frame-buffer :)
Below is what it could look like without the mask:
These are the *relevent* pixels...
Of course, there's no reason the *text* has to be diagonal... the display itself could certainly be rotated to make the text horizontal... There's no reason the rest of the display needs to be visible, either... it could be completely masked except where the segments are located.
Anyways, it's more a mental-challenge than anything else... opening up new ideas for how to make use of/improve this circuitry/software.