As many of you know, I have a predilection for making code parsing engines. This time I don't have any grand expectations to finish this as a programming language. I will, however, offer my latest attempt for anybody who wants to make a custom parser.

---

Adding a binary operator
   Operations like ‘+’ and ‘-’ are considered binary operators. They take two inputs and produce one output. In this parser, binary operators are performed left-to-right. To add a new bin op, open up the source file 'binop.z80'. In the routine isBinOp, after the ld a,(de) line, insert binoperator(token,my_op). Then add the routine to the file somewhere like:
my_op:
;;checks if x<y
    xor a
    sbc hl,de
    ld h,a
    rla
    ld l,a
    xor a    ;sets type as uint16
    ret


---

Adding functions
This is a tad more complex of a process, but once you add a few, it's super easy. There are several built-in packages for different types of functions (math or graphics, for example). Each of these packages are listed in the look up table in the file "includes.z80". You can even add your own built-in packages if you want. Each package has an alphabetically sorted lookup table of functions and you will need to add your function to one of these tables. First however, let's add the code:
my_func00:
    .db "SPRITE",0    ;This is the name of the function

;;To make sure Ans is preserved, use this default code
    ld hl,(ans_ptr)
    push hl
    push af
    ld a,(ans_type)
    push af

;;Parse the arguments. Remember you can't modify DE or BC unless you save them.
;;parseNum returns A as the type, HL as the value. It checks to make sure the input was a number, and since only uint16 is supported, you don't need to check the type.
    call parseNum \ ld a,l \ push af
    call parseNum \ pop af \ ld h,a \ push hl
    call parseData
;;Now the stack holds the coordinates, HL points to the data string.
;;Save BC,DE so we can have full reign
    ld (parsePtr),de    ;Save these values
    ld (parseSize),bc   ;
    pop bc          ;B=X,C=Y
    call drawSprite

;;Now restore BC,DE
    ld bc,(parseSize)
    ld de,(parsePtr)

;This is the default ending. Jump to closeFUnc with
;A = ans_type
;H = opening token. Ex. '(' for SPRITE(x,y,data)
;<stack> holds ans_ptr
    pop hl
    pop af
    jp closeFunc
When that is finished, insert .dw my_func00 into the graphics LUT (located in graphics.z80). You need to insert this so that the LUT is in alphabetical order! Since "SPRITE" comes after "RECTXOR", you would insert it at the end of the LUT.

---

To Use:
Send prgmPARSER to your calc. You need Ans to contain the name of the program file to parse. For prgmTEST, use "ETEST" or "[TEST".

Included functions:
DISP x
RECTXOR(y,x,h,w)
ABS(x)

Binary ops:
+,-,*,/ are the traditional binary ops, currently only performed on uint16
plotdot, plotcross, plotbox are used as in Axe for 16-bit AND, OR, and XOR.

---

Things that would make this much better:

-Adding metadata after the function names to indicate stuff like whether it is a binary operator (so that 'x nCr y' can be added, for example.)
-An ASCII editor, since this is actually supposed to take ASCII input, not tokens.
-Variable support

Thanks! Now that I figured out how to sign apps on my computer (and now that I have all the programs required), I have it compiling as both an app and a program! I am thinking of adding in a filesystem as I did in FileSyst, but with a slightly modified (and hopefully more optimal) approach. This will also make it much easier to add in variable support and really expand the functionality of this as a programming language.

Yes, it is almost OS independent using only four bcalls-- two to search for a var, 1 to to display a string,and 1 to convert an int to a string (I have routines for this, I just wanted a cheap way).

Also, some tokens would need to be changed to pure ascii (space token, comma, decimal). I'm not exactly sure how to integrate such a program into KnightOS, but you are welcome to.

---

In other news, I'm working on rebuilding FileSyst using this code and I'm making a bunch of headway.

Cool, I might try it some time when I actually have some free time.

Haha, good luck By the way, I'm still working on a method of creating variables. On the TI-OS, I'm writing a file system, but KnightOS already has one so it might actually be able to piggyback on that.

So, are you doing a complete re-write of FileSyst, or are you working off of what you had before?

I don't have the old code, so it is kind of a complete rewrite. With that said, my approach is almost identical:

• Make a binary-search algorithm that matches a sorted list of strings.
• This is used to match commands as well as locate files.
• Make a high level InsertMem/DelRAM routine.
• This takes a signed input so it can intelligently choose between inserting or deleting (for example, when changing a name, you can just resize by "inserting" new_size-old_size bytes).
• The way files are set up, wherever it is inserted in RAM, it can adjust every file and folder pointer and size.
• Error checking is done to make it is safe as possible. You can insert *almost* anywhere and not have to worry.
• Make a routine for adding/removing files.
• This also gives us an easy way to make variables