Omnimaga
Calculator Community => TI Calculators => Calculator C => Topic started by: blue_bear_94 on June 21, 2012, 11:08:13 am
-
As you know, assembly programs on the 68k are limited to 24 KB for AMS 2.05 and up. I am programming a large game, and aside from storing maps and enemy data externally, I need a way to reduce the size of the main program. It's already about 5K right now, and without much in it. I considered putting certain functions in an external file, but I asked: 1. How would functions with arguments be called? and 2. How would I determine the offset for certain functions? I am also considering putting the main game content in chapters and in separate files, but I have no idea how to use global variables from the main program. Any ideas? Thanks in advance!
-
Someone will have to answer the other questions. But if you haven't already, you might also consider the optimization options available in TIGCC/GCC4TI, which may help with executable size. http://debrouxl.github.com/gcc4ti/httigcc.html#advanced There are especially things like FLINE calls/jumps, which trade off speed for size. And, of course, there are the compressed programs (the ones that use Super Start/ttstart/their own launcher), but I haven't made one myself yet, so I don't know much about making those.
-
Thanks! But since the original TI-Basic program spans about 82 KB in size, I'll need more than these.
-
The size limit for assembly programs is even 8 KB on the earliest AMS 2.xx versions; it was raised to 64 KB (i.e. made completely ineffective, but the code is not suppressed...) for the 89T.
But frankly, nobody bothers with the size limit until the program's size reaches 55-60 KB (at which point it's time for a round of optimization). The "ASAP or Exec string too long" and "Invalid Program Reference" artificial limitations are nullified by:
* PreOS and KerNO;
* by using a compressed program, as TravisE mentioned;
* by using tiosmod+amspatch'ed OS, but that's not very easy, for non-technical (read: legal) reasons.
About optimization: over the years, I've optimized dozens of third-party programs. I've summarized this experience in a tutorial about optimization of TI-68k programs, http://tict.ticalc.org/downloads/S1P9.zip :)
The documentation of GCC4TILIB's system for DLLs (dll.h) and the documentation of PreOS give a number of explanations about the concepts and implementation, and FAT Engine has its own DLL support. GCC4TILIB's sytem is very limited, in that it doesn't support more than one DLL at a time, which is a significant restriction for some use cases. So-called "kernels", namely PreOS, provide a much more powerful system.
I once spent a bit of time making a simple (probably simplistic), fairly rough proof of concept for multiple simultaneous DLLs. Needless to say, the program requires HW2/3Patch, because trying to execute multiple simultaneous DLLs without relying on the RAM execution protection being disabled is insanely complicated and slow. http://tict.ticalc.org/downloads/launchmultiple.tar.bz2 if you're interested in it.
Don't hesitate to ask more questions :)
-
So... the 24K protection is not present on 3.xx?
-
Yup, at least on the 89T. I don't remember about the V200 offhand, and anyway, it doesn't matter: as I wrote, the 8K/24K limit has never been more than a minor annoyance. Don't worry about it ;)
-
Can I at least put some of my code in another program?
-
Sure, that's precisely the purpose of GCC4TILIB's DLL support, and the purpose of the better PreOS DLL support ;)
-
Hmm... It seems that the main program needs to be executed in the ghost space (which doesn't work on the Titanium) for GCC4TI's DLL support, and I don't want to force the user to install PreOS...
-
On the 89T, users will have to install HW3Patch (easiest solution), or install PreOS (which disables the RAM execution protection), or use tiosmod+amspatch'ed OS (but nobody does that, because it's not very convenient - for legal reasons, users have to either compile and use the patcher by themselves, or use the provided binary diffs).
If you don't want to rely on PreOS's features, but nevertheless want to use more than one DLL at a time, then you'll have to embed your own custom support into the program...
BTW: splitting the program into pieces has a size cost (and an associated speed cost, though it's very low, unless you're jumping back and forth and the functions' bodies contain very few instructions).
Until you have done more of your program (say, you're reaching ~50 KB), don't bother splitting your program into pieces, but start a bit of optimization on it (e.g. reading and writing files through native, non-standard vat.h functions, rather than standard, non-built-in stdio.h functions, or worse, the pitiful semi-standard, built-in functions from files.h). Around the 50 KB mark, we can optimize the program further; when you're really going to hit the limit fairly soon, then we can start focusing on splitting the program.