It won't work as it doesn't support OTG or host mode. Supported cables have another sense line to put the USB controller into the correct mode when plugged in AFAIK.

Great! It really fixed everything, I could load a CX and a classic OS without any problems. Booting took about 2-3 minutes

Same here. How much RAM do you have? Large or small NAND?

The only thing that doesn't seem to work is the "Reset" menu entry, but that's a minor problem (actually not important at all as long as there's no input ).

Not surprising, it's not implemented yet, like the file transfer and settings tabs.

Oh, and the progress percentages are displayed after each other on a very long line instead of overwriting the old percentage as on the PC.

That's a known bug, it's just appending the serial data to the QPlainTextEdit, '\b' and '\r' are ignored, like other ANSI escape sequences for colors.

I believe I found the issue:
In nspire_emu theres an array called addr_cache, which holds two values (read and write) for each 400 bytes of memory.
Each entry (For example, if you want to read at 18000020, its entry is addr_cache[(0x18000020 >> 10) << 1]) contains the following information:
-Pointer: If you add the address you want to access to the entry, bit 31 is clear and you can dereference the result directly
-Special entry: If you add the address you want to access to the entry, bit 31 is set
-MMIO: A special entry which (the entry itself, not the result of the addition) has bit 22 set
-Invalid entry: A special entry which has bit 22 clear.

The issue is, if the allocated memory is beyond 0x7CFFFFFF, you lose information and it crashes.
I expanded the entry format to 64 bits (but kept the bit positions!) and it works, except for rare occasions when the address itself has bit 31 already set!
So now I have to either:
-Fix the algorithm for computations
-Make a new format

This issue is also present on 32bit machines, but nspire_emu invoked VirtualAlloc with some parameter magic so it's always below 2GiB.
This "trick" also works on linux,  but not on mac.

I went for the latter, but it's slower, for now. I encode the 3 various kinds of entries in the lowest 2 bits.
Do you have a better suggestion?

I recompiled the App and it may work now, although I don't consider this as fixed.
I also solved the bug that you can't exit if the emulation thread enters an infinite loop (that's what happens if addr_cache overflows, what probably happened in your case).

If you enter the debugger, nothing will happen until you execute a command, like "s" or "r".
I have seriously no idea where the error comes from, are you sure you have the correct flash image?
I just flashed 4.2.2 to my tablet and it works without (major) issues there.

What I really don't like to see is that the write address changes everytime.

Oh, ok. I just read the last posts again and I don't know how I assumed you weren't running the android version 
You need at least 1GB RAM and you definitely need to use a 32 MiB flash image if it crashes due to mem exhaustion.

If you can "adb logcat" your device, it should print some OOM kills and then a final SIGKILL to nspire_emu.

The flash image that can be booted using the provided boot1. I called the file "flash_3.9_nothing.img" as I had "flash_3.9_cas.img" etc.
It doesn't matter whether it's 132MiB or 32MiB.

Edit: boot1 not boot2.

Yeah, I can upload the "working" app if you want to, but it'll take some minutes to fix some stupid issues (using "-Os" instead of "-Ofast" e.g.) and the framebuffer.
Also, as I have hardcoded the path to boot1 and flash, is "/sdcard" ok?

Quote from: Vogtinator on November 09, 2014, 12:40:33 pm

Quote from: Streetwalrus on November 09, 2014, 12:19:38 pm

Nspire-emu is like, the only thing I rely on Wine for atm.

I've still got IDA. It's a real PITA to use sometimes.

You might want to try try radare2. You can import the Nspire .idc files using a script called idc2rdb. Although radare2 doesn't have a good GUI and it lacks decompilation support.

The core of a good reverse engineer tool is to provide a nice user interface. Decompilation is mostly useless anyway. I'll try it, do you use it?

Quote from: Vogtinator on November 06, 2014, 05:03:12 pm

In theory you could run X and wine with qemu and binfmt support in a chroot.
If you just want some calculating capabilities similiar to the nspire, there are some apps in the store.

I tried that once, but apparently qemu required a patch for something called "NTPL support" to run wine

You know, "there's an app for that" I'm sure that somewhere is wine on an android device on the internet. Wouldn't be much fun, though.

BTW, what about QT for iOS ? It compiles fine (and runs almost fine, probably the same issue you mentioned) on Mac, so... maybe ?
I can try (sometime later....), I guess, as I have a iOS dev. account.

It may work but be even slower as iOS has some massive restrictions. But I guess it would run on iOS as well if it works on android.

Quote from: Adriweb on November 11, 2014, 07:45:21 pm

Anyway, ARM emu on ARM, though...

Does ARM support hardware virtualization ?

Most ARM processors in consumer devices don't, but AFAIK Aarch64 requires it. (Xen and KVM support the extensions already, they're quite new)
Some kind of accelleration would be needed, though, I had to wait for ~8m to boot this:


Also, I had to do a quick hack to display the 4bit framebuffer, that's why it's blue for now.
I had to use a classic image as my device doesn't have enough RAM to allocate the various caches, flash and SDRAM, I'll have to change that to utilize nmap.