WikiTI - User contributions [en]

84PCE:Syscalls:00035C

2020-09-11T21:22:19Z

MateoConLechuga: Created page with "Sha256Init 00035C - Sha256Init == Synopsis == '''Hypothesized Official Name:''' Sha256Init '''Sysca..."

[[Category:84PCE:Syscalls:By Name|Sha256Init]]
[[Category:84PCE:Syscalls:By Address|00035C - Sha256Init]]
== Synopsis ==
'''Hypothesized Official Name:''' Sha256Init

'''Syscall Address:''' 00035Ch

Initializes the SHA256 hardware.

=== Inputs ===
* None

=== Outputs ===
* None

=== Registers Destroyed ===
* Assume all

84PCE:OS:Applications

2020-09-11T20:43:45Z

MateoConLechuga: /* Application File Type */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag

[Bit 0 - Disable TI splash screen]
[Bit 1 - App can use OpenLib]

00Eh = Flag

[Bit 0 - Use offset 01Eh for languages]
[Bit 1 - Integrated app]
[Bit 2 - Unknown]
[Bits 3-5 control something]

012h = Main section

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset used in Language apps (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Reserved word

02Ah = Start of relocation table

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

The relocation map consists of a six-byte entry for each location which needs to be updated.

{| class="wikitable"
|-
! Offset
! Length
! Contents
|-
| 000h
| 003h
| Hole offset
|-
| 003h
| 003h
| base (2 bits) and relative value to place in hole (22 bits)
|}

----

'''Relocation Map Format'''

The hole offset specifies where in the application code or initial data table an absolute address needs to be updated.
The value to store in the hole is calculated from the base and relative value. The base is 00 for code-segment relative and 10 for data-segment relative. Base values 01 and 11 are reserved.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
.org cursorImage
ExecuteApp_Start:
ld de,progToEdit
ld bc,8
ldir
ld a,cxExtApps
jp _NewContext

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2018-10-27T01:07:15Z

MateoConLechuga: /* Relocations */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

You can find code for creating an application; along with other fancy items [https://github.com/mateoconlechuga/app-inc here]

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag

[Bit 0 - Disable TI splash screen]
[Bit 1 - App can use OpenLib]

00Eh = Flag

[Bit 0 - Use offset 01Eh for languages]
[Bit 1 - Integrated app]
[Bit 2 - Unknown]
[Bits 3-5 control something]

012h = Main section

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset used in Language apps (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Reserved word

02Ah = Start of relocation table

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

The relocation map consists of a six-byte entry for each location which needs to be updated.

{| class="wikitable"
|-
! Offset
! Length
! Contents
|-
| 000h
| 003h
| Hole offset
|-
| 003h
| 003h
| base (2 bits) and relative value to place in hole (22 bits)
|}

----

'''Relocation Map Format'''

The hole offset specifies where in the application code or initial data table an absolute address needs to be updated.
The value to store in the hole is calculated from the base and relative value. The base is 00 for code-segment relative and 10 for data-segment relative. Base values 01 and 11 are reserved.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
.org cursorImage
ExecuteApp_Start:
ld de,progToEdit
ld bc,8
ldir
ld a,cxExtApps
jp _NewContext

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Certificate

2017-10-18T23:26:43Z

MateoConLechuga: /* Certificate Overview */

[[Category:84PCE:OS_Information]]
==Certificate Overview==
The certificate is a critical region of flash memory which holds information that should persist across reboots and resets. It can be entirely cleared and reset; as is demonstrated by the bootcode itself. The following discusses particular fields and structures contained within the certificate.

84PCE:OS:Certificate

2017-10-18T23:26:23Z

MateoConLechuga: Created page with "Category:84PCE:OS_Information ==Certificate Overview== The certificate is a critical region of flash memory which stores critical information that should persist across re..."

[[Category:84PCE:OS_Information]]
==Certificate Overview==
The certificate is a critical region of flash memory which stores critical information that should persist across reboots and resets. It can be entirely cleared and reset; as is demonstrated by the bootcode itself. The following discusses particular fields and structures contained within the certificate.

84PCE:OS:Applications

2017-10-16T06:27:07Z

MateoConLechuga: /* Additional App Structure */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

You can find code for creating an application; along with other fancy items [https://github.com/mateoconlechuga/app-inc here]

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag

[Bit 0 - Disable TI splash screen]
[Bit 1 - App can use OpenLib]

00Eh = Flag

[Bit 0 - Use offset 01Eh for languages]
[Bit 1 - Integrated app]
[Bit 2 - Unknown]
[Bits 3-5 control something]

012h = Main section

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset used in Language apps (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Reserved word

02Ah = Start of relocation table

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

The relocation map consists of a six-byte entry for each location which needs to be updated.

{| class="wikitable"
|-
! Offset
! Length
! Contents
|-
| 000h
| 003h
| Hole offset
|-
| 003h
| 003h
| base (2 bits) and relative value to place in hole (22 bits)
|}

----

'''Relocation Map Format'''

The hole offset specifies where in the application code or initial data table an absolute address needs to be updated.
The value to store in the hole is calculated from the base and relative value. The base is 00 for code-segment relative and 10 for data-segment relative. Base values 01 and 11 are reserved.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
.org cursorImage
ExecuteApp_Start:
ld de,progToEdit
ld bc,8
ldir
ld a,cxExtApps
jp _NewContext

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-10-14T05:14:27Z

MateoConLechuga: /* Example */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

You can find code for creating an application; along with other fancy items [https://github.com/mateoconlechuga/app-inc here]

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh] [Bit 3 controls something]

012h = Main section

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Reserved word

02Ah = Start of relocation table

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

The relocation map consists of a six-byte entry for each location which needs to be updated.

{| class="wikitable"
|-
! Offset
! Length
! Contents
|-
| 000h
| 003h
| Hole offset
|-
| 003h
| 003h
| base (2 bits) and relative value to place in hole (22 bits)
|}

----

'''Relocation Map Format'''

The hole offset specifies where in the application code or initial data table an absolute address needs to be updated.
The value to store in the hole is calculated from the base and relative value. The base is 00 for code-segment relative and 10 for data-segment relative. Base values 01 and 11 are reserved.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
.org cursorImage
ExecuteApp_Start:
ld de,progToEdit
ld bc,8
ldir
ld a,cxExtApps
jp _NewContext

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-10-08T12:04:05Z

MateoConLechuga:

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

You can find code for creating an application; along with other fancy items [https://github.com/mateoconlechuga/app-inc here]

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh] [Bit 3 controls something]

012h = Main section

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Reserved word

02Ah = Start of relocation table

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

The relocation map consists of a six-byte entry for each location which needs to be updated.

{| class="wikitable"
|-
! Offset
! Length
! Contents
|-
| 000h
| 003h
| Hole offset
|-
| 003h
| 003h
| base (2 bits) and relative value to place in hole (22 bits)
|}

----

'''Relocation Map Format'''

The hole offset specifies where in the application code or initial data table an absolute address needs to be updated.
The value to store in the hole is calculated from the base and relative value. The base is 00 for code-segment relative and 10 for data-segment relative. Base values 01 and 11 are reserved.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

83PCE:Hooks:D0260E

2017-10-08T04:19:56Z

MateoConLechuga:

[[Category:83PCE:Hooks:By_Name|Token Hook]] [[Category:83PCE:Hooks:By_Address|D0260E - Token Hook]]
== Synopsis ==
'''Name:''' Token Hook

'''Hook Pointer Block Address:''' D0260E

'''Hook Enable BCALL:''' 0213F8

'''Hook Disable BCALL:''' 0213FC

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

'''Hook Active Flag:''' [[83Plus:Flags:35#Bit_0|0, (iy + 35h)]]

This hook allows you to change the strings displayed for TIOS tokens. It is called every time the OS is about to display a one- or 2-byte token.

== Using the Hook ==
* DE = token number * 3 (DEU = 0)
** 1-byte: 0000 to 02FD
** Matrix: 0300 to 031B
** List: 031E to 032D
** Equation: 0330 to 038A
** Picture: 038D to 03A8
** GDB: 03AB to 03C6
** String: 03C9 to 03E4
** Statistics: 03E7 to 049B
** Window/finance: 049E to 0546
** Graph format: 0549 to 057F
** Miscellaneous: 0582 to 0861
** Extra tokens: 0864 to *
* HL points to the default string
** Change HL to display another string. The format of that string should be:
<keypress of token>,<length string>,"string"

84PCE:OS:Applications

2017-10-02T06:41:09Z

MateoConLechuga: /* Relocations */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh] [Bit 3 controls something]

012h = Main section

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Reserved word

02Ah = Start of relocation table

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

The relocation map consists of a six-byte entry for each location which needs to be updated.

{| class="wikitable"
|-
! Offset
! Length
! Contents
|-
| 000h
| 003h
| Hole offset
|-
| 003h
| 003h
| base (2 bits) and relative value to place in hole (22 bits)
|}

----

'''Relocation Map Format'''

The hole offset specifies where in the application code or initial data table an absolute address needs to be updated.
The value to store in the hole is calculated from the base and relative value. The base is 00 for code-segment relative and 10 for data-segment relative. Base values 01 and 11 are reserved.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-10-02T06:37:03Z

MateoConLechuga: /* Additional App Structure */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh] [Bit 3 controls something]

012h = Main section

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Reserved word

02Ah = Start of relocation table

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-10-02T04:54:32Z

MateoConLechuga: /* Additional App Structure */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh] [Bit 3 controls something]

012h = Main section

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Relocation information or something?

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-10-02T04:51:35Z

MateoConLechuga: /* Additional App Structure */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh] [Bit 3 controls something]

012h = Main section (this also points to the end of the relocations table)

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Relocation information or something?

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-10-02T03:41:53Z

MateoConLechuga: /* Additional App Structure */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh] [Bit 3 controls something]

012h = Main section (this also points to the end of the relocations table)

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Offset to relocation information

02Ah = If no relocations this location should be what 012h offsets to

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-10-02T03:06:07Z

MateoConLechuga:

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh]

012h = Main section (this also points to the end of the relocations table)

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Offset to relocation information

02Ah = If no relocations this location should be what 012h offsets to

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-10-02T03:01:22Z

MateoConLechuga:

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh]

