Hi ! I'm very impressed by your work calc84, this is simply amazing ! Because I don't brought my laptop with me I can't test it but it seems really impressing So because I used exactly the same open source C code of gp2x as base for my try-of-sort-of-gba-emulator (wow, great project name, nope ? ^^) I wanted to know if you used the files ARM_EMIT, STUB and other .S files without modifying them and how you organized your makefile to obtain a lighter TNS file than mine (it was 14Mb, so you can easily imagine that the 8mb metroid fusion rom + 160kb bios + 14 mb emulator + 30mb TI-os == reboot ^^). If course if the informations I ask you are classified as "top-secret" or "for-calc84maniac-eyes-only" you are not forced to tell me this Secret Just wanted to know were my code was crashing !

So congratulations for this app, I believe you will suceed in optimizing it and make it perfect better than me (14mb emu ... I need to fix my linker I think ><), great job !

   * Disable document screen refresh on exit, it made exiting too slow.

What exactly were you refreshing ? The whole file system or just the My Documents menu ? Because that would be useless to refresh anything else than the My Documents menu and maybe that was why is was slow ?

Also, I had a feature request. Could file association not change the rom directory ?

For example, I have a.gba in tha A folder and b.gba in the B folder.
I use the gpSP browser to go to the B folder, launch b.gba then quit.
Then I use the file association to launch a.gba, and there, it would be great if gpsp_romdir still indicated the B folder

Quote from: calc84maniac on August 09, 2012, 10:35:26 am

The main "secret" is that I used the ELF loader created by tangrs (with some modifications because it didn't catch all relocation cases) to load my generated ELF file into memory for execution. This solves lots of problems with global variables and such, and I was also able to force it to load to an address aligned to 32 bytes, which Ndless doesn't do. That's why there is a launcher file and a resources file, the latter is actually just an ELF.

I suppose the alignment requirement isfor a screen buffer array, and that tangrs's BFLT loader doesn't support 32-bytes alignment? I? Does ELF allow to define this on a per variable basis?

The screen buffer requires 8-byte alignment, and that was a problem. I used some GCC syntax to align to 8 bytes, but of course this means nothing if the program itself is only 4-byte aligned. Alignment of 32 is nice because of how the program might be optimized due to cache line boundaries. The issue is that malloc itself is only 4-byte aligned, so I had to malloc with the size+32 and then align manually.

I'm wondering if you'll implement (feature request) the codebreaker codes(the one with the syntax like ABCDEF10 0001)

calc84maniac, would the integration of tangrs's BFLT loader to Ndless make the emulator lighter (there's a patch ready for it, and its much more simple that the ELF loader), even if you still need to align the malloc yourself? (I'm not sure if making a 32-byte alignment the default in Ndless would make sense for all programs).

calc84maniac, would the integration of tangrs's BFLT loader to Ndless make the emulator lighter (there's a patch ready for it, and its much more simple that the ELF loader), even if you still need to align the malloc yourself? (I'm not sure if making a 32-byte alignment the default in Ndless would make sense for all programs).

32-byte alignment seems like it would be pretty standard for ARM programs. I'm talking about the program itself; the screen buffers I mentioned are in the .bss section of the program (and this is certainly dependent on the program loader). If the BFLT converter is based on that ELF loader, though, it might be missing some relocation cases. I'm not sure how much lighter BFLT would make it, either (it does define the .bss section by size and not a bunch of zeroes, right?)

Just curious, how well does gba homebrew run?