I remembered a feature that I never added to Grammer 2 Parser hooks would have made this project great, but I think I have a better idea... When an unrecognised token is come across, code can be redirected and parsed by the program. I would try to use the token "?" somehow to read arguments. This would also let me add in the ability to pass arguments to subroutines "easily." What do you guys think?

EDIT: Okay, what I have added so far:

• ? is now a variable.
• Using prgm(pointer will work just like prgmpointer (so it will call a subroutine). However, ? will be updated with the pointer to the next argument
  
• The token "]" will read an argument pointed to by a pointer var and then update the pointer var with the location of the next argument. For example, ]? will read an argument pointed to by ?, then ? will be updated.
  
  I am going to try to add in the error code for unrecognised tokens, too, that way you can set up an error handler that will instead parse the tokens in whatever way you want :) Here is an example of what can currently be done:
  
  
  Code: [Select]
  Lbl ".→Z
prgm(Z,X,Y,S
Stop
..
]?→x
]?→y
]?→s
If  and 1
Pxl-On(y,x
If s and 2
Pxl-On(y,x,39026
End


I copied and pasted my program code to ORG and I got a bazillion errors like this:

"Reference to undefined equate HL (line "          ld d,(hl) " in Grammer_z80)"

Any ideas why? Also, another feature that might be good is to return the output size of an app or program, that way we can figure out how much room we have left 

I am trying to remember to modify the header before release. The problem is that Brass automatically includes the header, so I have to try and modify it using WabbitEmu This makes it a hassle and a step that I sometimes forget.

Hmm, it looks like you are performing some computations and probably drawing a bit, too, when you press a key (the lag is noticeable between frames). I think you should try putting the LCD updating in an interrupt, then it will be constantly updating on its own

Necropost!

I decided that this program might be a good demonstration of BatLib's compression and decompression routines. It is currently included with BatLib and is called MultiComp. Basically, it attempts lossless compression on a file as much as possible with the BatLib commands. Decompression is fast, compression takes a bit longer just because it tests to see if the file can be compressed further. Anyways, screenshot:



prgmMLTICMP
Inputs: Ans is the name of the variable to compress
Outputs: Str1 is the compressed data, Ans is the compression ratio. 0 means no compression was possible.
Destroys: A,B,C,D,Str2,Str3,Str4,Str5

prgmMLTIDCMP
Inputs: Str1 (same as the output from prgmMLTICMP)
Outputs: Str2 is the uncompressed data
Destroys: A,B,Str1

It might be useful to write a version 2 of prgmMLTIDCMP that takes Ans as an input (as the name of a variable) and then it decompresses Str1 and stores it in the variable.

Download

Next up, now that I understand grayscale much better now, I shall see if I can make a grayscale image editor in BatLib BASIC.

I use that link quite a bit, actually. Also, it seems that almost all of TempSwapArea is used during the graphing process.
EDIT: The weird part is that a lot of the data is clearly FP values, not code from flash as it is normally used for.

That looks awesome I'm glad they modified it to use XOR Since it is a program, SMC could be used so that another argument can tell how to draw the sprite (XOR, OR, AND, Overwrite). That's what I used to do with my utilities.

Wow, that is great! Is it able to be used on some other site?