012h = Main section (this also points to the end of the relocations table)

015h = Initialized data section (Can be at most 4kB in size)

018h = Initialized data section Length

01Bh = Execution entry point

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset to ExecLib jump table

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Relocation information (Not an offset, relocation information starts here)

02Ah = If no relocations this location should be what 012h offsets to

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-09-30T16:33:47Z

MateoConLechuga: /* ExecLib */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh]

012h = Offset to main code block section (this also points to the end of the relocations table)

015h = Offset to the initialized data section which should be copied to ram (Can be at most 4kB in size)

018h = Length of the initialized data section

01Bh = Offset to the execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset used for ExecLib

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Offset to perhaps the start of data to be relocated?

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the jump table offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-09-30T16:33:20Z

MateoConLechuga: /* ExecLib */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh]

012h = Offset to main code block section (this also points to the end of the relocations table)

015h = Offset to the initialized data section which should be copied to ram (Can be at most 4kB in size)

018h = Length of the initialized data section

01Bh = Offset to the execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset used for ExecLib

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Offset to perhaps the start of data to be relocated?

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.

2. Initialize offset 021h to the start of the library jump table

3. Ensure that the offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:OS:Applications

2017-09-30T16:33:06Z

MateoConLechuga: /* Additional App Structure */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh]

