Difference between revisions of "84PCSE:OS:Applications"

From WikiTI
Jump to: navigation, search
(mention that TI's tools are still usage)
(Added download for .key file.)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category:84PCSE:OS_Information]]
 
[[Category:84PCSE:OS_Information]]
 +
''See also [[83Plus:OS:Certificate/Headers:Fields:Application_Headers|the page on TI-83+ series application headers]].''
 +
 +
The TI-84 Plus C SE is based on nearly-identical hardware and software. So it's no surprise that it supports applications, just like previous models. For the most part, application development is the same, although there are important differences.
 +
 +
= Creating an Application =
 +
 +
== App Header ==
 +
 
Creating an application for the TI-84 Plus C SE is just like creating an application for the TI-8x B&W series. Aside from all the changes to OS equates and hardware, the only thing you need to change is the signing key. Any TI-8x app will include the byte sequence 80120104; simply change this to 8012010F to specify that your application is signed with the TI-84+CSE key. Therefore, an example header might be:
 
Creating an application for the TI-84 Plus C SE is just like creating an application for the TI-8x B&W series. Aside from all the changes to OS equates and hardware, the only thing you need to change is the signing key. Any TI-8x app will include the byte sequence 80120104; simply change this to 8012010F to specify that your application is signed with the TI-84+CSE key. Therefore, an example header might be:
 
  <nowiki> ; Master Field
 
  <nowiki> ; Master Field
 
.db 80h, 0Fh, 0, 0, 0, 0
 
.db 80h, 0Fh, 0, 0, 0, 0
−
; Name
+
; Name. Note that the name field reads 80 46 because the name specified here is 6 characters long.
 
.db 80h, 46h, "My App"
 
.db 80h, 46h, "My App"
 
; Disable TI splash screen.
 
; Disable TI splash screen.
Line 26: Line 34:
 
call MySplashScreen</nowiki>
 
call MySplashScreen</nowiki>
  
−
Then, you need the actual TI-84+CSE 010F.key file to sign the application. This is the file:
+
== Key File ==
 +
 
 +
You need the actual TI-84+CSE 010F.key file to sign the application. This is the file:
 
  <nowiki>40A5269CCDFAD4ACBE816B6C6ED00B984B08E34A3172F504C58DDB9F1E1F92E9B357FCF0314148E80881DBD1B8C8D7E4E81025B9158CB808706E45ABC1E218E982
 
  <nowiki>40A5269CCDFAD4ACBE816B6C6ED00B984B08E34A3172F504C58DDB9F1E1F92E9B357FCF0314148E80881DBD1B8C8D7E4E81025B9158CB808706E45ABC1E218E982
 
20FBB377F8EFDAD1C03FF076BB1E7956C0D0B0D7E41613B726F805D5E7F2D23843
 
20FBB377F8EFDAD1C03FF076BB1E7956C0D0B0D7E41613B726F805D5E7F2D23843
Line 33: Line 43:
 
</nowiki>
 
</nowiki>
  
−
Simply copy and paste that text into a file and name it 010F.key.
+
You can also download the key file directly from WikiTI here: [[File:010F.key]]
  
−
If you're using Spasm as your assembler and rabbitsign to sign the application:
+
== Building Your Application ==
 +
 
 +
Generally, building an application will be a two-step process: assembling the application into a .hex file, and signing the .hex into a .8ck file. Below are instructions for creating .hex files with Spasm and Brass, and signing instructions for RabbitSign. Spasm, Brass, and RabbitSign can be invoked from the command line, and can be automated into a .bat file.
 +
 
 +
=== Spasm ===
 +
 
 +
Spasm is a fast, modern macro Z80 assembler which can generally be used as a drop-in replacement for TASM. It can be gotten from its Website: https://wabbit.codeplex.com/wikipage?title=SPASM%20Documentation .
 +
 
 +
Spasm infers the output format the extension you pass it. Therefore, to assemble your app into a .hex file simply do:
 
  spasm myapp.asm myapp.hex
 
  spasm myapp.asm myapp.hex
 +
 +
=== Brass ===
 +
 +
Brass 1.x is a powerful macro assembler. It happens to be preferred by KermM, who also distributes it with the DCSE SDK. If you're using Brass 1.x:
 +
