The default emu_debug_alloc_size is 8MiB. It prints a message "[Zehn] emu_debug_alloc_size too small!" if the executable needs more.

Quote from: gameblabla on April 22, 2016, 02:45:25 AM
Mame for TI Nspire, you want it ?
It's yours my friend, as long as you debug it with GDB !
TNS file
Github repo

Trying to port Wolf4SDL and guess what ? Crashes.
Crashes before the application even starts...
Same thing for MAME apparently.

I tried to compile it, didn't work. I had to add "#undef TRUE" and "#undef FALSE" to nucleus.h.
The reason for the crashes is probably that malloc fails. The binary is also too big to be debugged (without tweaking emu_debug_alloc_size) and it doesn't even load on OS >= 4.0.

Quote from: catastropher on April 20, 2016, 04:35:07 PM

Quote from: Vogtinator on April 19, 2016, 04:16:59 PM
I experimented a bit with nGL and found that the caches (I and D) are your biggest friends and enemys. Especially on the Nspire, RAM is horribly slow, so huge tables will cause more slowdowns than speedups. Still: Do many benchmarks and profile everything!

Thanks for the suggestion! I actually didn't realize the Nspire has cache... oops haha I've changed my texture format to be indexes into a color table (8 bits, 4 bits, or 1 bit). Hopefully that'll increase the chance of a texture fitting in cache! I may also implement mipmapping and reduce the resolution of the textures (right now I'm using 128x128... perhaps 64x64 or 32x32 will work better).

Maybe, but I'd expect that mipmapping might slow it down.

QuoteAre there instructions for the emulator somewhere? I never could get it to work for some reason so I've been testing on the real device.

https://github.com/nspire-emus/firebird/wiki/First-Time-Setup
Keep in mind that the emulation is not cycle accurate, it's actually not even close.

QuoteAlso, how would I go about profiling things?

Either manually by putting some output into your code or by running it through a profiler such as gprof or valgrind's cachegrind on x86 or ARM.

Quote from: catastropher on April 19, 2016, 03:42:18 PM

Quote from: Vogtinator on April 19, 2016, 03:10:11 PM
Gouraud shading is using interpolated vertex normals for lighting, isn't it? If so, definitely awesome!

Indeed it is! I actually got lighting/dithering to work faster than texture mapping for colored walls. The tricky part is getting that to work with textures. Luckily, I think I've found a solution that involves several huge color tables haha

I experimented a bit with nGL and found that the caches (I and D) are your biggest friends and enemys. Especially on the Nspire, RAM is horribly slow, so huge tables will cause more slowdowns than speedups. Still: Do many benchmarks and profile everything!

QuoteRight now, my biggest bottleneck is that I'm doing perspective-correct texture mapping for every pixel. I'll likely do what Descent did and only do it once every 16 or 32 pixels. Curse you ARM for not having a division instruction!

I'm only doing affine mapping in nGL and it doesn't really make a difference when playing.

Quote from: catastropher on April 19, 2016, 04:34:21 AM

Quote from: Vogtinator on April 19, 2016, 04:24:58 AM
That looks great! Now add shadows and ambient occlusion to make it look even better

haha While I can't do either of those things, I have figured out a way to do gouraud shading with textures at a very low cost... hopefully I'll add that in once I get it fast enough!

Gouraud shading is using interpolated vertex normals for lighting, isn't it? If so, definitely awesome!

QuoteFor anyone who's interested in a bit of eye-candy (hopefully it'll look a bit familiar):

That looks great! Now add shadows and ambient occlusion to make it look even better

QuoteLol, imagine if Nspire C had linking capabilities

It has: https://hackspire.unsads.com/index.php/Syscalls#NavNet

Quoteand someone made a game that had a quadruple screen mode that allowed one to use 4 TI-Nspires as one large screen. It would be akward XD

*awesome!

An experimental emscripten version can be found on https://nspire-emus.github.io/firebird/firebird.html
OS 3.1 boots in around 40 seconds.

Quote from: Adriweb on March 26, 2016, 12:07:16 AM
It's been talked about on TI-Planet and, well, the Ndless repo (see the recent commits) along with several Ndless programs that got updated for it

The main reference is hackspire: https://hackspire.unsads.com/index.php/Libndls#LCD_API

QuoteThanks, I got rid of the last "cannot find". Two more to go
No, actually, only one. The -lnspireio one was fixed too with a make in the ndless-sdk/thirdparty folder.

Run "git reset --hard; git pull" and then "make clean; make" in the repository.
Only running make in the folders that you need is not enough, you have to build everything.
the usbd_* functions are part of libsyscalls and the generated syscall-list.h header.

Quote from: Hayleia on March 13, 2016, 12:23:48 PM
I'm trying to compile Jetpack Impossible (to then make it compatible with the CR4 models) but I see this when I try.

Code Select Expand


make
nspire-gcc -Wall -W -marm -Os -c Jetpack.c -o Jetpack.o
mkdir -p .
nspire-ld Jetpack.o -o JetpackImpossible.elf
arm-none-eabi-ld: cannot find -lnspireio
arm-none-eabi-ld: cannot find -lndls
arm-none-eabi-ld: cannot find -lsyscalls
collect2: erreur: ld a retourné 1 code d'état d'exécution
Makefile:39 : la recette pour la cible « JetpackImpossible.elf » a échouée
make: *** [JetpackImpossible.elf] Erreur 1

No idea what I have to do.

Plus, I already had to change something in os.h to get to this point. It was looking for syscall-decl.h but it doesn't exist, so I replaced it with syscall-list.h. Not sure if I was supposed to do that.

That header file is generated by a PHP script during "make" in ndless-sdk/libsyscalls.

Quote from: DJ Omnimaga on March 13, 2016, 10:09:03 PM

Quote from: Vogtinator on March 13, 2016, 11:06:55 AM
I can't say how the difference is as I do not have a HW-W calc, but gbc4nspire is definitely usable: https://github.com/ndless-nspire/Ndless/issues/26

What about nDoom, Crafti and gp-SP?

nDoom is not supported by lcd_compat due to using 8bpp. Critor is currently porting it.
Crafti (nGL) works fine so far, but I'll port it soon as well.
gpSP seems to work fine in lcd_compat, but it can be ported as well if necessary.

I can't say how the difference is as I do not have a HW-W calc, but gbc4nspire is definitely usable: https://github.com/ndless-nspire/Ndless/issues/26

New ndless 4.2 r2004 with full support for HW-W (including a compatibility layer that works most of the time): https://github.com/ndless-nspire/Ndless/releases/tag/v4.2

Quote from: Adriweb on March 10, 2016, 06:47:25 PM
Edit: technically, kArmTI isn't outdated, since IIRC it's based on the latest nspire_emu (which is old but doesn't get new versions since Firebird is its logical successor) and gets updated from time to time... But yeah, its emulation accuracy is not as good as Firebird.

It's based on nspire_emu 0.50 or 0.60, while the latest version available was 0.71 IIRC.

Firebird runs everywhere where Qt is supported and mmap/VirtualAlloc is available, so Android, BSDs, iOS, Linux, OS X, Windows...
It's also not a "TI Nspire CX" emulator, it also emulates classic calcs (Although I don't expect anyone to use that...)

Quote from: Jean-Baptiste Boric on March 08, 2016, 02:16:57 PM
I used that page as a starting point, but I've done my reverse-engineering with only arm-none-eabi-objdump since I don't have IDA. I've requested an account, now waiting for the email.

IDA 5.0 is free and a huge step up compared to objdump -D...