Multipage Applications and Data

[hotdog1234]

Does game data, such as sprites, have to be kept on the first page of a multi-page application, or can it be stored on other pages? So far, the pages I looked at told me only how to access routines on other pages, not data on other pages.

[Mapar007]

It's possible, but only if you move it to RAM.


EDIT: the moving code should be in RAM too, of course.

[hotdog1234]

Any other way? I want to access a sprite (via label) from another page..let's, for instance, I wanted IX to point to the sprite when it's not on the same page

[DrDnar]

You can't do it without messing with the memory mapping. You always have to swap data into the address space before you can use it; the CPU can't access data it can't see. For a multipage application, if the data isn't on the current page, you have to copy it to RAM some way or another before using it. Put a copier routine on the page that has the data, and use the B_CALL system to call the routine. Or put a copier routine in RAM.

If you don't mind not using any B_CALLs whatsoever, you could disable interrupts—or set im 2 and run your own interrupt—move all of your variables to RAM page 0 (which is hard to do), and then swap in the page that has the data you want into memory bank B. The fact that most of RAM page 0 is dynamically allocated space and can't run code makes doing this very hard. Unless you're on a TI-83+SE/TI-84. Then you could use page 83h or page 85h for your stack and variables, and you'd have the whole 16K page free to use for your own purposes. But that's crazy talk.

EDIT: Let me explain things a little bit. The Z80 has 16-bit addresses, which means it can only address 64K of data. In order to access more data, you need some way to move parts of memory in and out the address space. This is done using bank switching. On the TI-83+, there are four banks, at 0h, 4000h, 8000h, and 0C000h. The bank at 0h is fixed to ROM page 0, and the bank at 0C000h is fixed to RAM page 0. The 4000h and 8000h banks can be switched to any page in RAM or ROM, but the operating system always expects RAM page 1 to be in the 8000h, so if you put a ROM page in there and run any OS code, chances are you'll crash. That means that applications normally must copy data to RAM if the data isn't on the same page as the code currently running.

[hotdog1234]

Okay...so you're saying that if, as an example, I had the copy routine on page 0 or page 2, it could not read anything from page 1, but if the copy routine were on page 1, it could read anything from page 1?

[Graphmastur]

I can see brandonw is reading this, so he will probably explain it better, but...

The memory structure of the TI is in 4 parts:
0000h-3FFFh ; Rom page 0
4000h-7FFFh ; Rom page X
8000h-BFFFh ; Ram page Y
C000h-FFFFh ; Ram page 0

So the pages X and Y, can be swapped via port 5 and 6. If you have a multipage application, you will have a table, and some code with it. The table will have address/page of the command you want. If you define your call to be, say an F_call(, and your code is on, let's use AppBackupScreen, for example. It would back up all the variables, see what function was called, based on number, access the address and what page the command the is in, load the page X in rom, call the function, restore the original page, and then return. The problem is, that you will have to find what page your app is on, because if it was a two page app, it could be on page 69 and 68, or 63 and 62.

[hotdog1234]

:confused: Okay, let me rephrase my whole question. I understand that there's a table which tells which page the command you want is on. But so far, that's all I've heard about...in other words, I only know what to do to access commands. I have not heard anything about how to tell the application what page data is on.

So if one uses the table to have addresses and their respective pages when it comes to instructions, which are either called or jumped to, what about data?

I'll even give an example to show what I'm talking about. From what I know, when there's a command on another page, say "Display_The_Number_One" on page 1, you tell the calculator where the command is located using the following:

DW Display_The_Number_One
DB 1

Does the same thing apply if the address points to, for example, sprite data, rather than instructions?

[calc84maniac]

I think the easiest way to display a sprite on page 1 is to put your sprite routine on page 1 as well.

[Michael]

[Graphmastur]

[Michael]

In response to your rephrased question, you cannot tell the application what page the data is on. I presume you've read TI's help file on multipage apps.

All of the pages of your app are swapped into the *same* address space, 4000-7FFFh. The app can never directly access or jump to anything on any other app page, for the simple fact that the act of swapping replaces the code on one page with code from another page. If you tried, you'd find that immediately after outputting the new page to port 6, your subsequent code from that routine no longer exists in the Z80's memory map. The act of swapping the page put another page of data in, and the location where the Z80 is reading your routine from has suddenly changed to random bytes from the new page. Crash.

The B_CALL routine that TI provides for multipage apps to call a routine on another page works because a B_CALL is really a jump to 0038h, which is not on your app page. 0000-3FFFh is always mapped to ROM page 0. So execution goes there, and since the Z80 is executing from that area, it is safe to swap app pages in 4000-7FFFh without crashing. The OS at 0038h looks at what page it was called from, finds the start of your app, swaps into 4000-7FFFh your first page of the app, looks in the table of routines and reads where it's going, then swaps in the appropriate page, and then calls your routine there.

This will not work for data because you would be attempting to have a routine on the first page access data on the second page, an impossibility when both pages will occupy the same memory area (and therefore cannot both be swapped in at once). Suppose you have a routine on the first page of the app. How do you access data on page 2 from within that routine? You can't, because if you swap the second page in, your code is no longer mapped in memory. The processor will look to the same location for the next instruction in the routine, find some random bytes from the second page, and crash.

The common alternative is to execute a routine on the second page which copies the data into RAM (perhaps appbackupscreen). Then the routine on the first page can access it from RAM.

[hotdog1234]

Well, rather than start up a new topic, I decided to display my sorrows up on this page.

I have no compile errors when practicing working with multi-page applications, and the application works just fine...except my procedure on the page 1 won't run. It just executes everything in page 0. What am I doing wrong? By the way, PAGE 0, PAGE 1, and JUMP TABLE are in three seperate files, but I decided to just combine them all in the code below.

[TheStorm]

I know very little about multipage apps, but when posting large amounts of code try the [ codebox ] tag rather than [ code ]. as to your issue, are you sure your swapping pages correctly?

[FloppusMaximus]

A few tips:
- If it's reasonable to do so, you should generally put data on the same page as the code that is going to use that data. As somebody suggested, put your sprite routines on the same page with all your sprites; put your text display routines on the same page with all your text, and so forth.
- Try to estimate how frequently (how many times per second) a given routine needs to be used. If you use B_CALLs to call routines on other pages, realize that every B_CALL takes on the order of 100 microseconds. So for instance, you might want to have a single off-page routine that draws the entire screen, meaning you'd only need to perform one B_CALL per frame (as opposed to potentially hundreds.)
- If you have a huge amount of data (more than will fit on a single page), consider loading the code that accesses it into RAM. (You should also, of course, consider compressing that data; it may make sense to place a routine into RAM that decompresses the data and stores it in a temporary buffer, at which point you can access it using code in Flash.) Loading code into RAM isn't free either, but it's sometimes faster than a B_CALL, and depending on where you load it, you may only need to do so once.

[hotdog1234]

Problem solved. I had to set up ZDS differently and sign my application rather than just debugging the hex file

EDIT: Thanks for the tips, Floppus