I am writing a game in ASM on the ti-83+/ti-84+ and have reached the 8200 byte size limit. No problem, I broke the game into two separate programs, one being 7124 bytes and the other 1301 bytes and 15817 bytes free in ram. The second program will eventually be about 7000 bytes also. I am using b_call(4E7Ch) to execute the second program from within the first. It runs fine, both from the first program and as a stand alone program. When run as a stand alone it does nothing to my free ram.

When I execute any program using b_call(4E7Ch) from the first program my available free memory goes down by 7100+- bytes. I can archive the two programs and reset the calc to get the memory back, but I can not find the bug. Here is the code I am using. Does anyone see anything I am overlooking? Or is there another way to run a program from another program? Does a shell take care of the 8200 byte size restriction for programs? My game was the only thing in ram with 15000+ bytes free and said something to the effect of variable size limit exceeded.

Hunt:

Code:

The 8200 size limit only applies to code, not data, so if you rearrange your program to have all code before data you might be fine. That being said, if you actually do need more than 8200 bytes of code, you can make it into an app which allows almost 16k of code without any trickery, or as much room as you have in archive if you are willing to jump through the hoops of making a multipage app.

Edit: The reason using ExecutePrgm leaks memory is because it doesn't unallocate the currently running program. You would have to delete yourself before using that bcall, or only use it from an app.

Is there a way to unallocate the currently running program? I can make a jp routine at the beginning to get me back to the correct position in the game.

Thanks for the info. On five websites claiming they can help, no one even knew what I was talking about. My code is almost all code. I could move my variables into "safe ram", set them when I declare them and gain a couple of bytes, but only 100 or so.

I really need that extra 8000+- bytes. I don't know about application programming. ZDX doesn't work for me as I can not get even their examples to compile and I use TASM. Can't figure out how to use TASM for application programming. Also, as I understand it b_call's are gone unless you load your info into ram first. That takes even more memory. Can't ask for that much memory for my game. Its good, but not a 3 page app good.

Can I store pictures etc in another program that does nothing and just access them without running the program?

Generally the preferred method is to delete the currently running program with bcall(_Delmem), copy the new program to usermem (Using bcall(_InsertMem) and ldir), and at the end of your program execute a bcall(_Delmem) to erase the copied program and return to the OS. SPASM is by far the preferred assembler today; feel free to look it up Also, welcome to Cemetech! Let us know if we can help more

You can store pictures into AppVars, and just read them as data as well.

You would have to copy a routine that bcalls DelMem to saferam and then call it. The whole point of bcalls is that they only take up 3 bytes of code in the program and call os code in archive, so they take up almost no space. For app programming the easiest is to use spasm's app.inc. When I say data, I mean precisely things like pictures. If you move the pictures to the end of your program, they don't count towards the 8200 code size limit.

Thanks. Ive never looked at spasm. I will give it a try. Also the moving pictures to the end may save enough space if I go through and optimize out things like ld a, 0. I usually don't do that until the end, but might have to just start thinking of it when coding.

Anyone know why the 8200 byte limit exists? Maybe how to change it?

Way back in 1996, when TI started working on the TI-83+, they wanted to start an app store (no, Apple definitely did NOT think of it first). They implemented cryptography on the software side to prevent people from pirating apps, but, supposedly, they were worried about apps being hacked and run in RAM, so they implemented hardware that limits PC to being less than C000. I believe the OS won't execute programs larger than 8 K; however, it's trivial for a shell to bypass that limit, and all shells do, so if you make your program require a shell, you can simply keep all 16+ K in a single file, assuming you don't need more than 8 K of executable code.

You can read---but not execute---data directly from the archive, so streaming data from the archive is also viable if you don't mind taking a performance hit due to every read requiring a page alignment check. If you don't want to be dependent on a shell to let you have a bigger program, and you can keep your executable code to < 8 K, you can check if there is enough available RAM to copy your second program into RAM, and if so, call _InsertMem on yourself, at your final address, and then use _FlashToRam to cache your data file to a known, fixed location in RAM (the end of your program). Just make sure to _DelMem that data before quitting.

There ARE various ways to execute code past C000, but they either involve changing the memory map configuration, or changing the protection ports. The former is fragile and prone to crashing if you use certain OS routines, and the latter requires using some kind of exploit in the OS to allow you to change the values in the ports that control memory protection. Also, the latter doesn't work on the TI-83+, but it does work on the TI-83+SE, TI-84+, TI-84+SE, and TI-84+CSE.

You can find everything there is for a programmer to know about TI-83+ series ports at http://wikiti.brandonw.net/index.php?title=Calculator_Documentation, along with a bunch of OS documentation you won't get from TI.

The protection hardware in the TI-83+ through TI-84+CSE is quite robust, and can't be tricked; however, the OS has at least a dozen exploits that let you disable the protection hardware. By contrast, the protection hardware in the TI-84+CE is trivially bypassed due to hardware bugs, so nobody's really bothered with looking at OS exploits.