WikiTI - User contributions [en]

Talk:83Plus:BCALLs:4522

2006-05-07T16:34:57Z

JasonM:

This B_CALL never returns to the caller, when you exit the application
it will return to the homescreen like it normally does.
Um... what? [[User:FloppusMaximus|FloppusMaximus]] 08:53, 5 May 2006 (PDT)

:I think he copied the layout from the [[83Plus:BCALLs:4C51|ExecuteApp]] page and forgot to change the last part.--[[User:84plusfreak|84plusfreak]] 05:50, 6 May 2006 (PDT)
::I think so too. :-) --[[User:JasonM|JasonM]] 09:34, 7 May 2006 (PDT)

83Plus:BCALLs:4522

2006-05-07T16:34:31Z

JasonM:

[[Category:83Plus:BCALLs:By Name:Display|WPutSEOL]] [[Category:83Plus:BCALLs:By Name|WPutSEOL]] [[Category:83Plus:BCALLs:By Address|4522 - WPutSEOL]]
== Synopsis ==
'''Official Name:''' WPutSEOL

'''BCALL Address:''' 4522

Displays a string, putting an ellipsis (an ...) on the end of row if needed.

=== Inputs ===
* HL = String to display.

=== Outputs ===
None

=== Destroys ===
''Unknown''

== Comments ==
None

== Example ==
<nowiki>ld hl, Appname
ld de,progToEdit
ld bc,8
ldir
B_CALL ExecuteApp
Appname: db "Calcsys "</nowiki>

== Credits and Contributions ==
* '''Kirk Meyer:''' For hinting on the use of this B_CALL.

Category:Z80 Routines

2005-12-30T22:16:13Z

JasonM: I hate "here" links. I have to roll my mouse over them to figure out where they go.

[[Category:Calculator Documentation|General Z80 Calculator Routines]]
This Category contains routines that can be used on many Z80-based calculators. Please consult each example for which calculators they apply to.

----

When you paste code, there is a simple step you can do to format the code properly. Start the first line of code with <nowiki>, and put a space in front of the <. On the last line of your code, end it with </nowiki>. This allows for code to be formatted like this (click edit on this page to see how it's done):

<nowiki>cp 10
ccf
adc a, 30h
daa</nowiki>

Also, there are a bunch of routines [http://www.detachedsolutions.com/forum/viewtopic.php?t=1154 here (DS forums)] and [http://map.tni.nl/sources/external/z80bits.html here (Z80 bits)].

Talk:Z80 Instruction Set

2005-12-30T22:14:07Z

JasonM: Wait, I don't want this to be a minor change. :-)

We could probably just use one of the publically available instruction set lists to save the time and trouble of typing everything out again.
--Dan 00:28, 22 Dec 2005

:Emacs.
:Anyway, what you've got so far is not particularly clear, and doesn't really present the important information. I'm thinking of a series of tables something like this:

{| border="1" cellpadding="2"
! Oct !! Hex !! Instruction !! States !! Clock !! S !! Z !! X !! H !! Y !! P !! N !! C
|-
| 100 || 40 || ld b, b || OCF(4) || 4 || - || - || - || - || - || - || - || -
|-
| 101 || 41 || ld b, c || OCF(4) || 4 || - || - || - || - || - || - || - || -
|-
| 102 || 42 || ld b, d || OCF(4) || 4 || - || - || - || - || - || - || - || -
|-
| 103 || 43 || ld b, e || OCF(4) || 4 || - || - || - || - || - || - || - || -
|}

:A quick reference for people who actually know what they're doing. For those who don't, these tables should of course be accompanied by detailed descriptions of what the various opcodes actually do.
:Any comments before I go and waste a few hours wikifying the rest of the Z80 instruction set?
::Perhaps we can be more intelligent about this and not do this by hand? At least have some source file and then we have a nice program we auto-generate the list from? I sure don't want you wasting hours wikifying the instruction set, no matter how good vi might be. ;-) --[[User:JasonM|JasonM]] 14:13, 30 Dec 2005 (PST)
:Please don't use parentheses for anything other than indirection!
:[[User:FloppusMaximus|FloppusMaximus]] 12:28, 23 Dec 2005 (PST)
::Is providing an octal representation actually useful for anything?

:A binary representation would be more useful -- [[User:Jib|Jib]]

::You're right, it could be. Of course octal is useful -- just take a look at a complete table of the instructions; everything is grouped by eights and sixty-fours. So I know that 1''r'' ''s'' = LD ''r'',''s'', or that 3''a''6 ''nnn'' = ALU(''a'') ''nnn'', or that 3''z''7 = RST 0''z''0, or less obviously that 3''c''0 = RET ''c''. Much easier to remember than hexadecimal. But that's just me. I think you're right, binary would be better. [[User:FloppusMaximus|FloppusMaximus]] 15:53, 25 Dec 2005 (PST)
:::Can we just do both? I think I have enough screen real-estate. --[[User:JasonM|JasonM]] 14:13, 30 Dec 2005 (PST)

Talk:Z80 Instruction Set

2005-12-30T22:13:15Z

JasonM:

Talk:83Plus:Ports:05

2005-07-22T00:09:00Z

JasonM: Spelling error. :-P

I'm not sure how I feel about calling this "RAM Paging port", because all of 05,06, and 07 can be used to page in RAM. Personally I think that if we designate 0000-3FFF as bank0, 4000-7FFF as bank1, 8000-BFFF as bank2, and C000-FFFF as bank3 it will be the clearest. Then we can say port 5 controls bank3, port 6 controls bank1, and port 7 controls bank2. --[[User:Dan Englender|Dan Englender]] 09:46, 28 Mar 2005 (PST)

:Well, does it even make sense to assign a bank number to 0000h~3FFFh, since that's permanently set as ROM Page 0? Also another option would be to just call them by the address block they effect (or at least the first address)? Eg, bankC000, bank4000, bank8000? --[[User:Aquanight|Aquanight]] 15:47, 30 Mar 2005 (PST)

::I've heard them be called the 0000, 4000, 8000, and C000 banks before, so that would seem to be a good choice. I would go with this one...and at least these names can't result in any possible confusion at all. Simple and elegant. --[[User:JasonM|JasonM]] right now

I don't see why not to assign a bacnk number to 0000-3FFF. Just because the data in there isn't changing doesn't mean it's not useful to talk about it. Memory is logically split into these four different segments, so it's useful to have names for all of them. --[[User:Dan Englender|Dan Englender]] 08:32, 31 Mar 2005 (PST)

----

Should it be pointed out somewhere that only when the port is 0 (RAM page 0 selected) that execution is forbidden above address C000h? --[[User:Aquanight|Aquanight]] 15:10, 2 May 2005 (PDT)
:Isn't all execution prevented on ram page 0 regardless of where it is? --[[User:AndyJ|AndyJ]] 15:13, 2 May 2005 (PDT)
::Yes, but for people that might be semi-new to assembly it might be a good idea to point out *somewhere* that the execution limit is tied to the RAM page, and not the logical memory. Putting it here would seem to make the most sense :) . That or maybe somewhere in 83Plus:OS or something? --[[User:Aquanight|Aquanight]] 23:08, 3 May 2005 (PDT)
:::Well, it's a hardware thing, not an OS thing, so no it doesn't go there. It would go here. :) Someone fix that sometime, it's way too late for me to. :P --[[User:AndyJ|AndyJ]] 23:09, 3 May 2005 (PDT)

----

Added info about TI-83 Plus. Didn't know exactly how to separate BE with higher models given how radically different the behaviour of the port is, so I did what seemed logical and marked the page as non-standard. Also, the table could be better. [[User:Sigma|Sigma]] 16:25, 18 Jul 2005 (PDT)
:I'll fix the table later, once I've brushed up on wikitables. Also, I agree with how you split it. --[[User:AndyJ|Andy Janata]] 16:35, 18 Jul 2005 (PDT)
::table == wikied. --[[User:Aquanight|Aquanight]] 16:59, 18 Jul 2005 (PDT)

== 83+ Link assist ==

As I didn't see this information in his text file, I'll post the log of #WikiTI here:
<nowiki>[13:17:41] <+Kalimero_> ooooh, I just found a link assist on the 83+
[13:17:49] <+Kalimero_> well, at least for receiving
[13:18:25] <+Gambit_> ..
[13:18:27] <+Gambit_> O_O
[13:18:37] <@Andy_J> really
[13:19:19] <+Kalimero_> yes, set bit 2 of port 0, wait for bit 3 to set and read port 5 to get the byte just received
[13:19:30] <@Andy_J> wow
[13:19:35] <+Gambit_> :O
[13:20:06] <+Kalimero_> so bit 2 of port 0 seems to enable the assist
[13:20:16] <@Andy_J> wiki update time!
[13:20:25] <+Gambit_> yay! :D
[13:20:32] <+Kalimero_> and bit 3 is set when there's a byte waiting
[13:20:44] <+Kalimero_> when you read port 5 bit 3 of port 0resets
[13:22:22] <+Kalimero_> well, I still have to figure out the details
[13:22:43] <+Kalimero_> bit 6 of port 0 means something too
[13:23:35] <+Kalimero_> might be a "busy receiving" flag
[13:24:01] <+Kalimero_> anyway, I wonder why ti built that in didn't use it
[13:24:32] <+Kalimero_> *and
[13:24:32] <+Peter_W> Maybe it's not something that has always been there?
[13:25:22] <+Kalimero_> could be, though you'd think hw features are tight to the boot code version
[13:25:29] <+Kalimero_> and only version 1.00 exists
[13:25:39] <+Gambit_> I'd say that too.
[13:25:40] <+Peter_W> true </nowiki>

--[[User:AndyJ|Andy Janata]] 12:39, 21 Jul 2005 (PDT)

Z80 Routines:Graphic:Fastcopy

2005-07-06T02:15:27Z

JasonM: Giving a warning about the bad LCD drivers. I meant to do this before, but forgot.

[[Category:Z80 Routines:Graphic|fastcopy]]
[[Category:Z80 Routines|fastcopy]]
'''Warning:''' The routines presented below will fail on some calculators due to manufacturing defects. Before using any of the routines below, read the safe copy 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 do with one less '''inc hl''' (6 cycles) and thus load 11 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 1 of Port 2 tells us that the lcd can accept an instruction
* Bit 7 of Port 10 tells us that the lcd can accept an instruction

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 (c) is an undefined instruction.
;You may have to add it in order for the routine to work.

.addinstr IN (C) 70ED 2 NOP 1

SafeCopy:
di
ld c,$10
ld a,$80
setrow:
in (c)
jp m,setrow
out ($10),a
ld hl,gbuf
ld de,12
ld a,$20
col:
in (c)
jp m,col
out ($10),a
ex af,af'
ld b,64
row:
ld a,(hl)
rowwait:
in (c)
jp m,rowwait
out ($11),a
add hl,de
djnz row
ex af,af'
dec h
dec h
dec h
inc hl
inc a
cp $2c
jp nz,col
ret
</nowiki>