012h = Offset to main code block section (this also points to the end of the relocations table)

015h = Offset to the initialized data section which should be copied to ram (Can be at most 4kB in size)

018h = Length of the initialized data section

01Bh = Offset to the execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset used for ExecLib

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Offset to perhaps the start of data to be relocated?

== ExecLib ==

In order to use ExecLib properly from BASIC programs, you must:

1. Set the proper bit at offset 00Ch.
2. Initialize offset 021h to the start of the library jump table
3. Ensure that the offsets are stored in the relocation table

The format for the jump table is shown below: (Note that you store AppLibraryTable offset to 021h).

<pre> .db "LIB"
.dl NUMBER_OF_FUNCTIONS_IN_JUMP_TABLE
AppLibraryTable:
.dl Function_1
.dl Function_2
...</pre>

== Relocations ==

Because apps are not stored at a fixed memory address, they require a relocation table to relocate them during sending and defragmentation.

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:Syscalls:021320

2017-09-26T01:54:03Z

MateoConLechuga:

[[Category:84PCE:Syscalls:By Name|GetStringInput]]
[[Category:84PCE:Syscalls:By Address|021320 - GetStringInput]]
== Synopsis ==
'''Hypothesized Official Name:''' GetStringInput

'''Syscall Address:''' 021320h

Gets a string of input from the user, much like the common 'Input' command used in TI-Basic programs. This system call does not return until after the user presses enter, but allows for use of all OS menus and input variations, including the Alpha and 2nd Keys special abilities. It works by creating a temporary equation which it then makes the edit buffer. It can also display an optional prompt for the user, in order to be more user friendly. Note that when using this routine, the system monitor completely takes over, so it will act exactly as it does in TI-Basic programs, which may have unintended side effects. It is highly recommended you call [[84PCE:Syscalls:021578|DeleteTempEditEqu]] once you are finished with your input parsing. It basically calls _NewContext with 50h, _Mon, then _NewContext with 3Fh.

=== Inputs ===
* [[84PCE:RAM:D00879|ioPrompt]] - Copy the optional prompt string here, or write a null byte for no prompt
* [[84PCE:RAM:D00595|curRow]],[[84PCE:RAM:D00596|curCol]] - Set to the appropriate values for the location where to display the prompt and input string
* [[84PCE:RAM:D00596|curUnder]] - This is the character that is first displayed under the cursor. You should set it to 0, unless you want something under the cursor
* '''NOTE:''' You must reset 6,(iy+28) and set 7,(iy+9) before calling this function!

=== Outputs ===
* [[84PCE:RAM:D0244E|editSym]] - Contains the VAT pointer to the temporary variable used for editing the input string. Can be used with [[84PCE:Syscalls:020AE8|VarNameToOP1HL]] to lookup the actual input data.

=== Destroys ===
* All

=== Example ===
call _ClrScrn
call _HomeUp ; clean up things
ld hl,inputPrompt
ld bc,inputPrompt_end-inputPrompt
ld de,ioPrompt
ldir ; copy the input prompt here
xor a,a
ld (curUnder),a
ld b,(iy+9)
ld c,(iy+28) ;back up old flag values
res 6,(iy+28)
set 7,(iy+9)
push bc
call _GetStringInput ; get the input from the user
pop bc
res 4,b ;restore old flag values
ld (iy+9),b
ld (iy+28),c
ld hl,(editSym)
call _VarNameToOP1HL ; lookup the temporary input symbol
call _ChkFindSym
jr c,SomeError
ex de,hl
call _LoadDEInd_s ; get the size of the the string
push de
pop bc
ld de,pixelshadow ; copy it to saferam
ldir
xor a,a
ld (de),a ; null terminate the string
SomeError:
call _DeleteTempEditEqu ; delete the temporary input
call _ClrScrn
jp _HomeUp ; clean up and leave

inputPrompt:
.db "Input:",0 ; Input prompt
inputPrompt_end:

84PCE:Syscalls:021320

2017-09-26T01:50:53Z

MateoConLechuga: /* Inputs */

[[Category:84PCE:Syscalls:By Name|GetStringInput]]
[[Category:84PCE:Syscalls:By Address|021320 - GetStringInput]]
== Synopsis ==
'''Hypothesized Official Name:''' GetStringInput

'''Syscall Address:''' 021320h

Gets a string of input from the user, much like the common 'Input' command used in TI-Basic programs. This system call does not return until after the user presses enter, but allows for use of all OS menus and input variations, including the Alpha and 2nd Keys special abilities. It works by creating a temporary equation which it then makes the edit buffer. It can also display an optional prompt for the user, in order to be more user friendly. Note that when using this routine, the system monitor completely takes over, so it will act exactly as it does in TI-Basic programs, which may have unintended side effects. It is highly recommended you call [[84PCE:Syscalls:021578|DeleteTempEditEqu]] once you are finished with your input parsing.

=== Inputs ===
* [[84PCE:RAM:D00879|ioPrompt]] - Copy the optional prompt string here, or write a null byte for no prompt
* [[84PCE:RAM:D00595|curRow]],[[84PCE:RAM:D00596|curCol]] - Set to the appropriate values for the location where to display the prompt and input string
* [[84PCE:RAM:D00596|curUnder]] - This is the character that is first displayed under the cursor. You should set it to 0, unless you want something under the cursor
* '''NOTE:''' You must reset 6,(iy+28) and set 7,(iy+9) before calling this function!

