Forum TI-Planet.org

(Ok apparently it was just due to an old CEmu version, it's fine now)

Ok, now it does not reboot with the latest nightly build.

Everything is working now. I have a better understanding on app splitting. One question: what is the maximum size for a splitted app? Is it limited to half the free flash size?

With the way that the installer currently works, yes, it won't be possible to install an app that's larger than about half the amount of free archive, since the app is allocated before the variables containing its data are deleted. If your app is large enough that that becomes an issue, I could probably use a more complicated installer that works a page at a time.

This will indeed be an issue. The smallest size of a KhiCAS port is the Casio FXCG50 port in 1 file, it is 2M large and I had a hard work by hand to make a light version discarding some parts of giac (like geometry). I expect a future ez80 port to be a little bit smaller than a sh4 port, but fitting in less than 1.5M would be a big challenge.

I have a somewhat better understanding on how things work, here is a summary, please correct me if I'm wrong.

• SDK doc: https://ce-programming.github.io/toolchain/index.html
• Makefile options https://ce-programming.github.io/toolch ... tions.html
• memory layout: https://ce-programming.github.io/toolch ... c/faq.html
• Default parameters are in CEdev/meta (and app_tools if present)
  In makefile.mk:
  

  Code: Tout sélectionner

  BSSHEAP_LOW ?= D052C6
BSSHEAP_HIGH ?= D13FD8
STACK_HIGH ?= D1A87E
INIT_LOC ?= D1A87F


• BSSHEAP corresponds to a safe memory area that TI seems to use for temporary buffers (https://wikiti.brandonw.net/index.php?t ... By_Address).
• According to this documentation, for a normal program running from RAM, INIT_LOC starts a 64K area that is located at the begin of UserRAM and is used for code+data+ro_data. For a flash app, code and ro_data will be in flash. This means that we have 64K for data, and only 4K for stack. 4K of stack is not enough for an application like KhiCAS, and also probably not sufficient for micropython+shell/editor. Can we set STACK_HIGH to another value? I think the global area stack+data could be "reversed", I mean stack top at 0xD2A87F and data(+code+ro_data for RAM programs) at a new position: INIT_LOC=D1987E (maybe +1 or +2)
• other potential free RAM areas
  1023 bytes: uint8_t[1023] os_RamCode (do not use if a flash write occurs)
  size_t os_MemChk(void **free) size and position of free ram area.
  Or we could create a VarApp in RAM with no real data inside and use this area for temporary storage.
• more complex but interesting: at 0xD40000 we have Start of VRAM. 320x240x2 bytes = 153600 bytes. Half may be used in 8 bits palette mode (graphx) if direct rendering is used (no swapping). This might be used to increase heap size by replacing malloc/free with a custom malloc like kmalloc from gint (authored by Lephe, available for Casio calculators, it should be portable to the TI83)

A few other things that are worth noting:

• The default data section for apps is not stored in userMem and is substantially smaller than that of a regular program. I forget the exact amount but believe it's under 5 KB. BSS and the stack are still in the same place.
• AppVars in RAM can move around, and I believe that the result of os_MemChk does as well, if variables or files are modified.
• The stack can definitely be moved around if necessary, though I believe several OS routines have checks for stack overflow that assume that the stack is in the default position.
• You could can statically allocate memory at userMem, but this requires you to call InsertMem and update asm_prgm_size, and it needs to happen in the crt script before dynamic libraries are loaded. I could probably add an option to app_tools to do this automatically and use userMem for the data section.
• You could in theory back up the entire contents of RAM to flash each time the app is run and restore it afterwards (the OS has a mechanism for doing this), allowing you to use the memory basically however you want, but you wouldn't be able to use most TI-OS functions, so it would involve a substantial amount of reimplementing stuff.

In other news, I'm basically done with an installer that's capable of installing much larger apps. At this point it's mostly just figuring out how to integrate it into the build system.

commandblockguy a écrit:The default data section for apps is not stored in userMem and is substantially smaller than that of a regular program. I forget the exact amount but believe it's under 5 KB. BSS and the stack are still in the same place.

On the monochrom Casio, giac data is about 1K (ro data is of course much larger, about 160K), it should fit without any change.

AppVars in RAM can move around, and I believe that the result of os_MemChk does as well, if variables or files are modified.

Then it's not an option, except for a temporary buffer (like for example allocating the structure for the complete catalog of khicas commands).

The stack can definitely be moved around if necessary, though I believe several OS routines have checks for stack overflow that assume that the stack is in the default position.

If the checks are "as usual", they will only check that the stack pointer is >= to the system stack low at D1A87E-4K, they won't check that it's <= to D1A87E. Therefore if the stack is moved somewhere above D1A87E, it should not be a real problem, is this correct?

You could statically allocate memory at userMem, but this requires you to call InsertMem and update asm_prgm_size, and it needs to happen in the crt script before dynamic libraries are loaded. I could probably add an option to app_tools to do this automatically and use userMem for the data section.

I don't need memory for the data section, I need memory for the stack. 16K would probably be sufficient, maybe 20K (20K is what we have on the Casio, but the 83 will probably require less with many data structs of size 3 instead of 4). If we have access to more memory (say another 16K), giac may store some fixed-size data that are normally heap-allocated, this spares memory and is faster.

In other news, I'm basically done with an installer that's capable of installing much larger apps. At this point it's mostly just figuring out how to integrate it into the build system.

Great news!
Thank you a lot!