WikiTI - User contributions [en]

Talk:WikiTI Home

2008-12-19T23:27:18Z

Darkstone knight:

= Discussion =
What do you think about this wiki?

== More! ==

I think it needs information on more calculators than just the Ti-83+ series, and general assembly information (like a good cathegorized tutorial overview for instance) wouldn't hurt either, I think :)

Timendus

== I hope we can do that soon ==

Just, we don't want to waste time getting it all set up for that and have no one use it. If we see a lot of people milling around here, contributing, then by all means, we'll expand. But one thing we '''DON'T''' want to do is mirror 28 Days. We can link TO it, but we don't want it actually here.

--[[User:AndyJ|AndyJ]] 06:50, 27 Mar 2005 (PST)

== Categories ==

On many pages, there is now a sizable blank space at the top due to several lines of category links. What, if anything, should we do about this? [[User:FloppusMaximus|FloppusMaximus]] 19:06, 29 Mar 2005 (PST)

== Move them? ==

Move the Category links to the bottom should do it. :) That, or put them all on one line.

--[[User:AndyJ|AndyJ]] 19:07, 29 Mar 2005 (PST)

:Yeah, that sounds like a good idea. :) [[User:FloppusMaximus|FloppusMaximus]] 20:18, 29 Mar 2005 (PST)

:: I think I officially qualify as a robot now. You can tell I was getting tired towards the end, as I missed the minor-edit button a few times... sorry about that... [[User:FloppusMaximus|FloppusMaximus]] 21:28, 29 Mar 2005 (PST)
:: Actually, I was going to just mod the php code to fix this bug....keeping the category tags on the top might be a good idea actually. (JasonM)
:::That might still be a good idea. [[User:FloppusMaximus|FloppusMaximus]] 13:18, 3 Apr 2005 (PDT)

== Caching ==

Is it just me, or are there some serious caching problems here?
[[User:FloppusMaximus|FloppusMaximus]] 21:32, 1 Apr 2005 (PST)

: In particular? --[[User:Dan Englender|Dan Englender]] 21:42, 1 Apr 2005 (PST)

:: Ya, the wiki seems to have weird caching problems, especially since it appears the reload the page every time, even if it doesn't get changes. I don't know what's up. --[[User:AndyJ|AndyJ]] 22:35, 1 Apr 2005 (PST)

::: Considering the dynamic nature of a wiki (a page could be edited, at pretty much any time), I wouldn't mind not having it cached. (Though I would personally disable browser caching altogether if firefox would let me... :P ) --[[User:Aquanight|Aquanight]] 22:44, 1 Apr 2005 (PST)

:::: Er... I think I see what you mean... stuff is getting cached when it shouldn't be. (I could've sworn I told firefox to only use 0 KB (aka none) for cache and it's still caching ... argh.) --[[User:Aquanight|Aquanight]] 22:46, 1 Apr 2005 (PST)

::::: I've disabled caching myself as well. Perhaps we should just disable caching altogether? (JasonM)

::::::Caching has been disabled. (JasonM)

::: I found a "Disable Caching" option in Misc. Preferences, if that helps. [[User:Gambit|Gambit]] 00:28, 2 Apr 2005 (PST)

== On Other Calculators ==