=== Outputs ===
* [[84PCE:RAM:D0244E|editSym]] - Contains the VAT pointer to the temporary variable used for editing the input string. Can be used with [[84PCE:Syscalls:020AE8|VarNameToOP1HL]] to lookup the actual input data.

=== Destroys ===
* All

=== Example ===
call _ClrScrn
call _HomeUp ; clean up things
ld hl,inputPrompt
ld bc,inputPrompt_end-inputPrompt
ld de,ioPrompt
ldir ; copy the input prompt here
xor a,a
ld (curUnder),a
call _GetStringInput ; get the input from the user
ld hl,(editSym)
call _VarNameToOP1HL ; lookup the temporary input symbol
call _ChkFindSym
jr c,SomeError
ex de,hl
call _LoadDEInd_s ; get the size of the the string
push de
pop bc
ld de,pixelshadow ; copy it to saferam
ldir
xor a,a
ld (de),a ; null terminate the string
SomeError:
call _DeleteTempEditEqu ; delete the temporary input
call _ClrScrn
jp _HomeUp ; clean up and leave

inputPrompt:
.db "Input:",0 ; Input prompt
inputPrompt_end:

83Plus:Ports:89

2017-09-24T21:31:52Z

MateoConLechuga: /* Synopsis */

[[Category:83Plus:Ports:By Address|89 - USB Input-Enabled Pipes]] [[Category:83Plus:Ports:By Name|USB Input-Enabled Pipes]]
{{84P-Only Port|01}}
== Synopsis ==
'''Port Number:''' 89h

'''Function:''' USB Input-Enabled Pipes

This port is a bitmap of which pipes in the A0h-A7h range are enabled for input. Similar to [[83Plus:Ports:8A|port 8A]].

=== Read Values ===
* Bit 0: Probably always 0. (Just a guess)
* Bit 1: Set if pipe 1 is enabled for input.
* Bit 2: Set if pipe 2 is enabled for input.
* Bit 3: Set if pipe 3 is enabled for input.
* Bit 4: Hypothetically, set if pipe 4 is enabled for input.
* Bit 5: Hypothetically, set if pipe 5 is enabled for input.
* Bit 6: Hypothetically, set if pipe 6 is enabled for input.
* Bit 7: Hypothetically, set if pipe 7 is enabled for input.

=== Write Values ===
* No effect

84PCE:Ports:0006

2017-08-06T18:07:32Z

MateoConLechuga: /* Details */

[[Category:84PCE:Ports:By_Address|0006 - Unknown]]
== Synopsis ==
'''Port Number:''' 0006

'''Function:''' Unknown

== Details ==

This port seems to affect the display refresh.

=== Bit [0] ===
Latches value written, no apparent effect.

=== Bit [1] ===
Reset this bit to disable display upadates.

=== Bit [2] ===
Set this bit to enable display updates if bit 1 is ever reset.

=== Bit [3] ===
Writes do not latch; no apparent effect.

=== Bit [4] ===
Flash lock status.

=== Bits [7:3] ===
Writes do not latch; no apparent effect.

84PCE:Ports:0002

2017-08-06T18:00:17Z

MateoConLechuga:

[[Category:84PCE:Ports:By_Address|0002 - Unknown]]
== Synopsis ==
'''Port Number:''' 0002

'''Function:''' Unknown

== Details ==

This port is read only; it appears to be based off of the battery level.

=== Bits [7:0] ===
Writes have no apparent effect, value does not latch.

84PCE:Ports:0000

2017-08-06T17:22:56Z

MateoConLechuga: /* Bit [6] */

[[Category:84PCE:Ports:By_Address|0000 - System Config]] [[Category:84PCE:Ports:By_Name|System Config]]
== Synopsis ==
'''Port Number:''' 0000

'''Function:''' Controls interrupt speed and power

=== Bits [1:0]: OS Timer Rate ===
This controls the rate of interrupt source 4, which seems to be some kind of timer. Changing this changes the cursor blink rate. It's probably some kind of interrupt speed. 11b is the slowest, 00b is the fastest. If this is anything like the timers on the Z80 models, its source is the 32768 Hz quartz crystal. A frequency table is below, along with probable divisors if this really is from the 32768 Hz crystal.
{|-
|Value   
|Rate (Hz)   
|Probable Divisor
|-
|00
|~442.81
|32768/74
|-
|01
|~212.78
|32768/154
|-
|02
|~150.31
|32768/218
|-
|03
|~104.36
|32768/314
|-
|}

=== Bits [3:2] ===
Writes have no apparent effect, value does not latch.

=== Bit [4] ===
Set this bit to crash. The bootcode uses this to crash when catching a non-maskable interrupt.

=== Bit [5] ===
Writes have no apparent effect, value does not latch.

=== Bit [6] ===
Set this bit to turn calc and screen off until next ON key. Value does not latch.

=== Bit [7] ===
Latches value written, no apparent effect. Used when reading battery status.

84PCE:Ports:0000

2017-08-06T17:14:21Z

MateoConLechuga: /* Bit [7] */

[[Category:84PCE:Ports:By_Address|0000 - System Config]] [[Category:84PCE:Ports:By_Name|System Config]]
== Synopsis ==
'''Port Number:''' 0000

'''Function:''' Controls interrupt speed and power

