z80:Intro to Flash Applications
Contents
Memory
ROM and RAM
In the older model calculators, there are two types of memory; ROM and RAM. ROM stands for "Read Only Memory" while RAM stands for "Random Access Memory". ROM can only be read, thus the name, but RAM means that it can be read and written to at any point. For our purposes, ROM is the calculator's equivalence of a BIOS and the RAM controls everything else. Now that you understand more about your calculator's memory, we can move on to newer calculators.
Flash ROM
Newer calculators have a new kind of ROM. It is Flash ROM, and it is a hybrid of the two. Flash ROM is similar to ROM because it is safe from accidental erasures, but with the capability of being erased and written to roughly 100,000 times.(Similar to RAM) Because of this useful feature, it allows us to create a new kind of program: flash applications.
Applications
Comparison
The application is written in assembly, but run from Flash ROM. Applications use a special header that allows the base loader to extract information from the app. What Flash Apps have over normal asm programs is that they can be much larger, get their own AppVars, and are safe from accidential deletion. Apps are also run from the [Apps] button and not from a Shell.
++= Applications = to Applications
Most people don't build apps when they make games; they just make asm programs to fit into shells like Mirage OS. Most people enjoy accessing their games from one place. Most people make apps when they are making large math & science programs, like polynomial finder, periodic table etc. Apps are also used if the program is very large. Detached Solutions is a group that makes apps. Although a couple apps are games, most of them are graphing, shells, or added feature apps.
Differences in Application Programming
Programming a flash application has a couple differences that must be taken into consideration.
Click here to get the TI SDK for developing flash applications (and other programs), as well as many useful Windows applications that make programming easier.
App Header
TI has created a Windows application that creates an app header for you. It is download-able here. Type in the name, Developer Key (more on that in a sec), pages... etc. Here is a sample header in it's full entirety. To understand what it means, see the Application Header page.
.db 080h,00Fh ;Field: Program length .db 00h,00h,00h,00h ;Length=0 .db 080h,012h ;Field: Program type .db 01h,04h ;Type= Shareware, TI-83Plus .db 080h,021h ;Field: App ID .db 01h ;Id = 1 .db 080h,031h ;Field: App Build .db 01h ;Build = 1 .db 080h,048h ;Field: App Name .db "Name", 000h, 000h, 000h, 000h ;Name: "Name" .db 080h, 081h ;Field: Number of pages .db 001h ;Pages: 1 .db 080h, 090h ;Field: Security data .db 003h, 026h, 009h, 004h ;Start of security data used with signing .db 013h, 069h, 0DBh, 04Bh .db 002h, 00Dh, 040h, 0A1h, 06Bh, 099h, 0F6h, 059h, 0BCh, 067h .db 0F5h, 085h, 09Ch, 009h, 06Ch, 00Fh, 0B4h, 003h, 09Bh, 0C9h .db 003h, 032h, 02Ch, 0E0h, 003h, 020h, 0E3h, 02Ch, 0F4h, 02Dh .db 073h, 0B4h, 027h, 0C4h, 0A0h, 072h, 054h, 0B9h, 0EAh, 07Ch .db 03Bh, 0AAh, 016h, 0F6h, 077h, 083h, 07Ah, 0EEh, 01Ah, 0D4h .db 042h, 04Ch, 06Bh, 08Bh, 013h, 01Fh, 0BBh, 093h, 08Bh, 0FCh .db 019h, 01Ch, 03Ch, 0ECh, 04Dh, 0E5h, 075h ;End of security data used with signing .db 80h,7Fh ;Field: Program Image length .db 0,0,0,0 ;Length=0, N/A .db 000h, 000h, 000h, 000h ;padding .db 000h, 000h, 000h, 000h ;padding .db 000h, 000h, 000h, 000h ;padding .db 000h, 000h, 000h, 000h ;padding
Flash Pages
First of all, you can't just make your 40k application. Your application is written on flash pages, and they are 16,384 bytes. Each page must also be written in a separate assembly file, but don't worry about that for now. Another thing to keep in mind that your flash application is set to the size of all the pages you used combined. This means that if your code happens to be 16,385 bytes, then you would have to go onto the next flash page. This is a big waste because that means that the whole 2nd page is empty except for that 1 byte, but you also can't use the rest of that page for anything else because of the way TI has designed the flash page system.
Now once you have written 16k worth of code and you are not done yet, you need to use another page. You can't just write onto another one. What you need is a jump table. A jump table is data that tells the program about functions that are called across pages. Where do we put it? We put it right after the app header, but because the jump table entries are 3 bytes, we have to actually start the program before the Jump table. Deal with it. Sample code pulled from Ti.
; ; Application header ; + padding jp StartApp ; ; Jump table here ; StartApp: ; ; Application here! ;
What we did here was jump to the start of the app, and bypassed the jump table. Now to see what a jump table looks like. Each entry, uses three bytes, a word and a byte. The word defines the offset, while the byte defines the page. Code sample from Ti:
dw Page1Call ; Rom call name db 0 ; Page it is on (this page) dw Page2Call ; db 1 ; Next page
Signing
To finish an application, you need to sign your app. If you want to sell your app for money, then A) stop reading now because that is just wrong, plus who will buy it anyways you ameuteur, and B) You need to buy a developer key. On the other hand, if you are making a free app than all you need to do is plug in 0104 as a key. This was given in the SDK, and all ti 83+ and ti 84+ contain it. It is the "free key".
Actual Coding
The actual coding of a flash application is very similar to a regular program with a few exceptions:
1. You return to the OS using bjump(_JForceCmdNoChar) instead of ret. This is because the flash application and the OS reside on different flash pages, so a simple ret won't get you back to the OS.
2. RAM vs. Flash ROM. RAM is the area of memory the calculator actually has access to. Some OS routines require you to copy data to RAM. An example is PutS. To get around this, it is usually easier to include the OS routine into your flash application inline.
;PutS Inline
;Same as OS's PutS routine, but inline
;
PutS:
PUSH BC
PUSH AF
LD A,(winBtm)
LD B,A ; B = bottom line of window
PutS10:
LD A,(HL) ; get a character of string name
INC HL
OR A ; end of string?
SCF ; indicate entire string was displayed
JR Z, PutS20 ; yes --->
B_CALL PutC ; display one character of string
LD A,(curRow) ; check cursor position
CP B ; off end of window?
JR C,PutS10 ; no, display rest of string
PutS20:
POP BC ; restore A (but not F)
LD A,B
POP BC ; restore BC
RET
Keep these things in mind and you'll be able to program flash applications of equal or greater quality than regular asm programs.
NOTE: This information is a compilation of TI tutorials and various discussions via forums.
