[Z80 Apps] use $9D95 while running an app
Moderator: MaxCoderz Staff
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
[Z80 Apps] use $9D95 while running an app
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
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
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
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
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.
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact:
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.
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.
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'.
- KermMartian
- Calc Wizard
- Posts: 549
- Joined: Tue 05 Jul, 2005 11:28 pm
- Contact:
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
Possibly but an unexpected quit shouldn't happen. In most cases there would be crash.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.
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
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
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?
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
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?
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
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.
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.
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).
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
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?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).
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.
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.
- driesguldolf
- Extreme Poster
- Posts: 395
- Joined: Thu 17 May, 2007 4:49 pm
- Location: $4080
- Contact:
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
thanks for that spot, didnt knew it existed