Just a random idea I had -- a lot of the ROM calls, RAM addresses, and ports are very similar, if not identical, between the 83 and 83+, and more generally, between all of the Z80 calculators. For some of them -- [[83Plus:RAM:86D8]] and [[83:RAM:8253]], for instance -- it may be possible to combine the two into a single page, though I'm not sure that would be a good idea, given the potential for confusion. So here's what I propose instead:
* For simple things like penRow, we can just have two copies of the page, as there isn't very much to keep synchronized.
* For more detailed pages such as GetKey, have a brief description with a link -- "This routine waits for the user to press a key and returns it. It is equivalent to [[83Plus:BCALLs:4972|GetKey]] on the TI-83 Plus." -- on one page, and the more detailed description on the other. Not a redirect in this case; I'm talking about a distinct page, which would point out the different call points and RAM addresses; in the case of GetKey, for instance, the address of keyExtend is different and should be noted.
* In either case, on ''both'' pages, add a new section "On Other Calculators" near the bottom, with appropriate links. This section serves two purposes: First, it's simply useful information to have available, both for people trying to write cross-platform code, and for those of us who are interested in researching the OS. Secondly, it would serve as a reminder to editors that there are multiple pages that may need to be updated.
* It's also important to maintain the distinction between routines/variables/ports that are ''identical'' as opposed to those which merely have related functions. For example, the widely used GetK routine on the 83 isn't known -- to my knowledge -- on the 73, but GetCSC serves as an adequate substitute in many situations. This is something that belongs in "See Also," not in this section.
* Some templates might be in order here.

[[User:FloppusMaximus|FloppusMaximus]] 18:41, 24 May 2005 (PDT)

:It's not a bad idea. The only problem is that it makes a lot more work for people who just want to make a simple addition to the wiki. There's already a fairly high initial barrier (figuring out the templates and categories) to overcome for someone who wants to stroll along and add something to the wiki. For you and I it wouldn't be a big deal, but I'm worried it's going to dissuade a random person who floats by from adding ErrMemory to 83 Plus, because then 83 (and 86 or 73, if someone decides to start them) will have to be added/changed as well. --[[User:Dan Englender|Dan Englender]] 10:01, 25 May 2005 (PDT)
:It might also be cool to hack up the interlanguage features so we can have the nifty language link-box similar to what exists on wikipedia. --[[User:Dan Englender|Dan Englender]] 12:57, 27 March 2006 (PST)

== Wanted Pages ==
I decided it was too minor to post as news on the main page, but I modified the [[Special:wantedpages|Wanted Pages]] page so that the threshold is 1 link instead of 2 links. A *lot* more wanted pages show up now, though there is some junk in the list now too (like fake links from templates). I figure wanted pages are as good a place as any to start adding, so I'm going to try to make a dent in the list. Anyone who would like to help is welcome to do so :) --[[User:Dan Englender|Dan Englender]] 10:06, 25 May 2005 (PDT)

== Not "hardware" specific documents ==

I was so free to edit the artilce over Emulator(s). I also created an article regarding PindurTI.

As I already stated on the MaxCoderz board (http://joepnet.com/hosted/maxcoderz/phpBB2/viewtopic.php?t=1521), I think WikiTI has a lot of potential to collect information about the TI community aswell. Thinks like PindurTI, GrayScale and maybe even information about all the Zelda attempts. In my opinion, people can benefit from that information. --[[User:Kv83|Vincent Junemann]] 15:00, 21 February 2006 (CET)
:Hehe... Zelda attempts? We really do need a page for that ;) [[User:TD-Linux|TD-Linux]] 09:24, 19 October 2006 (PDT)

== Required logon ==

If the spam is being done by bots, perhaps instead of requiring a log-on, we can require either a log-on or a captcha? I realize there's additional coding involved, but we've had a fair number of useful contributions by non-logged in contributors, and it would be a shame to scare them off by prospects of account creation or the fact that we can track their activities, or what have you. --[[User:Dan Englender|Dan Englender]] 13:55, 23 Feb 2006 (PST)
:Agreed, if we can either find a mod for that or code one ourselves. Of course, maybe even a simple "check this box" thing would work if the bots are programmed just to hit mediawiki and not check for stuff... And if a botrunner ever finds it and fixes their bots, we can either just change it or go to a captcha... However, I think most of the legit anon edits were by people who have an account but just didn't notice they weren't logged in at the time. [[User:AndyJ|Andy Janata]] 18:40, 23 Feb 2006 (PST)

== Wiki update ==

