[Z80 Apps] use $9D95 while running an app

Got questions? Got answers? Go here for both.

Moderator: MaxCoderz Staff

Post Reply
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

[Z80 Apps] use $9D95 while running an app

Post by driesguldolf »

I'm currently making a games collection app, but i have some problems
I would like to use the user mem ($9D95) to store routines that need smc...
I tought because it is called 'user memory' that it could be written to no matter what, but i was wrong...
After some testing i found out that Ans and the entries are some how stored there...
Does anyone know a workaround? or how to correctely reset these variables?
Thanks
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

My first try is just resetting that memory... hehe, got some very funny results...
If the Ans was a real number, its 0 after resetting, no big deal.
if it was a list, Ans = {}
If it was a string, Ans = ""
BUT, if ans was a Matrix and i try to recall it, i get matrix with infinite columns, with weird values (a complicated number with powers of ten over 100 yay)

I couldnt make any sense of the last entries...

And if you type something and then run the app... You don't want to know what happens...

This post is just to make things funny
Last edited by driesguldolf on Thu 21 Jun, 2007 7:52 am, edited 1 time in total.
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

Use _InsertMem to reserve the memory that you need at $9d95. You can find the arguments in the 83+ Routine Reference.

Edit:
DE = where to insert
HL = how many to insert

Note that when you're done, you need to use _DelMem to remove it again:
DE = how many
HL = where

Notice that the registers used are opposite for _InsertMem and _DelMem.
Image Image Image
User avatar
Dwedit
Maxcoderz Staff
Posts: 579
Joined: Wed 15 Dec, 2004 6:06 am
Location: Chicago!
Contact:

Post by Dwedit »

I'd recommend creating an appvar, and relocating it to 9D95. Then use 9D97 and on as your memory space. When you're done, you can delete that variable. Or if your program unexpectedly quits, then the user can delete that variable. That's a good idea to avoid memory leaks.
You know your hexadecimal output routine is broken when it displays the character 'G'.
User avatar
KermMartian
Calc Wizard
Posts: 549
Joined: Tue 05 Jul, 2005 11:28 pm
Contact:

Post by KermMartian »

Actually, if you only need 768 or fewer bytes, just use AppBackupScreen. There's also assorted other SafeRAM that you can use.
Image Image Image
User avatar
Jim e
Calc King
Posts: 2457
Joined: Sun 26 Dec, 2004 5:27 am
Location: SXIOPO = Infinite lives for both players
Contact:

Post by Jim e »

Dwedit wrote:I'd recommend creating an appvar, and relocating it to 9D95. Then use 9D97 and on as your memory space. When you're done, you can delete that variable. Or if your program unexpectedly quits, then the user can delete that variable. That's a good idea to avoid memory leaks.
Possibly but an unexpected quit shouldn't happen. In most cases there would be crash.
Image
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

kerm_martian: Thanks, I'll try that, btw does it detect if there is enough ram to preserve Ans and Last Entries?

Dwedit: Do you mean that I should temporarily store the previous contents of $9D95 (and on) to it, and restore it afterwards? I have an exit routine wich is also use to quit if the user presses 'del' (teacher key), That routine should take care of everything

kerm_martian: Thats my temporarily solution for now, but I doubt if I have enough memory left for the games to run

Code: Select all

plotsscreen -> gbuf
savescreen -> system vars and interrupt
statvars -> currently used for the smc routines (I have a warning that checks (when compiling) if it takes more than 512 bytes)
leaves only appbackupscreen (and some more small, useless places),I hope that will be enough
Dwedit and Jim e: I'm not sure what you mean by 'unexpected quit', my game has a teacher key, but it uses my standard exit routine

btw I realized that MirageOS has the same problem (copying the games to $9D95) but it just erases the Ans and last entries, any idea how to erase them?
User avatar
Jim e
Calc King
Posts: 2457
Joined: Sun 26 Dec, 2004 5:27 am
Location: SXIOPO = Infinite lives for both players
Contact:

Post by Jim e »

Just use EnoughMem to see if theres enough ram. It will also cleanup some stuff if there isn't.


Don't worry about the quiting thing, it really shouldn't be an issue. Insertmem is generally the choice for allocating mem at a certain address.
Image
brandonw
New Member
Posts: 17
Joined: Thu 21 Jun, 2007 1:11 pm

Post by brandonw »

As long as you're not writing a multipage application, you can use the 1087 bytes at appData if you need more safe RAM. That uses all of appData, ramCode, boot code scratch space, and the base page table for the 83+. The only downside is that you should probably BCALL 5011h before you quit (which refills the base page table, wherever it happens to be on that particular calculator).
User avatar
Jim e
Calc King
Posts: 2457
Joined: Sun 26 Dec, 2004 5:27 am
Location: SXIOPO = Infinite lives for both players
Contact:

Post by Jim e »

brandonw wrote:As long as you're not writing a multipage application, you can use the 1087 bytes at appData if you need more safe RAM. That uses all of appData, ramCode, boot code scratch space, and the base page table for the 83+. The only downside is that you should probably BCALL 5011h before you quit (which refills the base page table, wherever it happens to be on that particular calculator).
I didn't know there was that much safe there. Though does multi-page matter if there aren't any bcalls to another page of the app?
Image
brandonw
New Member
Posts: 17
Joined: Thu 21 Jun, 2007 1:11 pm

Post by brandonw »

No, that's what I meant...if you aren't using the BCALL routine for off-page calls in your own application, you can use it.

I should also mention that arcInfo is in that spot as well, so if you're archiving variables, you might lose what's stored there. 1087 is just the absolute max I would attempt to use.
User avatar
driesguldolf
Extreme Poster
Posts: 395
Joined: Thu 17 May, 2007 4:49 pm
Location: $4080
Contact:

Post by driesguldolf »

Archiving shouldnt be a problem, I was thinking of a system where at the beginning I copy the data from the appvar (i don't unarchive) and at the end I'll unarchive, write the data and rearchive, that way the data will never be lost if theres a bug, neither should archiving be a concern
thanks for that spot, didnt knew it existed
Post Reply