TI-H: Color backlighting
[Prev][Next][Index][Thread]
TI-H: Color backlighting
A reqest for comments concerning the possability of
creating a color backlighting system for the calculators.
First, yes, I know its a silly idea, I persue it because
hacking the calcs is amusing, not because I think it has
any inherent value. Its interesting to see just how far
beyond its original design you an push a system. So don't
worry about it if you think its stupid, I'm only interested
in your opinion if you have input on the technical aspects
of implimenting it (suggestions, possable difficulties,
etc), or you wish to participate in software or hardware
development.
I don't know much about the grayscale routines in the
calculator. This all makes the assumption that it would
be possable to have 3 or 4 seperate screens, or color
planes, which can each be shown for an interval. (??)
First, a fiber optic backlight panel is installed behind
the LCD, and three LED's are used to illuminate it, red,
green and blue. The LED's are driven by a microcontroller.
The microcontroller can multiplex the LEDs such that a wide
range of colors is produced (I'm aiming for a palette of
around 256).
Since timing between the color change and screen-flips
is critical, the microcontroller must either have its
clock syncronized to the calculator, or have a low-
latency communication channel to the calculator.
The clocks could be sycronized in two ways, either the
microcontroller can be clocked off of the calculators
clock, or the micro can use a regular ~10Mhz clock and
replace the calculators RC clock circuitry.
Option 1 is probably less intrusive, but does not provid
a clock that is anywhere near as stable, and forces the
micro to run at a fairly slow rate, which may degrade
its ability to provide color mixing.
Option 2 is probably more difficult to get working, and
is more intrusive (requiring the removeal of the calc
clock), but allows for a very stable and adjustable
clock. This option also allows for the use of an
accurate real-time clock on the calculator.
Using a sycronized clock removes the need for a low
latency communications channel, the color palette
and timing info can be preloaded into the micro,
and the calc program can then easily know when each
color will be active.
One possable problem would be with startup sycronization,
where the calc would know when the micro was switching
colors, but not which color was active. This could
probably be worked around by careful counting of clock
cycles.
If the clocks are not syncronized, some form of low
latency communication will be necessary so that the
micro can notify the processer when the color will
change (or the calc can notify the micro when to
change the color). This could possably use a direct
interface to the address bus, or possably an interrupt
signal. I'm not clear on the options here.
Without knowing more about how the display works,
I'm not sure how color screens would be displayed,
perhaps someone could give a few examples?
If someone can explain how it would work, I can
write a windows app to demonstrate the technique.
This would be a preliminary step towards actually
implimenting the scheme.
later
DK
Follow-Ups: