WikiTI - User contributions [en]

User talk:84plusfreak

2006-09-14T08:33:15Z

84plusfreak: /* Mouse/Kbd driver */

<nowiki>*poke*</nowiki> You could just log in from that school computer. :) There should be an option to not remember you (or rather, ignore the option TO remember you). --[[User:AndyJ|Andy Janata]] 06:43, 24 Sep 2005 (PDT)

:These computers have so many restrictions that I can't login on any site. It doesn't support cookies and all the other stuff to remember users. --[[User:84plusfreak|84plusfreak]] 00:25, 26 Sep 2005 (PDT)

::I hate computers like that... Thankfully all the schools I've been in (well just high school and college) aren't that restrictive. --[[User:AndyJ|Andy Janata]] 12:59, 26 Sep 2005 (PDT)

== Mouse/Kbd driver ==

I am curious, what device you were writing the driver for? Does it pass the kbd and mouse information together in a single report? --[[User:Dan Englender|Dan Englender]] 10:44, 11 September 2006 (PDT)
:It's for my own Wireless Mouse/Keyboard Combo Device, but it can be used for other Mouse/Keyboard Combo Devices as well. I'm still figuring out how it passes the information. Next week I'll be in Rome. After that I'll get back to it and finish the job. Usb8x 0.11 is helping me a lot. Btw, I know where you can find the scroll wheel data. I'll send you an email on Sourceforge with the information before I leave. --[[User:84plusfreak|84plusfreak]] 01:33, 14 September 2006 (PDT)

83Plus:Software:usb8x/Supported Devices

2006-09-11T12:15:33Z

84plusfreak: /* Works, No Complete Driver */

Most USB devices that are self-powered, or draw 100mA or less current from the USB bus should be compatible with usb8x. Below is a list of device classes and specific devices that have been tested. Devices that require isochronous endpoints or have an integrated USB hub are not currently compatible.

