Also EEPRO isn't linked with EEPROM, right?

Right, no relation. EEPROM means electrically-erasable programmable read-only memory; it's like Flash except that individual bytes can be erased instead of having to erase entire large blocks.

The Japanese Super Mario Bros. 2 (aka "Lost Levels") was for the Famicom Disk System add-on, which was a lot more than just a mapper.

Aren't the other versions made by patching the original Clickpad version? Should be much smaller to just have the Clickpad version + patches + code to apply patches at startup.

Java would be nice on the Nspire since a bunch of people know this language and this might increase the Nspire programmer audience considerably, although of course it won't be even close to Ndless (and maybe Lua?) performance.

Running Java code is generally faster than running Lua code, because of the type information available to the JVM. Take object field accesses for example - in Java, if you have a variable "Rectangle r", the JVM knows at class-loading time that it points to a Rectangle object, and therefore can determine in advance what location within the object will be accessed in an expression like "r.width". In an untyped language like Lua, on the other hand, fields have to be looked up by name at run-time every time they're accessed, which is much slower.

The main problem with Java isn't its execution speed, it's its size. JamVM brags about its executable being only 200KB, but how much memory does it use, and how big is the required class library? Porting the class library could also be a lot of work. I was considering porting the CLDC reference implementation (a Java environment with a much smaller class library) a while ago, after I had found out about Jazelle, but never did anything substantial to that end.

can you make sonic work for me it gives a blank screen

Sonic has anti-emulator protection (or possibly just bad programming), which is not so easy to fix. It's getting stuck in the following loop:

E4DC   AD 02 20   LDA $2002
E4DF   10 FB      BPL $E4DC

This loop waits for the high bit of address $2002 to become set. The NES sets this bit at the beginning of the vertical blanking interval of each video frame. However, the NES *also* invokes an interrupt handler at the same time, and this game's interrupt handler takes so long that by the time it returns, the vertical blanking interval is already over, so $2002's high bit is clear again - the loop can never exit. The only reason it works on real NES hardware is because eventually the vertical blanking interval will happen to start in the middle of reading the LDA instruction, so the instruction reads a value with the high bit as set, because the interrupt won't be called until the instruction is finished. I can't emulate things happening in the middle of instructions; having to check for that would be extremely slow.

It seems to work if you just patch out that offending routine - hex-edit a copy of the ROM and change the byte at 3E4EC from AD to 60 (a return instruction).

Reo: Those errors imply you're trying to use an x86 assembler, rather than the ARM assembler required.

Reading from the screen can't be a problem specific to Ndoom - Both boot2 and the OS do it during initialization, and so does Ndless ploaderhook (line 65: "memcpy(savedscr, SCREEN_BASE_ADDRESS, SCREEN_BYTES_SIZE);"), but Ndoom doesn't do it.

I think the problem is related to the memory access size. I've seen the bug happen in my own programs when using byte-sized accesses, but never when using word-sized accesses.

Any reason not to just use the Lua port?