Talk:83Plus:BCALLs:4045

2005-06-11T14:01:50Z

JasonM:

My docs had this named execCxMain...any comments? --[[User:JasonM|JasonM]] 07:01, 11 Jun 2005 (PDT)

Talk:83Plus:OS:Page 0 Calls

2005-06-08T02:12:54Z

JasonM:

If you add an offset to that number and call it, you will always call the same function.

Is this true? I guess I've never seen this before, but it would be quite nice if it is. Anyways, we need to think up a way for naming pages (our usual address method won't work here.)

Ideas? Anyways, just pile all our info into this single page for now (no point in making a bunch of pages and then having to revise stuff later.) --[[User:JasonM|JasonM]] 10:05, 7 Jun 2005 (PDT)

I don't see a problem with creating a new 'namespace' for these, so long as there really is a semi-OS-independent way to use them. Remember, though, that they are not intended to be used by apps -- if they were, they'd be B_CALLs. And I really don't want to see programs manually garbage-collecting whenever they feel like it! ([[User:FloppusMaximus]], too lazy to log in) 11:18, 7 Jun 2005 (PDT)
: I suppose we could create a new namespace and have the page name be the offset from the beginning of the "table". I also didn't know that it was consistent between all OS versions (though I don't think we can be '''sure''' that it will stay this way in the future, even if it has been until now), but if it's consistent between all current OS versions, then I suppose it's worth documenting. Keep in mind that many of these calls mirror BCALLs, and if so, the pages should be linked. --[[User:Dan Englender|Dan Englender]] 15:11, 7 Jun 2005 (PDT)
:By the way, anyone got a good idea for the name of the namespace? --[[User:Dan Englender|Dan Englender]] 15:54, 7 Jun 2005 (PDT)
::How about 83Plus:Page0Calls? :-) Also, how sure are we that the offsets being constant is an intended design? --[[User:JasonM|JasonM]] 19:12, 7 Jun 2005 (PDT)

83Plus:OS:Page 0 Calls

2005-06-07T17:06:39Z

JasonM: adding comment

[[Category:83Plus:OS_Information|Page 0 Calls]]

The address of the first page 0 call is saved at 44FB on page 1B,3B or 7B. (Depending on your device)

If you add an offset to that number and call it, you will always call the same function.

For example: Adding 10b6 to the number read from 44FB on page 1B/3B/7B gives you the address of the function that returns the last 4 digits of the Calc-ID.

Another one: The offset for GCing is 032A.

This call has the following inputs:
A=Type, B=Confirmation

A = 0 -> GC
A = 1 -> Defrag
A = 3 -> ?
A = 4 -> ?
A = 5 -> ?
A = 6 -> ?
B = 0 -> No confirmation
B = 1 -> Ask user

Maybe one of the staff members could create a section which contains page 0 calls.
:See the talk page for a discussion on how we should handle the sectioning. --[[User:JasonM|JasonM]] 10:06, 7 Jun 2005 (PDT)

Talk:83Plus:OS:Page 0 Calls

2005-06-07T17:05:55Z

JasonM: hmm...

83Plus:Hooks:Catalog

2005-06-03T01:22:54Z

JasonM:

''This page consists of combined documentation for both the [[83Plus:Hooks:9BB4|Catalog 1]] and [[83Plus:Hooks:9BC4|Catalog 2]] hooks. Hook equates can be found on each of those pages.''

==Overview==
These two hooks are unique on the 83+, as they are, in many cases, the same hook. Although there are a few cases where the differ, in many cases the OS passes the same event to both hooks, one after another (Catalog 1 hook first, hence the name.)

Because of this, the only way to get the complete picture of what's going on is to have a description of both hooks at the same time and how they work together. Therefore, this documentation is rather different. The documentation is organized by "events," which are either events based on user actions, or internal implementation stuff (like pointers manipulation.) Each event's documentation will then provide general information about both hooks (information that you can apply to both Catalog 1 and Catalog 2), and then also more specific information for each hook.

The downside to this method is the documentation becomes really complex: reading through this will probably make your head explode. If you want to try hooks for the first time, try some different hooks, not these. There's a reason these were one of the last hooks documented: they're messy, complex, and not overly useful. If you have any questions, don't hesitate to ask questions in the discussion for this article.

The TI Localization apps use the Catalog 2 hook for their activities (probably because the Catalog 2 hook also provides keypress notification, required to implement the Characters item it provides), so it would be possible to use the Catalog 1 hook to override some of their behaviors.

==Keypress Table==
At the heart of the catalog hooks is the keypress table, which provides the ordering for the tokens in the list (obviously it's a good idea to presort the table for speed reasons.) Each entry in the table is two bytes long, the format depending on the whether the key is a one- or two-byte keypress:

* If it's a one byte keypress, then the first byte is zero, and the second byte is the value of the key.
* If it's a two byte keypress, the first byte is the prefix (FCh-FEh, but the OS seems to use FDh and FFh as well - anyone know why?), and the second byte is the other value.

In OS 1.16, the TI-OS stores this table on page 7. Obviously, expect this to change on different calculators and possibly different OS versions.

You can provide your own keypress table in a unique way. It's obvious that, inside the OS's implementation of the catalog, it would have to do something like "ld hl, table_start". However, after doing this, it always calls the Catalog hooks, allowing it to modify the value. It looks something like this internally (this is not the exact code, and is only for showing the theory):

<nowiki> ld hl, table_start
ld a, 5
bit Catalog1HookActive, (iy + Catalog1HookFlag)
call nz, CallCatalog1Hook
bit Catalog2HookActive, (iy + Catalog2HookFlag)
call nz, CallCatalog2Hook</nowiki>

where CallCatalog#Hook would return the registers and flags that the hook returned. Consequently, if we change HL in either routine, we can change the pointers the OS is using.

These pointers are pointers to entries within that keypress tables. It would seem that all we can do is just change the range of tokens displayed, but it turns out that the OS only actually reads the table in one situation: when displaying a token, otherwise it's just manipulating the pointers without actually knowing where they are pointing! The cool part is we are able to change how this read occurs. Before drawing an item, the Catalog Hooks are called, with the table pointer being passed in HL. If we want, we can point this somewhere else (say somewhere in RAM, TI uses sFont_record) where we can put our own item that we copied there (realize that the read is performed with page 7 in the 4000h-7FFFh range, so we can't keep anything in flash.) The other interesting side effect is that we can copy anything we want to RAM: we could generate a virtual table on the fly.

Therefore, we can completly create our own table with our own entries. We give our own start and end pointers (which can be on our page.) When the OS does read from this table, it gives us the pointer to the entry it is about to read. We then copy our own entry at this address to RAM, and change the entry pointer to RAM. This will result in our own entry being added.

==Events==
This is sorted by "events," a very non-technical term for something that the user does, or something the OS needs to do with the hooks. It's grouped this way instead of by inputs to each hook so I can document the interactions between the hooks.

===Get Table Start===
This event is passed to the Catalog 1 hook first.

'''Both Catalog Hooks:''' The OS wants the address of the keypress table. HL contains the address for the OS's table. If you want to provide your own table, change HL to its address.

'''Catalog 1 Hook Only:''' This message seems to get triggered in two cases:

* ''A = 05h.'' If you don't want the message to be passed to the Catalog 2 hook, return with the zero flag reset. If you modify A, realize that whatever value you change it to will be passed to the Catalog 2 hook (should you permit it.) Although this could be useful, if you don't want to break the Catalog 2 hook, make sure you set A back to 5.
* ''A = 0Ah.'' This is called under some unknown circumstances (anyone know why?), but it seems acceptable to treat it as A = 5. In this case, you don't have to worry about trashing A; if you permit the Catalog 2 hook to be called under this condition, the TI-OS sets A = 5 for you.

'''Catalog 2 Hook Only:''' ''A = 05h.'' HL may contain the address of the table provided by the Catalog 1 hook instead of the OS-provided address. Return flags are ignored.

=== Get Table End===
This event is passed to the Catalog 1 hook first. This event is similar to the previous event.

'''Both Catalog Hooks:''' ''A = 06h.'' The OS wants the address of the keypress table. DE contains the OS's value. If you want to provide your own address, simply set DE.

'''Catalog 1 Hook Only:''' Returning with the zero flag reset prevents the Catalog 2 hook from processing the event. If you modify A, restore it as mentioned in the previous event.

'''Catalog 2 Hook Only:''' DE may contain the address provided by the Catalog 1 hook as above. Return flags ignored.

===Get Last Screen===
This event is passed to the Catalog 2 hook only, A = 2.

The user has pressed up on the topmost item, so we must scroll back around to the last item. Here, we must provide in HL the pointer to the first item that must be displayed (so when displaying the bottom of the list, the first item shown.) HL will be set to the predefined OS value, but you can overwrite it. Return flags are ignored.

===Get Last Screen Item===
This event is passed to the Catalog 2 hook only, A = 3.

In the situation above, you must provide, in HL, the pointer to the item that will be selected. This will probably just be the pointer to the last item in the list, but you could make it different if you want. The return flags are ignored.

===Get Item from Letter===
This event is passed to the Catalog 1 hook first.

'''Both Catalog Hooks:''' ''A = 04h.'' The user has pressed a letter key, and we need to return the address of the item to be selected. DE is set to (key - 41h) * 2, where key is the ASCII value of the key. It's somewhat expected that you store a list of addresses; this would seem to be the most efficient way to do it anyways.

'''Catalog 1 Hook Only:''' Returning with zero reset will immediatly use the value in HL as the address of the entry of the keypress table we should display. The catalog 2 hook will not be called. Returning with zero set could result in one of two things happening:
*The Catalog 2 hook is not installed, at which point the OS will call LdHLInd and use that as the pointer to the keypress table. It's assuming that, by returning with zero set, you have essentially ignored the message, and HL is pointing inside it's lookup table. Realize that if you return with zero set you shouldn't trash HL!
*The Catalog 2 hook is installed, and how to handle HL is its decision

Make sure you restore A should you trash it.

'''Catalog 2 Hook Only:''' DE or HL could be modified by the Catalog 1 hook. Returning with zero set will immediately use the pointer in HL as a pointer to the item to be displayed next. Returning with zero set will cause LdHLInd to be called, treating the result as a pointer in the keypress table.

===Display Title===
This event is passed to the Catalog 1 hook first.

'''Both Catalog Hooks:''' ''A = 07h.'' The title of the catalog is about to be displayed, but this event can also be used as a generic catalog-is-open event (note: the Get Table Start event is called first!) There aren't any register inputs or outputs.

'''Catalog 1 Hook Only:''' If you modify A, make sure you set it back to 7, or the Catalog 2 app (if called) will not recieve the event properly. Return flags ignored.

'''Catalog 2 Hook Only:''' Returning with zero set causes the catalog to exit.

===Display Item===
This event is passed to the Catalog 1 hook first.

'''Both Catalog Hooks:''' HL is the address of the key in the keypress table. Remember, if you want to provide your own key / token, you must copy the keypress data into RAM, and point HL to it.