== Internal Driver ==
These devices work and usb8x contains an internal driver to control them.
* HID Keyboard
* HID Mouse
* Mass Storage Device. Tested with:
** Sandisk Cruzer
** Lexar JumpDrive/Secure
** SMI Corp USB Disk
* TI Silverlink
* Some gamepad controllers. Tested with:
** Logitech Precision Gamepad
** [http://www.retrousb.com/nintendo.html RetroZone NES pad]
** [http://www.planetgamecube.com/hardArt.cfm?artid=2459 Skillz Gamecube to USB] (The company no longer seems to exist.)

== External Driver ==
These devices work and an external driver exists to control them.
* None

== Works, No Complete Driver ==
These devices have been tested to work with usb8x, but no complete driver currently exists.
* EMS HID Playstation 2 controller adapter
* Vernier EasyTemp
* HID Mouse/Keyboard Combo (I ([[User:84plusfreak|84plusfreak]]) am writing a driver for it.)

== Should Work ==
These devices have been tested to properly initialize with usb8x, but no drivers have been attempted.
* Canon i850 printer
* Canon SD400 digital camera
* Motorola SURFboard cable modem
* Motorola V220 (can act as USB Modem)
* TI-84 Plus (calc<->calc)

== Not Compatible ==
These devices are not compatible with usb8x.
* Ezonics webcam - isochronous endpoints
* Netgear WG111 802.11 adapter - draws too much current?
* SMC 802.11b adapter - draws too much current
* Taurus MBT-1203 bluetooth adapter - has integrated hub

83Plus:Software:usb8x/Supported Devices

2006-08-29T10:17:19Z

84plusfreak: /* Should Work */

== Internal Driver ==
These devices work and usb8x contains an internal driver to control them.
* HID Mouse
* Mass Storage Device. Tested with:
** Sandisk Cruzer
** Lexar JumpDrive/Secure

== External Driver ==
These devices work and an external driver exists to control them.
* None

== Works, No Driver ==
These devices have been tested to work with usb8x, but no complete driver currently exists.
* HID Keyboard
* TI Silverlink
* EMS HID Playstation 2 controller adapter
* Vernier EasyTemp

== Should Work ==
These devices have been tested to properly initialize with usb8x, but no drivers have been attempted.
* Canon i850 printer
* Logitech Precision Gamepad
* Motorola SURFboard cable modem
* Motorola V220 (can act as USB Modem)
* TI-84 Plus (calc<->calc)

== Not Compatible ==
These devices are not compatible with usb8x.
* Ezonics webcam - isochronous endpoints
* SMC 802.11b adapter - draws too much current
* Taurus MBT-1203 bluetooth adapter - has integrated hub

Talk:83Plus:BCALLs:80FF

2006-06-30T19:50:32Z

84plusfreak:

I called this routine with A=7A (as written in the article) and my calculator crashed.
When I called it with A=00 it worked like a charm.
Can someone confirm this? --[[User:84plusfreak|84plusfreak]] 12:49, 30 June 2006 (PDT)

Talk:83Plus:BCALLs:80FF

2006-06-30T19:49:39Z

84plusfreak:

I called this routine with A=7A and my calculator crashed.
When I called it with A=00 it worked like a charm.
Can someone confirm this? --[[User:84plusfreak|84plusfreak]] 12:49, 30 June 2006 (PDT)

83Plus:Hooks:9BC4

2006-05-30T08:35:50Z

84plusfreak: /* Synopsis */

[[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:''' [[83Plus:BCALLs:5059|5059]]

'''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:9BB4

2006-05-30T08:10:10Z

84plusfreak: /* Synopsis */

[[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:9BB4|9BB4]]

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

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

'''Hook Call BCALL:''' [[83Plus:BCALLs:505C|505C]]

'''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

2006-05-30T08:09:23Z

84plusfreak: /* Synopsis */

[[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:9BB4|9BB4]]

'''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]].

Z80 Routines:Security:CRC32

2006-05-29T15:31:13Z

84plusfreak: /* Memory Usage */

[[Category:Z80 Routines:Security|CRC32]][[Category:Z80 Routines|CRC32]]

== Notes from the author ==

I (84plusfreak) made this routine on-calc.
If you find an error, please tell me (serninpc at gmail dot com).

== Memory Usage ==

These routines use RAM that is also used by the built-in MD5 routines.

The code takes 147 bytes in your program.

== The code ==

=== CRC32Init ===

CRC32Init:
;Inputs:
; A=0 -> Use 'default' Polynomial (the one used in the ZIP Format)
; A=1 -> Use custom Polynomial
; -> DEHL=Polynomial
;Outputs:
; ($8292)=Polynomial
; ($8296)=Current CRC (~($8296)=CRC32)
;Destroys:
; AF,DE,HL
or a
jr nz,$+08
ld de,$EDB8
ld hl,$8320
ld a,d
ld d,e
ld e,a
ld a,h
ld h,l
ld l,a
ld ($8292),de
ld ($8294),hl
ld hl,$FFFF
ld ($8296),hl
ld ($8298),hl
ret

=== CRC32Update ===

CRC32Update:
;Inputs:
; HL -> Points to data
; BC -> Number of bytes
;Outputs:
; ($8296) = Updated
;Destroys:
; AF,BC,DE,HL
ld a,b
or c
ret z
push hl
push bc
ld b,(hl)
call CRC32Update_Routine
pop bc
pop hl
inc hl
dec bc
jr CRC32Update
CRC32Update_OneByte:
;Inputs:
; A = Byte to add to CRC
;Destroys:
; AF,BC,DE,HL
ld b,a
CRC32Update_Routine:
ld a,($8296)
xor b
call CRC32TableLookup
ld a,($8297)
xor l
ld ($8296),a
ld a,($8298)
xor h
ld ($8297),a
ld a,($8299)
xor e
ld ($8298),a
ld a,d
ld ($8299),a
ret
CRC32TableLookup:
ld de,$0000
ld h,d
ld l,a
ld b,8
CRC32TableLookupLoop:
push bc
or a
rr d
rr e
rr h
rr l
jr nc,CRC32TableLookupLoopEnd
push hl
pop bc
ld hl,$8292
ld a,d
xor (hl)
inc hl
ld d,a
ld a,e
xor (hl)
inc hl
ld e,a
ld a,b
xor (hl)
inc hl
ld b,a
ld a,c
xor (hl)
ld c,a
push bc
pop hl
CRC32TableLookupLoopEnd:
pop bc
djnz CRC32TableLookupLoop
ret

=== CRC32Finalize ===

CRC32Finalize:
;Inputs:
; None
;Outputs:
; DEHL = CRC32
;Destroys:
; AF,BC,DE,HL
ld de,($8298)
ld bc,($8296)
ld hl,$FFFF
push hl
or a
sbc hl,bc
ex (sp),hl
sbc hl,de
ex de,hl
pop hl
ret

User:84plusfreak

2006-05-23T15:06:40Z

84plusfreak:

I'm Sernin van de Krol. My IRC-nick is serninpc.
I live in The Netherlands.
The timezone is GMT+01:00 and we have DST.

I've got a TI-83+SE and a TI-84+SE.<br>
If you've got programs that have to be converted from BASIC to ASM/APP send me an email.

My email is: [mailto:serninpc@gmail.com serninpc@gmail.com]<br>
My website is: [http://www.sernin.net/ www.sernin.net]

83Plus:Hooks:9BAC

2006-05-18T13:36:51Z

84plusfreak: /* Class 3 Functions */

[[Category:83Plus:Hooks:By_Name|Parser Hook]] [[Category:83Plus:Hooks:By_Address|9BAC - Parser Hook]]
== Synopsis ==
'''Name:''' Parser Hook

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

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

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

'''Hook Call BCALL:''' ''(none known)''

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

This hook allows you to change the behavior of the TI-BASIC parser and functions.

== Using the Hook ==
These different values, passed in A, determine what the hook should do.
* 0: The calculator is about to parse a variable.
** OP1 = name of variable to be parsed.
** Return Z if the variable should be parsed normally.
* 1-3: A BASIC function has been encountered. The various types are described below.
** BC identifies the particular function within the class. For many 1-byte tokens, B is the token itself; for many others, B is the OP-number given in ti83plus.inc (although some of these are incorrect.)
** Return Z to run the standard function.

=== Class 1 Functions ===

Class 1 tokens all take some positive number of arguments (zero arguments is a syntax error.) These are separated by commas, or in the case of binary operators, by the operator itself. All of the arguments are evaluated before the function is.

The arguments are placed on the FPS in "reverse" order. That is to say, the earliest argument read is deepest in the stack. The final argument is in OP1. The total number of arguments is passed in HL.

Any of the following data types may be used (except where prohibited by syntax rules): Real, List, Matrix, Equation, String, Complex, Complex List. Real numbers are stored on the stack as floating-point. Complex numbers are stored as two consecutive stack entries or in OP1 and OP2 (see the SDK documentation for Push/Pop OP1/3/5.) Other data types are stored as variable names.

A hook may do any of the following:
* Leave all arguments as is, and return Z.
* Modify arguments, or add or remove them while updating HL appropriately, and return Z.
* Remove all arguments from the FPS, place the result of your computation in OP1, and return NZ.
* Remove all arguments from the FPS, reset [[83Plus:Flags:07#Bit0|numOP1,(iy+ParsFlag2)]], and return NZ. (This is generally preferable if you are not returning a useful value, as it will preserve Ans.)

=== Class 2 Functions ===

These include most "programming" commands. No arguments are parsed.

You may, if you are prepared to face the consequences, attempt to read the arguments yourself. The undocumented B_CALL [[83Plus:BCALLs:4B73|IncFetch]] can be useful in doing so.

If you return Z, the parser will run the function normally. If you return NZ, the parser will continue execution from where you left off.

=== Class 3 Functions ===

If very little is known about class 2, less is known about class 3. Tenatively, it looks like the class 2 functions that you would expect to be class 1 have class 3 secondary callbacks.

It looks like the parameters are stored in OP1 and the FPS as in class 1 and the number of arguments is stored at [[83Plus:RAM:9661|9661]]. HL is the same as (OPS) and should be saved.

== Examples ==

=== Prevent running prgmEXEC ===

<nowiki>ParserHook:
.db 83h ; Required for all hooks
or a ; Which condition?
jr nz,ReturnZ
ld hl,EXECStr ; Check whether our string
ld de,OP1+1 ; matches the name to be run.
call CompStrs ; Will return NZ if they don't match
jr nz,ReturnZ
or 1
ret
ReturnZ:
cp a
ret
EXECStr:
.db "EXEC",0

CompStrs:
ld a,(de)
cp (hl)
ret nz
inc de
inc hl
or a
jr nz,CompStrs
ret</nowiki>

=== Random sin function ===

<nowiki>ParserHook:
.db 83h ; Required for all hooks
or a ; Which condition?
ret z
push hl
ld hl,0C2C2h ; Is it the sin( token?
sbc hl,bc
pop hl
jr nz,ReturnZ
dec hl
B_CALL _DeallocFPS ; free unused parameters
B_CALL _Random
or 1 ; set NZ
ret
ReturnZ:
cp a
ret</nowiki>

== Credits and Contributions ==
* '''Brandon Sterner:''' Analysis, and the Symbolic source code.
* '''Michael Vincent:''' The Omnicalc source code.

Z80 Routines:Security:CRC32

2006-05-16T09:58:47Z

84plusfreak:

[[Category:Z80 Routines:Security|CRC32]][[Category:Z80 Routines|CRC32]]

== Notes from the author ==

I (84plusfreak) made this routine on-calc.
If you find an error, please tell me (serninpc at gmail dot com).

== Memory Usage ==

These routines use RAM that is also used by the built-in MD5 routines.

The code takes 149 bytes in your program.

== The code ==

=== CRC32Init ===

CRC32Init:
;Inputs:
; A=0 -> Use 'default' Polynomial (the one used in the ZIP Format)
; A=1 -> Use custom Polynomial
; -> DEHL=Polynomial
;Outputs:
; ($8292)=Polynomial
; ($8296)=Current CRC (~($8296)=CRC32)
;Destroys:
; AF,DE,HL
or a
jr nz,$+08
ld de,$EDB8
ld hl,$8320
ld a,d
ld d,e
ld e,a
ld a,h
ld h,l
ld l,a
ld ($8292),de
ld ($8294),hl
ld hl,$FFFF
ld ($8296),hl
ld ($8298),hl
ret

=== CRC32Update ===

CRC32Update:
;Inputs:
; HL -> Points to data
; BC -> Number of bytes
;Outputs:
; ($8296) = Updated
;Destroys:
; AF,BC,DE,HL
ld a,b
or c
ret z
push hl
push bc
ld b,(hl)
call CRC32Update_Routine
pop bc
pop hl
inc hl
dec bc
jr CRC32Update
CRC32Update_OneByte:
;Inputs:
; A = Byte to add to CRC
;Destroys:
; AF,BC,DE,HL
ld b,a
CRC32Update_Routine:
ld a,($8296)
xor b
call CRC32TableLookup
ld a,($8297)
xor l
ld ($8296),a
ld a,($8298)
xor h
ld ($8297),a
ld a,($8299)
xor e
ld ($8298),a
ld a,d
ld ($8299),a
ret
CRC32TableLookup:
ld de,$0000
ld h,d
ld l,a
ld b,8
CRC32TableLookupLoop:
push bc
or a
rr d
rr e
rr h
rr l
jr nc,CRC32TableLookupLoopEnd
push hl
pop bc
ld hl,$8292
ld a,d
xor (hl)
inc hl
ld d,a
ld a,e
xor (hl)
inc hl
ld e,a
ld a,b
xor (hl)
inc hl
ld b,a
ld a,c
xor (hl)
ld c,a
push bc
pop hl
CRC32TableLookupLoopEnd:
pop bc
djnz CRC32TableLookupLoop
ret

=== CRC32Finalize ===

CRC32Finalize:
;Inputs:
; None
;Outputs:
; DEHL = CRC32
;Destroys:
; AF,BC,DE,HL
ld de,($8298)
ld bc,($8296)
ld hl,$FFFF
push hl
or a
sbc hl,bc
ex (sp),hl
sbc hl,de
ex de,hl
pop hl
ret

Category:Z80 Routines:Security

2006-05-16T09:53:37Z

84plusfreak:

[[Category:Z80 Routines|Security Routines]]
This is the list of all routines related to security (e.g. hash, encryption) in WikiTI.

Z80 Routines:Security:CRC32

2006-05-16T09:52:19Z

84plusfreak: wikified

[[Category:Z80 Routines:Security|CRC32]][[Category:Z80 Routines|CRC32]]

== Notes from the author ==

I (84plusfreak) made this routine on-calc.
If you find an error, please tell me (serninpc at gmail dot com).

== The code ==

=== CRC32Init ===

CRC32Init:
;Inputs:
; A=0 -> Use 'default' Polynomial (the one used in the ZIP Format)
; A=1 -> Use custom Polynomial
; -> DEHL=Polynomial
;Outputs:
; ($8292)=Polynomial
; ($8296)=Current CRC (~($8296)=CRC32)
;Destroys:
; AF,DE,HL
or a
jr nz,$+08
ld de,$EDB8
ld hl,$8320
ld a,d
ld d,e
ld e,a
ld a,h
ld h,l
ld l,a
ld ($8292),de
ld ($8294),hl
ld hl,$FFFF
ld ($8296),hl
ld ($8298),hl
ret

=== CRC32Update ===

CRC32Update:
;Inputs:
; HL -> Points to data
; BC -> Number of bytes
;Outputs:
; ($8296) = Updated
;Destroys:
; AF,BC,DE,HL
ld a,b
or c
ret z
push hl
push bc
ld b,(hl)
call CRC32Update_Routine
pop bc
pop hl
inc hl
dec bc
jr CRC32Update
CRC32Update_OneByte:
;Inputs:
; A = Byte to add to CRC
;Destroys:
; AF,BC,DE,HL
ld b,a
CRC32Update_Routine:
ld a,($8296)
xor b
call CRC32TableLookup
ld a,($8297)
xor l
ld ($8296),a
ld a,($8298)
xor h
ld ($8297),a
ld a,($8299)
xor e
ld ($8298),a
ld a,d
ld ($8299),a
ret
CRC32TableLookup:
ld de,$0000
ld h,d
ld l,a
ld b,8
CRC32TableLookupLoop:
push bc
or a
rr d
rr e
rr h
rr l
jr nc,CRC32TableLookupLoopEnd
push hl
pop bc
ld hl,$8292
ld a,d
xor (hl)
inc hl
ld d,a
ld a,e
xor (hl)
inc hl
ld e,a
ld a,b
xor (hl)
inc hl
ld b,a
ld a,c
xor (hl)
ld c,a
push bc
pop hl
CRC32TableLookupLoopEnd:
pop bc
djnz CRC32TableLookupLoop
ret

=== CRC32Finalize ===

CRC32Finalize:
;Inputs:
; None
;Outputs:
; DEHL = CRC32
;Destroys:
; AF,BC,DE,HL
ld de,($8298)
ld bc,($8296)
ld hl,$FFFF
push hl
or a
sbc hl,bc
ex (sp),hl
sbc hl,de
ex de,hl
pop hl
ret

Z80 Routines:Security:CRC32

2006-05-16T09:50:11Z

84plusfreak:

[[Category:Z80 Routines:Security|CRC32]][[Category:Z80 Routines|CRC32]]
I (84plusfreak) made this routine on-calc.
If you find an error, please tell me (serninpc at gmail dot com).

==CRC32Init==

CRC32Init:
;Inputs:
; A=0 -> Use 'default' Polynomial (the one used in the ZIP Format)
; A=1 -> Use custom Polynomial
; -> DEHL=Polynomial
;Outputs:
; ($8292)=Polynomial
; ($8296)=Current CRC (~($8296)=CRC32)
;Destroys:
; AF,DE,HL
or a
jr nz,$+08
ld de,$EDB8
ld hl,$8320
ld a,d
ld d,e
ld e,a
ld a,h
ld h,l
ld l,a
ld ($8292),de
ld ($8294),hl
ld hl,$FFFF
ld ($8296),hl
ld ($8298),hl
ret

==CRC32Update==

CRC32Update:
;Inputs:
; HL -> Points to data
; BC -> Number of bytes
;Outputs:
; ($8296) = Updated
;Destroys:
; AF,BC,DE,HL
ld a,b
or c
ret z
push hl
push bc
ld b,(hl)
call CRC32Update_Routine
pop bc
pop hl
inc hl
dec bc
jr CRC32Update
CRC32Update_OneByte:
;Inputs:
; A = Byte to add to CRC
;Destroys:
; AF,BC,DE,HL
ld b,a
CRC32Update_Routine:
ld a,($8296)
xor b
call CRC32TableLookup
ld a,($8297)
xor l
ld ($8296),a
ld a,($8298)
xor h
ld ($8297),a
ld a,($8299)
xor e
ld ($8298),a
ld a,d
ld ($8299),a
ret
CRC32TableLookup:
ld de,$0000
ld h,d
ld l,a
ld b,8
CRC32TableLookupLoop:
push bc
or a
rr d
rr e
rr h
rr l
jr nc,CRC32TableLookupLoopEnd
push hl
pop bc
ld hl,$8292
ld a,d
xor (hl)
inc hl
ld d,a
ld a,e
xor (hl)
inc hl
ld e,a
ld a,b
xor (hl)
inc hl
ld b,a
ld a,c
xor (hl)
ld c,a
push bc
pop hl
CRC32TableLookupLoopEnd:
pop bc
djnz CRC32TableLookupLoop
ret

==CRC32Finalize==

CRC32Finalize:
;Inputs:
; None
;Outputs:
; DEHL = CRC32
;Destroys:
; AF,BC,DE,HL
ld de,($8298)
ld bc,($8296)
ld hl,$FFFF
push hl
or a
sbc hl,bc
ex (sp),hl
sbc hl,de
ex de,hl
pop hl
ret

83Plus:BCALLs:4522

2006-05-09T07:59:08Z

84plusfreak: /* Example */

[[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 ==
ld hl,str
ld de,OP1
ld bc,17
ldir
ld hl,OP1
B_CALL WPutSEOL
ret
str: db "TextTextTextText",0

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

Talk:83Plus:BCALLs:4522

2006-05-06T12:50:09Z

84plusfreak:

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)

Talk:83Plus:BCALLs:4522

2006-05-06T12:49:56Z

84plusfreak:

User talk:Dan Englender

2005-11-02T14:20:04Z

84plusfreak: /* USB Mouse */

Hi, I'm Dan.

== Page 0 Calls -> Maybe we could create a new section? ==

Hi Dan,

I made a page about page 0 calls. (like CALL 2EEE)

Maybe you could create a new section for it?

It seems to be a source of much functions.

Thanks for your time.

Sernin van de Krol

---[[User:84plusfreak|84plusfreak]] 09:01, 7 Jun 2005 (PDT)
: Discussion moved [[Talk:83Plus:OS:Page_0_Calls|here]] --[[User:Dan Englender|Dan Englender]] 15:15, 7 Jun 2005 (PDT)

== USB Mouse ==

Can I have that App? And the instructions for connecting the mouse? ---[[User:84plusfreak|84plusfreak]] 05:22, 28 Jun 2005 (PDT)

:The app as currently written is not very useful for anything other than a mouse demo or reading standard descriptors. Source will be up soon though, once I clean it up and start working on a driver layer. As for connecting the mouse, you just need to get some sort of adaptor or cable with a mini-A plug on one end, and a standard A female on the other end. I'm using the Gold-X Quick Connect 5 in 1 set, but I think there are other options on the market too. --[[User:Dan Englender|Dan Englender]] 13:49, 28 Jun 2005 (PDT)

:: Wal*mart has a universal cable for $15. --[[User:AndyJ|AndyJ]] 14:54, 28 Jun 2005 (PDT)

::: I live in The Netherlands, so the Wal*mart is a little bit too far away. ;-) --[[User:84plusfreak|84plusfreak]] 06:20, 2 Nov 2005 (PST)

To whoever felt to need to add my last name to my user page: *shrug*
:yeah... User pages should only be edited by the user to whom it belongs.... [[User:AndyJ|Andy Janata]] 18:02, 31 Oct 2005 (PST)

User:84plusfreak

2005-10-12T15:12:23Z

84plusfreak: /* Added website */

I'm Sernin van de Krol.

I live in The Netherlands.

The timezone is GMT+01:00 and we have DST.

I've got a TI-83+SE and a TI-84+SE.

If you've got programs that have to be converted from BASIC to ASM/APP send me an email.

My email is: [mailto:serninpc@gmail.com serninpc@gmail.com]

My website is: [http://www.sernin.net/ www.sernin.net]

User talk:84plusfreak

2005-09-26T07:25:10Z

84plusfreak:

User:213.132.169.38

2005-09-23T08:03:13Z

84plusfreak:

Computer at my school --[[User:84plusfreak|84plusfreak]] 01:03, 23 Sep 2005 (PDT)

User:84plusfreak

2005-09-10T09:07:08Z

84plusfreak: Added my timezone

83Plus:OS:How BCALLs work

2005-09-10T09:05:36Z

84plusfreak: Added category

[[Category:83Plus:OS_Information|How BCALLs work]]
Sorry, this article isn't very well written. It would be good if someone else could maybe look at the TI-OS code a bit and explain this better.

BCALLs are the way to call TI-OS ROM routines, and also the way that the branch table works in multi-page apps. A BCALL is the RST 28h instruction, with a 16-bit number after it which is used to identify which routine it is calling.

If the first bit (bit 15) of the number is set, this is what the OS does:

*It resets bit 15
*It adds 0x4000 to the number
*It maps page 1F/3F/7F* into memory space 4000-7FFF

Otherwise, if bit 15 is reset and bit 14 is set, this is what the OS does:

*It resets bit 14
*It adds 0x4000 to the number
*It maps page 1B/3B/7B** into memory space 4000-7FFF

Otherwise, if bit 15 and 14 are both reset, it is treated as a multipage app branch, which is explained in the TI developer's guide.

Once the OS has mapped the appropriate page into 4000-7FFF, it uses the number in memory as a pointer into this page. In page 1B and 1F there are lists of vectors for the actual ROM routines. The vectors are 3 bytes, the first two bytes are a memory address and the next byte is the page that the routine is on.

<nowiki>*1F for the TI-83 Plus, 3F for the TI-84 Plus and 7F for the TI-83 Plus Silver Edition & the TI-84 Plus Silver Edition.</nowiki><br>
<nowiki>**1B for the TI-83 Plus, 3B for the TI-84 Plus and 7B for the TI-83 Plus Silver Edition & the TI-84 Plus Silver Edition.</nowiki>

83Plus:OS:How BCALLs work

2005-09-10T09:03:36Z

84plusfreak: Added page numbers for 84+ & SE

Sorry, this article isn't very well written. It would be good if someone else could maybe look at the TI-OS code a bit and explain this better.

BCALLs are the way to call TI-OS ROM routines, and also the way that the branch table works in multi-page apps. A BCALL is the RST 28h instruction, with a 16-bit number after it which is used to identify which routine it is calling.

If the first bit (bit 15) of the number is set, this is what the OS does:

*It resets bit 15
*It adds 0x4000 to the number
*It maps page 1F/3F/7F* into memory space 4000-7FFF

Otherwise, if bit 15 is reset and bit 14 is set, this is what the OS does:

*It resets bit 14
*It adds 0x4000 to the number
*It maps page 1B/3B/7B** into memory space 4000-7FFF

Otherwise, if bit 15 and 14 are both reset, it is treated as a multipage app branch, which is explained in the TI developer's guide.

Once the OS has mapped the appropriate page into 4000-7FFF, it uses the number in memory as a pointer into this page. In page 1B and 1F there are lists of vectors for the actual ROM routines. The vectors are 3 bytes, the first two bytes are a memory address and the next byte is the page that the routine is on.

<nowiki>*1F for the TI-83 Plus, 3F for the TI-84 Plus and 7F for the TI-83 Plus Silver Edition & the TI-84 Plus Silver Edition.</nowiki><br>
<nowiki>**1B for the TI-83 Plus, 3B for the TI-84 Plus and 7B for the TI-83 Plus Silver Edition & the TI-84 Plus Silver Edition.</nowiki>

83Plus:OS:84 Plus USB Information

2005-07-01T12:28:32Z

84plusfreak: /* Port 5B */ typo

:I moved this page from Talk:83Plus:BCALLs:5254 to here because it seems to fit better. Please note that this is still a work in progress, and don't take the information as gold. I figured having an option for a Talk page for this would outweigh the moving of it. For the time being, we'll leave the data formatted as-is, since it's still nicely done. --[[User:AndyJ|AndyJ]] 07:44, 27 May 2005 (PDT)

OK, I've started this talk page to post information about the 84 Plus USB. This isn't the ideal place, since not all of this stuff has to do with entry point 5254, but it'll have to do. If anyone else would like to contribute any information or thoughts, please do so. Much of this data has been discovered by analyzing how the EasyData application interacts with the EasyTemp probe. --[[User:Dan Englender|Dan Englender]] 22:32, 23 May 2005 (PDT)

== Easy Data ==
The USB entry points that Easy Data uses are:
5254
5257
525A
525D
5260

These routines return carry flag with an error code in A on failure, or no carry on success. On success they return BC=(9C16), DE=(9C1A), and HL=(9C18). 9C16 = Vendor ID. 9C18 = Device ID. 9C1A = ????.

The entry points seem to be called only on initialization and quit. On initialization 5254 then 525D are called, and then 525A six times. On quit, 5254, then 5260, then 5257 are called.

=== 5254 BCALL ===
The 5254 entry point seems to take a callback address to be passed in A (page) and HL (address). That callback address appears to be called on quit, after 5257 is called.

=== 5260 and 5257 BCALLs ===
The 5260 and 5257 entry points are called right after each other in the code, and don't seem to take any input. I guess they're some kind of USB shut down. 5260 doesn't do much of anything other than set 9C1E to 0000. 5257 plays with the ports some, and then clears the callback address. Since the call back address gets called, I'm assuming it must also call the callback address somewhere in there.

=== 525A BCALL ===
525A takes a pointer to a structure in HL. 9C1C will be set to the structure pointer. Some checks on port 4C and 8F are done at teh beginning of this call. A data segment of value: 21 09 0002 0000 0800 will be sent through the control data port. This cooresponds to Host to Device's endpoint, vendor type, set configuration.

=== 525D BCALL ===
525D takes a pointer to a structure in HL. The 525D entry point first checks to see if bit 3 of port 4C and bits 0 and 2 of port 8F are set. If they are not, it returns failure. These bits are not set by, say, plugging in the hardware. They are set, however, after 5254 has been called. After checking these bits, 9C1E is set to the passed structure pointer. If this value is zero, the routine will return failure. A value of 1 will be stored to HL+2, then a value of 1 will be output to port 8E, a value of 20h to port 94h, and success will be returned.

=== 5290 BCALL ===
A BCALL to 5290 alone is enough to turn on the LED on EasyTemp. (Though it turns on to a strange orange color which is never seen during EasyData execution). It must do some sort of USB initialization type stuff. If bit 3,(iy+41) is set, 5290 will fail. So this must either be a USB-already-initialized flag, or a Don't-Use-USB flag I guess.

This BCALL appears to do the following:
# Do stuff
# Request the device descriptor with a maximum size of 8 bytes.
# Issue a Set Address Request, with an address of 2
# Request the device descriptor again, this time with a 18 byte maximum data size.
# Check device description for an appropriate TI or Vernier device and quit if not found.
# Do stuff

Why are there two device descriptor requests? Presumably so that the calculator can check the peripheral's max packet size (which is in the first 8 bytes), so that it will know how to segmentize further traffic.

=== 5293 BCALL ===
This BCALL is enough to to turn the LED off on EasyTemp. It's called by 5260.

=== Other ===

The callback routine appears to recieve some kind of input in B. I'm not sure what yet.

I'm, err, not exactly clear at this point how the app actually gets the temperature data from the EasyTemp probe, as the entry point seem to only be called on init and quit. The callback routine seemed a likely candidate, but it's not that either. Maybe there's something going on in the interrupt that I'm not aware of. Or maybe there are some more entry points used that I missed. ------- I'm now pretty sure that EasyData gets data through the 9C1E structure's callback which I believe returns data retrieved from an interrupt transfer in the OS's interrupt.

EasyData is automatically started when you plug the EasyTemp into the USB port if: The current app is Home Screen, a program is not currently executing, and EasyTemp is loaded on the calculator. EasyTemp is searched for via the app header table below.

==4087 Header==
The calculator knows to run EasyData when the Probe is plugged in because it includes a special header at address 4087h.
The format is as follows:
<nowiki> db 096h, 0E2h, 00h, 01h
dw TablePtr
.....
TablePtr:
dw 1, TableEntryType, DataPtr
.....
DataPtr: ;This is the EasyData data
db 03h, 80h, 03h, 00h, 0F7h, 08h, 02h, 00h
db 80h, 03h, 00h, 0F7h, 08h, 03h, 00h
db 80h, 03h, 00h, 0F7h, 08h, 04h, 00h
db 00h, 00h</nowiki>
In theory, the Table should be terminated with a 0000 word. It does not appear that EasyData does this.

=== Header Table Entries ===
The TableEntryType value can be one of the follow:
*1 - This type is checked for in what seems to be unused OS code. There's a string "IsDevice" that is used in conjunction with it. Perhaps it's an unimplemented feature, or perhaps it's debug code that's not active in the release OS. Your guess is as good as mine.
*2 - This is for the library functions used by OpenLib and ExecLib
*3 - This is for the USB auto-launch, as used by EasyData

=== USB Data Table ===
If the TableEntryType is 3, then the data will be USB data and will be formatted as follows: The first byte will be the number of entries in the USB data table. Then, each entry, starts with a byte. Not sure what that is. Then comes a word. Not really sure what that is either. But weird things happen if the high byte is not 00. And it appears that if the low byte is 01, only the vendor ID will be checked, if it's 03, the vendor ID and the product ID will be checked. If it's something else, well, something else happens. if the low byte was 03, then the next word will be the vendor ID, and the following word will be the product ID. If both of these match a connected USB device, then the app will launch.

=== FindSpecialAppHeader BCALL ===
The 50EF BCALL reads the 4087 Header. It is used by the OS. Returns SCF on failure, NC on success. On success, returns in HL the read table value. App name in OP1. Input DE is passed as the table entry to look for. Input A holds whether to look at certain app, or all apps. A = 0 means start at the first app, and search until you find an app with the appropriate header. A = 1 means start searching after the app in OP1. This would be used after the first success returned by A=0, to search the entire app list. A=2 means search only the app named in OP1.

=== 5263 BCALL ===
The 5263 BCALL reads the 4087 Header. it is used by the OS. This appears to be very similar to the above entry point, except that it searches all the pages by number, instead of searching by name. Input DE = header type to find. Output C on failure, NC on success. HL = table entry value. (appSearchPage) = page it was found on. This only finds the first instance of the header type.

=== 5266 BCALL ===
This allows you to continue a search you started with the 5263 BCALL. Input page in B.

=== 5269 BCALL ===
The 5269 BCALL is used by the OS after determining that an app with the USB special app header exists. In general, this entry point seems to compare the values in the USB app header data table with the values at 9C16, 9C18, and 9C1A. Some kind of ID I guess? In specific, it's actually very convoluted and strange code. Input is HL -> data table, A = page.

== Hardware ==
Ports 55h and 56h are initially polled in the interrupt routine to determine USB activity. If activity is detected, 4Dh, 82h, 84h, 86h, 8Fh, 91h, and others may be polled as well.

=== Port 4C ===
Some sort of status port. Values of 1A or 5A and 12 or 52 mean something. Default value is 22. Some of the host routines make sure bit 3 is set.

=== Port 4D ===
Some sort of status port. Bit 4 is set if a type A cable is plugged in. The high nibble appears to be A if nothing is plugged in, and 6 while connected to the computer. The port is checked bit-wise, but I haven't quite figured out how the rest of the bits function yet. I'm as yet unsure whether the values of this port are set based on external events alone, or also influenced by stuff going on in the interrupt. Will check with interrupts disabled later. There is a routine that is called when the bit 1 port 56 event occurs which first waits for bit 6,4D to be reset (which seems like the standard condition after a peripheral has been plugged in). It then does some outputs to ports 3A, 39, 4C, and 8F; after which it waits for bit 6,4D to be set (which seems like the standard condition after a peripheral has been initialized). This doesn't exactly clarify what bit 6 actually means though.

=== Port 55 ===
This port determines whether there's USB activity for the interrupt routine to take notice of. If any of the first five bits of the port are reset, that means something's happening in USB land.
*bit 0 - Not sure. Only seems to happen with peripheral.
*bit 1 - ???? (not checked by OS)
*bit 2 - Check port 56 for details on what event has happened
*bit 3 - ???? (not checked by OS)
*bit 4 - Data waiting? Or read for data? Or something like this.

=== Port 56 ===
The default value for port 56h is 00. If bit 2 of port 55 is reset in the interrupt routine, this port should be checked to see what event occured. Each set bit indicates a particular event:
* bit 0 - I've seen this bit set while playing around, but the OS doesn't use it.
* bit 1 - Something to do with peripheral initialization?
* bit 2 - ??
* bit 3 - ??
* bit 4 - Plug-in, calc-as-host
* bit 5 - Unplug, calc-as-host
* bit 6 - Plug-in, calc-as-peripheral
* bit 7 - Unplug, calc-as-peripheral

=== Port 5B ===
Used a lot in initialization type code, this output port takes either a value of 0 or 1. Wish I had a clue what it was for.

=== Port 80 ===
This input/output port holds the address for the device. Valid both when acting as peripheral and when acting as host. (Though the calculator always assigns address 2 when acting as host.)

=== Port 82 ===
Bit 0 might get set to indicate that the previously sent instruction from port 91h is complete/done, or something along those lines. Reading this port a background port monitor messes up USB connections, so reading the port probably resets it.

=== Port 86 ===
Some sort of status port. Seems to generally hold a value of 0. Bits 5 or 7 being set seems to be an error condition. Other bits may or may not be error conditions, though it's beginning to look like they'll all errors or abort-conditions of some kind.

=== Port 87 ===
It's not clear to me what this port is, specifically. However, outputting a value of F7h appears to imply that calculator-as-peripheral has an address. FF has no address.

=== Port 8C ===
The low byte of the 15-bit frame counter. It is automatically incremented. I haven't timed it, but in theory it should be incremented about once per millisecond.

=== Port 8D ===
The high byte of the 15-bit frame counter. See port 8C.

=== Port 8E ===
This input/output port designates current endpoint to read from/transfer to. Can be 0-15.

=== Port 8F ===
Values of 1 or 3 are outputted to this port. I have no clue what they mean. After USB init, on read, it seems to be some sort of status. Bit 2 being set appears to imply calculator-as-host, reset seems to imply calculator-as-peripheral.

=== Port 91 ===
This output port seems to send some kind of command to the USB controller. Port 82h seems to indicate when the command is ready. Output values from host and/or peripheral:
*02 - Wants to send data packet previously outputed via port A0, but there are more packets to come (<- Not correct. They may not be more packets. Not sure of details.) (periph)
*0A - Wants to send the data packet previously outputted via port A0.(host/periph)
*20 - Wants to read a data packet for port A0 (send an in packet). (host)
*40 - Done reading data on port A0. (send an ack?) (periph)
*42 - Done reading data on port A0. (Send an ack?) (host)
*48 - Done reading data on port A0. (send an ack?) (periph)
*60 - No data to send. (Send NAK?) (host/periph)
On read, bits 2 or 4 being set indicate an error state. Bit 2 might be NAK specifically.

=== Port 93 ===
This might setup the max packet size for interrupt and bulk pipes.

=== Port 94 ===
Seems to indicate, among other things, whether there's data ready to be read from port A1.

=== Port 98 ===
If the description of port 9A is even remotely right, then this port has a good chance of being the same thing, but for outgoing pipes.

=== Port 99 ===
While I'm making things up, if ports 98, 9A, and 9B are all correct, then maybe this is the interrupt interval for setup of outgoing interrupt pipes and 9B is incoming interrupt pipes. *shrug*

=== Port 9A ===
OK, this is quite a strech, long shot, guess, etc; but here are some possibilities for this port: This might set up incoming pipes. The high nibble might define the type of pipe. 2 would be bulk, and 3 would be interrupt. That might make 1 isochronous, but I'm not going to go there. The low nibble might be which pipe to map the current endpoint to. This cooresponds to the port in the AX range. So 21 would map an incoming bulk pipe to port A1h. Or, that could all be completely nonsense.

=== Port 9B ===
This might setup the poll interval for an interrupt endpoint. Or it might not. Just a thought.

=== Port A0 ===
I believe this is a/the data input/output port. Control transfer port?

=== Port A1 ===
Unhappily, there appears to be multiple data I/O ports. This is another. Interrupt transfer port?

=== Port A2 ===
Port A2 has decided to join the club of data I/O ports. Bulk transfer port? (Shot in the dark...)

== RAM ==
=== 9C13/9C14 ===
9C13 is the page, and 9C14 is the address of a callback routine. It is set by the 5254 BCALL, and called at various times. I'm not really sure what the callback routine is for yet.

=== 9C16 ===
This is where the vendor ID is stored. It is populated by at least the 5290 BCALL, and perhaps others.

=== 9C18 ===
This is where the product ID is stored. It is populated by at least the 5290 BCALL, and perhaps others.

=== 9C1A ===
This is where the device release number is stored. It is populated by at least the 5290 BCALL, and perhaps others.

=== 9C1C ===
A pointer to another structure. Similar to 9C1E. Output control transfers?

=== 9C1E ===
A pointer to some sort of structure. First word of structure is a pointer to some sort of receive buffer. Reads from port A1 may be stored here. Perhaps for interrupt transfers? Offset 2 of structure is a byte value. Offset 3 of structure is a callback page and address

=== 9C26 ===
Byte value representing device state (calc as peripheral)
*0 = Device in default state
*1 = Device in addressed state
*2 = Device in configured state

=== 9C27 ===
Another byte denoting something about the current state or operation. A value of 1 might imply a host->periph communication and a value of 2 might imply a periph->host communication.

=== 9C28 ===
Some kind of value denoting either the current state or current operation. The 5290 reoutine initially sets this to 1, though may later change the value. Is used to determine a lot of conditional code in various routines, especially stuff going on in the interrupt.

=== 9C29 ===
This is an 8 byte output buffer

=== 9C31 ===
This is an input buffer of undetermined length. Possibly 64 bytes.

=== 9C75 ===
A flag byte of some sort. Bits 5, 6, and 7 appear to be used. Bit 6 reset might indicate that an 84P is connected as a peripheral, set might indicate a Vernier (or perhaps "other") peripheral. Bit seven set might indicate that a Set Address request was just received.

=== 9C77 ===
Used by the OS to hold the offset in the descriptor table of the descriptor to return.

=== 9C78 ===
Used by the OS to keep track of how many bytes it needs to send for USB device request replies.

== Flags ==
Flag byte 41 appears to be the main USB flag. Bit 0 of byte 43 is also used for something related.

=== 2,(iy+40) ===
If this flag is set, the 82/83 page set might be used for data storage when reading from port A2.

=== 0,(iy+41) ===
If this flag is set, it will cause a certain part of USB code to abort. This is the code that is called from the interrupt routine when port 55h is 0Fh, and port 56h is 00h. This flag is set in an odd piece of code that loops around an output to port 0A2h. It reads the data to output, however, from RAM pages 02h and 03h. Will have to look into in more detail later.

=== 2,(iy+41) ===
This flag is set after loading the values of 9C16, 9C18, and 9C1A. But then it's reset if the VID/PID is 0451, E00F. *shrug* In BCALL 5254, it is reset after the bcall to 5290. This bit is checked in Mon, I think.

=== 3,(iy+41) ===
If this is set the BCALL 5290 will immediately terminate. Set in Init if device is E00F. At end of init, if flag is set, screen will turn on and be refreshed.

=== 5,(iy+41) ===
Reset somewhere in USB code. Not sure what it is. This bit is checked in Mon, I think.

=== 6,(iy+41) ===
Reset somewhere in USB code. Not sure what it is.

=== 7,(iy+41) ===
Reset somewhere in USB code. Not sure what it is.

== 84 as peripheral USB device requests ==
This section describes the various USB commands that the calculator, acting as a peripheral, will accept. If the calculator receives commands that are not defined below, or if one of the checks designated as "makes sure" fails, it will set 9C84 to FF, and send a value of 60 out endpoint 0. NAK? Stall?

=== Host to Device @ Device (0) ===
These are commands in the host to device direction, with the device (as opposed to endpoint or interface) as the recipient.

==== Clear Feature (1) ====
When it receives a 0, 1 Clear Feature command, the calculator first makes sure that an address has been set (9C26 != 0). It also makes sure that the rest of the USB packet is not all zeros, for whatever reason. If processing is completed successfully, a value of 48 will be sent out port 91. WValues accepted as follows:
*1 - According to the USB spec this is Device Remote Wakeup. Sets 9C76 to 0.
*3 - Undefined according to USB spec, but this acts the same as 0,1,1 above.
*5 - Undefined according to USB spec, this makes sure 9C74 is zero, sets 9C73 to zero, and 9C75 to 1.

==== Set Feature (3) ====
When it receives a 3 Set Feature command, the calculator checks that the rest of the packet is not all zeros. It accepts the following wValues:
*1 - As per USB Spec, Sets Device Remote Wakeup. Sets 9C76 to 2
*3 - Sets 9C73 to 1.
*4 - Sets 9C74 to 1.
*5 - Makes sure 9C74 is 0, and then sets 9C73 to 0 and 9C75 to 1.

==== Set Address (5) ====
Sets 9C86 to FF. Sets 9C71 to the received address value. (This will later be loaded to port 80). Sets bit 7 of 9C75 (which will indicate later to load the value to port 80). Outputs a value of 1 to port 5B. Outputs a value of 7F to port 87.

==== Set Configuration (9) ====
Makes sure the device is currently in the address or configured states. Accepts wValues as follows:
* 0 - This will return the device to the address state. Sets 9C26 appropriatly and then outputs 1 to port 5B and FF to port 87.
* 1 - Sets the calculator configuration 1, setting 9C26 appropriatly. Sets endpoint (8E) to 1, outputs 8 to port 90, 48 to port 91, 0 to port 92, 8 to port 93, 90 to port 94, and 0 to port 95. Then sets endpoint to 2, and repeats port outputs.

=== Host to Device @ Endpoint (2) ===

==== Clear Feature (1) ====
Clear halt?

==== Set Feature (3) ====
Set halt?

=== Device @ Device to Host (80) ===

==== Get Status (0) ====
Makes sure device is not in the default state. Makes sure packet data is not all zero (possibly with TIOS bug). Makes sure wLength is 2. If 9C76 is 2, responds with two bytes at offset of D5 from descriptor table. Otherwise responds with offset D6. The data seems to be 0,0 either way.

==== Get Descriptor (6) ====
Returns the requested descriptor. This is complicated. I'll fill in the details later.

==== Get Configuration (8) ====
Makes sure packet isn't all zeros. Makes sure wLength is 1. If currently in address state, returns 00. Otherwise returns 01.

=== Device @ Interface to Host (81) ===

==== Get Status (0) ====
Makes sure the device is not in the default state. Makes sure packet is not all zeros. Makes sure wIndex is 0 and wLength is 2. Responds with 0,0.

==== Get Interface(A) ====
I'm pretty sure this code is buggy, as it make sure that the device is in the default state, when it ought to be in the configured state. Anyway, after making sure of that and making sure wIndex and wLength are 1, it returns 0.

=== Device @ Endpoint to Host (82) ===

==== Get Status (0) ====
Details later...

== In Other News ==

=== Stuff ===
* At some point, TI checks for USB devices VID: 045A, PID: E003, E008, and E00F. It seems to return "ok" on E008 and E003, and error on E00F. E008 is the 84P SE. E003 is the 84P. No clue what E00F is. Perhaps the Viewscreen connector?
* I have successfully connected my calculator and digital camera, and retrieved the Product ID and Vendor ID from the camera. Yay :)
* The EasyTemp is an HID device. Haven't figured out the protocol yet.
* For the ever curious: if you have both the serial and USB links connected, the calculator will choose to use the USB link.
* I don't know exactly how much current the calculator can provide, but it can definitely provide enough to power an optical mouse. I managed to turn the mouse on from the calculator, and everything seemed to work fine.

=== Port Monitor ===
I've written a [http://wikiti.denglend.net/stuff/portmon.8xk Port Monitor] that's been useful for figuring out what some of the ports do. It may be useful for others, but it's not extensively tested, so beware. "Setup Hook" records port data through the USB hook. "Setup Int" records data through an IM2 interrupt (will only take a new sample if a port in the requested range has changed). "Disable Mon" will Stop either the interrupt or hook monitor. "Exec Code" allows you to execute a BCALL or hex code, presumably while one of the monitors is running. Exec program isn't implemented yet. "View Data" allows you to view all the data by sample. "View Changes" allows you to view the data by port, only showing ports that had data changes. In future revisions I may add more monitor triggers through other hooks. Oh, it doesn't read from ports 82 or A0, as these will cause problems with USB activity. The interrupt doesn't read from ports 8C or 8D because these are just counter ports and throw off the sampling.

=== Mouse ===
So, I've successfully written an HID Mouse driver. One that, amazingly enough, actually works, with both corded and wireless optical mice. Video proof for disbelievers: [http://wikiti.denglend.net/stuff/mouse.avi mouse.avi (7MB)]. Source code will be going on SourceForge sometime in the near future.

=== USB Protocol ===
This PC<->calc (and presumably calc<->calc) USB protocol is different than the serial protocol. The first word is always 0000. The next word is, MSB first, the size of the packet minus 5.
A data packet of 05E000 seems to be an ack packet and can be sent in either direction.

=== Presentation Link ===
The presentation link, conjectured to be the E00F device (and E00E for the 89 version) appears to request 16 byte packets? If someone can get ahold of one of these to confirm that, it would be wonderful.

[[Category:83Plus:OS_Information|84 Plus USB Information]]

83Plus:Ports:68

2005-07-01T12:19:02Z

84plusfreak:

#REDIRECT [[83Plus:Ports:45]]

This port is a mirror of port 48.

83Plus:Ports:67

2005-07-01T12:18:37Z

84plusfreak:

#REDIRECT [[83Plus:Ports:45]]

This port is a mirror of port 47.

83Plus:Ports:66

2005-07-01T12:18:19Z

84plusfreak:

#REDIRECT [[83Plus:Ports:45]]

This port is a mirror of port 46.

83Plus:Ports:65

2005-07-01T12:18:01Z

84plusfreak:

#REDIRECT [[83Plus:Ports:45]]

This port is a mirror of port 45.

83Plus:Ports:64

2005-07-01T12:17:37Z

84plusfreak:

#REDIRECT [[83Plus:Ports:41]]

This port is a mirror of port 44.

83Plus:Ports:63

2005-07-01T12:17:24Z

84plusfreak:

#REDIRECT [[83Plus:Ports:41]]

This port is a mirror of port 43.

83Plus:Ports:62

2005-07-01T12:17:06Z

84plusfreak:

#REDIRECT [[83Plus:Ports:41]]

83Plus:Ports:62

2005-07-01T12:16:54Z

84plusfreak:

#REDIRECT [[83Plus:Ports:42]]

This port is a mirror of port 42.

83Plus:Ports:61

2005-07-01T12:16:41Z

84plusfreak:

#REDIRECT [[83Plus:Ports:41]]

This port is a mirror of port 41.

83Plus:Ports:60

2005-07-01T12:15:33Z

84plusfreak:

#REDIRECT [[83Plus:Ports:40]]

This port is a mirror of port 40.

User talk:Dan Englender

2005-06-28T12:22:37Z

84plusfreak: USB Mouse

83Plus:Flags:33

2005-06-20T12:22:35Z

84plusfreak: /* Bit 0 */ fixed link text

[[Category:83Plus:Flags:By Address|33]]
[[Category:83Plus:Flags:By Name|sysHookFlg0]]
== Synopsis ==
'''Flag Byte:''' 33h

'''Known Names:''' sysHookFlg0

== Bit Overview ==

=== Bit 0 ===
'''Unofficial Name:''' Run ONSCRPT

You must also set [[83Plus:Flags:08|4,(iy+8)]] to run ONSCRPT.

=== Bit 1 ===
'''Unofficial Name:''' Run OFFSCRPT

=== Bit 2 ===
'''Unofficial Name:''' External recall queue

If this bit is set, the recall queue is in "external" mode. In this mode, data is read from an external RAM area, as opposed to "internal" recall mode, in which data is read directly from the buffer gap. See [[83Plus:OS:Recall_Queue|OS Recall Queue]] for more information.

=== Bit 3 ===
'''Unofficial Name:''' Link Activity Hook Override

If this flag is set, the [[83Plus:Hooks:9B78|Link Activity Hook]] is disabled.
If this flag is reset, the [[83Plus:Hooks:9B78|Link Activity Hook]] is enabled or disabled depending on the Active Flag (bit 4).

=== Bit 4 ===
'''Unofficial Name:''' Link Activity Hook Active

If this flag is reset, the [[83Plus:Hooks:9B78|Link Activity Hook]] is disabled
If this flag is set, the [[83Plus:Hooks:9B78|Link Activity Hook]] is enabled or disabled depending on the Override Flag (bit 3).

=== Bit 5 ===
{{Unknown-flag}}

=== Bit 6 ===
{{Unknown-flag}}

=== Bit 7 ===
{{Unknown-flag}}

83Plus:Flags:33

2005-06-20T12:21:17Z

84plusfreak: /* Bit Overview */ bit 0

[[Category:83Plus:Flags:By Address|33]]
[[Category:83Plus:Flags:By Name|sysHookFlg0]]
== Synopsis ==
'''Flag Byte:''' 33h

'''Known Names:''' sysHookFlg0

== Bit Overview ==

=== Bit 0 ===
'''Unofficial Name:''' Run ONSCRPT

You must also set [[83Plus:Flags:08]] to run ONSCRPT.

=== Bit 1 ===
'''Unofficial Name:''' Run OFFSCRPT

=== Bit 2 ===
'''Unofficial Name:''' External recall queue

If this bit is set, the recall queue is in "external" mode. In this mode, data is read from an external RAM area, as opposed to "internal" recall mode, in which data is read directly from the buffer gap. See [[83Plus:OS:Recall_Queue|OS Recall Queue]] for more information.

=== Bit 3 ===
'''Unofficial Name:''' Link Activity Hook Override

If this flag is set, the [[83Plus:Hooks:9B78|Link Activity Hook]] is disabled.
If this flag is reset, the [[83Plus:Hooks:9B78|Link Activity Hook]] is enabled or disabled depending on the Active Flag (bit 4).

=== Bit 4 ===
'''Unofficial Name:''' Link Activity Hook Active

If this flag is reset, the [[83Plus:Hooks:9B78|Link Activity Hook]] is disabled
If this flag is set, the [[83Plus:Hooks:9B78|Link Activity Hook]] is enabled or disabled depending on the Override Flag (bit 3).

=== Bit 5 ===
{{Unknown-flag}}

=== Bit 6 ===
{{Unknown-flag}}

=== Bit 7 ===
{{Unknown-flag}}

83Plus:OS:Recall Queue

2005-06-17T12:47:54Z

84plusfreak: PRGM Editor Warning

[[Category:83Plus:OS Information|OS Recall Queue]]
''Recall Queue''

The recall queue can be used to output on the homescreen after quitting an application or inside an hook. The tokens will be inserted as soon as the homescreen becomes visible and editable for the user. If this is used in the program editor the OS crashes.

Here's how it works:
*Copy the data you want tios to recall into a saferam area that isn't erased before you return to the home screen. The data should be in the same form as they would be in a program (eg t3,tdecpt,t1,t4)
*Put the location of the first byte of data in [[83Plus:RAM:86D9|rclQueue]]. You need to add one to this value if you use it inside a keyhook(I didn't test any other hooks but I guess this also applies to them) Thus if you would copy the data to appbackupscreen the code would be the following (outside a keyhook):
<nowiki>ld hl,appbackupscreen
ld (rclQueue),hl</nowiki>
*Put the location of the last byte of data +1 in 86DBh. Thus if you would copy the data to appbackupscreen and the data would be two bytes large, the code would be the following:
<nowiki>ld hl,appbackupscreen+2 ;+1 is the location of the last byte
ld (86DBh),hl</nowiki>
*Now you only have to set the following two flags and return/bjump back to tios.
<nowiki>set 7,(IY+0Eh)
set 2,(IY+33h)</nowiki>

83Plus:Flags:33

2005-06-17T12:44:24Z

84plusfreak:

[[Category:83Plus:Flags:By Address|33]]
[[Category:83Plus:Flags:By Name|sysHookFlg0]]
== Synopsis ==
'''Flag Byte:''' 01h

'''Known Names:''' sysHookFlg0

== Bit Overview ==

=== Bit 0 ===
'''Unofficial Name:''' Run ONSCRPT

=== Bit 1 ===
'''Unofficial Name:''' Run OFFSCRPT

=== Bit 2 ===
'''Unofficial Name:''' Recall queue waiting

If this bit is set, there's data in the [[83Plus:OS:Recall_Queue|OS Recall Queue]].

=== Bit 3 ===
'''Unofficial Name:''' Link Activity Hook Override

If this flag is set, the [[83Plus:Hooks:9B78|Link Activity Hook]] is disabled.
If this flag is reset, the [[83Plus:Hooks:9B78|Link Activity Hook]] is enabled or disabled depending on the Active Flag (bit 4).

=== Bit 4 ===
'''Unofficial Name:''' Link Activity Hook Active

If this flag is reset, the [[83Plus:Hooks:9B78|Link Activity Hook]] is disabled
If this flag is set, the [[83Plus:Hooks:9B78|Link Activity Hook]] is enabled or disabled depending on the Override Flag (bit 3).

=== Bit 5 ===
{{Unknown-flag}}

=== Bit 6 ===
{{Unknown-flag}}

=== Bit 7 ===
{{Unknown-flag}}

83Plus:OS:Small Edit Buffers

2005-06-17T12:34:22Z

84plusfreak: _SmallEditCxPutaway

[[Category:83Plus:OS Information|Small Edit Buffers]]
The TI-OS offers a number of undocumented B_CALLs and B_JUMPs that allow for input to be performed using the small font. Perhaps the best example of these functions is TI's Conics app, which uses them for inputting the variables for the relations. You can use the small edit routines for either one-line input (which scrolls left to right), or multi-line input (which will scroll up/down, wrapping text like on the homescreen.)

The following entry points are used with the small editing routines:

<nowiki>_InitSmallEditBox EQU 4CDBh
_InitSmallEditBoxOP1 EQU 4D38h
_InitSmallEditBoxVar EQU 4D35h
_InitSmallEditLine EQU 4CA5h
_InitSmallEditLineOP1 EQU 4D32h
_InitSmallEditLineVar EQU 4D2Fh
_ReleaseSEdit EQU 4CA2h
_SmallEditCxErrorEP EQU 4CC6h
_SmallEditCxMain EQU 4CABh
_SmallEditCxPPutaway EQU 4CC3h
_SmallEditCxPutaway EQU 4CC0h
_SmallEditCxRedisp EQU 4CBAh
_SmallEditCxSizeWind EQU 4D2Ch
_StartSmallEdit EQU 4CA8h
_StartSmallEditReturn EQU 4E1Fh</nowiki>

Customization of the small edit buffer occurs by setting up certain areas of the RAM, with their equates listed below. Interestingly, all of these equates fall between ramCode and ramCodeEnd.

<nowiki>SmallEditCancelParse EQU 8194h
SmallEditColumnLeft EQU 8177h
SmallEditColumnRight EQU 8179h
SmallEditRow EQU 8178h
SmallEditRowCount EQU 81B7h
SmallEditPromptString EQU 81CCh</nowiki>

To begin an edit session, you first must setup some of the settings in RAM. All of the small edit routines require the following to be set:

'''SmallEditCancelParse:''' Set to 03h if you do not want the small edit routines to parse the string typed, set to anything else for automatic parsing. This will be discussed later.

'''SmallEditColumnLeft:''' The leftmost column for the small edit buffer.

'''SmallEditColumnRight:''' The rightmost column. If the text would extend past this point, the edit routines will automatically handle scrolling.

'''SmallEditRow:''' The row (in pixels, from the top of the screen) for the first row of the edit buffer.

'''SmallEditPromptString:''' The string to display. This is analogous to the first string argument for the Input command in TI-BASIC. SmallEditPromptString should contain the length, in characters, and SmallEditPromptString + 1 should contain the actual string. If you don't want a string, simply set SmallEditPromptString to zero.

Also, if you are doing multi-line input ("box" input), then you must also set SmallEditRowCount, which is the number of rows to use for editing.

Once the various settings in RAM are setup, you must then B_CALL one of the Init entrypoints. There are six of them, with their names describing exactly what behaviors should occur, the format being _InitSmallEdit[Type][WhatToEdit]. Type is either line, which is for one line input, or Box, which does multi-line. WhatToEdit describes what should appear in the edit buffer by default. If WhatToEdit isn't there (either _InitSmallEditLine or _InitSmallEditBox), then the edit buffer is initially empty. If WhatToEdit is Var, the contents of the variable given in OP1 is used. If WhatToEdit is OP1, then OP1 is treated as a real and converted to a string, the resulting string then is placed in the edit buffer.

The following actions are taken by the _InitSmallEdit entry points:

* An edit buffer is opened on the "text_buf" equation, with the contents requested (if any) placed inside.
* The prompt string and contents of the edit buffer are displayed based on the settings in RAM and the form of InitSmallEdit called.
* Monitor vectors are installed to prepare for the editing. The previous monitor vectors are backed up. I believe appFlags is not touched.

Once the small edit buffer is open, you perform the actual editing by B_CALLing _StartSmallEdit. This entrypoint saves the return page / address combination for the B_CALL to RAM, and then passes control to Mon, and editing starts.

Editing is completed by pressing Enter or 2nd+Quit, and if you are doing line input, then also up or down. _StartSmallEdit returns with A being the key pressed that caused the edit session to complete. If you didn't disable parsing, parsing will occur (a system error is thrown if a parse error occurs), with OP1 (and maybe OP2 in the case of complex results) containing the result. Otherwise, OP1 contains the name of "text_buf", which is:

EquObj, 0

Notes about _StartSmallEdit:

* appBackUpScreen is used when backing up the image during a cxPPutAway for restoration during cxRedisp.
* Switching to other contexts (say by doing 2nd+Mem, 2) can cause unexpected behaviors. TI's Conics app uses a keyhook to disable various keys that open menus that contain problematic items (the memory, stat and program menus are blocked entirely, for example.)
* 2nd-Off also causes problems. Conics handles this by installing it's own monitor vectors, as mentioned later.
* If a parse error occurs, you can call this again to continue input, but it appears some internal states are messed up, so errors are always thrown (at least if we're asking it to parse for us.) If anyone can clear this up, tell me!

Once you are done with the edit buffer, B_CALL ReleaseSEdit. This closes the edit buffer, and restores the original monitor vectors. You must do this under all conditions.

There is an extra B_CALL _StartSmallEditReturn, which is a very odd and not very useful routine. When you B_CALL _StartSmallEdit, the top three items on the stack (placed there by the B_CALL routine itself) are popped off (and stored at 818Bh for the curious), and the SP is then saved (saved to 9D88h.) This is used so StartSmallEdit can actually return (the sp is restored, the values are pushed back, and the OS then does ret.) _StartSmallEditReturn basically restores the SP to what it was before you B_CALLed _StartSmallEdit. Incidently, this also changes the same pieces of RAM where _StartSmallEdit saved the return location, so if you were to call _StartSmallEditReturn in a hook (key hook for example), the edit session may continue, but when it's done, _StartSmallEdit will return to the op-code after where you B_CALLed _StartSmallEditReturn!

Notes about Conic's use of the small edit routines:

* A _GetKey hook is used for disabling various keys that open uneeded menus. Also, the softkeys are also implemented with this hook. If the user presses Graph for example, the hook sets an internal flag and changes the key to kEnter. This causes the small edit to finish (_StartSmallEdit returns), at which point the app then checks the internal flag to see if extra actions should be taken.
* Conics installs it's own monitor vectors before calling _StartSmallEdit (but after it calls one of the _InitSmallEdit routines.) This allows it to get putaway notification to cleanly handle 2nd+Off. It's cxMain, cxPPutaway and cxRedisp handlers simply B_JUMP to _SmallEditCxMain, _SmallEditCxPPutaway, and _SmallEditCxRedisp for handling. _SmallEditCxErrorEP an _SmallEditCxSizeWind can also be used for the same purpose. (thanks to mmartin for this info!) _SmallEditCxPutaway loads SP from 9D88h, pushes three saved items on the stack and does a ret. Which is the routine used to return in the _StartSmallEdit B_CALL.
* Conics parses text_buf manually by setting the SmallEditCancelParse byte, and then calling ParseInp with an error handler.

== Credits and Contributions ==
* '''mmartin:''' For helping figure out some of the extra B_JUMPs

83Plus:RAM:965B

2005-06-17T08:28:35Z

84plusfreak:

[[Category:83Plus:RAM:By_Name|basic_start]] [[Category:83Plus:RAM:By_Address|965B - basic_start]]
== Synopsis ==
'''Official Name:''' no official name, calling it basic_start for now

'''Memory Address:''' 965Bh

'''Length:''' 2 bytes.

This is the start address of the currently executing TI-Basic program.

== Comments ==

83Plus:OS:84 Plus USB Information

2005-06-15T11:20:43Z

84plusfreak: /* Stuff */ 'are' changed to 'is'

Talk:83Plus:OS:Page 0 Calls

2005-06-08T10:37:57Z

84plusfreak:

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)

:::The 84-Plus has different offsets. ---[[User:84plusfreak|84plusfreak]] 03:37, 8 Jun 2005 (PDT)

Talk:83Plus:OS:Page 0 Calls

2005-06-08T10:37:40Z

84plusfreak:

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)

The 84-Plus has different offsets. ---[[User:84plusfreak|84plusfreak]] 03:37, 8 Jun 2005 (PDT)

User talk:Dan Englender

2005-06-07T16:01:03Z

84plusfreak: Page 0 Calls -> Maybe we could create a new section?

83Plus:OS:Page 0 Calls

2005-06-07T16:00:00Z

84plusfreak: Corrected pages

[[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.

83Plus:OS:Page 0 Calls

2005-06-07T15:57:26Z

84plusfreak: Added category

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

The address of the first page 0 call is saved at 44FB on page 1F,3F or 7F. (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 1F/3F/7F 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.

83Plus:OS:Page 0 Calls

2005-06-07T15:56:36Z

84plusfreak: Page 0 Calls -> Maybe we could create a new section?

The address of the first page 0 call is saved at 44FB on page 1F,3F or 7F. (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 1F/3F/7F 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.