* Don't use the Brass macro to generate app headers; manually create the header as shown above.
 +
* Use .defpage and .page to define your pages
 +
* Set .binarymode intel
 +
* Brass will generate a .hex file as its output, which you can then pass into RabbitSign, as shown above.
 +
Invoke it as you normally would:
 +
brass myapp.asm myapp.hex
 +
 +
=== ZDS ===
 +
 +
ZDS is the official ZiLog assembler. It's what TI used in the the app SDK, and it's probably what they themselves use.
 +
 +
=== Signing the Application ===
 +
 +
RabbitSign is a multiplatform application signer. It functions as a stand-alone application, just like Brass and Spasm do. RabbitSign for Linux is at http://www.ticalc.org/archives/files/fileinfo/383/38392.html and RabbitSign for Win32 is at http://www.ticalc.org/archives/files/fileinfo/420/42035.html
 +
 +
To sign myapp.hex:
 
  rabbitsign -g -o myapp.8ck myapp.hex
 
  rabbitsign -g -o myapp.8ck myapp.hex
−
Spasm is can be gotten from its Website: https://wabbit.codeplex.com/wikipage?title=SPASM%20Documentation; similarly, RabbitSign for Linux is at http://www.ticalc.org/archives/files/fileinfo/383/38392.html and RabbitSign for Win32 is at http://www.ticalc.org/archives/files/fileinfo/420/42035.html
 
  
−
You can still use ZDS + TI's Wappsign to sign applications, but I'm not as familiar with those tools.
+
You can also use TI's Wappsign to sign applications. Just make sure it can find the .key file.
 +
 
 +
= Application Programming =
 +
 
 +
The TI-84 Plus C SE significantly changes many parts of the OS to support the color screen. You'll want to review the new BCALLs in the .inc file, as well as everything else documented on the Wiki.
 +
 
 +
== Termination ==
 +
 
 +
Applications are not supposed to touch the status bar the way we like to. This is because TI established the status bar as being a UI convention, and using that space for our own purposes violates that convention. You're also not supposed to use cmdShadow as scrap RAM (you weren't supposed to do it on the B&W series, either). The OS also has conventions about not changing the top and bottom LCD windows bounds. Assuming you keep these conventions, JForceCmdNoChar is all you need do to quit your application.
 +
 
 +
If not, however, you'll need to do some more clean up. If you draw over the status bar, you'll need to call DrawStatusBarInfo. If you use cmdShadow for scrap RAM, you should fill it with spaces. Interestingly, regardless of whether the user selects CLASSIC or MATHPRINT, the screen will be redrawn using the math history instead of cmdShadow. The only exception is the cursor, which will blink whatever you leave in cmdShadow. If you are using custom code to drive the LCD (as well you should if you want to app to run at a reasonable speed), you need to undo whatever you do to the LCD registers, because the OS won't, unless you quit with PowerOff.
 +
 
 +
DoorsCSE quits by using JForceCmd with A = kClear, in an attempt to trigger the OS to clear the screen.
 +
 
 +