'''Catalog 1 Hook Only:''' ''A = 09h.'' Returning with zero reset will prevent drawing this item, and the Catalog 2 Hook will not be called.

'''Catalog 2 Hook Only:''' ''A = 01h.'' HL contains whatever the Catalog 1 hook provided, either the OS provided pointer or a custom pointer (if it was called.) Returning with zero reset will prevent drawing the item.

===Key Press===
This event is passed to Catalog 2 only.

The accumulator is 08h, B contains the keypress. You can modify it if you want. If you return with zero set, it will be canceled.

Note: If you want to look for up / down, then also check for kAlphaUp and kAlphaDown, since Alpha Lock is set by default in the catalog.

==Related Information==
* [[83Plus:RAM:85DA|CatalogCurrent]] - Holds the table pointer of the item selected.

83Plus:Hooks:Catalog

2005-06-03T01:07:38Z

JasonM: saving work so far....

''This page consists of combined documentation for both the [[83Plus:Hooks:9BB4|Catalog 1]] and [[83Plus:Hooks:9BC4|Catalog 2]] hooks. Hook equates can be found on each of those pages.''

==Overview==

These two hooks are unique on the 83+, as they are, in many cases, the same hook. Although there are a few cases where the differ, in many cases the OS passes the same event to both hooks, one after another, effectivly resulting in the two hooks being chained. Consequently, it's best to document both hooks together, and also commenting on their interactions.

The TI Localization apps use the Catalog 2 hook for their activities (probably because the Catalog 2 hook also provides keypress notification, required to implement the Characters item it provides), so it would be possible to use the Catalog 1 hook to override some of their behaviors.

This document is formatted a little differently from normal, organizing by general event, not by hook specifics, and then discussing how each hook handles it.

==Keypress Table==

At the heart of the catalog hooks is the keypress table, which provides the ordering for the tokens in the list (obviously it's a good idea to presort the table for speed reasons.) Each entry in the table is two bytes long, the format depending on the whether the key is a one- or two-byte keypress:

* If it's a one byte keypress, then the first byte is zero, and the second byte is the value of the key.
* If it's a two byte keypress, the first byte is the prefix (FCh-FEh, but the OS seems to use FDh and FFh as well - anyone know why?), and the second byte is the other value.

In OS 1.16, the TI-OS stores this table on page 7. Obviously, expect this to change on different calculators and possibly different OS versions.

You can provide your own keypress table in a unique way. It's obvious that, inside the OS's implementation of the catalog, it would have to do something like "ld hl, table_start". However, after doing this, it always calls the Catalog hooks, allowing it to modify the value. It looks something like this internally (this is not the exact code, and is only for showing the theory):

<nowiki> ld hl, table_start
ld a, 5
bit Catalog1HookActive, (iy + Catalog1HookFlag)
call nz, CallCatalog1Hook
bit Catalog2HookActive, (iy + Catalog2HookFlag)
call nz, CallCatalog2Hook</nowiki>

where CallCatalog#Hook would return the registers and flags that the hook returned. Consequently, if we change HL in either routine, we can change the pointers the OS is using.

These pointers are pointers to entries within that keypress tables. It would seem that all we can do is just change the range of tokens displayed, but it turns out that the OS only actually reads the table in one situation: when displaying a token, otherwise it's just manipulating the pointers without actually knowing where they are pointing! The cool part is we are able to change how this read occurs. Before drawing an item, the Catalog Hooks are called, with the table pointer being passed in HL. If we want, we can point this somewhere else (say somewhere in RAM, TI uses sFont_record) where we can put our own item that we copied there (realize that the read is performed with page 7 in the 4000h-7FFFh range, so we can't keep anything in flash.) The other interesting side effect is that we can copy anything we want to RAM: we could generate a virtual table on the fly.

Therefore, we can completly create our own table with our own entries. We give our own start and end pointers (which can be on our page.) When the OS does read from this table, it gives us the pointer to the entry it is about to read. We then copy our own entry at this address to RAM, and change the entry pointer to RAM. This will result in our own entry being added.

==Events==
This is sorted by "events," a very non-technical term for something that the user does, or something the OS needs to do with the hooks. It's grouped this way instead of by inputs to each hook so I can document the interactions between the hooks.

===Get Table Start===
This event is passed to the Catalog 1 hook first.

'''Both Catalog Hooks:''' The OS wants the address of the keypress table. HL contains the address for the OS's table. If you want to provide your own table, change HL to its address.

'''Catalog 1 Hook Only:''' This message seems to get triggered in two cases:

* ''A = 05h.'' If you don't want the message to be passed to the Catalog 2 hook, return with the zero flag reset. If you modify A, realize that whatever value you change it to will be passed to the Catalog 2 hook (should you permit it.) Although this could be useful, if you don't want to break the Catalog 2 hook, make sure you set A back to 5.
* ''A = 0Ah.'' This is called under some unknown circumstances (anyone know why?), but it seems acceptable to treat it as A = 5. In this case, you don't have to worry about trashing A; if you permit the Catalog 2 hook to be called under this condition, the TI-OS sets A = 5 for you.

'''Catalog 2 Hook Only:''' A = 05h. HL may contain the address of the table provided by the Catalog 1 hook instead of the OS-provided address. Return flags are ignored.

===Event: Get Table End===
This event is passed to the Catalog 1 hook first. This event is similar to the previous event.

'''Both Catalog Hooks:''' ''A = 06h.'' The OS wants the address of the keypress table. DE contains the OS's value. If you want to provide your own address, simply set DE.
'''Catalog 1 Hook Only:''' Returning with the zero flag reset prevents the Catalog 2 hook from processing the event. If you modify A, restore it as mentioned in the previous event.
'''Catalog 2 Hook Only:''' DE may contain the address provided by the Catalog 1 hook as above. Return flags ignored.

===Event: Get Last Screen===
This event is passed to the Catalog 2 hook only, A = 2.

The user has pressed up on the topmost item, so we must scroll back around to the last item. Here, we must provide in HL the pointer to the first item that must be displayed (so when displaying the bottom of the list, the first item shown.) HL will be set to the predefined OS value, but you can overwrite it. Return flags are ignored.

===Event: Get Last Screen Item ----------------------------------------------

This event is passed to the Catalog 2 hook only, A = 3.

In the situation above, you must provide, in HL, the pointer to the item that will be selected. This will probably just be the pointer to the last item in the list, but you could make it different if you want. The return flags are ignored.

===Event: Get Item from Letter ----------------------------------------------

This event is passed to the Catalog 1 hook first.

Both Catalog Hooks: A will be 4. The user has pressed a letter key, and we need to return the address of the item to be selected. DE is set to (key - 41h) * 2, where key is the ASCII value of the key. It's somewhat expected that you store a list of addresses; this would seem to be the most efficient way to do it anyways.

Catalog 1 Hook Only: Returning with zero reset will immediatly use the value in HL as the address of the entry of the keypress table we should display. The catalog 2 hook will not be called. Returning with zero set could result in one of two things happening:

- the Catalog 2 hook is not installed, at which point the OS will call LdHLInd and use that as the pointer to the keypress table. It's assuming that, by returning with zero set, you have essentially ignored the message, and HL is pointing inside it's lookup table. Realize that if you return with zero set you shouldn't trash HL!

- the Catalog 2 hook is installed, and how to handle HL is its decision

Make sure you restore A should you trash it.

Catalog 2 Hook Only: DE or HL could be modified by the Catalog 1 hook. Returning with zero set will immediately use the pointer in HL as a pointer to the item to be displayed next. Returning with zero set will cause LdHLInd to be called, treating the result as a pointer in the keypress table.

===Event: Display Title -----------------------------------------------------

This event is passed to the Catalog 1 hook first.

Both Catalog Hooks: A = 7. The title of the catalog is about to be displayed, but this event can also be used as a generic catalog-is-open event (note: the Get Table Start event is called first!) There aren't any register inputs or outputs.

Catalog 1 Hook Only: If you modify A, make sure you set it back to 7, or the Catalog 2 app (if called) will not recieve the event properly. Return flags ignored.

Catalog 2 Hook Only: Returning with zero set causes the catalog to exit.

===Event: Display Item ------------------------------------------------------

This event is passed to the Catalog 1 hook first.

Both Catalog Hooks: HL is the address of the key in the keypress table. Remember, if you want to provide your own key / token, you must copy the keypress data into RAM, and point HL to it.

Catalog 1 Hook Only: The accumulator is set to 9 for this event. Returning with zero reset will prevent drawing this item, and the Catalog 2 Hook will not be called.

Catalog 2 Hook Only: The accumulator is set to 1 for this event. HL contains whatever the Catalog 1 hook provided, either the OS provided pointer or a custom pointer (if it was called.) Returning with zero reset will prevent drawing the item.

===Event: Key Press ---------------------------------------------------------

This event is passed to Catalog 2 only.

The accumulator is 8, B contains the keypress. You can modify it if you want. If you return with zero set, it will be canceled.

Note: If you want to look for up / down, then also check for kAlphaUp and kAlphaDown, since Alpha Lock is set by default in the catalog.

83Plus:Hooks:9BC4

2005-06-02T23:29:56Z

JasonM:

[[Category:83Plus:Hooks:By Address|9BC4 - Catalog 2 Hook]]
[[Category:83Plus:Hooks:By Name|Catalog 2 Hook]]
== Synopsis ==
'''Name:''' Catalog 2 Hook

'''Hook Pointer Block Address:''' [[83Plus:RAM:9BC4|9BC4]]

'''Hook Enable BCALL:''' [[83Plus:BCALLs:4F8D|4F8D]]

'''Hook Disable BCALL:''' [[83Plus:BCALLs:4F90|4F90]]

'''Hook Call BCALL:''' ''Unknown''

'''Hook Active Flag:''' 6, (iy + 34h)

This is one of the two catalog hooks. For an understanding on how these hooks work, see the [[83Plus:Hooks:Catalog|combined documentation]].

83Plus:Hooks:9B90

2005-06-02T23:17:40Z

JasonM:

[[Category:83Plus:Hooks:By Address|9B90 - Window Hook]]
[[Category:83Plus:Hooks:By Name|Window Hook]]
== Synopsis ==
'''Name:''' Window Hook

'''Hook Pointer Block Address:''' [[83Plus:RAM:9B90|9B90]]

'''Hook Enable BCALL:''' [[83Plus:BCALLs:4FB1|4FB1]]

'''Hook Disable BCALL:''' [[83Plus:BCALLs:4FB4|4FB4]]

'''Hook Call BCALL:''' ''Unknown''

'''Hook Active Flag:''' 2, (iy + 35h)

This hook is triggered when various events occur on the Window screen (where you adjust the Xmin, Xmax, etc. values). It is also called for the finance solver and TblSet interfaces.

This hook is based around a special table which is documented in the comments section below. It might help to read that section first.