=== Bits [1:0]: OS Timer Rate ===
This controls the rate of interrupt source 4, which seems to be some kind of timer. Changing this changes the cursor blink rate. It's probably some kind of interrupt speed. 11b is the slowest, 00b is the fastest. If this is anything like the timers on the Z80 models, its source is the 32768 Hz quartz crystal. A frequency table is below, along with probable divisors if this really is from the 32768 Hz crystal.
{|-
|Value   
|Rate (Hz)   
|Probable Divisor
|-
|00
|~442.81
|32768/74
|-
|01
|~212.78
|32768/154
|-
|02
|~150.31
|32768/218
|-
|03
|~104.36
|32768/314
|-
|}

=== Bits [3:2] ===
Writes have no apparent effect, value does not latch.

=== Bit [4] ===
Set this bit to crash. The bootcode uses this to crash when catching a non-maskable interrupt.

=== Bit [5] ===
Writes have no apparent effect, value does not latch.

=== Bit [6] ===
Set this bit to turn calc and screen off until next ON key.

=== Bit [7] ===
Latches value written, no apparent effect. Used when reading battery status.

84PCE:OS:Applications

2017-08-06T11:45:53Z

MateoConLechuga: /* Applications in the Archive */

[[Category:84PCE:OS_Information]]
[[Category:84PCE:OS_Information]]
==Application File Type==
Applications for the CE calculator have the extension 8ek.

Relocations exist to place the app correctly in the archive, 6 bytes per block (2+22 bits):

0b00 indicates a reference to the code segment executing from Flash, and 0b10 indicates a reference to the data/bss segment in RAM.
0b01 and 0b11 are a reserved format;

Applications can be of arbitrary size, no longer multiples of 16kB.

==Applications in the Archive==
Applications are stored beginning at the address 03B0000h and grow downwards. 3 bytes are used as offsets to the start of the app, since the search is backwards. The following status bytes represent what might be found when parsing for applications:

081h = valid Flash application (part of the app header)

000h = deleted Flash application (part of the app header)

Some search code may look like this (Will locate the start of all the app headers):

_FindValidLocation:
ld hl,03B0000h ; applications start here
find:
dec hl
dec hl
dec hl
push hl
ld de,(hl)
ld hl,0FFFFFFh ; check for end
or a,a
sbc hl,de
pop hl
ret z ; found end of applications
or a,a
sbc hl,de ; hl points to the start of the app header here if found
jr find

The actual App header contains certain fields which correspond to the type of data they represent. TI dropped the ball and even though these are variable length fields, the OS code can only handle headers that are padded to 256 bytes in length.

810(F)h = Master field, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

811(2)h = Signing key ID. On the CE, this is 2 bytes in length with the value 0130Fh, indicating it was signed with the '130F' key.

812(D)h = Version information. Begins with the length of the version string, followed by the string itself. This is a minimum compatible version.

813(2)h = Unknown, but contains the 2 byte data 05900h.

814(N)h = Name of App. In this case, 'N' represents the length of the name in bytes. This field is then followed by the name of the app.

817(F)h = End app header information, 4 bytes in length, which contains the offset to the signature field. (Big Endian)

81A(1)h = Unknown, but contains the 1 byte data 007h

Other fields:

003h & 2(6)h & 009h & 0(4)h = Time stamp field. 4 bytes long; represents the number of seconds since January 1st 1997, 00:00:00 in some timezone, and some step of the build process.

00Dh & 0NNh = This (NN) represents how much padding until the next field, as app headers must be padded to 256 bytes.

002h & 03(E)h = Signature field. The is followed by the two bytes containing the value 0100h, the length of the 2048 bit signature

At the end of the signature is 3 bytes representing the size of the application. (These bytes are not included however)

App size calculation is as follows: [Length of master header + offset to signature field in (810)] + [4 bytes of signature field + 256 bytes of signature] + [3 bytes application size]

This is pretty much the same as adding 269 to the value in the big endian master field.

This is an example of such a header:

; Master Field -- This app is 102247 + 269 (102516) bytes in size
.db 081h, 00Fh, 000h, 001h, 08fh, 067h
; Signing Key Field
.db 081h, 012h, 013h, 00Fh
; Version information -- 00Bh represnets the length until the next field
.db 081h, 02Dh, 00Bh, "5.0.0.0089", 000h
; Unknown field
.db 081h, 032h, 059h, 000h
; Name Field -- Name is 7 bytes long, so that is where the 047h comes from
.db 081h, 047h, "CabriJr"
; Unknown field
.db 081h, 0A1h, 007h
; Time stamp -- Who knows what time is was?
.db 003h, 026h, 009h, 004h
.db 021h, 0BBh, 06Eh, 0DCh
; Amount of pading (This is so, so silly)
.db 000h, 00Dh, 0C7h
; Padding of 0C7h (199) bytes
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
.db 0,0,0,0,0,0,0
; Final field
.db 081h, 07Fh, 000h, 001h, 08Eh, 06dh
; End of 256 byte header

==Additional App Structure==

However, apps are also made up of a certain sequence of bytes following the header. Offsets are calculated from the posistion after the header, in addition to the offsets derived from offsets.

Offset after 256 byte header:

000h = The ASCII string "eZ8", potentially signifying an eZ80 application

003h = Null terminated Application name (zero padded to be 9 bytes in length with terminator byte)

