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:

   ld a, $02
   out ($05), a
   
   ld e, $5D
   ld bc, $2000
   ld hl, $C000
   
loop:
   ld (hl), e
   dec bc
   inc hl
   xor a
   or b
   or c
   jr nz, loop
   
   xor a
   out ($05), a
   
   ret

(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:
    ld hl, $C000
    ld de, $C001
    ld bc, 1FFFh
    ld (hl), 5Dh
    ldir
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:

di
   
   ld a, $03
   out ($05), a
   
   ld e, $5D
   ld bc, $2000
   ld hl, $C100
   
loop:
   ld (hl), e
   dec bc
   inc hl
   xor a
   or b
   or c
   jr nz, loop
   
   xor a
   out ($05), a
   
   b_call($5011)
   
   ei
   
   ret

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:
 .db $bb,$6d
 .org $9d95

 di ; for safety, don't mess with memory mapping while the system interrupt is active
 ld a,$03 ; page $83 is the same as $82 on 48K models, but this also works on emulators and 128K models
 out ($05),a
 ld hl,$c000
 ld de,$c001
 ld bc,$3fff
 ld (hl),$ff
 ldir ; fill the entirety of the page with FF

 xor a
 out ($05),a ; back to the regular ram page in this bank
 ld ($8e29),a ; clear entries
 ei
 ret

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.
Crazy_Fox2 wrote:
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.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement