Is it possible to build a custom PRIME_APP.DAT with your tools?

[parisseb]

Your project looks like very promising, I'd be very interested to know if it is possible to build KhiCAS for the Prime G1 using your tools, like ExistOS does for the hp39gii.
This would bring up some welcome enhancements on the G1 wrt the builtin CAS including:

• up to date Giac/Xcas version with all commands available
• inclusion of LGPL-ed libraries: GMP, MPFR, MPFI: faster bigint support, bigfloat library with arbitrary number of digits computation, interval arithmetic
• programming editor and shell with syntax coloration, parenthese match
• 3d geometry app
• javascript support
  That way the Prime G1 would match other ports of KhiCAS on the Casio fxcg50, Numworks N0110/N0115/N0120 and TI Nspire.

[dogtopus]

First of all, thanks for your interest in this project. It's pretty rare to see others here.

Also, I'm not very familiar with Prime G1 since I don't own one and reversing the G1 firmware isn't really my priority. The priority was always running code on Besta dictionaries, since they have a less restrictive OS with official ways to load external binaries without reflashing boot (ROM) and system (DAT) partitions, unlike G1.

AFAIK almost all of the Prime G1 firmware logic resides in armfir.elf. It should be possible to write code that replaces it. Maybe you could use the GCC provided here to compile the code, but use a custom ldscript to ensure that the ELF will be loaded to the correct RAM address. A second possible option could to be changing the startup INI file to use the relocatable PE files that elf2bestape would generate.

That being said, I'm not sure how beneficial this would really be comparing to something similar to ripem, but with a less janky port of an off-the-shelf OS instead (like FreeRTOS or a heavily trimmed Linux kernel), since AFAIK S3C2416 is pretty well documented.

[dogtopus]

Also to answer your question on the title:

Is it possible to build a custom PRIME_APP.DAT with your tools?

No, at least not at the moment. You'd need to modify that image yourself. AFAIK it only has 1 section (also being a FAT16 filesystem that you can mount read/write and write to it, so it should be pretty easy) but there is some checksum involved, that I still didn't bother to take a look at how it really works. On a second look, seems like it uses the 3 partition layout similar to BA742, and the actual PRIME_APP.DAT aka the AP/system data/"whatever you want to call it" partition is not checksummed.

[parisseb]

Switching to another OS is far out of reach for me. In addition, there is a risk to brick the device. I believe that modifying PRIME_APP.DAT is much more secure, if the device fails to boot, it's certainly possible to do a reset while keeping the Symb key pressed and reflash it with HP connectivity kit.
How did you mount the PRIME_APP.DAT file? I tried mount -o loop with a few -t options without success.

[parisseb]

After doing some hexedit, it seems there is a header of size 0x2000 that does not change between different firmware versions, then the remaining part of the file can be mounted with -t msdos.

[dogtopus]

Yes. It's (mostly) in standard Besta data partition image format and there's a header that you need to either skip or cut out before you mount and edit the filesystem itself. The fact that the partition image has only 1 section made it a lot easier to edit as well.

[parisseb]

Once the fat16 partition is mounted, ls returns
ls /a
appslist.inf appslist.map appslist.md5 bestabfs.ind firstrun.ini programs window

bestabfs.ind is empty. appslist.md5 is a list of MD5 signature.
more /a/firstrun.ini displays:
[RUNING SETTING]
FirstRunApp = \.\ARMFIR.ROM

hexedit /a/appslist.inf has references to BESTAFIR.ROM/bestafir.exe, ARMFIR.ROM/armfir.elf, ARMFIRDB/armfir.dat, HELLO.ROM/hello.exe, ARMHELLO.ROM/armhello.elf, ARMHELLODB.ROM/armhello.dat, DIAGNOSE.ROM/diagnose.exe,

appslist.map is a binary file, it begins by 7, which is the number of references above. I don't know what follows, but I'm afraid it should be modified if the partition is modified.

ls /a/programs/
misc tools
ls /a/programs/tools
bestafir.dat bestafir.exe
ls /a/programs/misc
armfir.dat armfir.elf diagnose.dat diagnose.exe

It is perhaps possible to add an elf file in /programs/misc that is already referenced, e.g. armhello.elf, and replace armfir.rom with armhello.rom in firstrun.ini. This might be better than replacing armfir.elf, because maybe one can load armfir.elf later from hello, if the user want to run the calculator firmware.

[dogtopus]

You might also be able to change the path to something like A:\PROGRAMS\MISC\MYCODE.EXE instead of registering your code as a ROM. This worked for C:\SYSTEM\DESKTOP.INI so I imagine that this would work for A:\FIRSTRUN.INI as well.

[dogtopus]

Also I think chainloading armfir would be difficult since it has hardcoded base address and therefore is not relocatable. You might be able to somehow start the MMU (which is present on S3C2416 but not used in any Besta RTOS build AFAIK) and fake an address range but I never tried anything like that and it may be difficult to figure out how to do that exactly.

[parisseb]

Commandline to get the partition from PRIME_APP.DAT
dd if=PRIME_APP.DAT of=fat16 skip=1 bs=8192
Mounting to an existing /path
sudo mount -t msdos -o loop fat16 /path

[parisseb]

Getting the header
dd if=PRIME_APP.DAT of=header count=1 bs=8192
Merge header with partition
/bin/cp header FILE.DAT && dd if=fat16 of=FILE.DAT oflag=append conv=notrunc bs=8192

[dogtopus]

I'll move this to discussions since it's not directly related to the tools themselves.

[parisseb]

In fact I just rediscovered what was already known 11 years ago, and there is an easier way to modify the fat16 partition
mount -o loop,offset=8192 PRIME_APP.DAT appsdisk/
cf. https://tiplanet.org/forum/viewtopic.php?t=13329#p151670
I could run diagnose.exe by modifying firstrun.ini, It was also ok to copy diagnose.exe to hello.exe and use hello.rom. I do not really understand why there are these *.rom extensions, perhaps using a complete path name would indeed also work in firstrun.ini.
Chainloading is perhaps possible by copying a small loader/launcher code somewhere in an allocated area in the heap (or on the stack?) and running this code. It's not the first task to do anyway. And even if it works at some point,, once you run the HP firmware, you could not escape it without a reset. Having a reset+key shortcut to run a specific *.rom would be nice!

I still have no idea what PRIME_MASTER.DAT is. Is it a part of besta OS that would not fit in 1Mo of PRIME_OS.ROM?

[dogtopus]

In case you still want to know what's inside the MASTER.DAT (spoiler alert: nothing interesting) and as a teaser of what to come for besta-tools, here is a dump of the MASTER.DAT in firmware 20130808.

MASTER.zip