00Ch = Flag, [Bit 0 set - don't draw the TI splash screen] [Bit 1 set - app can use OpenLib]

00Eh = Flag, [Bit 0 set - use the offset in 01Eh]

012h = Offset to main code block section (this also points to the end of the relocations table)

015h = Offset to the initialized data section which should be copied to ram (Can be at most 4kB in size)

018h = Length of the initialized data section

01Bh = Offset to the execution entry point (usually same as 012h)

01Eh = Unknown 3 byte offset (See 00Eh)

021h = Offset used for ExecLib

024h = Offset to the string used to display a message in the memory screen (Usually a copyright, i.e. "(c) 2005-2015 Texas Instruments")

027h = Offset to perhaps the start of data to be relocated?

==Example==

Here is a full demo program demonstrating finding each application, displaying the name, size, version, and copyright information
<pre>#include "ti84pce.inc"

.db tExtTok,tAsm84CECmp
.org usermem

;--------------------------------------------------------------------
; Finds all the apps and displays info
_FINDAPPS:
ld ix,0
add ix,sp
ld hl,ExecuteApp
ld de,cursorImage
ld bc,ExecuteApp_End-ExecuteApp_Start
ldir
call _ZeroOP3
ld a,appObj
ld (OP3),a
_: call _HomeUp
call _ClrScrn
call _OP3ToOP1
call _FindAppUp ; find the app
ret c
call _OP1ToOP3 ; store name
ld hl,OP1+1
push hl
call _PutS ; put name of app
pop hl ; don't need this push/pop (here for readability)
call _FindAppStart ; find the start of the app
push hl
call GetAppSize
call _DispHL ; display the size of the app
call _NewLine
pop hl
push hl
push hl
call _os_GetAppVersionString
pop bc
call _PutS
call _NewLine
pop hl
call FindAppInfoString ; Get the information
call _PutS
_: call _GetCSC
or a,a
jr z,-_
cp a,sk2nd
jr nz,--_
ld hl,OP3+1
jp cursorImage

;--------------------------------------------------------------------
ExecuteApp:
; HL -> name of app (0 terminated)
; An alternative would be to copy to progtoedit and call _NewConext0
.org cursorImage
ExecuteApp_Start:
push hl
call DeletePgrmFromUserMem
ld hl,$100
call _EnoughMem
pop hl
jp c, _ErrMemory
call _FindAppStart ; This locates the start of executable code for an app
ld a,E_Validation
jp c,_JError ; If we can't find it, that's a problem (throw a validation error)
push hl ; push location of start of app
call _ReloadAppEntryVecs
call _AppSetup
set appRunning,(iy+APIFlg) ; turn on apps
set 6,(iy+$28)
res 0,(iy+$2C) ; set some app flags
set appAllowContext,(iy+APIFlg) ; turn on apps
ld hl,$D1787C ; copy to ram data location
ld bc,$FFF
call _MemClear ; zero out the ram data section
pop hl ; hl -> start of app
push hl ; de -> start of code for app
ld bc,$100 ; bypass header information
add hl,bc
ex de,hl
ld hl,$18 ; find the start of the data to copy to ram
add hl,de
ld hl,(hl)
call __icmpzero ; initialize the bss if it exists
jr z,+_
push hl
pop bc
ld hl,$15
add hl,de
ld hl,(hl)
add hl,de
ld de,$D1787C ; copy it in
ldir
_: pop hl ; hl -> start of app
call FindStartOfAppCode ; After this, hl -> start of code for app
jp (hl)

;----------------------------------------------------------------------------
FindAppInfoString:
; Finds the information string about an App
; i.e. (c) 2005-2014 Texas Instruments
; Arguments:
; HL : contains start of app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$24
add hl,bc
ld hl,(hl) ; load location of info string
add hl,de
or a,a
sbc hl,de ; check if HL is 0
ret z
add hl,de ; add extra bytes
ret

;----------------------------------------------------------------------------
FindStartOfAppCode:
; Finds the start of the actual executable from the start of an App
; Arguments:
; HL : contains the start of the app address
ld bc,$100 ; bypass some header info
add hl,bc
push hl
pop de
ld bc,$1B ; offset
add hl,bc
ld hl,(hl)
add hl,de
ret

;----------------------------------------------------------------------------
DeletePgrmFromUserMem:
ld de,(asm_prgm_size) ; load total program prgmSize
or a,a
sbc hl,hl
ld (asm_prgm_size),hl ; delete whatever current program was there
ld hl,userMem
jp _DelMem ; HL->place to delete, DE=amount to delete

;----------------------------------------------------------------------------
GetAppSize:
; Gets the size of an app based from the start of the app
push hl
call _NextFieldFromType ; move to start of signature
call _NextFieldFromType ; move to end of signature
pop de
or a
sbc hl,de
inc hl
inc hl
inc hl ; bypass app size bytes
ret ; haha, we're probably looking at another app here
ExecuteApp_End:</pre>

==Credits and Contribution==
Matt "MateoConLechuga" Waltz

84PCE:Ports:Control

2017-08-06T11:37:33Z

MateoConLechuga:

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]
== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address. It is mirrored every 0x100 bytes.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

== Port Address Space ==

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0003|0003]]
|00
|Hardware ID
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM. Upon set, VRAM is garbage Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:001D|001D]]
|A7
|Privileged address
|-
|[[:84PCE:Ports:0020|0020]]
|7C
|Memory protection
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:Control

2017-08-06T11:33:58Z

MateoConLechuga: /* Port Address Space */

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]
== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

== Port Address Space ==

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0003|0003]]
|00
|Hardware ID
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM. Upon set, VRAM is garbage Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:001D|001D]]
|A7
|Privileged address
|-
|[[:84PCE:Ports:0020|0020]]
|7C
|Memory protection
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:Control

2017-08-06T11:32:22Z

MateoConLechuga: /* Port Address Space */

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]
== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

== Port Address Space ==

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0003|0003]]
|00
|Hardware ID
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:001D|001D]]
|A7
|Privileged address
|-
|[[:84PCE:Ports:0020|0020]]
|7C
|Memory protection
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:0028

