Although it's just a matter of setting a simple OS switch. Ndless really requires developers to help me handle all these requests, I can't do it alone anymore.

I would be more than happy to help when I have time, if I know this OS switch.

Quote from: alberthrocks on September 18, 2012, 07:23:08 pm

- open Ndless-SDK/ndless/system/osstub.c and comment out void _exit(void) { exit(-1); } and rebuild Ndless

What is this one for?

This is a modification to the SVN checkout of ndless to fix the "multiple definition of _exit()" error (building *.c with -nostdlib, then nspire-ld without that option). It links but crashes (of course).

Using newlib functions is not recommended as long as tangr's bFLT loader hasn't been merged into Ndless, since some of these functions require relocation, and you can't guess which ones.

Yeah, that's probably the cause of these crashes.

Quote from: alberthrocks on September 18, 2012, 07:23:08 pm

I guess I'll have to find a way to hook up GDB to the nspire_emu.

This one is also at the top of the TODO list.
Lionel Debroux has already merge my GDB stub into the latest (but not released publicly?) update of nspire_emu. I'll do some non-regression tests on Ndless and update the SDK with it as soon as possible.

That's great! I'm looking forward to seeing that integrated! (And perhaps in a release of the graphical version too!)

Once again sorry for the delay. Fill free to contribute a way or another to all these tasks, I can give update rights to the repository to anyone I trust willing to contribute if needed.

No problem! I'm busy as well, so I can understand your situation. (Again, only work when you get the chance!) I would love to get update rights, though I would prefer getting an experimental branch on the Ndless SVN** so I can push my changes to my own SVN branch without some innocent user accidentally blowing up their calculator! Do you have any particular coding standards? Also, is there anything I need to know to get familiar with the code structure?

** Actually, I could create a Google Code SVN instead and do management from there, if the code can be public. It would be easier for anyone to add people that are willing to contribute. Later, when the code becomes stable, I can simply commit my repo to the official source tree. Let me know your opinion/decision on this!

Wow, this is pretty amazing! Finally, the possibility of making an Axe shell is realized!
Will you be aiming for DoorsCS-like features?
And definitely make it comfy with OmniCalc/Symbolic/zStart!

ELF is very complicated. tangrs had made an ELF loader, but ELF files could be overly big in some simple cases.

Yes indeed... but dynamically loading libraries is essential for any application that depends of plugins written in C.
I guess what I'm asking for is some implementation of dlopen(), dlsym(), and dlclose() for BFLT.

And Nucleus is indeed a multi-threaded RTOS.

Yup, as I thought: http://www.mentor.com/embedded-software/nucleus/kernel

Is there any way SDL_GetTicks() can get implemented? It currently aborts due to SDL Threads not being implemented.

Little confused, but what exactly does this do? I don't get it

This is a library for a virtual console on the Nspire. Most people won't need it, unless they are developing a console based game of app.

Do you mean alberthrocks's update or Nspire I/O itself?

This is my update

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.

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.

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!