Re: A83: Two graphical problems to solve.
[Prev][Next][Index][Thread]
Re: A83: Two graphical problems to solve.
On 2001-01-19 07:13PM, Martin Virt wrote:
>
> Hi!
>
> Is it really calculator dependent or does that depend on the batteries?
> IIRC, in devices like Palms, calculator speed is related to the voltage
> of the batteries (and the oscillator, of course). Now assuming that the
> LCD driver's delay rate is constant, new batteries require a longer
> delay in the code, while those already in use may work just fine with a
> smaller delay rate.
I think it is calculator dependent because I never have a problem with
Ion (even with new batteries) and yet I get emails from people with
messed up screens. I often suggest using weak batteries, I tried this
on someone else's calculator once and it worked. Certainly not the
best solution though.
>
> So 65 (perhaps even 70) clocks is a safe guess. Hmmm ...
>
Probably, next time I work on Ion I'm going to try raising the delay,
maybe even have multiple versions (after all, the Silver edition is
probably going to be a major pain).
>
>
> In any case, what happens exactly if the delay is too fast for the
> calculator?
>
The screen gets garbled, it's not permanent damage though.
> Not this one. The Eble/Yopp routine benefits from from the 86's screen
> length of 16 bytes, and a neat trick with the RLD-Routine. There's no
> way this can be duplicated, as the 83/83+'s screen length is 12 bytes
> and therefore doesn't conform to nibble-boundaries. To be honest, I've
> already written a routine, but the ~160 clock cycles can't compare to
> the 127 of Ti-86's. I'd like to compare it to other routines in order to
> find anything that I may have overseen. (And I still have to test it for
> *possible* bugs...)
>
160 clocks sounds very good to me. Is there some reason you need it to
go faster? Or just optimization fun...
> Thanks again,
> Martin
>
--
Joe Wingbermuehle
http://joewing.calc.org
Syntactic sugar leads to cancer of the semicolon.
- Alan Perlis
Follow-Ups:
References: