Difference between revisions of "Z80:Multi-Page Apps"

From Learn @ Cemetech
Jump to navigationJump to search
(Created page with "The biggest advantage of flash applications over regular assembly programs is the ability to create absolutely massive projects. However, because of the way the hardware is se...")
 
(Adjusted lowercase z80)
Line 91: Line 91:
  
 
{{lowercase}}
 
{{lowercase}}
[[Category:z80 Assembly]]
+
[[Category:Z80 Assembly]]
[[Category:z80 Heaven]]
+
[[Category:Z80 Heaven]]

Revision as of 21:09, 3 February 2016

The biggest advantage of flash applications over regular assembly programs is the ability to create absolutely massive projects. However, because of the way the hardware is set up, you have to make some changes in your code to accommodate the hardware limitations. This page will explain these changes and how to properly set up your code to make everything and everyone happy.

Paging

[! Someone please go over this, I'm not sure if this information is entirely correct]

The TI-83+ series calculators' memory is mapped into $4000 (16384) byte pages. Every page is either empty, or it contains a flash application, is a RAM page (contains OS elements), or is an empty flash page. This is why when you look in your memory, every flash application occupies a multiple of $4000 bytes no matter how much useful data is actually on that page. Execution of a flash page is done by swapping it into Bank A. The details can be found elsewhere, as for most programs they are unnecessary.

Changes in the Header

There is an element in the header that denotes the number of flash pages your flash app contains. Depending on your assembler/compiler, you may or may not need to change this.

Page declaration

[! This is true for Brass/Latenite, someone please check to see if this is universal, or what it is using different compilers]

At the start of each page, it is important to tell the compiler you are on a certain page. This is done using the .page # directive. Pages start counting from 0.

   ;ex:
   .page 0
   ; page0 code
   .page 1
   ; page1 code
   ...


Change in 'Memory Counter'

Instead of using .org $9D93, use .org $4000. This is because the Flash address is mapped starting at $4000. Also, the asmprgm token can be omitted (the .db $BB,$6D).

Jump Table

Jump Tables are the easiest way to access different pages. They allow us to almost ignore the fact that we have to swap pages in order to access data on other pages and having to deal with memory nightmares. An example of a rather large jump table is the ti83plus.inc file. For every entry-point on flash pages other than page0 you will need to map a jump table (or not, but it will make your life easier). Then to access that entry-point, we can use the bcall macro. How this works is currently out of the scope of this lesson, but if someone wants to add it, please do.


   ; example of a simple multi-page app
   .org $4000
   .page 0
   ;app header
   .block 128
   
    jp main     ; skip over the jump table to the start of the program
   
   ;jump table
    .dw func1
    .dw myPutS
   
   main:
    bcall(func1)      ;call func1
    ld hl,appbackupscreen
    bcall(myPutS)
    bjump(_JForceCmdNoChar)
   
   .page 1
   
   ; copy txt1 to appbackupscreen
   func1:
    ld de,txt1
    ld hl,appbackupscreen
    ld bc,13
    ldir
    ret
   
   ; PutS, except included into our program
   myPutS:
    push bc
    push af
    ld a,(winBtm)
    ld b,a
   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
   
   txt1:
    .db "Hello world!",0