Update
Today, I worked extremely hard converting the tiDE assembler to use regex instead of wildcards, a much needed improvement. I also fixed some other bugs in the assembler. Today, tiDE successfully assembled a program!
Unfortunately, I lost the whole a thing when it suddenly didn't show up in my projects folder.

First part: YAY!
Second part: Aww Sorry to hear. I wish the best of luck as you try to rebuild up to where you lost it.

I think I can recover the GUI and the emulator (the latter not mattering at all), but the real guts of it (the assembler) is gone.

I don't understand where it would have gone. I hope that you find it again soon.

Update
I finished project creation, which is based on XML templates. Users can have any number of templates. Here's a screenshot of the new project wizard:

(Click to Expand)
And after clicking OK (and opening some new windows):

(Click to Expand)

Here is the XML for the nostub template:

Code:

SIr, epic. Does it assemble anything yet?

It used to, before I lost a ton of progress. But there isn't very much assembler code at the moment, mostly some skeleton methods. But if you push Ctrl+Shift+B (or manually click build) in the Editor, it will go through the motions, sending the code through the assembler and into the linker.

That's disappointing, very sorry to hear it. Yet another reason to be acutely aware of the importance of backups, I'm afraid.

Update
Hello,
I've added full support for TI-Nspire projects, and at this point, you can use tiDE to compile TI-Nspire C programs. I will add support for ncubate soon, as well as extend the current support for TI-Nspire projects. I've also partially added file creation based on XML templates in a similar manner to project templates. The IDE portion is really fleshed out quite far. As for the z80 assembler and z80 emulator, progress as usual. We've also added projects for tokenizers (TI-Basic support). A fully working sprite editor has also been added (with grayscale support), and will be made more and more functional over time. It also accepts customized parameters from tiDE, so that a particular format can be accepted (TI-Basic has text sprites, assembly uses "db", C uses arrays, etc), which of course can tie into add-ins for more languages. A DCS7 GUI editor has also been added, only partially in progress, to give an experience very similar to designing forms in Visual Studio.

As always, you can download the latest source code here. Today marks the first day where you might actually want to get tiDE, for Nspire C programming (which is now fully supported). Of course, it will be better in a few days, when integrated emulator support is added, as well as some more features to the suite as a whole.

What compiler are you using underneath the Nspire editor? Gcc? Something else? Is it packaged with TiDE, or does it need to be downloaded separately?

It uses gcc underneath it all. Right now, you need MSys installed beforehand, but this will eventually be done through the installer.

Sounds good regarding gcc, that's what I figured. What is MSys, and how heavy is it?

I'm not sure, I can only get to this from my phone atm and can't check. However, it is not absurdly large and most Nspire developers already have it.

That's fair. So what progress on this, what future work, what deadlines?

No deadlines yet, but progress is rather speedy. A lot of the UX is done, and work on the assembler and emulator is steadily plunging on. The emulator has about a third of the z80 opcodes done, although few of them correctly emulate flag behavior. The way the assembler works is well defined, all that remains is to implement it (we need a custom opcode table, we're optimizing it in such a way that requires a special table). The DCS7 GUI editor is functional, we just need to add all of the GUI objects, and the ability to export as code.
We also have a nice sprite editor going, with the ability to use any number of gray levels (although we've currently restricted it to four), and with a few simple tools - pencil, brush, flood fill.
The TI-Basic (de)tokenizer has the basic framework in place, and we'll be expanding on that soon.
XML based project and file templates also work great, with the ability for the user to define their own templates as well. The templates are extremely customizable.
And Linux/Mac compatibility is currently broken, and will be difficult to fix.

Any particular reason for making a brand-new emulator instead of using WabbitEmu? Any features that WabbitEmu is missing that you need to add? Sounds like some solid progress.

We want to use source level debugging, and did consider using WabbitEmu, but I was never successful in using it, and (with all due respect for its creators) the libraries are not easily used.

Did you consider chatting with Spencer and Buckeye and either requesting further interfaces or clarify the use of the old ones? I suppose if you're dead-set on creating a new one though, I wouldn't be unhappy, as long as it has:

1) A minimal CPU footprint
2) Accurate interrupt emulation (talk to Calc84 and I for some common pitfalls that are easy for emulator coders to make but drive interrupt writers up the walls)
3) Accurate port emulation
4) Syncable instances for linking/network emulation

Thanks for the task list, we'll make sure to include those. I was also thinking of CalcNet/gCn emulation. And I spent quite some time chatting with Buckeye, but WabbitEmu just didn't seem like it would work for us. If they improve the library, I'd be more than happy to use Wabbit. Buckeye himself told me that the library wasn't very well done at the moment, and that they would be improving it in the future.

Well, if you get the things on that list working, then Cn2.2 will work right off the bat, hence why I came up with that list. If it came to it, I'd also be happy to talk you through implementing gCn compatibility so that your emulator could join gCn as a client hosting one or more emulator instances. Thanks for the clarification on Wabbit.