== Using the Hook ==
Events are determined by the accumulator, as usual.
* '''A = 04h:''' The WINDOW title is about to be displayed. Returning with zero reset will cancel this drawing; you can draw your own title.
* '''A = 00h:''' Execute this code (just paste this right into your routine):
<nowiki>or 1 \ ld a, (ix) \ ret</nowiki>
* '''A = 01h:''' Execute this code (same as above):
<nowiki>or 1 \ ld a, (ix + 3) \ ret</nowiki>
* '''A = 02h:''' Execute this code (ditto):
<nowiki>or 1 \ ld a, (ix - 3) \ ret</nowiki>
* '''A = 03h:''' Draw the table item pointed by IX. curRow and curCol are already setup for outputting the prompt (the Xmin=-style thing.) After showing this prompt, B_CALL [[83Plus:BCALLs:452B|SetNumWindow]]. Then, output the number (see message 9 below.)
* '''A = 05h:''' We are about to edit an entry. HL is a pointer to the table entry corresponding to the entry to edit. You need to set OP1 to the value in the editing field. (So say you type something into Xmin, you must set OP1 to the value of Xmin here.)
* '''A = 06h:''' We are done editing an entry. HL points to the table entry that we are done editing, and the value is in OP1. You probably want to save this value.
* '''A = 07h:''' The hook needs the address of the first real entry in the table (''not'' one of the start/end entries.) See the comments section for details.
* '''A = 09h:''' We are going to display one of the numbers. HL is pointing to the appropriate table entry. You probably want to copy the number into OP1 and execute the following code (see the docs for [[83Plus:BCALLs:4522|WPutSEOL]] for more info):
<nowiki>ld a, 15h
B_CALL FormEReal
ld hl, OP3
B_CALL WPutSEOL</nowiki>
* '''A = 0Ah:''' A key was pressed, the keycode is in B. You can modify this as needed.

== Comments ==
The table is the most important part of the hook, which tells what you want the table to look like. Each record in the table is three bytes. The first byte is simply a value which you can use to identify the entry. It can be a memory offset (one byte only), token identifier, keypress equate, or any other one byte value. However, it has one special value, 0FFh, which means this record indicates either the start or end of the table. The second and third bytes are simply the pointer to the string to be displayed, null terminated as usual.

Here's an example table:

<nowiki> db 0FFh ; Dummy Entry signifying start of table
dw 0 ; Doesn't matter on string pointer
TableStart:
db 0 ; Lets identify the first item by a value of 0
dw EntryString1 ; Pointer to string
; Simply using this assemble trick is perfect
db 1 ; Same as above
dw EntryString2 ; Same as above

db 0FFh ; Dummy Entry signifying end of table
; No need for string pointer, the OS never checks

EntryString1: db "Var=", 0
EntryString2: db "Var2=", 0</nowiki>

When you pass the table pointer in message 7, pass "TableStart" as indicated above, as that is the first entry to be displayed.

== Credits and Contributions ==
* '''Kirk Meyer:''' For Graph3, which uses this hook and provided a working example of the hook.

83Plus:Hooks:9BB4

2005-06-02T23:17:07Z

JasonM:

[[Category:83Plus:Hooks:By Address|9BB4 - Catalog 1 Hook]]
[[Category:83Plus:Hooks:By Name|Catalog 1 Hook]]
== Synopsis ==
'''Name:''' Catalog 1 Hook

'''Hook Pointer Block Address:''' [[83Plus:RAM:8562|8562]]

'''Hook Enable BCALL:''' [[83Plus:BCALLs:5044|5044]]

'''Hook Disable BCALL:''' [[83Plus:BCALLs:5047|5047]]

'''Hook Call BCALL:''' ''Unknown''

'''Hook Active Flag:''' 3, (iy + 36h)

This is one of the two catalog hooks. For an understanding on how these hooks work, see the [[83Plus:Hooks:Catalog|combined documentation]].

83Plus:Hooks:9BB4

2005-06-02T23:16:58Z

JasonM:

[[Category:83Plus:Hooks:By Address|9BB4 - Catalog 1 Hook]]
[[Category:83Plus:Hooks:By Name|Catalog 1 Hook]]
== Synopsis ==
'''Name:''' ImAHook

'''Hook Pointer Block Address:''' [[83Plus:RAM:8562|8562]]

'''Hook Enable BCALL:''' [[83Plus:BCALLs:5044|5044]]

'''Hook Disable BCALL:''' [[83Plus:BCALLs:5047|5047]]

'''Hook Call BCALL:''' ''Unknown''

'''Hook Active Flag:''' 3, (iy + 36h)

This is one of the two catalog hooks. For an understanding on how these hooks work, see the [[83Plus:Hooks:Catalog|combined documentation]].

83Plus:Hooks:Catalog

2005-06-02T23:14:04Z

JasonM:

General Information ------------------------------------------------------------

Catalog1HookPtr = 9BB4h
_EnableCatalog1Hook = 5044h
_DisableCatalog1Hook = 5047h
Catalog1HookActive = 3
Catalog1HookFlag = 36h

Catalog2HookPtr = 9BC4h
_EnableCatalog2Hook = 4F8Dh
_DisableCatalog2Hook = 4F90h
Catalog2HookActive = 6
Catalog2HookFlag = 34h

CatalogCurrent = 85DAh

Overview -----------------------------------------------------------------------

These two hooks are unique on the 83+, as they are, in many cases, the same hook. Although there are a few cases where the differ, in many cases the OS passes the same event to both hooks, one after another, effectivly resulting in the two hooks being chained. Consequently, it's best to document both hooks together, and also commenting on their interactions.

The TI Localization apps use the Catalog 2 hook for their activities (probably because the Catalog 2 hook also provides keypress notification, required to implement the Characters item it provides), so it would be possible to use the Catalog 1 hook to override some of their behaviors.

This document is formatted a little differently from normal, organizing by general event, not by hook specifics, and then discussing how each hook handles it.

Keypress Table -----------------------------------------------------------------

At the heart of the catalog hooks is the keypress table, which provides the ordering for the tokens in the list (since it's sorted.) Each entry in the table is two bytes long, the format depending on the whether the key is a one- or two-byte keypress:

- if it's a one byte keypress, then the first byte is zero, and the second byte is the value of the key.

- if it's a two byte keypress, the first byte is the prefix (FCh-FEh, but the OS seems to use FDh and FFh as well - anyone know why?), and the second byte is the other value.

The TI-OS stores this table on page 7 (tested in OS 1.16), but this might change, expecially with the TI-84+.

You can provide your own keypress table in a unique way. It's obvious that, inside the OS's implementation of the catalog, it would have to do something like "ld hl, table_start". However, after doing this, it always calls the Catalog hooks, allowing it to modify the value. It looks something like this internally (this is not the exact code):

ld hl, table_start
ld a, 5
bit Catalog1HookActive, (iy + Catalog1HookFlag)
call nz, CallCatalog1Hook
bit Catalog2HookActive, (iy + Catalog2HookFlag)
call nz, CallCatalog2Hook

where CallCatalog#Hook would return the registers and flags that the hook returned. Consequently, we are free to provide any value that we want.

It would seem that all we can do is just change range of tokens displayed, but it turns out that the OS only actually reads the table in one situation: when displaying a token, otherwise it's just manipulating the pointers without actually knowing where they are pointing! The cool part is we are able to change how this read occurs. Before drawing an item, the Catalog Hooks are called, with the table pointer being passed in HL. If we want, we can point this somewhere else (say somewhere in RAM, TI uses sFont_record), where we can put our own item that we copied there (realize that the read is performed with page 7 in the 4000h-7FFFh range, so we can't keep anything in flash.) The other interesting side effect is that we can copy anything we want to RAM: we could generate a virtual table on the fly.

So the easy method of reordering the catalog: replace all the OS-provided pointers with your own on your flash page, and when the display item event is fired, copy the item at the pointer provided into RAM, and give the OS the pointer to the area in RAM.

----- Event: Get Table Start ---------------------------------------------------

This event is passed to the Catalog 1 hook first.

Both Catalog Hooks: The OS wants the address of the keypress table. HL contains the address for the OS's table. If you want to provide your own table, change HL to its address.

Catalog 1 Hook Only: This message seems to get triggered in two cases:

- A = 5. If you don't want the message to be passed to the Catalog 2 hook, return with the zero flag reset. If you modify A, realize that whatever value you change it to will be passed to the Catalog 2 hook (should you permit it.) Although this could be useful, if you don't want to break the Catalog 2 hook, make sure you set A back to 5.

- A = 0Ah. This is called under some unknown circumstances (anyone know why?), but it seems acceptable to treat it as A = 5. In this case, you don't have to worry about trashing A; if you permit the Catalog 2 hook to be called under this condition, the TI-OS sets A = 5 for you.

Catalog 2 Hook Only: A = 5. HL may contain the address of the table provided by the Catalog 1 hook instead of the OS-provided address. Return flags are ignored.

----- Event: Get Table End -----------------------------------------------------

This event is passed to the Catalog 1 hook first. This event is similar to the previous event.

Both Catalog Hooks: A = 6. The OS wants the address of the keypress table. DE contains the OS's value. If you want to provide your own address, simply set DE.

Catalog 1 Hook Only: Returning with the zero flag reset prevents the Catalog 2 hook from processing the event. If you modify A, restore it as above.

Catalog 2 Hook Only: DE may contain the address provided by the Catalog 1 hook as above. Return flags ignored.

----- Event: Get Last Screen ---------------------------------------------------

This event is passed to the Catalog 2 hook only, A = 2.

The user has pressed up on the topmost item, so we must scroll back around to the last item. Here, we must provide in HL the pointer to the first item that must be displayed (so when displaying the bottom of the list, the first item shown.) HL will be set to the predefined OS value, but you can overwrite it. Return flags are ignored.

----- Event: Get Last Screen Item ----------------------------------------------

This event is passed to the Catalog 2 hook only, A = 3.

In the situation above, you must provide, in HL, the pointer to the item that will be selected. This will probably just be the pointer to the last item in the list, but you could make it different if you want. The return flags are ignored.

----- Event: Get Item from Letter ----------------------------------------------

This event is passed to the Catalog 1 hook first.

Both Catalog Hooks: A will be 4. The user has pressed a letter key, and we need to return the address of the item to be selected. DE is set to (key - 41h) * 2, where key is the ASCII value of the key. It's somewhat expected that you store a list of addresses; this would seem to be the most efficient way to do it anyways.

Catalog 1 Hook Only: Returning with zero reset will immediatly use the value in HL as the address of the entry of the keypress table we should display. The catalog 2 hook will not be called. Returning with zero set could result in one of two things happening:

- the Catalog 2 hook is not installed, at which point the OS will call LdHLInd and use that as the pointer to the keypress table. It's assuming that, by returning with zero set, you have essentially ignored the message, and HL is pointing inside it's lookup table. Realize that if you return with zero set you shouldn't trash HL!

- the Catalog 2 hook is installed, and how to handle HL is its decision

Make sure you restore A should you trash it.

