Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: ralphdspam on September 09, 2011, 10:03:28 pm
-
Currently I am using SaveSScreen, appBackupScreen, and plotSScreen for display buffers. Where can I place my fourth buffer of $300 bytes?
Thanks in advance. :)
-
Runer and I talked about using statVars as a fourth buffer. It looks like it should be clear to use. Starting at statVars, you have about 830 bytes to work with that really shouldn't cause any problems unless you do stat operations or graph something.
To see the complete list of what you are destroying head over here (http://brandonw.net/calcstuff/ti83plus.txt) and look at everything between 8A3Ah and 8D3A.
Edit:
$8000 is also free to use as long as you don't archive/unarchive anything, just be sure to call bcall(_fillBasePageTable) when you are done.
-
Is this a program? If so, you could alternately add 768 bytes of data to the program and use that as your fourth buffer.
(Personally I'd use the space at $8000. I used it in Cube Droid and found it the smoothest method of obtaining more data space.)
-
$8000 is also free to use as long as you don't archive/unarchive anything, just be sure to call bcall(_fillBasePageTable) when you are done.
Why do you need the bcall routine afterwards?
-
$8000 is also free to use as long as you don't archive/unarchive anything, just be sure to call bcall(_fillBasePageTable) when you are done.
Why do you need the bcall routine afterwards?
Some operating systems (I believe the 83 ones, but I may be wrong) there is a table that has to do with Applications somewhere in that block of memory. If you destroy it, that bcall will rebuild it and make it as if it was never destroyed.
-
$8000 is also free to use as long as you don't archive/unarchive anything, just be sure to call bcall(_fillBasePageTable) when you are done.
I think using Copy() from an archived file would also destroy stuff in that area, because that uses bcall(_FlashToRam). Also, isn't the base page table only required if you're running a multi-page app with the custom bcall system?
-
Remember that if you want it to be compatible with MirageOS, don't use statVars at all.
-
I think using Copy() from an archived file would also destroy stuff in that area, because that uses bcall(_FlashToRam). Also, isn't the base page table only required if you're running a multi-page app with the custom bcall system?
Yeah, really, anything related flash will destroy $8100. If you destroy the base page table, most likely, you'll never notice. The only time it matters is when you run something before the base page table is built, for instance: a hook to a multipage application (CtlgHelp). So to be safe, just call the bcall.
Remember that if you want it to be compatible with MirageOS, don't use statVars at all.
That's only if you want it to be compatible with the MirageOS interrupt system. Do an IM 1 and you can trash statVars.
-
Remember that if you want it to be compatible with MirageOS, don't use statVars at all.
That's only if you want it to be compatible with the MirageOS interrupt system. Do an IM 1 and you can trash statVars.
Nope, still can't, because MirageOS uses it for more than just interrupts: http://cemete.ch/t5934
EDIT: You were the one who told me that O.o
-
I just ran a program under MirageOS that disables interrupts and then sets 733 bytes starting at statVars to $FF. Upon returning, I notice no errors with MirageOS and no changed options. So it certainly seems like you can trash as much of statVars as you want, just make sure you disable MirageOS's interrupt handler. Maybe MirageOS uses a few bytes for options, like the return location, but setting them to $FF doesn't appear to mess up MirageOS anyways as far as I can tell. Perhaps I need to set a certain byte to a certain value to cause bugs in MirageOS, but I don't know of any such byte.
-
Maybe MirageOS uses a few bytes for options, like the return location, but setting them to $FF doesn't appear to mess up MirageOS anyways as far as I can tell.
If you set some of the option bytes to a valid value like 0 or 1, it does cause some minor glitches when it returns to the shell (for example, making the cursor point to the eight program in a folder that has only four files, which can cause serious problems when you try to archive or rename it).
-
EDIT: You were the one who told me that O.o
;D Ok, so StatVars is free to destroy, however, what you leave there can have negative effects.
The only one I've ever found was leaving a 01 at $8A4A.
I think writing 00's to the whole thing should be safe though.
-
Thanks. :)
Before I asked the question, I was using $8000 and hoping that I wasn't destroying anything. :P