View source for Talk:Z80 Routines:Graphic:Fastcopy

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.  --[[User:Dan Englender|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? --[[User:JasonM|JasonM]] 16:38, 25 Apr 2005 (PDT)
:I added a Safe Copy routine, since there isn't really a reliable timing to suggest.--[[User:Jim e|Jim e]] 11:00, 26 Apr 2005 (PDT)
::Is is still faster than the _grbufcpy BCALL ? [[User:Guillaumeh|Guillaumeh]] 12:35, 26 Apr 2005 (PDT)
:::Of course, it should only take slightly longer than fastcopy, but will always work.--[[User:Jim e|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? --[[User:JasonM|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." --[[User:AndyJ|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.--[[User:Dwedit|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.--[[User:Jim e|Jim e]] 20:16, 26 Apr 2005 (PDT)
::And when the cursor flash has been disabled.--[[User:Kalimero|Kalimero]] 03:22, 27 Apr 2005 (PDT)
:::Well the cursor should only flash if the edit buffer is open, and shouldn't be.--[[User:Jim e|Jim e]] 07:16, 27 Apr 2005 (PDT)

::::What about grapher cursors?  They dont need edit buffers.--[[User:Woozle|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.--[[User:Jim e|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? --[[User:JasonM|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.--[[User:Jim e|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.) --[[User:Aquanight|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.--[[User:Jim e|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 <br>
NOP + Ld (HL),0 = 14 clocks <br>
INC HL + LD (HL),0 = 16 clocks <br>
2x INC HL (what ionfastcopy uses) 12 clocks <br>
[[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)