Hello there!

Perhaps this is already known...Anyway I post my work

Well...While studying Joe Wingbermuehle's FastCopy
(see http://wikiti.brandonw.net/index.php?title=Z80_Routines:Graphic:Fastcopy#IonFastCopy )
which, according to my counting, takes 51588 T-States,
I noticed that some of my TI's could manage "faster" fastcopy :
e.g. my TI-84 Pocket.fr & TI-82 Plus just don't need to wait a while between OUTs
Also my old TI-83 Plus (1999) needs no more than 45 T-States between out($11),a

So, I wrote a kind of faster fastcopy dedicated to those er, "not so old" TI's :

Code:

My version takes 13198 T-States (nearly four times faster)

Yep, the old FastCopy is tuned to work with the necessary delay on all of the calculators, including the ones with the slowest LCDs. Thanks for updating it for the newer, faster calculators! My only concern would be that most of us (to my knowledge) still write our monochrome ASM programs to work on the full TI-83+/TI-84+ line. I suppose that if you were aiming at the newer calculators, you wouldn't need to make that concession. Another technique people use is to use those delay cycles for actual useful work, like drawing sprites and so on.

By the way, what does the slowest/laziest LCD's TI 83+ model precisely require ,concerning T-States ?
I noticed that my oldest one (TI-83 PLus , 1997) requires packets equal to , at least, 56 T-States.
(for example : out($11),a ...then something 45 T-States long before next out(), )

Axe's equivalent routine has settled on 71-72 cycles between outputs, including the cycles taken by the output instruction itself.

In Axe's earlier stages, lots of people were eager to use it and report feedback. So if the delay was ever too low for even one in a hundred calculators, we'd probably hear about it. Through this mechanism, the delay was slowly brought up to what it is now. I believe the penultimate value tried was either 69 or 70 cycles, but one complainant prompted the increase to the final 71 or 72, after which it was confirmed that the complainant no longer had a problem.

Oh I see...thank you for these details ! I decided to find a way to distinguish between fast & slow LCD TI's...and i finally found :
In the beginning of the program, I added a way to check if the TI own a fast (enough) LCD controller:
you just run an In a,($10) just after an Out($10),a , in order to read bit7 named "lcdbusy"
(If =0 , that means LCD is fast enough)


Code:


It takes now 13237 T-States.