(I named the files that I could identify. The image itself doesn't contain filenames.)

[parisseb]

MASTER/img/lcd_surfaces.bin: could it be HP logo or the circle x^2+y^2=1 that are displayed at ON or after reset?

[dogtopus]

Yes.

[dogtopus]

(The first one is totally not ripped from iOS wallpapers)

[parisseb]

Interesting, I never saw the first one on the Prime...

[dogtopus]

Actually I wonder if Peanut-GB runs on Prime G1. It requires the Besta RTOS file select screen which I'm not completely sure whether or not it's compiled in.

You would need to rename it to something that doesn't require LFN (like pgb.exe).

You might also want to use the pgbcfg.ini file to disable audio and enable scheduler timer since it's known that these S3C2416 boards don't support millisecond RTC, and it's also very likely that audio support wasn't compiled in.

[parisseb]

binutils, gcc, muteki-shims compiled perfectly.
For newlib, I get an 4 times the same error about sys_seek_whence_e, 1st occurence:
In file included from ../../../newlib/newlib/libc/sys/muteki/applet_lifecycle.h:6,
from ../../../newlib/newlib/libc/sys/muteki/applet_main.c:1:
/usr/local/arm-none-bestaeabi/include/muteki/loader.h:281:71: error: unknown type name 'sys_seek_whence_e'
281 | extern int _FseekFile(loader_file_descriptor_t *ldrfd, size_t offset, sys_seek_whence_e whence);
| ^~~~~~~~~~~~~~~~~
CC libc/sys/muteki/libc_a-fstatvfs.o
make[2]: *** [Makefile:31731: libc/sys/muteki/libc_a-applet_main.o] Error 1

[parisseb]

This one solved by adding enum before sys_seek_whence_e in /usr/local/arm-none-bestaeabi/include/muteki/loader.h
Errors later with fwrite, solved by replacing first arg type of fwrite by const void * in /usr/local/arm-none-bestaeabi/include/muteki/file.h
newlib now compiles!

[dogtopus]

For newlib, I get an 4 times the same error about sys_seek_whence_e, 1st occurence

There were some important fixes that I forgot to push to muteki-shims. It should be fine now. Please pull the fixes for muteki-shims and reinstall it before rebuilding newlib.

I tried to copy Peanut-GB.exe to programs/misc/hello.exe and set HELLO.ROM as FIRSTRUN.INI but it did not run (I saw only the x^2+y^2=1 circle+hp logo), unlike the diagnostics if I copy diagnose.exe to hello.exe

I guess it indeed didn't have the file selection screen built into it. Anyway not a big deal. I was just curios that if it would just work.

[parisseb]

Now error in muteki: src/console.c I added #include<muteki/ui/font.h> otherwise GetCharWidth is unknown.
Then an error I do not know how to fix because I could not find vram_descriptor_t in the arm besta include in /usr/local
arm-none-bestaeabi-gcc -Ilibmutekix.a.p -I. -I.. -I../include -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -O3 -mcpu=arm7tdmi -Wall -MD -MQ libmutekix.a.p/src_console.c.o -MF libmutekix.a.p/src_console.c.o.d -o libmutekix.a.p/src_console.c.o -c ../src/console.c
../src/console.c: In function 'mutekix_console_init':
../src/console.c:373:9: error: unknown type name 'vram_descriptor_t'
373 | vram_descriptor_t *fbdesc = GetActiveVRamAddress();
| ^~~~~~~~~~~~~~~~~
../src/console.c:373:37: error: initialization of 'int *' from incompatible pointer type 'lcd_surface_t *' {aka 'struct lcd_surface_s *'} [-Wincompatible-pointer-types]
373 | vram_descriptor_t *fbdesc = GetActiveVRamAddress();
| ^~~~~~~~~~~~~~~~~~~~
../src/console.c:375:19: error: request for member 'depth' in something not a structure or union
375 | if (fbdesc->depth <= 4) {
| ^~

[dogtopus]

I (sort of accidentally) held the fix for mutekix because it was on a different local branch that has TLS support and so. It's now merged since it seems to be pretty stable anyway from my test, and plenty of projects here actually depend on the thread helper as well as the fix.

Thanks for bringing that up BTW.

[parisseb]

Everything is now installed, thanks! And congratulations for your toolchain!
Now some questions for Prime use:
1/ How do I call a syscall that is listed in syscall_def/syscalls_sdk.json? For example LCDOn, so that I'm certain that the screen is on. Maybe I missed something, but I didn't find something in the header files
2/ Do I need to pass specific processor options to arm-none-bestaeabi-gcc ? Like -marm -mcpu=arm926ej-s ? I guess I don't need to pass -ffreestanding. If I build an elf executable, should I name it with an .elf extension? (Like armfir.elf, not like PeanutGB.exe, where file returns MSDOS executable)
3/ I had a quick look at mutekix console, because it seems it's something like that I should try as example. Looking at mutekix_console_getchar(), it seems to be for another device than the Prime and should be adapted, correct?
4/ Do you have some simple helloworld-like program that I could test? (since I could not make Peanut-GB work...)
Thanks in advance!

[dogtopus]

1. For calling syscalls not defined in the header, you can define them outside the header as extern (e.g. extern void LCDOn(void);). You need to know the function signatures before making the call to properly use it though. Also feel free to send a PR to muteki-shims if you are able to figure out some of them.
2. You can, but it's not really necessary since it defaults to a mode that should run on every single Arm-based Besta RTOS devices out there i.e. -marm -mcpu=arm7tdmi. -mcpu=arm926ej-s might be useful if you are targeting Prime G1 only. For the ELF question: It's probably better to have the .elf suffix since firstrun seems to accept 8.3 filenames. Although beware that the ELF file my GCC outputs isn't exactly what Besta RTOS would expect, so for now I'd personally still recommend using elf2bestape to make it a Besta PE executable instead.
3. To be frank I didn't use mutekix_console_getchar() enough. I almost always just poll the events manually using the TestPendEvent, TestKeyEvent and GetEvent combo. And yes you might need to test the keycodes for Prime yourself since most of them probably won't make sense. I should have a keycode test program somewhere too but I need to find it.
4. This is what I've been using to do simple tests: https://gist.github.com/dogtopus/4ebd5c40b8a1c3050b79ae583dfd5ce7

[parisseb]

I just tried 4., using the same compilation script, and elf2bestape return me a test.exe
test.exe: PE32 executable (Windows CE) ARM (stripped to external PDB), for MS Windows, 4 sections
I copy it to the appdisk to programs/misc/hello.exe.
But this time, the calc reboots in a loop.
Perhaps, some loader script should be used, to tell that the RAM starts at 0x30100000?
Thanks for your patience!

[dogtopus]

That's strange. As a way to rule out the obvious possible cause i.e. features being left out from the stripped down kernel, could you comment out some code and see if it gets better? I'd comment out the GetFreeMemory printfs first as a start.

Also I know that HP Prime UI looks drastically different from any Besta dictionaries so I won't be surprised if it turns out that all the UI features were disabled in the kernel other than the most basic framebuffer setup stuff, including font rendering which mutekix_console relies on.

Perhaps, some loader script should be used, to tell that the RAM starts at 0x30100000?

The Besta PE loader is capable of relocating the file so base address shouldn't matter.

[parisseb]

You were right, I got a success with the code below.
Now, I know it works and I'll be able to explore more and I hope to get at some point the required support for my multi-calculator sdk.c/.h, then porting KhiCAS should be possible.
Wonderful, thanks again a lot for all your incredible work!

`// -- compile-command:"arm-none-bestaeabi-gcc -Wall -g -O2 test.c -o test.elf -lmutekix && elf2bestape test.elf" --
#include <stdlib.h>

#include <muteki/memory.h>
#include <muteki/utils.h>
#include <muteki/ui/event.h>
#include <mutekix/console.h>

// Declaration here

// End of declaration

int main() {
ui_event_t uievent = {0};

mutekix_console_init(NULL);
atexit(&mutekix_console_fini);

//mutekix_console_printf("GetFreeMemory() -> %u\n", GetFreeMemory());

// Experiment here
mutekix_console_puts("Hello world!");
// End of experiment

//mutekix_console_printf("GetFreeMemory() -> %u\n", GetFreeMemory());

while (true) {
    if ((TestPendEvent(&uievent) || TestKeyEvent(&uievent)) && GetEvent(&uievent) && uievent.key_code0 == KEY_ESC) {
        return 0;
    }
OSSleep(1000);
mutekix_console_puts("Hello world!");
}

}
`

[dogtopus]

Nice. Glad to see you got it to work.

Feel free to let me know if you have other questions in the future.

[parisseb]

I tried to detect keycodes, but I got nothing with uievent.keycode0 (always 0 except when you press shift-ON where a 45 appears) nor with keycode1.
There is a strange issue with a reset loop when I tried to print both keycodes with mutekix_console_sprintf.
I tried a workaround with my own printing code in case sprintf had an issue. But I'm still faced with a strange reset loop. If I compile the code below I get the reset loop (the 5s. sleep does not occur). If I uncomment the return 0; the program runs fine. Any idea why it can reset immediatly, without waiting at least 5s and showing Hello world? (The size of the exe remains the same, 162816 bytes).

// -*- compile-command:"arm-none-bestaeabi-gcc -Wall -g -O2 test.c -o test.elf -lmutekix && elf2bestape test.elf" -*-
// Install once muteki toolchain : https://github.com/Project-Muteki/besta-tools/discussions/7#discussioncomment-10092093
// Compile program with command above
// Transfert to the Prime G1:
// check once that inside PRIME_APP.DAT FIRSTRUN.INI is set to HELLO.ROM
//  sudo mount -o loop,offset=8192 PRIME_APP.DAT appdisk &&  sudo cp test.exe appdisk/programs/misc/hello.exe && sudo umount appdisk
// copy PRIME_APP.DAT to 'Documents/HP Connectivity Kit/Micrologiciel/PrimeG1' and run HP connectivity kit
// ON-Symb on the G1. Leave HP CK after 1 update.
#include <stdlib.h>
#include <stdio.h>
#include <muteki/memory.h>
#include <muteki/utils.h>
#include <muteki/ui/event.h>
#include <mutekix/console.h>

// Declaration here

// End of declaration

void append(char * buf,unsigned u){
  for (;*buf;++buf) ;
  int tab[8]={0};
  int i=0;
  for (;u;++i){
    tab[i]=u%16;
    u=u/16;
  }
  if (i==0){
    *buf='0';
    ++buf;
  }
  for (--i;i>=0;--i){
    int c=tab[i];
    if (c>=10)
      *buf='A'+c-10;
    else
      *buf='0'+c;
    ++buf;
  }
  *buf=0;
}

int main() {
    ui_event_t uievent = {0};

    mutekix_console_init(NULL);
    atexit(&mutekix_console_fini);

    //mutekix_console_printf("GetFreeMemory() -> %u\n", GetFreeMemory()); // reset on G1
    OSSleep(5000);

    mutekix_console_clear();
    mutekix_console_puts("Hello world!");
  // return(0);
    OSSleep(5000);
    while (true) {
      if ( (TestPendEvent(&uievent) || TestKeyEvent(&uievent)) && GetEvent(&uievent) ) {
	char buf[256];
	unsigned * ptr=(unsigned *)&uievent;
	for (int i=0;i<sizeof(uievent)/sizeof(int);++i){
	  buf[0]='0'+i;
	  buf[1]=':';
	  buf[2]=0;
	  append(buf,ptr[i]);
	  mutekix_console_puts(buf);
	  OSSleep(500);
	}
	sprintf(buf,"Keycode %u %u",uievent.key_code0,uievent.key_code1);
	mutekix_console_puts(buf);
      }
      OSSleep(50);
    }
}

[parisseb]

After some more tests, it seems that the size matters. If there is too much code, resets happen.
Perhaps the code is loaded in an already used RAM part

[parisseb]

Or maybe the loader overwrites memory while copying rodata or data.
Is it possible to link the code to a non relocatable address, like armfir.elf does at 0x30600000?

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 ER_RO         00735c80  30600000  30600000  00000034  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 ER_RW         00006bdc  30d35c80  30d35c80  00735cb4  2**3
                  CONTENTS, ALLOC, LOAD, DATA
  2 ER_ZI         0000602c  30d3c85c  30d3c85c  0073c890  2**3
                  ALLOC
  3 .note         0000001c  00000000  00000000  0073c890  2**2
                  CONTENTS, READONLY
  4 .comment      0007b85c  00000000  00000000  0073c8ac  2**0
                  CONTENTS, READONLY

[dogtopus]

There is a strange issue with a reset loop when I tried to print both keycodes with mutekix_console_sprintf.

Yes, seems like mutekix_console_printf was hit by a regression (or maybe a hidden bug somewhere that I never managed to uncover) that causes it to be unstable (some combinations crash the system, while deleting some seemingly irrelevant code stabilizes it). I need to look into this further. Meanwhile -O0 seems to be a good workaround.

EDIT: Maybe it's not just mutekix_console_printf since I've been seeing some strange and potentially unexplained crashes on other cases as well, where the code looked completely fine but will crash anyway on all devices I have.

After some more tests, it seems that the size matters. If there is too much code, resets happen.
Perhaps the code is loaded in an already used RAM part

Hmm I guess there is actually a shrunken heap on Prime? That would explain why the armfir.elf loads to 0x30600000 instead of immediately after the OS kernel or something. So maybe the heap is only about 5MB in size?

You could try to use this to check the heap region (probably try to compile it with -O0 for now due to the instability issue I mentioned):

#include <stdlib.h>
#include <errno.h>

#include <muteki/memory.h>
#include <muteki/utils.h>
#include <muteki/ui/event.h>
#include <mutekix/console.h>

// Declaration here
#include <inttypes.h>
// End of declaration

int main() {
    ui_event_t uievent = {0};

    mutekix_console_init(NULL);
    atexit(&mutekix_console_fini);

    //mutekix_console_printf("GetFreeMemory() -> %u\n", GetFreeMemory());

    // Experiment here
    uintptr_t *mem = lmalloc(16);
    if (mem == NULL) {
        goto fail_nofree;
    }
    uintptr_t heap_next = mem[-1];
    uintptr_t heap_prev = mem[-2];

    mutekix_console_printf("heap_next = %" PRIxPTR ", heap_prev = %" PRIxPTR "\n", heap_next, heap_prev);

    uintptr_t *prev = (uintptr_t *) heap_prev;
    while (true) {
        if (*prev == 0) {
            break;
        }
        prev = (uintptr_t *) *prev;
    }

    mutekix_console_printf("heap_head = %" PRIxPTR "\n", (uintptr_t) prev);

    uintptr_t *next = (uintptr_t *) (heap_next & 0xfffffffe);
    while (true) {
        if ((*next) == 0 || (*next) == 1) {
            break;
        }
        next = (uintptr_t *) ((*next) & 0xfffffffe);
        next++;
    }
    _lfree(mem);

    mutekix_console_printf("heap_tail = %" PRIxPTR "\n", (uintptr_t) next);

fail_nofree:
    // End of experiment

    //mutekix_console_printf("GetFreeMemory() -> %u\n", GetFreeMemory());

    while (true) {
        if ((TestPendEvent(&uievent) || TestKeyEvent(&uievent)) && GetEvent(&uievent) && uievent.key_code0 == KEY_ESC) {
            return 0;
        }
    }
}

[parisseb]

From my experiences, I can say that mutekix_console_printf is not raising the crash, because I have the delay of 5s before calling it. The crash happens either at load time, at init time or in one of these calls
mutekix_console_init(NULL);
atexit(&mutekix_console_fini);
Your test program raises the reset loop :-(
Perhaps armfir.elf is loaded at 0x30600000 so that there is room to load data from armfir.dat before?
When the Prime G1 is loaded with HP firmware, it reports 15.48M of RAM free, this is certainly not at addresses under 0x30600000, it must be after. Since 0x30600000+size of armfir.elf = about 0x30db0000, the heap certainly begins here and ends at 0x31d00000 (16e6 bytes - the part already allocated when the G1 runs). And the area 0x31d00000-0x32000000 is probably reserved for besta use.

[parisseb]

I just added an OSSleep(5000) before muteki_console_init and atexit. The reset happens immediatly, so the conclusion is that the crash is raised by the loading/init code.
Assuming besta load code is ok, I believe something bad happens in newlib/newlib/libc/sys/muteki/crt0.c

[dogtopus]

Then maybe the random crashing I was seeing had nothing to do with the crash you were seeing in the first place.

If the init code is broken, my first guess would be the TLS routines, since I abused some implementation details to get it to work. It would probably be hard to actually remove it though since I sort of hardcoded newlib to use TLS at all times. Maybe you can try to comment out the TLS code and also remove the --with-tls or whatever it's called flag from the configure script and see if the problem goes away.

And the area 0x31d00000-0x32000000 is probably reserved for besta use.

You nailed it. Besta RTOS reserves some RAM space for things like framebuffer.

[dogtopus]

Actually before that you can probably override applet_startup and/or applet_main to see if it's the calls there that cause problems.

[dogtopus]

Just for the record: Other than the difference in event formats, which is discussed later in this post, there's another related possible cause of crash.

There seems to be a bug in the Besta PE loader, that will cause a crash when the relocation section perfectly fills a single or multiple physical pages (i.e. the relocation data having the length of exactly 0x200 * n). This is now fixed in elf2bestape by always adding padding to the .reloc section. This means 0x1ff bytes will still be padded to 0x200 bytes, but 0x200 bytes will now be padded to 0x400 bytes instead of adding no padding.

[parisseb]

I don't understand what happened, probably I made some bad manipulation, because now all is working: I changed crt0.c to

#if 1
	char *argv[1] = { "" }; // ?"hello.exe"
	exit(main(1,argv));
#else
        exit(applet_startup(exec_proto_ver, app_ctx, _sbz));
#endif

then compile/install, tried again with #if 0, all the test programs are now working, including yours, it shows heap head at 0x30100000 and end at 0x31cffffc

Now, the event structure does not detect the keyboard, except OFF. Besta has certainly an extended event structure, that handles the multitouch screen as well as simultaneous keys. On your devices, I guess you do not have mouse-like and multi-keys events?

[parisseb]

The event structure has size 6*4 bytes in your implementation. If I declare unsigned tabevent[12]={0}; and call GetEvent((ui_event_t *) tabevent), there is additionnal data on the Prime for a keystroke;
tabevent[6] = 1, tabevent[7] = 0x10 (keydown) or 0x100000 (keyup), tabevent[8] has a value depending on the key. For example 1 key -> 0x590000, 2 key -> 0x5a0000
If I touch the screen,
tabevent[6] = 1, tabevent[7] = 0x2 (mouse down) or 0x8 (mouse up), tabevent[8] and [9] have non zero values certainly related to the coordinates

Therefore I think you should enlarge the ui_event_s structure declaration in muteki/ui/common.h, with a reserved tab of unsigned of size at least 8 (for multi-touch events, perhaps 16 for safety...), otherwise there will be memory area overwrites when calling GetEvent.
I'm myself adding a field unsigned primeg1[16];

[dogtopus]

I'll take a look at the Prime firmware when I got some time.

There's already this precedence lcd_thread_safe_s that handles data format differences across different Besta RTOS revisions but it's sort of incomplete and I'm not very proud of it (needs to manually cast). I'll try to formalize something that works on every device without rebuilding muteki-shims and plays well with doxygen, possibly through macros and a bunch of @sees.

[dogtopus]

I just set up a preliminary Prime G1 firmware reverse engineering project and I'm already discovering something horrifying.

The event struct for Prime G1 is sized at whopping 124 (!) bytes.

I have no idea why it's so large and what those extra data actually do.

I guess that's probably half the reason why you're seeing frequent crashing.

[parisseb]

Indeed 0x7c=124. That's 100 bytes more than before. Therefore unsigned primeg1[16] is not enough, I should modify to 25.
That's indeed a lot. Handling multi-touch screen and perhaps also simultaneous keys (like in ON-F-O-C) requires to have room for at least 4 "single events" in the same structure.
100=25 unsigned, could be 5 unsigned per "single simult event" and 5 single events.
Or 4 bytes for the number of single events, and 96/4=24 unsigned.
Could be 4 events (6*4=24 bytes per event), or 8 (!) events (12 bytes per event) if we have simultaneously keys and touchscreen.

[parisseb]

In fact, it seems to be 3 unsigned per "single event" (12 bytes)
For a multi-touch event for example I get in my unsigned primeg1[]
0: 2
1: 8
2: 0x820000
3: 0x96
4: 8
5: 0xe10001
6: 0x65
7: 0

For the key 1 input
0: 1
1: 0x10
2: 0x590000
3: 0
4...: 0

In other words, the event structure could report up to 8 simultaneous "single events", and the first value of the table primeg1 is the number of simultaneous single events (2 for 2 fingers on the touch screen, 1 for 1 keypressed)

[parisseb]

The keycode returned for a keypress corresponds to the alphabetic key written in orange if present. It's a 2 bytes integer, the 2 last bytes are 0000.
shift: 0x8b, symb: 0x91, plot: 0xb2, num: 0xb3, help: 0x95, view: 0xb4, menu: 0x93, Esc: 0x1: CAS: 0xb5
left: 0x2, right: 0x4, up: 0x3, down: 0x5
apps: 0xb1, home: 0xe047
alpha: 0xb6, -: 0xb7, .: 0xb8, +: 0xb9,

ON: does ON or OFF, like the Power key on the Numworks calculator.

[dogtopus]

I think it's ok (but I did not look at endianness). The last unk_0xb field is probably here for 4 bytes align. Note that I observed uievent.primeg1[0] (==available_multipress_events) was 0x20000 for a few events when hello.exe starts.

So I guess it's 2 unsigned shorts instead of 1 size_t?

[dogtopus]

Also could you try mutekix_console_printf and GetFreeMemory again with the new event struct? Since the allocation size is now fixed, it shouldn't corrupt the memory anymore.

[parisseb]

Probably but I have no idea what 0x20000 means.
GetFreeMemory returns 26332536 on my G1
main is located at 0x3044f15c, and the "rodata %x" string is at 0x3019d050

[dogtopus]

I updated muteki-shims to reflect the Prime G1 event struct format. You can opt-in with -DMUTEKI_HAS_PRIME_UI_EVENT=1.

[parisseb]

Thank you!