Catalog 2 Hook Only: DE or HL could be modified by the Catalog 1 hook. Returning with zero set will immediately use the pointer in HL as a pointer to the item to be displayed next. Returning with zero set will cause LdHLInd to be called, treating the result as a pointer in the keypress table.

----- Event: Display Title -----------------------------------------------------

This event is passed to the Catalog 1 hook first.

Both Catalog Hooks: A = 7. The title of the catalog is about to be displayed, but this event can also be used as a generic catalog-is-open event (note: the Get Table Start event is called first!) There aren't any register inputs or outputs.

Catalog 1 Hook Only: If you modify A, make sure you set it back to 7, or the Catalog 2 app (if called) will not recieve the event properly. Return flags ignored.

Catalog 2 Hook Only: Returning with zero set causes the catalog to exit.

----- Event: Display Item ------------------------------------------------------

This event is passed to the Catalog 1 hook first.

Both Catalog Hooks: HL is the address of the key in the keypress table. Remember, if you want to provide your own key / token, you must copy the keypress data into RAM, and point HL to it.

Catalog 1 Hook Only: The accumulator is set to 9 for this event. Returning with zero reset will prevent drawing this item, and the Catalog 2 Hook will not be called.

Catalog 2 Hook Only: The accumulator is set to 1 for this event. HL contains whatever the Catalog 1 hook provided, either the OS provided pointer or a custom pointer (if it was called.) Returning with zero reset will prevent drawing the item.

----- Event: Key Press ---------------------------------------------------------

This event is passed to Catalog 2 only.

The accumulator is 8, B contains the keypress. You can modify it if you want. If you return with zero set, it will be canceled.

Note: If you want to look for up / down, then also check for kAlphaUp and kAlphaDown, since Alpha Lock is set by default in the catalog.

83Plus:BCALLs:4522

2005-06-02T22:48:37Z

JasonM:

[[Category:83Plus:BCALLs:By Name:Display|WPutSEOL]] [[Category:83Plus:BCALLs:By Name|WPutSEOL]] [[Category:83Plus:BCALLs:By Address|4522 - WPutSEOL]]
== Synopsis ==
'''Official Name:''' WPutSEOL

'''BCALL Address:''' 4522

Displays a string, putting an ellipsis (an ...) on the end of row if needed.

=== Inputs ===
* HL = String to display.

=== Outputs ===
None

=== Destroys ===
''Unknown''

== Comments ==
This B_CALL never returns to the caller, when you exit the application it will return to the homescreen like it normally does.

== Example ==
<nowiki>ld hl, Appname
ld de,progToEdit
ld bc,8
ldir
B_CALL ExecuteApp
Appname: db "Calcsys "</nowiki>

== Credits and Contributions ==
* '''Kirk Meyer:''' For hinting on the use of this B_CALL.

83Plus:Hooks:9B90

2005-06-02T22:43:39Z

JasonM: minor change checkbox, yeah, I know

[[Category:83Plus:Hooks:By Address|9B90 - Window Hook]]
[[Category:83Plus:Hooks:By Name|Window Hook]]
== Synopsis ==
'''Name:''' Window Hook

'''Hook Pointer Block Address:''' [[83Plus:RAM:9B90|9B90]]

'''Hook Enable BCALL:''' [[83Plus:BCALLs:4FB1|4FB1]]

'''Hook Disable BCALL:''' [[83Plus:BCALLs:4FB4|4FB4]]

'''Hook Call BCALL:''' [[83Plus:BCALLs:9012|9012]]

'''Hook Active Flag:''' 2, (iy + 35h)

This hook is triggered when various events occur on the Window screen (where you adjust the Xmin, Xmax, etc. values). It is also called for the finance solver and TblSet interfaces.

This hook is based around a special table which is documented in the comments section below. It might help to read that section first.

== Using the Hook ==
Events are determined by the accumulator, as usual.
* '''A = 04h:''' The WINDOW title is about to be displayed. Returning with zero reset will cancel this drawing; you can draw your own title.
* '''A = 00h:''' Execute this code (just paste this right into your routine):
<nowiki>or 1 \ ld a, (ix) \ ret</nowiki>
* '''A = 01h:''' Execute this code (same as above):
<nowiki>or 1 \ ld a, (ix + 3) \ ret</nowiki>
* '''A = 02h:''' Execute this code (ditto):
<nowiki>or 1 \ ld a, (ix - 3) \ ret</nowiki>
* '''A = 03h:''' Draw the table item pointed by IX. curRow and curCol are already setup for outputting the prompt (the Xmin=-style thing.) After showing this prompt, B_CALL [[83Plus:BCALLs:452B|SetNumWindow]]. Then, output the number (see message 9 below.)
* '''A = 05h:''' We are about to edit an entry. HL is a pointer to the table entry corresponding to the entry to edit. You need to set OP1 to the value in the editing field. (So say you type something into Xmin, you must set OP1 to the value of Xmin here.)
* '''A = 06h:''' We are done editing an entry. HL points to the table entry that we are done editing, and the value is in OP1. You probably want to save this value.
* '''A = 07h:''' The hook needs the address of the first real entry in the table (''not'' one of the start/end entries.) See the comments section for details.
* '''A = 09h:''' We are going to display one of the numbers. HL is pointing to the appropriate table entry. You probably want to copy the number into OP1 and execute the following code (see the docs for [[83Plus:BCALLs:4522|WPutSEOL]] for more info):
<nowiki>ld a, 15h
B_CALL FormEReal
ld hl, OP3
B_CALL WPutSEOL</nowiki>
* '''A = 0Ah:''' A key was pressed, the keycode is in B. You can modify this as needed.

== Comments ==
The table is the most important part of the hook, which tells what you want the table to look like. Each record in the table is three bytes. The first byte is simply a value which you can use to identify the entry. It can be a memory offset (one byte only), token identifier, keypress equate, or any other one byte value. However, it has one special value, 0FFh, which means this record indicates either the start or end of the table. The second and third bytes are simply the pointer to the string to be displayed, null terminated as usual.

Here's an example table:

<nowiki> db 0FFh ; Dummy Entry signifying start of table
dw 0 ; Doesn't matter on string pointer
TableStart:
db 0 ; Lets identify the first item by a value of 0
dw EntryString1 ; Pointer to string
; Simply using this assemble trick is perfect
db 1 ; Same as above
dw EntryString2 ; Same as above

db 0FFh ; Dummy Entry signifying end of table
; No need for string pointer, the OS never checks

EntryString1: db "Var=", 0
EntryString2: db "Var2=", 0</nowiki>

When you pass the table pointer in message 7, pass "TableStart" as indicated above, as that is the first entry to be displayed.

== Credits and Contributions ==
* '''Kirk Meyer:''' For Graph3, which uses this hook and provided a working example of the hook.

83Plus:Hooks:9B90

2005-06-02T22:42:49Z

JasonM:

[[Category:83Plus:Hooks:By Address|9B90 - Window Hook]]
[[Category:83Plus:Hooks:By Name|Window Hook]]
== Synopsis ==
'''Name:''' Window Hook

'''Hook Pointer Block Address:''' [[83Plus:RAM:9B90|9B90]]

'''Hook Enable BCALL:''' [[83Plus:BCALLs:4FB1|4FB1]]

'''Hook Disable BCALL:''' [[83Plus:BCALLs:4FB4|4FB4]]

'''Hook Call BCALL:''' [[83Plus:BCALLs:9012|9012]]

'''Hook Active Flag:''' 2, (iy + 35h)

This hook is triggered when various events occur on the Window screen (where you adjust the Xmin, Xmax, etc. values). It is also called for the finance solver and TblSet interfaces.

This hook is based around a special table which is documented in the comments section below. It might help to read that section first.

== Using the Hook ==
Events are determined by the accumulator, as usual.
* '''A = 04h:''' The WINDOW title is about to be displayed. Returning with zero reset will cancel this drawing; you can draw your own title.
* '''A = 00h:''' Execute this code (just paste this right into your routine):
<nowiki>or 1 \ ld a, (ix) \ ret</nowiki>
* '''A = 01h:''' Execute this code (same as above):
<nowiki>or 1 \ ld a, (ix + 3) \ ret</nowiki>
* '''A = 02h:''' Execute this code (ditto):
<nowiki>or 1 \ ld a, (ix - 3) \ ret</nowiki>
* '''A = 03h:''' Draw the table item pointed by IX. curRow and curCol are already setup for outputting the prompt (the Xmin=-style thing.) After showing this prompt, B_CALL [[83Plus:BCALLs:452B|SetNumWindow]]. Then, output the number (see message 9 below.)
* '''A = 05h:''' We are about to edit an entry. HL is a pointer to the table entry corresponding to the entry to edit. You need to set OP1 to the value in the editing field. (So say you type something into Xmin, you must set OP1 to the value of Xmin here.)
* '''A = 06h:''' We are done editing an entry. HL points to the table entry that we are done editing, and the value is in OP1. You probably want to save this value.
* '''A = 07h:''' The hook needs the address of the first real entry in the table (''not'' one of the start/end entries.)
* '''A = 09h:''' We are going to display one of the numbers. HL is pointing to the appropriate table entry. You probably want to copy the number into OP1 and execute the following code (see the docs for [[83Plus:BCALLs:4522|WPutSEOL]] for more info):
<nowiki>ld a, 15h
B_CALL FormEReal
ld hl, OP3
B_CALL WPutSEOL</nowiki>
* '''A = 0Ah:''' A key was pressed, the keycode is in B. You can modify this as needed.

== Comments ==
The table is the most important part of the hook, which tells what you want the table to look like. Each record in the table is three bytes. The first byte is simply a value which you can use to identify the entry. It can be a memory offset (one byte only), token identifier, keypress equate, or any other one byte value. However, it has one special value, 0FFh, which means this record indicates either the start or end of the table. The second and third bytes are simply the pointer to the string to be displayed, null terminated as usual.

Here's an example table:

<nowiki> db 0FFh ; Dummy Entry signifying start of table
dw 0 ; Doesn't matter on string pointer
TableStart:
db 0 ; Lets identify the first item by a value of 0
dw EntryString1 ; Pointer to string
; Simply using this assemble trick is perfect
db 1 ; Same as above
dw EntryString2 ; Same as above

db 0FFh ; Dummy Entry signifying end of table
; No need for string pointer, the OS never checks

EntryString1: db "Var=", 0
EntryString2: db "Var2=", 0</nowiki>

When you pass the table pointer in message 7, pass "TableStart" as indicated above, as that is the first entry to be displayed.

== Credits and Contributions ==
* '''Kirk Meyer:''' For Graph3, which uses this hook and provided a working example of the hook.

83Plus:Hooks:9B90

2005-06-02T22:42:20Z

JasonM: YAY! Finally uploaded. Only a month or two late! :-)

[[Category:83Plus:Hooks:By Address|9B90 - Window Hook]]
[[Category:83Plus:Hooks:By Name|Window Hook]]
== Synopsis ==
'''Name:''' Window Hook

