84PCSE:OS:Applications

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

Simply copy and paste that text into a file and name it 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.)