Whats this undefined link I see on a lot of the pages?--[[User:Jim e|Jim e]] 06:07, 14 March 2006 (PST)
:Example? --[[User:Dan Englender|Dan Englender]] 06:12, 14 March 2006 (PST)

::This page has it right under the contents.--[[User:Jim e|Jim e]] 06:18, 14 March 2006 (PST)
:::I'm not seeing it. Screen grab? (Also, try clearing your browser's cache in case something's not playing nice between this and the old wiki) --[[User:Dan Englender|Dan Englender]] 06:21, 14 March 2006 (PST)

::::....It's gone now. I guess it was a fluke, but I did get an image before it disappeared, just to prove i'm not crazy. Pic
:::::I removed the link to that pic since your domain expired and it was snagged by nice search spammy people. [[User:AndyJ|Andy Janata]] 12:11, 21 July 2007 (PDT)

== Motivation Idea ==

Here's an idea that might spark more interest in WikiTI...

Usually, this stuff occurs on the subconscious level, but what if it was brought out from these depths? We have this inquisitive.. knowledge.. accumulate thing... and so what if there was a page (or maybe a set of them) that had a list of questions about the unknowns of the TI-OS? This idea came from this quote:

<nowiki>In mathematics the art of asking questions is more valuable than solving problems. ~ Georg Cantor</nowiki>

All questions would be welcome (not sure about programming help oriented ones though), but maybe not all questions would be answerable, and maybe some questions would be better off not being answered. Other users will fill in the blanks and try to answer the question (because of generosity/competition/whatever). Concurrently, some users might think that some Q&A sections fit well together and then they will merge these into a wiki page. It might also be possible for someone to write a wiki page as an answer to a question!

The point of such a page as this is to 'encourage hacking' in its traditional sense, as it were. As a side effect, it ''might possibly'' help us all (new and old alike) with our hesitancy in editing a page. Furthermore, I think that this idea will only work if there is a continual asking of questions; otherwise, it will lag and eventually '''fail'''. Hence, the [[Wikipedia:WP:BB|Be Bold]] slogan of Wikipedia.

For example:
What are the specific differences between GarbageCollect-ing and "Defragmenting..."?

[[User:Brandonw|Brandonw]] and I talked about this on IRC:
<nowiki><BrandonW> It's a good idea, but I'm not so sure about it working on WikiTI.
<BrandonW> Maybe the question is elsewhere and the answer can be posted on WikiTI.
<BrandonW> The answer to every question can be a WikiTI link.
<BrandonW> That makes WikiTI bigger with more information and people get their questions answered.
<Gambit_> hmm, asked where? Is there a central location somewhere where these would be asked?
<Gambit_> WikiTI subforum in DS, perhaps?
<BrandonW> It could be hosted anywhere...someplace new.
<Gambit_> hm
<BrandonW> Perhaps.</nowiki>

Good or bad? Thoughts? --[[User:Gambit|Gambit]] 23:55, 10 February 2007 (PST)

: It's a good idea, but I'd rather see a broader page about general requests/wanted pages for the wiki, not just TI-OS related ones. [[User:Guillaumeh|Guillaumeh]] 03:55, 18 February 2007 (PST)

== WikiTI Favicon ==