2017-08-06T11:31:57Z

MateoConLechuga: Created page with "0028 - Unknown == Synopsis == '''Port Number:''' 0028 '''Function:''' Unknown == Details == This port's function is unknown. === Bit [0..."

[[Category:84PCE:Ports:By_Address|0028 - Unknown]]
== Synopsis ==
'''Port Number:''' 0028

'''Function:''' Unknown

== Details ==

This port's function is unknown.

=== Bit [0] ===
Latches value written, no apparent effect.

=== Bit [1] ===
Always 0, writes do not latch.

=== Bit [2] ===
Latches value written, no apparent effect.

=== Bits [7:3] ===
Writes do not latch, no apparent effect.

84PCE:Ports:Control

2017-08-06T11:26:19Z

MateoConLechuga:

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]
== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

== Port Address Space ==

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0003|0003]]
|00
|Hardware ID
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:001D|001D]]
|A7
|Privileged address
|-
|[[:84PCE:Ports:0020|0020]]
|7C
|Memory protection
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:Control

2017-08-06T11:25:58Z

MateoConLechuga:

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]

== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

== Port Address Space ==

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0003|0003]]
|00
|Hardware ID
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:001D|001D]]
|A7
|Privileged address
|-
|[[:84PCE:Ports:0020|0020]]
|7C
|Memory protection
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:Control

2017-08-06T11:12:58Z

MateoConLechuga: /* Synopsis */

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]

== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0003|0003]]
|00
|Hardware ID
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:Control

2017-08-06T11:12:48Z

MateoConLechuga: /* Synopsis */

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]

== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0003|0003]]
|
|Hardware ID
|00
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:Control

2017-08-06T11:12:36Z

MateoConLechuga: /* Synopsis */

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]

== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0003|0003]]
|
|Hardware ID
|00
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:Control

2017-08-06T11:11:54Z

MateoConLechuga: /* Synopsis */

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]

== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0003|0003]]
|
|Hardware ID
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:000B

2017-08-06T11:10:47Z

MateoConLechuga: Created page with "000B - Charging Status == Synopsis == '''Port Number:''' 000B '''Function:''' Charging Status == Details == This port is read only. ===..."

[[Category:84PCE:Ports:By_Address|000B - Charging Status]]
== Synopsis ==
'''Port Number:''' 000B

'''Function:''' Charging Status

== Details ==

This port is read only.

=== Bit [0] ===
Writes have no apparent effect, value does not latch.

=== Bit [1] ===
When connected to a power source and charging, this bit is set.

=== Bits [7:2] ===
Writes have no apparent effect, value does not latch.

84PCE:Ports:Control

2017-08-06T11:09:14Z

MateoConLechuga: /* Synopsis */

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]

== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000B|000B]]
|F8
|Charging Status
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:0000 Unknowns

2017-08-06T11:06:25Z

MateoConLechuga: Blanked the page

84PCE:Ports:Control

2017-08-06T11:06:05Z

MateoConLechuga:

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]

== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control important things; possibly the reason why it does not have a memory-mapped address.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:Control

2017-08-06T11:05:34Z

MateoConLechuga:

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]

== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control masters.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:Control

2017-08-06T11:05:15Z

MateoConLechuga: Created page with "Control Control == Synopsis == '''Port Number:''' 0000-0fff '''Function:''' Master Control This port ra..."

[[Category:84PCE:Ports:By_Address|Control]] [[Category:84PCE:Ports:By_Name|Control]]

== Synopsis ==
'''Port Number:''' 0000-0fff

'''Function:''' Master Control

This port range is used to configure and control different things.

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:0000 Unknowns

2017-08-06T10:58:06Z

MateoConLechuga: /* 0000 Range */

[[Category:84PCE:Ports:By_Address|0000 Unknowns]] [[Category:84PCE:Ports:By_Name|0000 Unknowns]] [[Category:84PCE:Ports:Unknown|0000 Unknowns]]

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