'''Hook Pointer Block Address:''' [[83Plus:RAM:9B90|9B90]]

'''Hook Enable BCALL:''' [[83Plus:BCALLs:4FB1|4FB1]]

'''Hook Disable BCALL:''' [[83Plus:BCALLs:4FB4|4FB4]]

'''Hook Call BCALL:''' [[83Plus:BCALLs:9012|9012]]

'''Hook Active Flag:''' 2, (iy + 35h)

This hook is triggered when various events occur on the Window screen (where you adjust the Xmin, Xmax, etc. values). It is also called for the finance solver and TblSet interfaces.

This hook is based around a special table which is documented in the comments section below.

== Using the Hook ==
Events are determined by the accumulator, as usual.
* '''A = 04h:''' The WINDOW title is about to be displayed. Returning with zero reset will cancel this drawing; you can draw your own title.
* '''A = 00h:''' Execute this code (just paste this right into your routine):
<nowiki>or 1 \ ld a, (ix) \ ret</nowiki>
* '''A = 01h:''' Execute this code (same as above):
<nowiki>or 1 \ ld a, (ix + 3) \ ret</nowiki>
* '''A = 02h:''' Execute this code (ditto):
<nowiki>or 1 \ ld a, (ix - 3) \ ret</nowiki>
* '''A = 03h:''' Draw the table item pointed by IX. curRow and curCol are already setup for outputting the prompt (the Xmin=-style thing.) After showing this prompt, B_CALL [[83Plus:BCALLs:452B|SetNumWindow]]. Then, output the number (see message 9 below.)
* '''A = 05h:''' We are about to edit an entry. HL is a pointer to the table entry corresponding to the entry to edit. You need to set OP1 to the value in the editing field. (So say you type something into Xmin, you must set OP1 to the value of Xmin here.)
* '''A = 06h:''' We are done editing an entry. HL points to the table entry that we are done editing, and the value is in OP1. You probably want to save this value.
* '''A = 07h:''' The hook needs the address of the first real entry in the table (''not'' one of the start/end entries.)
* '''A = 09h:''' We are going to display one of the numbers. HL is pointing to the appropriate table entry. You probably want to copy the number into OP1 and execute the following code (see the docs for [[83Plus:BCALLs:4522|WPutSEOL]] for more info):
<nowiki>ld a, 15h
B_CALL FormEReal
ld hl, OP3
B_CALL WPutSEOL</nowiki>
* '''A = 0Ah:''' A key was pressed, the keycode is in B. You can modify this as needed.

== Comments ==
The table is the most important part of the hook, which tells what you want the table to look like. Each record in the table is three bytes. The first byte is simply a value which you can use to identify the entry. It can be a memory offset (one byte only), token identifier, keypress equate, or any other one byte value. However, it has one special value, 0FFh, which means this record indicates either the start or end of the table. The second and third bytes are simply the pointer to the string to be displayed, null terminated as usual.

Here's an example table:

<nowiki> db 0FFh ; Dummy Entry signifying start of table
dw 0 ; Doesn't matter on string pointer
TableStart:
db 0 ; Lets identify the first item by a value of 0
dw EntryString1 ; Pointer to string
; Simply using this assemble trick is perfect
db 1 ; Same as above
dw EntryString2 ; Same as above

db 0FFh ; Dummy Entry signifying end of table
; No need for string pointer, the OS never checks

EntryString1: db "Var=", 0
EntryString2: db "Var2=", 0</nowiki>

When you pass the table pointer in message 7, pass "TableStart" as indicated above, as that is the first entry to be displayed.

== Credits and Contributions ==
* '''Kirk Meyer:''' For Graph3, which uses this hook and provided a working example of the hook.

83Plus:OS:RST Routines

2005-06-02T21:54:11Z

JasonM: Guess who forgot about minor edits and such...sorry....

[[Category:83Plus:OS_Information|RST Routines]]
== Introduction ==

The Z80 restart instruction, or <code>RST</code>, can be used instead of a B_CALL for some system entry points. The advantage is that using the RST instruction takes only one byte, instead of the three bytes required for a B_CALL, and is very quick when compared with the relatively large overhead inherent of a B_CALL.

== RST Routines ==
All the RST routines work exactly the same as the corresponding B_CALLs:
{| border="0"
| '''B_CALL''' || '''RST'''
|-[[83Plus:BCALLs:412F|OP1ToOP2]] || rOP1ToOP2
|-
|[[83Plus:BCALLs:42F1|FindSym]] || rFindSym
|-
|[[83Plus:BCALLs:43BA|PushRealO1]] || rPushRealO1
|-
|[[83Plus:BCALLs:417A|Mov9ToOP1]] || rMov9ToOP1
|-
|[[83Plus:BCALLs:4072|FPAdd]] || rFPAdd
|}
== Example ==

<nowiki>rst rFPAdd</nowiki>

== Equates ==

<nowiki>
rOP1ToOP2 EQU 08h
rFindSym EQU 10h
rPushRealO1 EQU 18h
rMov9ToOP1 EQU 20h
rFPAdd EQU 30h
</nowiki>

== Remarks ==

You cannot define your own RSTs; they are part of the operating system.

83Plus:OS:RST Routines

2005-06-02T21:53:39Z

JasonM:

[[Category:83Plus:OS_Information|RST Routines]]

== Introduction ==

The Z80 restart instruction, or <code>RST</code>, can be used instead of a B_CALL for some system entry points. The advantage is that using the RST instruction takes only one byte, instead of the three bytes required for a B_CALL, and is very quick when compared with the relatively large overhead inherent of a B_CALL.

== RST Routines ==
All the RST routines work exactly the same as the corresponding B_CALLs:
{| border="0"
| '''B_CALL''' || '''RST'''
|-[[83Plus:BCALLs:412F|OP1ToOP2]] || rOP1ToOP2
|-
|[[83Plus:BCALLs:42F1|FindSym]] || rFindSym
|-
|[[83Plus:BCALLs:43BA|PushRealO1]] || rPushRealO1
|-
|[[83Plus:BCALLs:417A|Mov9ToOP1]] || rMov9ToOP1
|-
|[[83Plus:BCALLs:4072|FPAdd]] || rFPAdd
|}
== Example ==

<nowiki>rst rFPAdd</nowiki>

== Equates ==

<nowiki>
rOP1ToOP2 EQU 08h
rFindSym EQU 10h
rPushRealO1 EQU 18h
rMov9ToOP1 EQU 20h
rFPAdd EQU 30h
</nowiki>

== Remarks ==

You cannot define your own RSTs; they are part of the operating system.

83Plus:OS:RST Routines

2005-06-02T21:53:31Z

JasonM:

[[Category:83Plus:OS_Information|RST Routines]]

== Introduction ==

The Z80 restart instruction, or <code>RST</code>, can be used instead of a B_CALL for some system entry points. The advantage is that using the RST instruction takes only one byte, instead of the three bytes required for a B_CALL, and is very quick when compared with the relatively large overhead inherent of a B_CALL.

== RST Routines ==
All the RST routines work exactly the same as the corresponding B_CALLs:

{| border="0"
| '''B_CALL''' || '''RST'''
|-[[83Plus:BCALLs:412F|OP1ToOP2]] || rOP1ToOP2
|-
|[[83Plus:BCALLs:42F1|FindSym]] || rFindSym
|-
|[[83Plus:BCALLs:43BA|PushRealO1]] || rPushRealO1
|-
|[[83Plus:BCALLs:417A|Mov9ToOP1]] || rMov9ToOP1
|-
|[[83Plus:BCALLs:4072|FPAdd]] || rFPAdd
|}
== Example ==

<nowiki>rst rFPAdd</nowiki>

== Equates ==

<nowiki>
rOP1ToOP2 EQU 08h
rFindSym EQU 10h
rPushRealO1 EQU 18h
rMov9ToOP1 EQU 20h
rFPAdd EQU 30h
</nowiki>

== Remarks ==

You cannot define your own RSTs; they are part of the operating system.

Talk:83Plus:BCALLs:51B8

2005-05-24T03:13:57Z

JasonM:

What's with the casing on this B_CALL? LRESID is the residuals, so not anything to do with resource ID's or something (which was how I read it when I saw that casing.) --[[User:JasonM|JasonM]] 20:13, 23 May 2005 (PDT)

Talk:83Plus:RAM:82A5

2005-05-24T03:11:12Z

JasonM:

Would it be appropriate to copy the message from TI's discussion board? I'm not sure that it will be permanently available at that address, and I don't know that it's been published anywhere else. Alternatively, of course, somebody else could elaborate on exactly how the area is used when graphing... [[User:FloppusMaximus|FloppusMaximus]] 16:31, 23 May 2005 (PDT)
:For the time being, I'll post a copy of the message here until we can decide what we want to permanently do with it. --[[User:AndyJ|AndyJ]] 18:58, 23 May 2005 (PDT)
<nowiki>[0:00, 3/9/05] Use of TempSwapArea in OS 2.30 by Brian Dean

OS version 2.30 uses TempSwapArea for temporary storage during graphing
operations. System calls that may alter TempSwapArea include:

ReGraph
DrawCmd
ShadeCmd

If your App or program uses TempSwapArea and performs graphing operations,
you may need to consider using a different free RAM location or an Appvar
to store your data.

I hope this information is helpful. If you have any suggestions or feedback
regarding our development tools, please send me an e-mail at
ti-83plus-sdk-support@list.ti.com, or use the feedback form located in the
developer's section of our website.

Brian Dean
Developer Support</nowiki>

:So does InvCmd, according to brian --[[User:JasonM|JasonM]] 20:11, 23 May 2005 (PDT)

Talk:Contributing

2005-04-28T22:56:11Z

JasonM:

Should romcalls be put into only the most specific category, or should they appear in the parent category as well?--[[User:Dwedit|Dwedit]] 13:28, 28 Mar 2005 (PST)

----

They should be placed into both. We want a list of *all* bcalls/romcalls, but it's also nice to be able to browse by more specific type. So, for example, you would have something like this (pasted from the template) -

<nowiki>[[Category:83Plus:BCALLs:By Name|ProveTheRiemannHypothesis]]</nowiki>

and also

<nowiki>[[Category:83Plus:BCALLs:By Name|Utility|ProveTheRiemannHypothesis]]</nowiki>

And then a third category listing for the by address listing.
--[[User:Dan Englender|Dan Englender]] 14:22, 28 Mar 2005 (PST)

----

That'd be <nowiki>[[Category:83Plus:BCALLs:By Name:Utility|ProveTheRiemannHypothesis]]</nowiki>... *runs off to check the template*

--[[User:AndyJ|AndyJ]] 15:56, 28 Mar 2005 (PST)

----
Ick, I did goof that up... I fixed it. --[[User:AndyJ|AndyJ]] 15:57, 28 Mar 2005 (PST)