I was going through WikiTI when I noticed that it lacked a favicon. I don't know what you guys think about favicons, but I think they are an important part of a website's identity. With that thought in mind, I created a favicon for WikiTI. I placed the favicon on a [http://www.freewebs.com/tibasicdev/wikitifavicon.html sample page] available on my site so you guys can see it. I wanted to hear what you guys thought of it, if you had any improvements, and if you would use it. Thanks. --[[User:Burr|Burr]] 12:17, 17 February 2007 (PST)

== Searching ==

Why doesn't searching work well. If I type "scf" I would expect to get the z80 opcode reference. Or "LCD" brings up nothing pertaining to the LCD. Is it just me or is searching broken somewhat?--[[User:Jim e|Jim e]] 20:50, 21 September 2007 (PDT)

:brobaly because the minimum amount of letters is 4 [[User:Darkstone knight|Darkstone knight]] 09:12, 6 November 2008 (PST)

== the ban fest ==

[[Special:Longpages|can begin]] --[[User:Darkstone knight|Darkstone knight]] 15:27, 19 December 2008 (PST)

Talk:83Plus:BCALLs:4492

2008-11-12T11:26:12Z

Darkstone knight:

it destroys DE? lawl [[User:Darkstone knight|Darkstone knight]] 03:26, 12 November 2008 (PST)

Talk:83Plus:Ports:01

2008-11-11T09:25:36Z

Darkstone knight:

==reset needed==
From my experimentation with PindurTI, it seems to me that it is impossible to poll more than one group without reseting the keyport in betweeen. Being that I have never tested any direct key input routines. I know the directin routine from MirageOS resets before polling, and LearnAsm28d merely says that one "should" reset the port before switching groups. I hesitate to add this to the comments section without further confirmation. [[User:Saibot84|Saibot84]] 21:48, 1 June 2007 (PDT)

:Well, for one 28days is not the best reference for hardware. And pindur is an emulator, so it has the limitations of the PC hardware and what CoBB was willing to put in. However, I decided to check this more since some people keep bringing it up. I have to say my result is not what I expected. It seems that it's possible that groups not even being monitored can affect what is read. I wrote this test program: [http://jim.revsoft.org/code/key.zip Link for download]. It checks the top row and the arrow group.

{| WIDTH=600 BORDER=1 CELLPADDING=1 CELLSPACING=1 STYLE="page-break-before: always"
|-
| WIDTH=120 | Actually being pressed
| WIDTH=120 | Arrow
| WIDTH=120 | Top Row
| WIDTH=120 | Setting arrow without reset
| WIDTH=120 | Both arrow and top row
|-
| WIDTH=120 | Down
| WIDTH=120 | 11111110
| WIDTH=120 | 11111111
| WIDTH=120 | 11111110
| WIDTH=120 | 11111110
|-
| WIDTH=120 | Zoom & Graph
| WIDTH=120 | 11111111
| WIDTH=120 | 11111010
| WIDTH=120 | 11111111
| WIDTH=120 | 11111010
|-
| WIDTH=120 | Zoom & Graph & Down
| WIDTH=120 | 11111010
| WIDTH=120 | 11111010
| WIDTH=120 | 11111010
| WIDTH=120 | 11111010
|-
| WIDTH=120 | Down & 0 & Sin
| WIDTH=120 | 11011110
| WIDTH=120 | 11111111
| WIDTH=120 | 11011110
| WIDTH=120 | 11011110
|-
| WIDTH=120 | Down & sin
| WIDTH=120 | 11111110
| WIDTH=120 | 11111111
| WIDTH=120 | 11111110
| WIDTH=120 | 11111110
|}

It seems to be a bug in hardware, dealing with when multiple keys are being pressed. It looks like the AND logic doesn't exists as much as we all thought before. Still though TI set the convention of reseting the key port, but they do it following reads, that may have an impact on the results. Though we still need more confirmation, I tested this with an 83+, 83+SE and 84+SE. --[[User:Jim e|Jim e]] 09:14, 2 June 2007 (PDT)

:Actually, your results look exactly like what I would expect. You need to keep in mind that all of the keys are eventually connected to the same "matrix." (This is true of most keyboards; we've discussed its effects on the [[Talk:83Plus:OS:TI_Keyboard|TI Keyboard]] in the past.) Let's simplify the problem: say you have a keyboard with only four keys on it, arranged as follows:
| |
-(A)--(B)-
| |
-(C)--(D)-
| |
:Pressing one of the keys A, B, C, or D results in a (very low-resistance) electrical connection between the vertical and horizontal trace. So, to scan one column of the keyboard, we connect that vertical trace to ground while leaving the other disconnected. Meanwhile we connect each horizontal trace to +5V through a large resistor. (OK, I don't know if that's exactly how it works in the TI, but let's pretend it does.) If we connect the first vertical trace to ground and we see that the first horizontal trace is high and the second is low, we can infer that the C key has been pressed.
:But... what happens when you press A, B, and C all at once? If we pull just the first vertical trace low, obviously both horizontal traces go low. If we pull just the second vertical trace low... still both horizontal traces are low! This is because current can flow from the C key to the A key to the B key. It doesn't matter whether D is pressed or not. And in fact, there is no reliable way (in software) for us to tell which three of the four keys have been pressed.
:I would guess that the reason for "resetting" port 1 each time, and for the delay between writing and reading, is to give the input some time to stabilize (it is, after all, an analog signal... the resistance of each key depends on how hard the user is pressing it.) Which in turn will decrease the bouncing effect, which is really important for TIOS, but less important for your average game.
:So that's my non-electrical-engineer's answer :) [[User:FloppusMaximus|FloppusMaximus]] 08:34, 4 June 2007 (PDT)

actualy, this is wrong..
the system looks like this

(port, bit 0)
*--I--|
| bit n, output
|----^ |
| < >----O--I- 3
| | V------O--I- 2
| *--------O--I- 1
*-----------O--I- 0

those bit O's are AND switches whit the port (port input is inverted first) 
the I's are NOT switches 
- and | and * are wires 
i guess the reseting does only matter if you dont wair the required amount of time 
[[User:Darkstone knight|Darkstone knight]] 01:17, 11 November 2008 (PST)

notice this is all theory.... i havent actualy tesed it myself [[User:Darkstone knight|Darkstone knight]] 01:25, 11 November 2008 (PST)

Talk:83Plus:Ports:01

2008-11-11T09:17:48Z

Darkstone knight:

Z80 Routines:Graphic:Fastcopy

2008-11-09T11:15:47Z

Darkstone knight: erase buffer fastcopy is now at the same speed as the regulair one

[[Category:Z80 Routines:Graphic|fastcopy]][[Category:Z80 Routines|fastcopy]]
__FORCETOC__

==IonFastcopy==
'''Warning:''' ''The routines presented below may fail on some calculators due to manufacturing defects. Before using any of the routines below, read the safecopy section below.''

The '''Fastcopy''' routine is used to copy the content of the Graph Buffer to the screen. It concerns all TI-z80 calculators, except TI-85 and TI-86, that has a special RAM area directly mapped to the screen.

Fastcopy is widely used, because the rom call _GrBufCpy waits too long between each output to the LCD driver. Using Fastcopy instead of _GrBufCpy increases significantly the speed of a program if it refreshes often the display (such as a lot of games). Most shells have this routine as built-in (ION, MirageOS, Venus ...).

Here is Joe Wingbermuehle's version, which is the one used in ION.

<nowiki>
;-----> Copy the gbuf to the screen (fast)
;Input: nothing
;Output:graph buffer is copied to the screen
fastCopy:
di
ld a,$80
out ($10),a
ld hl,gbuf-12-(-(12*64)+1)
ld a,$20
ld c,a
inc hl
dec hl
fastCopyAgain:
ld b,64
inc c
ld de,-(12*64)+1
out ($10),a
add hl,de
ld de,10
fastCopyLoop:
add hl,de
inc hl
inc hl
inc de
ld a,(hl)
out ($11),a
dec de
djnz fastCopyLoop
ld a,c
cp $2B+1
jr nz,fastCopyAgain
ret
</nowiki>

==Remarks and Improvements==
* Some instructions in Joe Wingbermuehle's Fastcopy are only there for having enough delay between two outputs to the LCD driver. One can modify Fastcopy to change these useless instructions into instructions that will clear the Graph Buffer at the same time:
<nowiki>
;-----> Copy the gbuf to the screen and clear graph buffer (fast)
;Input: nothing
;Output:graph buffer is copied to the screen and subsequently cleared
fastCopy:
di
ld a,$80
out ($10),a
ld hl,gbuf-12-(-(12*64)+1)
ld a,$20
ld c,a
inc hl
dec hl
fastCopyAgain:
ld b,64
inc c
ld de,-(12*64)+1
out ($10),a
add hl,de
ld de,12
fastCopyLoop:
add hl,de
nop
ret z
ld a,(hl)
ld (hl),0 ; clears the graph buffer at the same time
out ($11),a
ret z
djnz fastCopyLoop
ld a,c
cp $2B+1
jr nz,fastCopyAgain
ret
</nowiki>

'''ld (hl),0''' takes 10 cycles, so we can replace both '''inc hl''' (6 cycles) whit '''nop''' (4 cycles) and thus load 12 into de instead of 10.
this is still 2 clocks slower than the origional routine, so we change '''inc de''' and '''dec de''' (6 cycles) and use '''ret z''' (5 cycles) instand.

==Safe Copy==
Many calculators recently manufactured by TI contained a buggy LCD driver, which had different (or varying) delays required to interface with it. Using the fast copy routines above with the LCDs will cause the LCD to display garbled information. However, we can do some additional hardware work to solve this problem, by waiting until we know the LCD is ready to accept a command:

* Bit 7 of Port 10 tells us that the lcd can accept an instruction
* '''SE Only:''' Bit 1 of Port 2 tells us that how long since the last lcd access

The TI-OS and other apps generally use port 2 but being that bit 7 is sign bit we can use that as faster method of waiting.

<nowiki>
;-----> Copy the gbuf to the screen, guaranteed
;Input: nothing
;Output:graph buffer is copied to the screen, no matter the speed settings
;
;in f,(c) is an unofficial instruction.
;It must be noted that you cannot specify any other register. Only f works.
;You may have to add it in order for the routine to work.
;if addinstr doesn't work, you may manually insert the opcodes .db 0EDh,070h

.addinstr IN F,(C) 70ED 2 NOP 1

SafeCopy:
di ;DI is only required if an interrupt will alter the lcd.

ld hl,PlotSScreen ;This can be commented out or another entry placed after it
;so the buffer can be provided by option.
ld c,$10
ld a,$80
setrow:
in f,(c)
jp m,setrow
out ($10),a
ld de,12
ld a,$20
col:
in f,(c)
jp m,col
out ($10),a
push af
ld b,64
row:
ld a,(hl)
rowwait:
in f,(c)
jp m,rowwait
out ($11),a
add hl,de
djnz row
pop af
dec h
dec h
dec h
inc hl
inc a
cp $2c
jp nz,col
ret
</nowiki>

Talk:WikiTI Home

2008-11-06T17:12:33Z

Darkstone knight: /* Searching */

Z80 Routines:Graphic:Fastcopy

2008-11-06T16:35:46Z

Darkstone knight: "faster" fastcopy

[[Category:Z80 Routines:Graphic|fastcopy]][[Category:Z80 Routines|fastcopy]]
__FORCETOC__

==IonFastcopy==
'''Warning:''' ''The routines presented below may fail on some calculators due to manufacturing defects. Before using any of the routines below, read the safecopy section below.''

The '''Fastcopy''' routine is used to copy the content of the Graph Buffer to the screen. It concerns all TI-z80 calculators, except TI-85 and TI-86, that has a special RAM area directly mapped to the screen.

Fastcopy is widely used, because the rom call _GrBufCpy waits too long between each output to the LCD driver. Using Fastcopy instead of _GrBufCpy increases significantly the speed of a program if it refreshes often the display (such as a lot of games). Most shells have this routine as built-in (ION, MirageOS, Venus ...).

Here is Joe Wingbermuehle's version, which is the one used in ION.

<nowiki>
;-----> Copy the gbuf to the screen (fast)
;Input: nothing
;Output:graph buffer is copied to the screen
fastCopy:
di
ld a,$80
out ($10),a
ld hl,gbuf-12-(-(12*64)+1)
ld a,$20
ld c,a
inc hl
dec hl
fastCopyAgain:
ld b,64
inc c
ld de,-(12*64)+1
out ($10),a
add hl,de
ld de,10
fastCopyLoop:
add hl,de
inc hl
inc hl
inc de
ld a,(hl)
out ($11),a
dec de
djnz fastCopyLoop
ld a,c
cp $2B+1
jr nz,fastCopyAgain
ret
</nowiki>

==Remarks and Improvements==
* Some instructions in Joe Wingbermuehle's Fastcopy are only there for having enough delay between two outputs to the LCD driver. One can modify Fastcopy to change these useless instructions into instructions that will clear the Graph Buffer at the same time:
<nowiki>
;-----> Copy the gbuf to the screen and clear graph buffer (fast)
;Input: nothing
;Output:graph buffer is copied to the screen and subsequently cleared
fastCopy:
di
ld a,$80
out ($10),a
ld hl,gbuf-12-(-(12*64)+1)
ld a,$20
ld c,a
inc hl
dec hl
fastCopyAgain:
ld b,64
inc c
ld de,-(12*64)+1
out ($10),a
add hl,de
ld de,11
fastCopyLoop:
add hl,de
inc hl
inc de
ld a,(hl)
ld (hl),0 ; clears the graph buffer at the same time
out ($11),a
dec de
djnz fastCopyLoop
ld a,c
cp $2B+1
jr nz,fastCopyAgain
ret
</nowiki>

'''ld (hl),0''' takes 10 cycles, so we can replace both '''inc hl''' (6 cycles) whit '''nop''' (4 cycles) and thus load 12 into de instead of 10.

==Safe Copy==
Many calculators recently manufactured by TI contained a buggy LCD driver, which had different (or varying) delays required to interface with it. Using the fast copy routines above with the LCDs will cause the LCD to display garbled information. However, we can do some additional hardware work to solve this problem, by waiting until we know the LCD is ready to accept a command:

* Bit 7 of Port 10 tells us that the lcd can accept an instruction
* '''SE Only:''' Bit 1 of Port 2 tells us that how long since the last lcd access

The TI-OS and other apps generally use port 2 but being that bit 7 is sign bit we can use that as faster method of waiting.

<nowiki>
;-----> Copy the gbuf to the screen, guaranteed
;Input: nothing
;Output:graph buffer is copied to the screen, no matter the speed settings
;
;in f,(c) is an unofficial instruction.
;It must be noted that you cannot specify any other register. Only f works.
;You may have to add it in order for the routine to work.
;if addinstr doesn't work, you may manually insert the opcodes .db 0EDh,070h

.addinstr IN F,(C) 70ED 2 NOP 1

SafeCopy:
di ;DI is only required if an interrupt will alter the lcd.

ld hl,PlotSScreen ;This can be commented out or another entry placed after it
;so the buffer can be provided by option.
ld c,$10
ld a,$80
setrow:
in f,(c)
jp m,setrow
out ($10),a
ld de,12
ld a,$20
col:
in f,(c)
jp m,col
out ($10),a
push af
ld b,64
row:
ld a,(hl)
rowwait:
in f,(c)
jp m,rowwait
out ($11),a
add hl,de
djnz row
pop af
dec h
dec h
dec h
inc hl
inc a
cp $2c
jp nz,col
ret
</nowiki>

Talk:Z80 Routines:Graphic:Fastcopy

2008-11-06T16:28:53Z

Darkstone knight:

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 
NOP + Ld (HL),0 = 14 clocks 
INC HL + LD (HL),0 = 16 clocks 
2x INC HL (what ionfastcopy uses) 12 clocks 
[[User:Darkstone knight|Darkstone knight]] 08:28, 6 November 2008 (PST)