(None of the above applies to no-shell assembly programs. You'll need to do a much more thorough cleanup because technically the homescreen app is still active.)

Latest revision as of 16:52, 21 October 2014

See also the page on TI-83+ series application headers.

The TI-84 Plus C SE is based on nearly-identical hardware and software. So it's no surprise that it supports applications, just like previous models. For the most part, application development is the same, although there are important differences.

Creating an Application

App Header

Creating an application for the TI-84 Plus C SE is just like creating an application for the TI-8x B&W series. Aside from all the changes to OS equates and hardware, the only thing you need to change is the signing key. Any TI-8x app will include the byte sequence 80120104; simply change this to 8012010F to specify that your application is signed with the TI-84+CSE key. Therefore, an example header might be: 

	; Master Field
	.db	80h, 0Fh, 0, 0, 0, 0
	; Name. Note that the name field reads 80 46 because the name specified here is 6 characters long.
	.db	80h, 46h, "My App"
	; Disable TI splash screen.
	.db	80h, 90h
	; Revision
	.db	80h, 21h, 0
	; Build
	.db	80h, 31h, 1
	; Pages
	.db	80h, 81h, 1
	; Signing Key ID
	.db	80h, 12h, 01, 0Fh
	; Date stamp.  Nothing ever checks this, so you can put nothing in it.
	.db	03h, 22h, 09h, 00h
	; Date stamp signature.  Since nothing ever checks this, there's no
	; reason ever to update it.  Or even have data in it.
	.db	02h, 00
	; Final field
	.db	80h, 70h
	; There's no need for more padding here.  TI just starts execution after
	; the last field.
	call	MySplashScreen

Key File

You need the actual TI-84+CSE 010F.key file to sign the application. This is the file: 

40A5269CCDFAD4ACBE816B6C6ED00B984B08E34A3172F504C58DDB9F1E1F92E9B357FCF0314148E80881DBD1B8C8D7E4E81025B9158CB808706E45ABC1E218E982
20FBB377F8EFDAD1C03FF076BB1E7956C0D0B0D7E41613B726F805D5E7F2D23843
21DFED75BE1329EC0AC94C91C23CED4339133CFCDDB3058E5316148AB7DE378BF201

You can also download the key file directly from WikiTI here: File:010F.key

Building Your Application

Generally, building an application will be a two-step process: assembling the application into a .hex file, and signing the .hex into a .8ck file. Below are instructions for creating .hex files with Spasm and Brass, and signing instructions for RabbitSign. Spasm, Brass, and RabbitSign can be invoked from the command line, and can be automated into a .bat file.

Spasm

Spasm is a fast, modern macro Z80 assembler which can generally be used as a drop-in replacement for TASM. It can be gotten from its Website: https://wabbit.codeplex.com/wikipage?title=SPASM%20Documentation .

Spasm infers the output format the extension you pass it. Therefore, to assemble your app into a .hex file simply do: 

spasm myapp.asm myapp.hex

Brass

Brass 1.x is a powerful macro assembler. It happens to be preferred by KermM, who also distributes it with the DCSE SDK. If you're using Brass 1.x:

  • Don't use the Brass macro to generate app headers; manually create the header as shown above.
  • Use .defpage and .page to define your pages
  • Set .binarymode intel
  • Brass will generate a .hex file as its output, which you can then pass into RabbitSign, as shown above.

Invoke it as you normally would: 

brass myapp.asm myapp.hex

ZDS

ZDS is the official ZiLog assembler. It's what TI used in the the app SDK, and it's probably what they themselves use.

Signing the Application

RabbitSign is a multiplatform application signer. It functions as a stand-alone application, just like Brass and Spasm do. RabbitSign for Linux is at http://www.ticalc.org/archives/files/fileinfo/383/38392.html and RabbitSign for Win32 is at http://www.ticalc.org/archives/files/fileinfo/420/42035.html

To sign myapp.hex: 

rabbitsign -g -o myapp.8ck myapp.hex

You can also use TI's Wappsign to sign applications. Just make sure it can find the .key file.

Application Programming

The TI-84 Plus C SE significantly changes many parts of the OS to support the color screen. You'll want to review the new BCALLs in the .inc file, as well as everything else documented on the Wiki.

Termination

Applications are not supposed to touch the status bar the way we like to. This is because TI established the status bar as being a UI convention, and using that space for our own purposes violates that convention. You're also not supposed to use cmdShadow as scrap RAM (you weren't supposed to do it on the B&W series, either). The OS also has conventions about not changing the top and bottom LCD windows bounds. Assuming you keep these conventions, JForceCmdNoChar is all you need do to quit your application.

If not, however, you'll need to do some more clean up. If you draw over the status bar, you'll need to call DrawStatusBarInfo. If you use cmdShadow for scrap RAM, you should fill it with spaces. Interestingly, regardless of whether the user selects CLASSIC or MATHPRINT, the screen will be redrawn using the math history instead of cmdShadow. The only exception is the cursor, which will blink whatever you leave in cmdShadow. If you are using custom code to drive the LCD (as well you should if you want to app to run at a reasonable speed), you need to undo whatever you do to the LCD registers, because the OS won't, unless you quit with PowerOff.

DoorsCSE quits by using JForceCmd with A = kClear, in an attempt to trigger the OS to clear the screen.

(None of the above applies to no-shell assembly programs. You'll need to do a much more thorough cleanup because technically the homescreen app is still active.)

Retrieved from "https://wikiti.brandonw.net/index.php?title=84PCSE:OS:Applications&oldid=10364"