----
Would it be a good idea to use this nomenclature when talking about the calculator's memory?
*"page" - 256 bytes of memory, usu. in the address range ??00..??FF.
*"(memory) slot" - A division of logical memory used for memory banks (the TI-83 has four slots).
*"(memory) bank" - An amount of physical memory that can be mapped in/out of logical memory through a memory slot.

There is also no standard for how code should be formatted. There are three articles in Z80 Routines, and all of them use a different assembler's syntax (bub_font: ZMASM, fastcopy: TASM, and itoa (arguably the finest of them all :-): WLA).
--[[User:Sigma|Sigma]] 14:30, 28 Apr 2005 (PDT)

:"Page" is already in common use for a 16KB section of RAM or flash that can be paged in, so we shouldn't change that. Af far as formatting: oh well. All of us use different assemblers, and we just need to live with it, I think. --[[User:JasonM|JasonM]] 15:56, 28 Apr 2005 (PDT)

Talk:Z80 Routines:Graphic:Fastcopy

2005-04-27T23:30:04Z

JasonM:

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)

83Plus:Hooks:9BD0

2005-04-27T02:52:58Z

JasonM: /* Using the Hook */

[[Category:83Plus:Hooks:By_Name|Silent Link Hook]] [[Category:83Plus:Hooks:By_Address|9BD0 - Silent Link Hook]]
== Synopsis ==
'''Name:''' Silent Link Hook

'''Hook Pointer Block Address:''' [[83Plus:RAM:9BD0|9BD0]]

'''Hook Enable BCALL:''' [[83Plus:BCALLs:50CE|50CE]]

'''Hook Disable BCALL:''' [[83Plus:BCALLs:50D1|50D1]]

'''Hook Call BCALL:''' ''Unknown''

