I'm currently working on a project which requires a large chunk of RAM, and so I decided to use page 82 of ram to store information.

Everything runs fine on emulator. On real hardware it crashes the calculator, but in a really weird way. The calculator will run fine, but after scrolling up the menu a bit, the calculator will either shut itself off and clear the ram, or it will lock up and I will have to take the batteries out.

Are there any specific limitations to using page 82 of ram that I am unaware of? I was under the impression that page 82 was used for temporary storage during some operations. (https://www.cemetech.net/forum/viewtopic.php?t=8137&start=0)

Sample code that causes the crash:

Code:

(Note: changing "ld bc, 2000" to "ld bc, 1000" does not cause the crash.)

Any help is appreciated!

Well, for one thing, it looks suspiciously like you forgot to disable interrupts. Any you time to change the memory mapping of anything other than the 4000h memory bank, you'll want to disable interrupts or set up your own ISR.

And for another thing. . . .

Code:

I just tried disabling interrupts, and the crash still occurs

According to this, it looks like you want to use 03, not 02. As well, if you want to use any of the first 128 bytes, you'll need to use bcall(_FillBasePageTable) when your code is done with the page.

All of these calcs have RAM pages 80 and 81. Any with a USB (84+) have page 83. For a short time, some calculators were being made with 8 pages, the other 82, 84, 85, 86, and 87. Most emulators seem to default to 8 pages, where your page 82 would be valid and unique. However, most real hardware just maps that to page 80 which is what is normally mapped to the C000-FFFF range.

For reference, I have one real 84+ that your code would work on, and two that it wouldn't work on.

I hope this is all correct and works, good luck!

Thank you for the information! I was hesitant to use pages beyond 82 because I had heard that some programs use that space for long-term storage, but looking at that link it seems that I don't have to worry about that when using page 83. Thank you very much!

Okay, so I tried using page 83 and running the b_call afterwards, and now both the calculator and the emulator are crashing.

New Code:

Code:

The crash also happens if the b_call is before the memory map change.

Hmm, in the chat, jacobly mentioned I may have misinterpreted the documentation. Maybe try page 82 again?

When mapping to page 82 only the real calculator crashes. When mapping to page 83 both the real calculator and the emulator crash. Would it help to send a video of the crash occurring?

Perhaps disabling MathPrint would help, because that also uses the extra RAM page. Just a wild guess, though.

Disabling MathPrint does not work.

Hmm, so I experimented a little (I'm not at home, so I can't *really* look into it). 0x83 is definitely the page you want. Are you executing from an app? If not, try instead to map it to 4000-7FFF (so using port 6 and $83 instead of 03, and of course adjust the addresses). You'll need to first save the value in port 6, then restore at the end, then use that bcall from above.

Mapping to 4000-7FFF does not seem to work either.

If it helps, here is a video of the crash occurring: https://drive.google.com/open?id=1gpWCiwODMPoulCJuN6wIEC8mBPv7OzPi
(I apologize for the horrendous video quality)

Just so you know, this is still a problem I'm having. Is there any sample code that deals with memory mapping that I could look at so I can figure it out myself?

We were talking about this on the Cemetech Discord the other day, and concluded the following:

• The OS uses at most 128 or so bytes on one extra RAM page. (EDIT: maybe more is used on the MP OSes, need to look at that later)
  
• This is stored on page 83. Emulators usually have 8 pages of RAM. Real 3-page models map 82 up to 87 to the same page. This is why it worked on an emulator but not on the real calculator.
  
• Because you can only scroll up since 2.53MP, it doesn't cause a crash on 2.43.
  
• The data stored is each app's base page.

According to WikiTI, the MP OSes use the RAM $977e–$9a7d. It also uses other parts, but this part is for storing the command history and causes crashes. If you leave this part of the page alone, it should not cause a crash.

Furthermore, I discovered that writing $00 to $8e29 (numLastEntries) will disable the user from scrolling up, and it doesn't even cause memory leaks, and works with MathPrint enabled as well. It still shows the past entries on the screen, but you can't scroll up to them. So, when exiting, write $00 to $8e29. If this is done by an assembly program (as opposed to an app), you can still access the program's entry, but all entries above that are unavailable. For example, this program doesn't cause a crash:
Code:

EDIT: modified a few words for clarity

Wow. I just tried that and it actually worked. Thank you so much! Assuming that the rest of the page is used for temporary storage, that would be $4000 bytes of spare ram to work with.

You might want to read http://wikiti.brandonw.net/index.php?title=83Plus:OS:Ram_Pages (specifically, page 83 there). There is another area $5A7E to $5D7D that you might want to be careful with. However, I haven't had any issues with it on 2.55 MP.