In Axe you have getCalc which is equivalent to malloc.

That is looking awesome, good luck with it!

Using an appvar (or any other variable but appvars are best since you can name them as you want and have them the size you want) is not really processor demanding. And you only need to provide its name once in the program since then it is repered by a pointer and no longer by its name (except if you lost that pointer and need to find it back). Here is an excellent tutorial about appvars (and external vars in general). Also, as StreetWalker said, when you need a lot of RAM, you don't really have the choice, you have to use those if you don't want you array to be in parts.

Using an appvar (or any other variable but appvars are best since you can name them as you want and have them the size you want) is not really processor demanding. And you only need to provide its name once in the program since then it is repered by a pointer and no longer by its name (except if you lost that pointer and need to find it back). Here is an excellent tutorial about appvars (and external vars in general). Also, as StreetWalker said, when you need a lot of RAM, you don't really have the choice, you have to use those if you don't want you array to be in parts.

what I mean is that you can't really use GetCalc as malloc in situations like these:

entity **collision(entity e) {
  entity **es = malloc(sizeof(entity *) * 16);
  int cursor = 0;
  for (int i = 0; i < num_entities; i++)
  if (collision_exists(entities[i], e)) {
      es[cursor++] = &entities[i];
  }
  return es;
}
Which is the primary use of malloc in modern C.

GetCalc is mainly used if you need persistant data (I don't), or if you need more ram than you can get away with statically allocating with Buff (I do).

I suppose it's possible to use a hack and dynamically generate names for appvars, store the name somewhere in the pointed memory block, and free it with DelVar using that name, but that's inefficient and unrealistic.

This is an off-topic discussion, and I feel like this isn't really the place for it.

If you write it in C on the computer, will you try to update the Axe version simultaneously too so we don't have to wait until the C version is completed before the calc version even starts being worked on?

Else, another idea could be to use SDCC (like AHelper is doing for his TI-84+ OS on Cemetech) so you can write the calc version in C as well. I heard that calc C is a bit slower, but nobody really ever tried making the same program in both calc languages to compare afterward.

If you write it in C on the computer, will you try to update the Axe version simultaneously too so we don't have to wait until the C version is completed before the calc version even starts being worked on?

Else, another idea could be to use SDCC (like AHelper is doing for his TI-84+ OS on Cemetech) so you can write the calc version in C as well. I heard that calc C is a bit slower, but nobody really ever tried making the same program in both calc languages to compare afterward.

I like that idea. I also like GlassOS, and I want to see it be successful. I'm considering developing isaac for GlassOS, to support it, even though that would mean a much smaller player base. If anyone sane is going to decide to switch to it, it's going to need to need some seed programs.

However from what I've heard, the linking tool isn't building right now, or at least something is broken. I'll get in contact with ahelper to see if there's some work around or if I can help fix it.

Sorry if this disappoints anyone wanting to see this project on AOS, but I think this is the direction I'll take the project.

I *think* Ahelper was saying there might be a way to get SDCC to output code that was compatible with TI-OS (is this what you mean by AOS?). I think if you release this as a GlassOS exclusive, your audience will be next to zero. IIRC, it can't be dual booted with TI-OS, and as far as I know, it is pretty far from a release. Nothing against GlassOS, but if anything, I'd suggest a dual release.

Yeah, I know. I'm fine with no audience. However, you bring up a good point with the dual release. with a bit of conditional compilation and a separate rel file, it should be possible to compile it for multiple targets.