'''Hook Active Flag:''' [[83Plus:Flags:36#Bit_7|7, (iy + 36h)]]

This hook allows you to abort a silent link request.

== Using the Hook ==
The hook only uses the zero flag. Set it to disable the silent link handler.

== Comments ==
This hook was introduced in OS 1.13. Apps should check the OS version before attempting to use this hook.

This hook can be used to make sure no silent links interrupt your GetKey call.

== Credits and Contributions ==
* '''Michael Vincent:''' For telling others about this hook.

Talk:Z80 Routines:Graphic:Fastcopy

2005-04-26T22:07:29Z

JasonM:

Z80 Routines:Graphic:Fastcopy

2005-04-26T22:06:32Z

JasonM: /* Remarks and Improvements */ - the di isn't dispensible!

[[Category:Z80 Routines:Graphic|fastcopy]]
[[Category:Z80 Routines|fastcopy]]
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 do with one less '''inc hl''' (6 cycles) and thus load 11 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 1 of Port 2 tells us that the lcd can accept an instruction
* Bit 7 of Port 11 tells us that the lcd can accept an instruction

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 (c) is an undefined instruction.
;You may have to add it in order for the routine to work.

.addinstr IN (C) 70ED 2 NOP 1

SafeCopy:
di
ld c,$10
ld a,$80
setrow:
in (c)
jp m,setrow
out ($10),a
ld hl,gbuf
ld de,12
ld a,$20
col:
in (c)
jp m,col
out ($10),a
ex af,af'
ld b,64
row:
ld a,(hl)
rowwait:
in (c)
jp m,rowwait
out ($11),a
add hl,de
djnz row
ex af,af'
dec h
dec h
dec h
inc hl
inc a
cp $2c
jp nz,col
ret
</nowiki>

Z80 Routines:Graphic:Fastcopy

2005-04-26T22:06:06Z

JasonM: Better explained what was messed with the LCDs

[[Category:Z80 Routines:Graphic|fastcopy]]
[[Category:Z80 Routines|fastcopy]]
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==
* The di instruction is dispensable.
* 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 do with one less '''inc hl''' (6 cycles) and thus load 11 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 1 of Port 2 tells us that the lcd can accept an instruction
* Bit 7 of Port 11 tells us that the lcd can accept an instruction

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 (c) is an undefined instruction.
;You may have to add it in order for the routine to work.

.addinstr IN (C) 70ED 2 NOP 1

SafeCopy:
di
ld c,$10
ld a,$80
setrow:
in (c)
jp m,setrow
out ($10),a
ld hl,gbuf
ld de,12
ld a,$20
col:
in (c)
jp m,col
out ($10),a
ex af,af'
ld b,64
row:
ld a,(hl)
rowwait:
in (c)
jp m,rowwait
out ($11),a
add hl,de
djnz row
ex af,af'
dec h
dec h
dec h
inc hl
inc a
cp $2c
jp nz,col
ret
</nowiki>

Talk:Z80 Routines:Graphic:Fastcopy

2005-04-25T23:38:48Z

JasonM: /* Warnings? */

Talk:Z80 Routines:Graphic:Fastcopy

2005-04-25T23:38:34Z

JasonM: Warnings?

WikiTI Home

2005-04-17T02:52:25Z

JasonM:

Welcome to WikiTI, a Wiki for assembly programmers of the TI-83 and TI-83 Plus Family. WikiTIâ€™s goal is to serve as a central place for the discussion and exploration of the undocumented features of the TI-OS. To browse our documentation, you can click the "Calculator Documentation" link to the left.

Any programmer is free to contribute any [[Calculator_Documentation|documentation]] of the TI-OS, even if the information is incomplete or possibly wrong. Realize, however, that WikiTIâ€™s current goal is to focus on calculator documentation for assembly programming only; articles unrelated to assembly programming for the TI-OS (including articles on TI-BASIC programming, specific programs and/or games, generic assembly tutorials, etc.) will be removed at this time. For more information, see our page on [[Contributing]]. Not sure where to start contributing? Check out the list of [[Special:Wantedpages|Wanted Pages]] that are linked to but don't yet exist.

== News ==

* '''April 12, 2005 - ([[User:Dan Englender|Dan Englender]]):''' There are now more than '''100''' [[:Category:83Plus:BCALLs:By Name|TI-83 Plus BCALLs]] in the database! Help this impressive number grow by [[Contributing|adding some more]]!
* '''April 4, 2005 - 22:02 GMT ([[User:JasonM|JasonM]]):''' Caching disabled.
* '''April 4, 2005 - 21:45 GMT ([[User:JasonM|JasonM]]):''' Category listings are now case-insensitive.

== Contacting the WikiTI Administration ==
If you wish to contact the maintainers of WikiTI, for any reason, on IRC, please join #WikiTI on EFnet. If you do not have an IRC client, [http://chat.efnet.info/ use this]. You can find email addresses and IM names on each [[Special:Listadmins|administrator's]] User page (soon).

== Disclaimer ==
WikiTI is not in any way affiliated with Texas Instruments Inc, or any of itâ€™s subsidiaries, including the educational products division. No guarantee to accuracy is made of the information herein. Use at your own risk. [[Disclaimer|(Full Disclaimer)]]

83Plus:Hooks:9BA0

2005-04-17T02:40:10Z

JasonM:

[[Category:83Plus:Hooks:By Address|9BA0 - Regraph Hook]]
[[Category:83Plus:Hooks:By Name|Regraph Hook]]
== Synopsis ==
'''Name:''' Regraph Hook

'''Hook Pointer Block Address:''' [[83Plus:RAM:9BA0|9BA0]]

'''Hook Enable BCALL:''' [[83Plus:BCALLs:4FEA|4FEA]]

'''Hook Disable BCALL:''' [[83Plus:BCALLs:4FED|4FED]]

'''Hook Call BCALL:''' ''(Unknown)''

'''Hook Active Flag:''' 6, (iy + 35h)

This hook allows one to intercept various events that occur during a regraph, and optionally cancel them. Be aware that this hook is called if a function is being drawn on top of a currently existing graph ("smart graph.")

'''Note:''' This was only extensively researched in function mode.

== Using the Hook ==
In most cases, returning with zero set will allow something to occur, and returning with zero reset will cancel something. Like some hooks, this hook is rather messy.

These events are listed in the order below to match the order they are actually called in.

* '''A = 00h:''' Graphing has started, otherwise nothing has occured. Returning with zero reset will cancel the entire graphing procedure.
* '''A = 01h:''' Graph about to be erased if required, otherwise presented (from plotSScreen) Returning with zero set will cancel the entire graphing process.
* '''A = 02h:''' About to draw axes and grid. Returning with zero reset will cancel this drawing only.
* '''A = 09h:''' Stat plots drawn. About to draw equations. Returning with zero reset will cancel drawing of all equations (or at least the ones being drawn in this graph.)
* '''A = 03h:''' About to evaluate a point. OP1 contains the value of the independant variable. E contains the equation number only if this is the first time this message is sent for this function, otherwise may hold C9h. Return value ignored. Message skipped in Simultaneous mode.
* '''A = 08h:''' About to evaluate a point---this is somewhat a duplicate of event 03h. OP1 contains equation name. Called more than once in the case of Parametric graphs (or quite a few times). Value of E here the same as value of E during the message A = 3, or if in Simultaneous mode then the number of the equation. During the first call per equation (when not in Simultaneous mode), OP4 may contain the name of the independant variable. Return value here affects inputs to the event below.
* '''A = 04h:''' Function evaluated. OP1 is the X coordinate after evaluation. OP2 is the Y coordinate after evaluation, assuming that zero was set as a return value when A = 08h, otherwise contains function name. Canceling this event will cancel drawing of that point, as well as any line connecting to it. This event is skipped if an error occured in parsing.
* '''A = 05h:''' A = 5 - Called after A = 4 regardless of return value or if A = 4 wasn't called due to parse error. Skipped in Simultaneous mode.
* '''A = 06h:''' B contains pixel x-coordinate of the next point to be drawn. Can be modified if desired (but not sure on exact behavior.) Skipped in Simultaneous mode.
* '''A = 07h:''' About to draw axes labels, and done drawing equations. Return values ingored.

== Comments ==
The events 03h, 08h, 04h, 05h, and 06h are called in that order for each point to be evaluated.

As mentioned, this hook's behavior is rather erratic and messy; the best way to learn it is to just mess with it.

Category:Z80 Routines

2005-04-05T21:36:45Z

JasonM: Come on people...capital Z in Z80 :-)

[[Category:Calculator Documentation|General Z80 Calculator Routines]]
This Category contains routines that can be used on many Z80-based calculators. Please consult each example for which calculators they apply to.

----

When you paste code, there is a simple step you can do to format the code properly. Start the first line of code with <nowiki>, and put a space infront of the <. On the last line of your code, end it with </nowiki>. This allows for code to be formatted like this (click edit on this page to see how it's done):

<nowiki>cp 10
ccf
adc a, 30h
daa</nowiki>

Also, there are a bunch of routines [http://www.detachedsolutions.com/forum/viewtopic.php?t=1154 here] and [http://map.tni.nl/sources/external/z80bits.html here].

83:ROMCalls

2005-04-05T21:35:18Z

JasonM: redirecting

#REDIRECT [[:Category:83:ROMCalls]]

83:RAM

2005-04-05T21:34:45Z

JasonM: redirecting to the category

#REDIRECT [[:Category:83:RAM]]

83:Ports

2005-04-05T21:33:42Z

JasonM:

#REDIRECT [[:Category:83:Ports]]

83:Flags

2005-04-05T21:29:47Z

JasonM: We redirect now

#REDIRECT [[:Category:83:Flags]]

83Plus:BCALLs:807E

2005-04-05T21:28:08Z

JasonM:

[[Category:83Plus:BCALLs:By Name:Other|GetCalcSerial]] [[Category:83Plus:BCALLs:By Name|GetCalcSerial]] [[Category:83Plus:BCALLs:By Address|807E - GetCalcSerial]]
== Synopsis ==
'''Official Name:''' GetCalcSerial

'''Other Name:''' GetID

'''BCALL Address:''' 807E

Gets the first five bytes of the calculator ID.

=== Inputs ===
None

=== Outputs ===
* [[83Plus:RAM:8499|OP4]]: Contains the first five bytes of the calculator ID

=== Destroys ===
* AF, B (Not C), DE, HL

== Comments ==
This B_CALL gets the first five bytes of the ID as actual bytes, you have to convert them before you display them. The rest of the ID can't be retrieved using a B_CALL, although there seems to be a call address to get them in every OS. The only problem with using this call address is that your software will only support the OSes you add support for and will never work after an upgrade to a new OS.

Routines:Graphic

2005-04-05T00:42:45Z

JasonM:

#REDIRECT [[:Category:Routines:Graphic]]

Z80 Routines:Other:DispA

2005-04-05T00:40:50Z

JasonM: Now using top level headings...sorry...bugged me

[[Category:Z80 Routines:Other|itoa]]
[[Category:Z80 Routines|itoa]]
<nowiki>
; ITOA
; --------------------------------------------------------------
; Converts a signed integer value to a zero-terminated ASCII
; string representative of that value (using radix 10).
; --------------------------------------------------------------
; INPUTS:
; HL Value to convert (two's complement integer).
; DE Base address of string destination. (pointer).
; --------------------------------------------------------------
; OUTPUTS:
; None
; --------------------------------------------------------------
; REGISTERS/MEMORY DESTROYED
; AF HL
; --------------------------------------------------------------

itoa:
push de
push bc

; Detect sign of HL.
bit 7, h
jr z, _DoConvert

; HL is negative. Output '-' to string and negate HL.
ld a, '-'
ld (de), a
inc de

; Negate HL (using two's complement)
xor a
sub l
ld l, a
ld a, 0 ; Note that XOR A or SUB A would disturb CF
sbc a, h
ld h, a

; Convert HL to digit characters
_DoConvert:
ld b, 0 ; B will count character length of number
- ld a, 10
syscall DivHLByA ; HL = HL / A, A = remainder
push af
inc b
ld a, h
or l
jr nz, -

; Retrieve digits from stack
- pop af
or $30
ld (de), a
inc de
djnz -

; Terminate string with NULL
xor a
ld (de), a

pop bc
pop de
ret
</nowiki>

==Comments==
*This routine uses the common [[Wikipedia:Numeral_systems#Change_of_radix|positive-integer radix conversion algorithm]] of repeatedly dividing a value by the desired radix (base case: the value is zero) and saving the remainders of each division.
*As this algorithm gives the digits in reverse order, they are pushed onto the hardware stack so that subsequently popping them yields the correct order.
*Note that the output string will not be fixed-width.

==Example Usage==
<nowiki> ld hl, -1004
ld de, OP1
call itoa
ld hl, OP1
syscall PutS</nowiki>

Talk:83Plus:BCALLs:4006

2005-04-05T00:34:05Z

JasonM:

The name seems rather ambiguous to me; I refer to this as "CallLocalizeHook," but does anyone else have any suggestions? [[User:FloppusMaximus|FloppusMaximus]] 13:04, 4 Apr 2005 (PDT)

I think I agree...CallLocalizeHook seems like a better idea. LocalizeHook might be the official name, however. --[[User:JasonM|JasonM]] 17:34, 4 Apr 2005 (PDT)

Talk:83Plus:BCALLs:4006

2005-04-05T00:33:52Z

JasonM:

Help:Contents

2005-04-04T02:59:43Z

JasonM: I got rid of the attack of the bullets.

For further information/syntax, please refer to [http://en.wikipedia.org/wiki/Help:Contents Wikipedia's Help system].

== Frequently Asked Questions ==
=== Registering ===
; How do I register/login?
: In the upper-right hand corner of the screen, select [[Special:Userlogin| Create a user or login]].
; Do I need to provide my real name?
: No, it is a matter of personal preference/privacy to provide your real name.
; Can I change it later?
: Yes, once you login, you can change your password, real name, and e-mail address.

=== Getting Started ===
; Ok, I've logged in<nowiki>:</nowiki> how do I make a new page?
: Type the name in the Goto box on the left-hand side of the screen; see [[Contributing|Contributing Guidelines]] for the syntax. As an example, if you want to add documentation for RAM address FFFF on the 83+, type the following in the Goto box:
<nowiki>83Plus:RAM:FFFF</nowiki>
:Make sure you read the [[Contributing|Contributing Guidelines]]!!!
;Do I need to denote hexadecimal with a $ or h, like in Z80 assembly?
:No, it is assumed in WikiTI that all numbers/addresses are hexidecimal by default.
;What are templates?
:Templates, are, as the name says, templates. :-) They provide a default structure for the various pages. If all the WikiTI users follow these templates, it'll make all B_CALL pages look consistent, all ports the same format, etc. Thus, it is encouraged to use these (see [[ Contributing#Templates| Templates]] for a list of templates).
; How do I use a template?
* Select a template
* View the source and copy it (the edit tab is near the top of the screen)
* Paste the source into your new page (that you just Goto'ed)
* Edit the text to fit your type of documentation
; What's the category text at the top of the templates for?
: That is how WikiTI categorizes the various pages. Following the previous example, you should have these lines at the top of your new page:
<nowiki>[Category:83Plus:RAM:By Address:FFFF - TheName]
[Category:83Plus:RAM:By Name|TheName]</nowiki>
:If you are curious as to how a page works, don't forget to view the source of it :-)

=== Editing ===
; How do I make bold/italicized text?
: See [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#Character_formatting Character Formatting]
; How do I make lists?
: See [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#Sections.2C_paragraphs.2C_lists_and_lines Lists and Lines]
; Argh! The tab doesn't work!
: In Wikipedia, you use a colon : to indent a paragraph.
; How do I put text in that blue border?
: Use <nowiki> preceded with a space. The leading space tells the Wiki parser to display the text as a preformatted, fixed-width font, which is analogous to <pre> in HTML. So " <nowiki>Your text here</nowiki></nowiki>" will show:
<nowiki>Your text here</nowiki>
; How do I make links?
: That depends on the kind of link you want to make. See [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#Links_and_URLs Links and URLs] for a more in-depth discussion.

=== Browsing ===
;Why does my contribution not show up in the list?
:Most likely, you are viewing a cached version of WikiTI. Try clearing out your cache (browser-specific). Alternatively, you may wish to disable caching in your preferences. If you do have any issues that appear to be cache-related, please contact [[User:JasonM|JasonM]].

== Tips & Hints ==
* Use the Preview Button to view your changes before you Save.
* Mark minor changes as Minor Edits (see [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#Minor_edits Minor Edits] as to what constitutes a Minor Edit).

As stated up above, please consult [http://en.wikipedia.org/wiki/Help:Contents Wikipedia's Help system] for more information.

Help:Contents

2005-04-04T02:52:29Z

JasonM: /* Tips && Hints */

For further information/syntax, please refer to [http://en.wikipedia.org/wiki/Help:Contents Wikipedia's Help system].

== FAQ ==
=== Registering ===
* '''How do I register/login?'''
** In the upper-right hand corner of the screen, select [[Special:Userlogin| Create a user or login]].
* '''Do I need to provide my real name?'''
** No, it is a matter of personal preference/privacy to provide your real name.
* '''Can I change it later?'''
** Yes, once you login, you can change your password, real name, and e-mail address.

=== Getting Started ===
* '''Ok, I've logged in: how do I make a new page?'''
** Type the name in the Goto box on the left-hand side of the screen; see [[Contributing| Contributing Guidelines]] for the syntax. As an example, if you want to add documentation for RAM address FFFF on the 83+, type the following in the Goto box:
<nowiki>83Plus:RAM:FFFF</nowiki>
* '''Do I need to denote hexadecimal with a $ or h, like in Z80 assembly?'''
** No, it is assumed in WikiTI that all numbers/addresses are hexidecimal by default.
* '''What are templates?'''
** Templates, are, as the name says, templates :) They provide a default structure for the various pages. If all the WikiTI users follow these templates, it'll make all B_CALL pages look consistent, all ports the same format, etc. Thus, it is encouraged to use these (see [[ Contributing#Templates| Templates]] for a list of templates).
* '''How do I use a template?'''
** Select a template
** View the source and copy it (the edit tab is near the top of the screen)
** Paste the source into your new page (that you just Goto'ed)
** Edit the text to fit your type of documentation
* '''What's the category text at the top of the templates for?'''
** That is how WikiTI categorizes the various pages. Following the previous example, you should have these lines at the top of your new page:
<nowiki>[Category:83Plus:RAM:By Address:FFFF - TheName]
[Category:83Plus:RAM:By Name|TheName]</nowiki>

If you are curious as to how a page works, don't forget to view the source of it :-)

=== Editing ===
* '''How do I make bold/italicized text?'''
** See [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#Character_formatting Character Formatting]
* '''How do I make lists?'''
** See [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#Sections.2C_paragraphs.2C_lists_and_lines Lists and Lines]
* '''Argh! The tab doesn't work!'''
** In Wikipedia, you use a colon : to indent a paragraph.
* '''How do I put text in that blue border?'''
** Use <nowiki> preceded with a space. The leading space tells the Wiki parser to display the text as a preformatted, fixed-width font, which is analogous to <pre> in HTML. So " <nowiki>Your text here</nowiki></nowiki>" will show:
<nowiki>Your text here</nowiki>
* '''How do I make links?'''
** That depends on the kind of link you want to make. See [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#Links_and_URLs Links and URLs] for a more in-depth discussion.

=== Recent Changes ===
None at this time

=== Browsing ===
* '''Why does my contribution not show up in the list?'''
** Most likely, you are viewing a cached version of WikiTI. Try clearing out your cache (browser-specific). Alternatively, you may wish to disable caching in your preferences.

=== Advanced ===
None at this time

== Tips & Hints ==
* Use the Preview Button to view your changes before you Save.
* Mark minor changes as Minor Edits (see [http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page#Minor_edits Minor Edits] as to what constitutes a Minor Edit).

As stated up above, please consult [http://en.wikipedia.org/wiki/Help:Contents Wikipedia's Help system] for more information.

MediaWiki:Contributing-url

2005-04-03T22:12:19Z

JasonM:

Contributing