Its just an idea.

The problem is that there's too many thoughts and "ideas", but not enough effort to actually implement those ideas. I'm sure plenty of people (if not all) would love to see a TI-8x emulator on the Nspire, but few have gotten close to making such an emulator.

As DJ_O said, calc84maniac was making such an emulator when he lost all of his work. I can't say I blame him; those kind of data loss are a freak of nature, and they can't be helped. Of course, he could've backed his stuff up, but even that wasn't a habit for really anyone until recently.

And to go back to doing the project? It's hard to go back to work on a project that you've spent hours, days, weeks, or even months on, and then have it vanish in an instant, knowing you have to start from scratch. A lot of developers understand this feeling: ever write a super awesome BASIC program on your calculator? Didn't know what Archive is? And suddenly, you miraculously crashed your calculator? It's miserable, and personally, I've only restarted maybe two or three programs, while the rest (up to 7-15) are lost in the nether/null of the virtual world. I'd be pretty surprised if calc84maniac actually restarted that project.

If you - or we - want to see a TI-8x emulator in the near future, action is a must! The TI-Nspire platform is not just limited to Lua, BASIC, or ASM - it also has a very versatile C development platform, which makes porting existing emulators (like Wabbitemu or TiLEM) very much possible! If you want to help, learn C. It might be easy, and then again, it might not - take your time, your own pace is the best! Learning it thoroughly is better than learning it quickly and making silly mistakes later. It's not easy - even for me - but it is doable, for most people. Then pickup the Z80 CPU design and its inner workings, as a bonus. Then you can take a project like SDLWabbitemu** and port it to the Nspire - there is a nice nSDL library just waiting to get used!

This applies to everyone, not just him - if you want to see it happen, pitch in!
Then the dream of having such an emulator can finally be fulfilled.

** In case you were wondering, I am indeed the developer of SDLWabbitemu. It's extremely messy and disorganized (which is why I tossed it away earlier this year), but it is something that can be ported, given enough time and energy. Unfortunately, I don't foresee myself being able to work on it much, but if you'd like, I'd love to add you in as a commiter, and I would be more than happy to guide you. I've spent earlier this evening updating the core a bit and the build system so that it can be worked on without too much hassle. Just let me know and I'll get you started!

SDLWabbitemu together with nSDL is actually the nearest we can have with this idea, as Albert said, it only takes someone who is interested to porting it.

Hmm... it's not quite a port, more like "improve it and then port it"

My TODO list for my project is up for anyone curious: http://code.google.com/p/sdlwabbitemu/wiki/Todo

Note that this CAN be a collaborative effort, so don't freak out!

EDIT: Just to show you what I mean:

(The cursor is blinking, just caught this screenshot at a bad time.)

Is it just me or is the calculator window size wrong? It looks super wide in that screenie for some reason.

Good catch! I forgot to stick that into the TODO, added!
Yeah, I think the core code has the whole array for the largest screen possible, but it's cropped when displayed.
The very bare minimum code simply displays that array.

Sorry guys, I have no experience in this kind of thing. Maybe later.

The "official emulator" can't be used because we don't know much about it, and it is extremely buggy anyway. The fact that they removed it means that the management for the code is pretty bad.

No, it means that the CX doesn't have removable keypads. I'm pretty sure the emulator still exists in non-CX OSes.

Also, ARM9 is not very competitive with x86 at all in terms of instructions per clock. There's no parallel execution or branch prediction, and I think memory access has more latency. I'm not trying to discourage giving it a shot, though.

Quote from: alberthrocks on September 04, 2012, 12:07:25 pm

The "official emulator" can't be used because we don't know much about it, and it is extremely buggy anyway. The fact that they removed it means that the management for the code is pretty bad.

No, it means that the CX doesn't have removable keypads. I'm pretty sure the emulator still exists in non-CX OSes.

Also, ARM9 is not very competitive with x86 at all in terms of instructions per clock. There's no parallel execution or branch prediction, and I think memory access has more latency. I'm not trying to discourage giving it a shot, though.

Hm, I was under the impression otherwise, since there was a little demo by ARM showcasing a 533 MHz CPU competing neck to neck with an Intel Atom netbook. Must've been a newer version of ARM (ARM11 perhaps?).

In that case, I'd propose not doing anything on that TODO list and jumping to just porting the code for nSDL/Nspire to see if it will run at normal speed, so that effort isn't wasted if it turns out to be too slow for practical use.

This sounds like a great idea!  I've got an Nspire CX CAS and just started learning C. I took a year course on Java at school and C does not seem too hard to learn after having some experience with Java.  Maybe I'll give it a shot some time in the future.