Difference between revisions of "Z80:Application Code"
KermMartian (talk | contribs) (Created page with "Now that we have the header of the application, it's time to discuss the code for applications. Intro to Flash Applications discussed a few...") |
KermMartian (talk | contribs) (Adjusted lowercase z80) |
||
Line 1: | Line 1: | ||
− | Now that we have the header of the application, it's time to discuss the code for applications. [[ | + | Now that we have the header of the application, it's time to discuss the code for applications. [[Z80:Intro to Flash Applications|Intro to Flash Applications]] discussed a few general things, but now we're ready to get into the nitty-gritty details. Note that this page will focus on things specific to single page flash applications. Multiple page applications have an added level of complexity, and are discussed [[Z80:Multi-Page Apps|here]]. |
= Hello world = | = Hello world = | ||
Line 31: | Line 31: | ||
− | It looks really similar to a regular assembly program at first glance. However, look carefully and the differences can be quite interesting. First of all, [[ | + | It looks really similar to a regular assembly program at first glance. However, look carefully and the differences can be quite interesting. First of all, [[Z80:Directives:org|.org]] is set to $4000. This is because flash addresses are addressed starting at $4000, quite different from assembly programs which address from $9D93. |
Also notice that we wrote our own PutS routine. What's up with that? The reason why we wrote our own PutS routine is because PutS can only display strings residing in RAM. Technically, we're not in RAM (actually, we've just swapped our flash app into "RAM" so it can be executed, but it's not what the OS thinks is "RAM). So, we have two solutions: copy our text to saferam (such as appbackupscreen, textShadow, etc.) or somewhere in actual RAM, then bcall PutS, or write our own PutS routine and just call it. Places that are actually in "RAM" are addresses '''outside of''' $4000-$8000. | Also notice that we wrote our own PutS routine. What's up with that? The reason why we wrote our own PutS routine is because PutS can only display strings residing in RAM. Technically, we're not in RAM (actually, we've just swapped our flash app into "RAM" so it can be executed, but it's not what the OS thinks is "RAM). So, we have two solutions: copy our text to saferam (such as appbackupscreen, textShadow, etc.) or somewhere in actual RAM, then bcall PutS, or write our own PutS routine and just call it. Places that are actually in "RAM" are addresses '''outside of''' $4000-$8000. | ||
Line 59: | Line 59: | ||
− | The last difference you can note here is that to quit an flash application, you must use [[ | + | The last difference you can note here is that to quit an flash application, you must use [[Z80:Macros:bjump|bjump(_JForceCmdNoChar)]]. |
= Self Modifying Code (SMC) = | = Self Modifying Code (SMC) = | ||
Line 91: | Line 91: | ||
{{lowercase}} | {{lowercase}} | ||
− | [[Category: | + | [[Category:Z80 Assembly]] |
− | [[Category: | + | [[Category:Z80 Heaven]] |
Revision as of 21:08, 3 February 2016
Now that we have the header of the application, it's time to discuss the code for applications. Intro to Flash Applications discussed a few general things, but now we're ready to get into the nitty-gritty details. Note that this page will focus on things specific to single page flash applications. Multiple page applications have an added level of complexity, and are discussed here.
Hello world
Let's get started! We'll create a simple hello world application to demonstrate a few of the novelties of flash application programming. So, here's the code (with out header):
.org $4000 .include ti83plus.inc ;app header is here. Omitted for now main: ld hl,0 ld (curRow),hl ld hl,txtHello call myPutS bcall(_GetKey) bjump(_JForceCmdNoChar) myPutS: ld a,(hl) or a ret z bcall(_PutC) jr myPutS txtHello: .db "Hello world!",0
It looks really similar to a regular assembly program at first glance. However, look carefully and the differences can be quite interesting. First of all, .org is set to $4000. This is because flash addresses are addressed starting at $4000, quite different from assembly programs which address from $9D93.
Also notice that we wrote our own PutS routine. What's up with that? The reason why we wrote our own PutS routine is because PutS can only display strings residing in RAM. Technically, we're not in RAM (actually, we've just swapped our flash app into "RAM" so it can be executed, but it's not what the OS thinks is "RAM). So, we have two solutions: copy our text to saferam (such as appbackupscreen, textShadow, etc.) or somewhere in actual RAM, then bcall PutS, or write our own PutS routine and just call it. Places that are actually in "RAM" are addresses outside of $4000-$8000.
;alternative way copying to saferam: .org $4000 .include ti83plus.inc ;app header is here. Omitted for now main: ld hl,0 ld (curRow),hl ld hl,txtHello ld de,appbackupscreen ld bc,12 ldir ld hl,appbackupscreen bcall(_PutS) bcall(_GetKey) bjump(_JForceCmdNoChar) txtHello: .db "Hello world!",0
The last difference you can note here is that to quit an flash application, you must use bjump(_JForceCmdNoChar).
Self Modifying Code (SMC)
In flash application coding, you can not create code that will modify anything between the addresses of $4000-$8000 (where the actual application is). To create SMC, you must first copy your code to somewhere else (saferam works best) and then that code is free to be modified.
;error ld (putix+1),hl putix: ld ix,$0000 ;ok ld hl,putix ld de,appbackupscreen ld bc,4 ldir ld (appbackupscreen+1),hl call putix ;... putix: ld ix,$0000 ret
Technically, I believe instructions that try to write to memory between $4000-$8000 are ignored, but their behavior is not really documented. It could result in a crash that could completely mess up your calculator.
Emulators Note
It is always a good idea to test on an emulator before testing on a real calculator. However, it is wise to note that emulators are not exactly accurate, especially when it comes to Flash memory. It is the least documented, and has the worst possible consequences if you mess with something you're not suppose to.