I've decided to attempt to write my own language for the calcs. The basic gist of this is that I want something fast, with friendly commands for games. I'm looking at doing a compiled & interpreted sort of thing, mostly because I can simply expect some things in my interpreter if it's compiled, and I didn't want to deal with using commas as delimiters.
But I digress. I intend to add more details later because I'm a little crunched for time right now, but I'm looking for a few people who are willing to help mostly with a compiler for on the computer, and possibly an on-calc editor (I just don't have the willpower to do something like that).

You said "compiled & interperated", although that is a bit of an oxymoron. How 'far' will it be compiled? Byte compiled? Z80 ASM compiled? How much will be interperated?

I'd be interested in helping out a bit (nothing major, just tweaking source and doing debugging/testing), but that would depend on what language you are programming the computer compiler in

Why not help in the coding of other unfinished languages (mlc, fastrpl, that thing in development by Detached Solutions, ect.)? It always hurts to see good projects die.

Meh, I'd rather see what he can come up with. Most of those other languages died due to either poor language design, poor compilers, or lack of developer support. For a project like this to get off the ground it needs alot of support from the creator, and lots of out-of-the-box functionality

Excellent idea. If you could fit it into about 6k, this could be the killer app for DCS - a new supported language. I'd be happy to help with the conceptual phase and debugging.

To clarify a little on this, I intend to have it byte compiled, and then just read arguments in an expected format. It will always work with integers, except when an "FP delimiter" is given preceding an instruction, in which case 9 byte FP numbers are expected.
For now, I'm interested in what sort of commands you all think a language needs, and things that would be nice to have (stuff like C-style arrays so you don't need to mess with lists and matricies, etc)

Superb, that sounds like a plan. Can you draw up documentation on what you've worked out so far so we can critique it?

structs, and strings would be nice. and some graphics work.

Agreed. How about a module for Timendus's API or my API?

Basically, I'm using the usual variables A-theta, but my parser will default to integer mode, where each of those is simply a 16 bit integer, vastly speeding up mathematical operations. For graphics, the LCD is never updated by draw routines, and the program does it itself, if it needs to render more than one thing at once. I'm tenatively allowing short interrupts, and also including the one thing BASIC is sorely missing: a call command.
I'm allowing any-dimensional arrays (see the GBuf( command), and I intend to allow strings to be addressed in the same way, possibly even allowing strings and arrays to be interchangeable.
As for commands, I started writing up instruction/token reference in math today; I got the first 16 tokens done, but nothing's definite at this point, expecially the interrupt commands, which I may end up removing altogether.

00h: Newline delimiter
01h: Integer - sets the parser to integer mode
02h: Float - sets the parser to FP mode
03h: Add(arg1,arg2) - adds arg2 to arg1
04h: Sub(arg1,arg2) - subtracts arg2 from arg1
05h: Mult(arg1,arg2) - multiplies arg1 by arg2
06h: Div(arg1,arg2) - divides arg1 by arg2 (if the parser is in integer mode, the remainder is stored in special variable r (not to be confused with R))
07h: BufCpy - copies plotSScreen to the LCD
08h: Sprite(xcoord,ycoord,width,height,data) - display the width wide and height high sprite described by hex string data at (xcoord,ycoord)
09h: GBuf(xcoord,ycoord) - addresses plotSScreen as an array at (xcoord,ycoord)
0Ah: StartInt lbl - Sets up the local interrupt to execute lbl
0Bh: StopInt - Disables execution of the local interrupt
0Ch: Lbl lbl - Defines label lbl
0Dh: Goto lbl - Jumps to lbl
0Eh: Call lbl - Calls lbl
0Fh: Ret - Returns from the last call, or, if none was executed, exits the program

You can probably see something of a similarity to z80 asm, and that's somewhat intentional. A tenative name for this project is EASM (EasyASM), allowing much of the data manipulation that can be done in asm, but trying to eliminate much of the complexity that's inherent.

this could be interesting. Are you going to syntatically base it off of another language (like C for example) or not?

From the stuff above, it looks like he's probably not. This looks like a very interesting project; I look forward to seeing what comes of it.

this may be necroposting.... but how is it coming? im quite interested...

I believe this may have died, unless he's planning on making it part of his latest OS project.

It's still around, but it's kinda died. It got pushed aside, but I still have a decent amount of documentation and code for it, so I might end up adapting it to LIFOS.

Sounds good to me. I'd be interested to hear more specifics about this LIFOS, though...

I hope to have the start of source code and documentation up in my CVS for it soon, and I also mentioned it over at UTI when I needed to write keypad access routines.
http://sourceforge.net/projects/lifos
http://lifos.sourceforge.net/ doesn't exist yet, anyone want to create a page?

Kerm hasn't said this yet so I will say it for him... Don't use any areas that DCS uses right now because he wants to be able to run it in Lifos =P (Oh yeah, and include an app menu )

All I can say is:
1: Of course, it'll be able to run apps (eventually).
2: Static safe RAM will be very hard to come by. Index registers (IY, too!) and indirection with HL are your friends (or SMC, for that matter). Oh, and enjoy deciding on uses for a standard IM2 vector table at $F500 (or so)
Remember this? You were all wrong.

Just a suggestion, if you are going to be making an entirely new OS, don't bother maintaining source/binary compatibility with TI-OS. Do a little spring cleaning. Throw out the crap that isn't needed. Maximize the available RAM by eliminating static safe ram areas (if you are going to have a malloc call, that is), etc....

But thats just my opinion