Thanks to Will West on the logo design.
I am working on a project, recently kept under wraps, that I call Mosaic. Mosaic is an application, and its sole purpose is as a z80 IDE. It has a simple GUI, an assembler, and a few tools. Not only that, the assembler is in assembly itself, so it has signifigantly more speed, resulting in almost instant build times for simple programs, unlike OTBP Assembler or Tasm On-Calc. It features many tools to make development easy, including on-calc debugging. It also can take advantage of usb8x to export and import code as .z80 files on a flash drive.

Here's a screenie:

I added a poll option.

Okay

Doing interrupt-based debugging wouldn't work because you can't guaranty anything about the state of the hardware. Client code could do whatever it wanted and magically break out of the debugger, or just crash.

You'd probably need some sort of interpreter core to allow proper debugging, so you could go through individual instructions and avoid bad things happening to very important bits of hardware- specifically, I'm thinking of things like your stack pointer and interrupt settings.

I could have an interrupt that breaks when the user presses a key, so that it wouldn't crash if the program ruined its variables?

I'm clueless when it comes to Assembly, but looks nice

Nice name, haha.

That assumes the user already knows when it's going to crash so they can prevent it by hitting something.. kinda defeats the purpose of debugging, eh?

Put another way, I don't think anybody has microsecond-range reflexes to break execution just before a crash after observing one before..

I had an idea for an on-calc debugger a while ago, the way it would work is it would read each instruction and if the instruction was say a Push or a Pop it would push or pop onto a stack at the end of the program (appbackupscreen might work, but if the actual program used that then it wouldn't). It would also have an internal PC that jumps would use. Just my thoughts, don't use them if you don't like them or don't understand them

also, I would maybe make the menus/buttons at the bottom of the screen a little more readable, but other than that, looks good so far

Now when you say, "it has blah blah," do you mean it has those things or it will have them once you code them? I tend to think the latter since you were asking me about the textWrite flag yesterday. Either way, mad respect, and I hope you're able to complete it (and of course make it have some kind of Doors CS interface!)

Lol about half and half


I would, but I'm making it as an App

I was thinking about something along the lines of making the data files (ie, source code files) be formatted in a Document DE-readable format, or with some other header to allow users to edit their files from Doors CS.

Oh dude I completely forgot one of the coolest features!
Import/Export your files as .z80 or .asm onto a flash drive

Awesome idea!
The import-export thing is cool, it makes your calc a totally portable programming environment. I doubt I'll use it for 'pure' on-calc programming, but being able to carry my project around is great!

WONDERFULWONDERFULWONDERFUL

the only reason i havent bothered with asmemblies so far is the unfriendly calc environments, so this would finally give me an excuse

Update
Just a quick update on progress:
*I got a menu system partially done (like clicking the Y= button and seeing a file menu)
*I started working on the assembler, and it can compile "ret" and "db"instructions all day long
*Started work on the debugger, and decided to modify the user's code a little so that it would call my routine on breakpoints.
*Changed the text a little so it is easier to read
*Worked on enviornment, it can now display wrapped text

So, quick question. This is the planned archetecture of the assembler:
Three passes:
First pass saves label names and proccesses nolist include files
Second pass converts labels and macros to pure z80
Third pass compiles z80

Thoughts?

Just finished support for every single one byte opcode from the assembler, more to come later.

could this have the ability to use different assemblers/macros, such as if someone wanted to write a different language like ti-basic or something it could read the entire file that you make and convert it to whatever. just kinda wondering

Well, I'm going to release the source code, and the way I have it set up, yes, that is easily done.