Page 1 of 1
[TI ASM] Interrupts/"Fast Mode"
Posted: Thu 29 Mar, 2007 9:22 pm
by bfr
I have some assembly-related questions:
1. Does disabling interrupts allow both regular assembly programs and Flash Applications to run faster?
2. There is something known as "fast mode" for the TI-83+ SE/TI-84+/TI-84+ SE that allows these calculators to run at 15MHz instead of 6MHz (I think). How would I turn on "fast mode" and turn off "fast mode" in an assembly program?
3. While "fast mode" is turned on, I will have to increase the delays when reading/writing from the key port and the LCD, right? If so, then by how much?
EDIT: Edited topic title
Posted: Thu 29 Mar, 2007 9:55 pm
by Jim e
1: Not a whole lot really. But yeah there maybe a speed up.
2:
Take a look at wiki ti for other info.
link
3: yeah, between the in and outs of the key port, add in say 12~16 tstates, thats about 3 nop's.
For the lcd you should wait until its done for maximum compatibility. Read up
here
Posted: Fri 30 Mar, 2007 8:24 am
by King Harold
for 3 you could use my infamous LCD waiter: (destroys C and F)
Code: Select all
WaitLCD:
ld c,$10
-: in (c)
ret p
jr {-}
if you call it, it will wait untill the LCD is ready for the next instruction regardless of CPU speed and the number of CC's that have already been passed since the last instruction to the LCD driver. The right place to call this would be right before an instruction to the LCD.
the "safecopy" on the page Jim E linked to uses the same trick, the safecopy routine will also always work no matter what the CPU speed is
Or you could mess with ports $29 - $2C (LCD delay)
Posted: Fri 30 Mar, 2007 9:27 pm
by bfr
OK, thanks for the help!
Posted: Fri 30 Mar, 2007 11:24 pm
by Liazon
too bad safe copy tstates will go unused
Posted: Sat 31 Mar, 2007 1:56 am
by tr1p1ea
Well thats why its a safecopy, since its safe
. Like mentioned in the wiki, of course you can use them to do stuff, but best to try those sorts of things once you know the full picture.
Posted: Thu 17 May, 2007 5:18 pm
by driesguldolf
A little optimising (I think) of the waitlcd routine:
in your header file write
#define waitlcd in f, (c) \ jp m, $ - 4
hmm..., not sure about that -4, plz correct me if I'm wrong
make sure that c is $10 tough (and don't use c unless you reset it to $10)
to use it just type waitlcd as you would type an instruction
im not sure if this is faster
Posted: Thu 17 May, 2007 8:43 pm
by Jim e
$-2
In terms of performance....it's mostly luck. How fast the driver works is not very uniform so its possible to get lucky and check the port at the right time. But if you missed the lcd reporting being ready by just a few tstates, then you would have to wait for the loop to check again. So thats why a smaller loop would be better.
Posted: Sat 19 May, 2007 2:43 am
by Dwedit
$-3 for JP, $-2 for JR
Posted: Sat 19 May, 2007 2:55 am
by Jim e
Dwedit wrote:$-3 for JP, $-2 for JR
$ behaviour will be the beginning of the current line being assembled. Thats true for tasm compatible and ZDS.
So it should be $-2 since he wants to jump before the in f,(c).
Posted: Sat 19 May, 2007 2:56 am
by Spencer
$ refers to the address of the start of the command. It's $-2 both ways
$ should never sanely be used in a command. most assemblers have some notion of a reusable label
Posted: Sat 19 May, 2007 4:26 am
by Halifax
doesn't call $000B do a suffcient delay no matter what mode. Maybe it's not optimized because I don't know about TI, but that's what I think it is IIRC. I would just go with the waitlcd but I was just saying.
Posted: Sat 19 May, 2007 6:19 am
by Jim e
Halifax wrote:doesn't call $000B do a suffcient delay no matter what mode. Maybe it's not optimized because I don't know about TI, but that's what I think it is IIRC. I would just go with the waitlcd but I was just saying.
It should under normal circumstances. It's possible it won't in certain circumstances but that would only happen if that calculator has already crashed or some one was playing with things they didn't know how to work.