I've got another question about multi page apps, this time having to do with spasm and the defpage macro. When I run spasm, I get an error that a page is being skipped, then a message stating that same page was added successfully:
Pass one...
Pass two...
-----------------------------------------------
Beginning APP "MyApp", courtesy of SPASM macros
-----------------------------------------------
(error)
Warning: Skipping page 1 at user request.
Page 0 free space: 14895
(error)
Warning: Skipping page 2 at user request.
Page 1 free space: 131
Page 2 free space: 144
Success: Page sizes validated and "MyApp" is ready for signing.
           In 3 page(s), 15170 bytes are available.
Done
Assembly time: 0.036 seconds

I have a lot of pages in my app (above, I commented everything out but the first two temporarily to reduce compile time), so this is the structure to my code:

main.asm:
#include "ti83plus.inc"
#include "app.inc"

defpage(0, "MyApp")

[code goes here]

#include "pageinc.asm"

validate()

pageinc.asm:
#include "page01.asm"
#include "page02.asm"
#include "page03.asm"
[and so on...]

page01.asm:
defpage(1)
.db [data goes here]

And so on for all the pages. Can someone help me understand what is causing these error messages?

I see what you mean. But here, as screen lines are always parallels to lines of texels, the BLIT_P function of PPL does this for me even faster. Nothing is computed at pixel level in fact : BLIT_P scales and copies on screen a whole line of a tile at once.

Ah, so it will scale the textels automatically for you? That's even better.

So they're like the buttons you would find on a microwave?

Quote from: t0xic_kitt3n on December 12, 2013, 10:32:53 pm

Are you calculating a lookup table for each pixel of the screen?

Not for each pixel. I use three tables :
rayTable stores the distance to the rendered plane for each screen line,
x1Table and x2Table are lists of lists of projected horizontal starts and ends of each square, for each screen line again.
Those are computed in init().

Good. I had originally done the naive per pixel look up table when writing my Nspire mode 7 engine, but I also came across a similar method. Instead of storing the start and end positions for each scanline, I stored the start position and a vector to increment the position by each pixel. I don't know the performance penalties for different calculations in HP-BASIC, but a vector addition per pixel should be cheaper than a vector linear interpolation (which involves multiple additions and multiplications) each pixel, so you may want to try it.

When your application starts, read the value of port 6, which dictates which page of physical flash the base page of your app resides on. Subsequent pages of your app extend downwards in physical page numbers.

Ok, so it's all linearly mapped, and there's no table the OS stores to access? Thanks, that's all I needed to know.

Well, I guess this should be written somewhere in your app when it's compiled. Then all you'll have to do is get that number and output it to port 6 from RAM.

But page x of an app does not correspond to page x of the physical flash page. If you have multiple apps installed, some of them will have to be offset.

For my app, which is going to consist of 1% code and 99% data, I need to be able to swap to an arbitrary page. I plan on copying my code to RAM, so that I am free to switch pages. I know you can switch to a physical flash page by writing to a port, but I need to switch to pages based on the order they appear in the app. Can someone help me out?

Also, for copying code to RAM, how do I get spasm to compute jp addresses as if they were for that RAM? If I don't, the addresses would still point flash, which would not work.

Are you calculating a lookup table for each pixel of the screen?