=== 0000 Range ===
{|-
|Port   
|Default   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:0000 Unknowns

2017-08-06T10:57:53Z

MateoConLechuga: /* 0000 Range */

[[Category:84PCE:Ports:By_Address|0000 Unknowns]] [[Category:84PCE:Ports:By_Name|0000 Unknowns]] [[Category:84PCE:Ports:Unknown|0000 Unknowns]]

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

=== 0000 Range ===
{|-
|Port   
|Default   
|Bits   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|Latches value written
|-
|[[:84PCE:Ports:000C|000C]]
|00
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:0000 Unknowns

2017-08-06T10:56:25Z

MateoConLechuga: /* 0000 Range */

[[Category:84PCE:Ports:By_Address|0000 Unknowns]] [[Category:84PCE:Ports:By_Name|0000 Unknowns]] [[Category:84PCE:Ports:Unknown|0000 Unknowns]]

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

=== 0000 Range ===
{|-
|Port   
|Default   
|Bits   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|D3
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|13
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|??
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|??
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|03?
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|FF
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|??
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|FD
|FF
|Latches value written
|-
|[[:84PCE:Ports:000C|000C]]
|00
|FF
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|FF
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|?3
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|??
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|FD
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|01
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|73
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|FF
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|FF
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|07
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|F1
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|31
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|3F
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|FF
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:0009

2017-08-06T10:53:49Z

MateoConLechuga: Created page with "0002 - Unknown == Synopsis == '''Port Number:''' 0002 '''Function:''' Unknown == Details == This port appears to be the power control...."

[[Category:84PCE:Ports:By_Address|0002 - Unknown]]
== Synopsis ==
'''Port Number:''' 0002

'''Function:''' Unknown

== Details ==

This port appears to be the power control.

=== Bits [1:0] ===
Latches value written, no apparent effect.

=== Bit [2] ===
Reset to disable screen. Setting after reset has no effect.

=== Bits [7:3] ===
Latches value written, no apparent effect.

84PCE:Ports:0000 Unknowns

2017-08-06T10:49:43Z

MateoConLechuga: /* 0000 Range */

[[Category:84PCE:Ports:By_Address|0000 Unknowns]] [[Category:84PCE:Ports:By_Name|0000 Unknowns]] [[Category:84PCE:Ports:Unknown|0000 Unknowns]]

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

=== 0000 Range ===
{|-
|Port   
|Default   
|Bits   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|D3
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|13
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|??
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|??
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|03?
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|FF
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|37
|??
|Power control system
|-
|[[:84PCE:Ports:000A|000A]]
|05
|??
|Latches value written, OS reset to 05
|-
|[[:84PCE:Ports:000B|000B]]
|FC
|??
|Cannot change value
|-
|[[:84PCE:Ports:000C|000C]]
|00
|FF
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|FF
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|?3
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|??
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|FD
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|01
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|73
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|FF
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|FF
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|07
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|F1
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|31
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|3F
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|FF
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:0000 Unknowns

2017-08-06T10:48:54Z

MateoConLechuga: /* 0000 Range */

[[Category:84PCE:Ports:By_Address|0000 Unknowns]] [[Category:84PCE:Ports:By_Name|0000 Unknowns]] [[Category:84PCE:Ports:Unknown|0000 Unknowns]]

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

=== 0000 Range ===
{|-
|Port   
|Default   
|Bits   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|D3
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|13
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|??
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|??
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|03?
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|FF
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|7F
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|
|??
|Appears to be a part of the power control system.
|-
|[[:84PCE:Ports:000A|000A]]
|05
|??
|Latches value written, OS reset to 05
|-
|[[:84PCE:Ports:000B|000B]]
|FC
|??
|Cannot change value
|-
|[[:84PCE:Ports:000C|000C]]
|00
|FF
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|FF
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|?3
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|??
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|FD
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|01
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|73
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|FF
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|FF
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|07
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|F1
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|31
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|3F
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|FF
|Ports 0036-0039 latch value written
|-
|}

84PCE:Ports:0000 Unknowns

2017-08-06T10:47:09Z

MateoConLechuga:

[[Category:84PCE:Ports:By_Address|0000 Unknowns]] [[Category:84PCE:Ports:By_Name|0000 Unknowns]] [[Category:84PCE:Ports:Unknown|0000 Unknowns]]

If a port is not listed; it indicates that writes have no effect and do not latch, and that reads are 0. Note that this may not be true one hundred percent.

=== 0000 Range ===
{|-
|Port   
|Default   
|Bits   
|Information   
|-
|[[:84PCE:Ports:0000|0000]]
|03
|D3
|CPU Speed Control
|-
|[[:84PCE:Ports:0001|0001]]
|03
|13
|OS Timer Control
|-
|[[:84PCE:Ports:0002|0002]]
|
|??
|Read only, value can change
|-
|[[:84PCE:Ports:0005|0005]]
|76
|??
|Set bit 5 to freeze, bit 6 affects backlight
|-
|[[:84PCE:Ports:0006|0006]]
|03
|03?
|Display refresh
|-
|[[:84PCE:Ports:0007|0007]]
|B7
|FF
|Latches values written
|-
|[[:84PCE:Ports:0008|0008]]
|7F
|??
|Cannot change value
|-
|[[:84PCE:Ports:0009|0009]]
|
|??
|Appears to be a part of the power control system.
|-
|[[:84PCE:Ports:000A|000A]]
|05
|??
|Latches value written, OS reset to 05
|-
|[[:84PCE:Ports:000B|000B]]
|FC
|??
|Cannot change value
|-
|[[:84PCE:Ports:000C|000C]]
|00
|FF
|Latches value written
|-
|[[:84PCE:Ports:000D|000D]]
|FF
|FF
|Bit 0: Freeze if reset Bit 1: Crash if reset Bit 2: No apparent effect if reset Bit 3: Reset to disable VRAM? Upon set, VRAM is garbage. Bits [7:4]Possibly last value written
|-
|[[:84PCE:Ports:000E|000E]]
|0A
|FF
|Latches value written
|-
|[[:84PCE:Ports:000F|000F]]
|42
|?3
|High nibble may be a status, low 2 bits latch value written
|-
|[[:84PCE:Ports:001C|001C]]
|80
|??
|Cannot change value
|-
|[[:84PCE:Ports:0028|0028]]
|
|FD
|Bit 1 is always 0, other bits latch value written
|-
|[[:84PCE:Ports:0029|0029]]
|00
|01
|Bit 0 latches value written
|-
|[[:84PCE:Ports:002A|002A]]
|70
|73
|Latches value written
|-
|[[:84PCE:Ports:002B|002B]]
|FE
|FF
|Latches value written
|-
|[[:84PCE:Ports:002C|002C]]
|
|FF
|Ports 002C-0031 latch value written
|-
|[[:84PCE:Ports:0032|0032]]
|
|07
|Latches value written
|-
|[[:84PCE:Ports:0033|0033]]
|
|F1
|Latches value written
|-
|[[:84PCE:Ports:0034|0034]]
|
|31
|Latches value written
|-
|[[:84PCE:Ports:0035|0035]]
|
|3F
|Latches value written
|-
|[[:84PCE:Ports:0036|0036]]
|
|FF
|Ports 0036-0039 latch value written
|-
|}