Difference between revisions of "Talk:Z80 Routines:Graphic:Fastcopy"

From WikiTI
Jump to: navigation, search
(Potential Nspire issues: new section)
Line 36: Line 36:
 
2x INC HL (what ionfastcopy uses) 12 clocks <br>
 
2x INC HL (what ionfastcopy uses) 12 clocks <br>
 
[[User:Darkstone knight|Darkstone knight]] 08:28, 6 November 2008 (PST)
 
[[User:Darkstone knight|Darkstone knight]] 08:28, 6 November 2008 (PST)
 +
 +
== Potential Nspire issues ==
 +
 +
The "safe" routines described on this page have their own problem: since they use undocumented instructions, they may not work on the Nspire.  (Can anyone confirm this?)
 +
 +
I would guess that, since the Nspire is emulating the T6A04 anyway, the delay isn't really needed at all.  (Can anyone confirm ''this''?)  If so, it should be sufficient to replace
 +
    in f, (c)
 +
    jp m, $-2
 +
with
 +
    cp a
 +
    in f, (c)
 +
    jp m, $-2
 +
since the Nspire will presumably skip over the undocumented instruction; "cp a" clears the sign flag regardless of the value of a.  At some points, of course, the "cp a" can be avoided, if you're sure that the sign flag is already reset.
 +
 +
At some points in the routines, it might also be possible to use a normal, documented instruction such as "in b,(c)" instead.  Which leads us to the question of whether the Nspire emulates port 10 for input at all...
 +
 +
[[User:FloppusMaximus|FloppusMaximus]] 01:44, 1 June 2009 (UTC)

Revision as of 18:44, 31 May 2009

The di is not that dispensible. The display may be messed up if an interrupt that displays to the screen occurs during the fastcopy routine. It's not the end of the world if this happens, but it's worth the extra byte to prevent it. --Dan Englender 07:11, 25 Apr 2005 (PDT)

Warnings?

Also, what would we say about the new issues with the bad LCD drivers? Can we provide a fast routine that will support the bad drivers? --JasonM 16:38, 25 Apr 2005 (PDT)

I added a Safe Copy routine, since there isn't really a reliable timing to suggest.--Jim e 11:00, 26 Apr 2005 (PDT)
Is is still faster than the _grbufcpy BCALL ? Guillaumeh 12:35, 26 Apr 2005 (PDT)
Of course, it should only take slightly longer than fastcopy, but will always work.--Jim e 14:51, 26 Apr 2005 (PDT)
I clarified what was going on with the messed LCDs a bit. Should we put something on the top of this page so programmers are alerted to this problem? --JasonM 15:07, 26 Apr 2005 (PDT)
We could make a template for it, saying something like "This code may not work properly on some calculators due to manufacturing differences." --AndyJ 15:34, 26 Apr 2005 (PDT)

MirageOS's fastcopy does not disable interrupts, while Ion's does. Anyone trying to emulate MirageOS should know that, or else MirageOS programs that assume interrupts are enabled and halt (Yahtzee) may crash.--Dwedit 19:56, 26 Apr 2005 (PDT)

True, but this isn't necessarily pertaining to MirageOS, or any shell for that matter. A nostub program would need to disable interrupts or disable the busy indicator. A note should be made about why DI could dispensible, if a person disables the busy indicator.--Jim e 20:16, 26 Apr 2005 (PDT)
And when the cursor flash has been disabled.--Kalimero 03:22, 27 Apr 2005 (PDT)
Well the cursor should only flash if the edit buffer is open, and shouldn't be.--Jim e 07:16, 27 Apr 2005 (PDT)
What about grapher cursors? They dont need edit buffers.--Woozle
Well now that's just pushing towards a different topic. "When do you need to use fastcopy." I guess something should be said about when you would need to fastcopy and when ti-os handles it for you.--Jim e 14:05, 27 Apr 2005 (PDT)

The main question regarding the interrupts is this: does the TI-OS touch the LCD driver if you have disabled the run indicator any anything like flashing cursors? --JasonM 16:30, 27 Apr 2005 (PDT)

We really shouldn't over complicate this. We know that there are certain instances where the DI isn't needed. That's when the interrupt won't use the lcd for anything but a status read. The most common case where an interrupt will affect the lcd driver is with the busy indicator.--Jim e 17:42, 28 Apr 2005 (PDT)

Why not just disable interrupts during fastcopy and turn them back on when returning to the program? (Or go even more tricky using ld a, i or similar.) --Aquanight 13:29, 29 Apr 2005 (PDT)

I foregot about the ld a,I thing. that could work. But still one problem, If the coder is depending the interrupt timing, then DI will mess that up. But again it's getting more complicated than it should.--Jim e 16:55, 29 Apr 2005 (PDT)

faster

ld (hl),0 takes 10 cycles, so we can do with one less inc hl (6 cycles) and thus 
load 11 into de instead of 10.

actualy, it is faster to load 12 into de instand of 10, and use NOP
NOP + Ld (HL),0 = 14 clocks
INC HL + LD (HL),0 = 16 clocks
2x INC HL (what ionfastcopy uses) 12 clocks
Darkstone knight 08:28, 6 November 2008 (PST)

Potential Nspire issues

The "safe" routines described on this page have their own problem: since they use undocumented instructions, they may not work on the Nspire. (Can anyone confirm this?)

I would guess that, since the Nspire is emulating the T6A04 anyway, the delay isn't really needed at all. (Can anyone confirm this?) If so, it should be sufficient to replace

   in f, (c)
   jp m, $-2

with

   cp a
   in f, (c)
   jp m, $-2

since the Nspire will presumably skip over the undocumented instruction; "cp a" clears the sign flag regardless of the value of a. At some points, of course, the "cp a" can be avoided, if you're sure that the sign flag is already reset.

At some points in the routines, it might also be possible to use a normal, documented instruction such as "in b,(c)" instead. Which leads us to the question of whether the Nspire emulates port 10 for input at all...

FloppusMaximus 01:44, 1 June 2009 (UTC)