I'm going to post most of the assembly routines I use in Axe Parser here to see if any of you asm programmers can help me with their optimizations.

• I am always trying to optimize for size, not speed, unless it is significantly faster and close to the same size.
• I would greatly prefer that it does not use any extra RAM to store temporary variables, but  that's not that big of a deal.
• No self modifying code or undocumented commands because I need to make this compatible for Apps and with the Nspire TI-84 emulator.

The most important thing right now is the clipped sprite routine since its really big.  Here's what I got so far:

p_DrawOr8x8:
   push   hl
   pop   ix      ;Input hl = Sprite
   ld   b,7      ;Input c = Sprite X Position
   ld   d,0      ;Input e = Sprite Y Position
   ld   h,d
   ld   a,c
   add   a,b
   jr   c,__ClipLeft
   sub   96+7
   ret   nc
   cpl
   cp   b
   jr   nc,__NoClipH
__ClipRight:
   inc   d
   jr   __ClipHDone
__ClipLeft:
   add   a,89
   ld   c,a
__ClipHDone:
   inc   d      ;d,c,e are updated
__NoClipH:
   ld   a,e
   add   a,b
   jr   c,__ClipTop
   sub   64+7
   ret   nc
   cpl
   cp   b
   jr   nc,__NoClipV
   jr   __ClipBottom
__ClipTop:
   inc   ix
   inc   e
   jr   nz,__ClipTop
__ClipBottom:
   ld   b,a
__NoClipV:         ;b,ix,e are updated.
   dec   d
   jr   z,__NoFix
   inc   e
__NoFix:
   push   de
   ld   l,e
   ld   d,h
   add   hl,hl
   add   hl,de
   add   hl,hl
   add   hl,hl
   ld   e,c
   ld   a,e
   srl   e
   srl   e
   srl   e
    add   hl,de
   ld   de,plotSScreen-11
   add   hl,de
   pop   de
   inc   b
    and   %00000111
   jr   z,__DrawOr8x8Aligned
   ld   c,a
__DrawOr8x8Loop:
   push   bc
   ld   b,c
   ld   c,(ix+0)
   xor   a
__DrawOr8x8Shift:
   srl   c
   rra
   djnz   __DrawOr8x8Shift
   dec   d
   jr   z,__SkipRight
   or   (hl)
   ld   (hl),a
__SkipRight:
   dec   hl
   inc   d
   jr   z,__SkipLeft
   ld   a,c
   or   (hl)
   ld   (hl),a
__SkipLeft:
   ld   c,13
   add   hl,bc
   inc   ix
   pop   bc
   djnz   __DrawOr8x8Loop
   ret
__DrawOr8x8Aligned:
   dec   hl
   ld   de,12
__DrawOr8x8AlignedLoop:
   ld   a,(ix+0)
   or   (hl)
   ld   (hl),a
   inc   ix
   add   hl,de
   djnz   __DrawOr8x8AlignedLoop
   ret
__DrawOr8x8End:


If you spot anything that can be optimized, bold it so I can see what you changed, thanks!

Unfortunately, do to the limitation of the calculator's available RAM, I am pretty much going to have to re-write the entire core of the program.  No one has notice the problem yet because all the example programs are small and don't require a lot of user specified data.  Once you start getting into medium and large sized programs, it will become a very big issue.

I will share the method I am using, the method I am planning on using, and other methods I've thought of to to see if maybe someone has a better idea before I start rewriting it.

THE OLD METHOD
The old method was to do a single pass.  Every time a label or name is encountered, it is added to the symbol table so that at the end of the programs, all the symbols are replaced.  All declared data like strings, pictures, sprites, and lists are added to the end of the program as it is being written and also to the symbol table.  The symbol table can only hold 150 entries and it really can't be expanded beyond that by much so that means you can only have 150 combined:

• Labels
• Name declarations
• Name references

ALTERNATIVE METHOD #1
Store all the data at the beginning of the program, that way once a variable is defined, you know exactly where the data is (since the expansion of the program doesn't push the data down further) so that way you don't need to add name references to the symbol table.  The down side is that now the labels are going to be pushed down as data is added to the top so I need to add all the label references  as well.  Also, a 3 byte increase in program size.  So 150 combined:

• Labels
• Gotos
• Name declarations

ALTERNATIVE METHOD #2
Same as alternative #1 except that the programmer is forced to define all variables at the beginning of the program instead of allowing variables to be defined within the program.  That way, the labels don't get pushed down as the program is being created.  Its kind of a slight inconvenience to the programmer though, and you would almost surely want to define the variables in a separate subprogram so that you don't have to keep scrolling all the way down to edit your code.  150 of:

• Labels
• Name declarations

THE NEW METHOD
2 passes are made.  In the first pass, all name declarations are skipped and name references are left blank so that no data is being added to the end of the program.  That way, only labels are kept track of the first pass.  Then on the second pass, the opposite happens.  All regular code is skipped, since it already was written in the first pass,
but all data is written to the end where it won't ever be pushed further down, so I don't need to keep track of references.  Disadvantage is that compiling will take about 1.5x longer and also I have to rewrite most of the core, but I think these leave a far more reasonable amount of variables:

150:

• Labels

AND 150:

• Name declarations

Don't forget, arrays of sprites count as 1 variable.  So if you have 20 8x8 sprites each representing a number on a grid, you can just store all of them consecutively to Pic1 and then reference them as Pic1, Pic1+8, Pic1+16, etc. or even Pic1+A.  Theoretically you can do this with strings too, but its a little harder since each string is probably a different size and you also have to take the terminating character into account.

THIS THREAD IS ONLY FOR UPDATES TO MAKE THEM EASY TO FIND.  PLEASE DISCUSS IN THE OTHER THREADS.

---

Axe Parser
Alpha 0.0.2

---

New Features:

• String storage
• Display strings
• Display new line
• rand
• Don't display done
• Pause in milliseconds

An example program also included.

Axe Parser
Alpha 0.0.1

---

WARNING:
This is still an alpha version.  It is not stable and you should not run this on any calculator that has anything intellectually valuable in the RAM.  Just for liability reasons, I will also add that there is a non-zero possibility your archive might not be safe either.

Description:
It is a new programming language for the calculator.  It is typed directly into a program just like BASIC and with a similar syntax.  Unlike BASIC however, this is a compiled language, not an interpreted one.  The program gets compiled into an assembly program.  In the future you will be able to make Ion, MirageOS, and Doors programs; possibly apps too.

Advantages:
You basically get the simplicity of BASIC programming but with nearly the same size, speed, and compatibility of assembly programs.  You won’t need “Shells” or “Libraries” to run the programs.  They are just like any other assembly program.

Syntax:
It is similar to BASIC, but also very different.  First, it has an extremely loose syntax.  You know how you can leave the end parenthesis off of BASIC commands and do multiple same-line DelVars?  It’s like that on steroids (if you so choose).  For instance: the store “->” can be used in expressions like A+B->C+1->D so now C holds A+B and D holds A+B+1.

Differences With BASIC:
I will be re-defining a lot of commands.  Most are usually unused anyway, but some are not.  For instance, “DiagnosticOff” turns off the run indicator.  But “sub()” now runs a subroutine since you will be able to take characters from a string the same way you do with lists in the future.

Variables and Numbers:
All numbers and letters A-Z are 16-bit unsigned integers.  Unlike BASIC variables, they don’t reside in the user ram so they take up zero memory.  You might want to read about unsigned numbers on Wikipedia or something if you are not familiar with it.

User Defined Variables:
Things like strings, lists, sprites, and floats will be defined by the user.  However, I haven’t gotten to that point yet, but expect that soon.



There is no UI right now.  Select your program, which must be in RAM, from the list, which is not in alphabetical order, and it will compile into a program called “LOL”, you can’t name it right now.  I figured I’d get the compiler working before I get back to the UI.  I’ve also attached a document with the complete instruction set so far.

I’d like to hear your thoughts
I have too many ideas right now to put on paper.

Just registered here!  I though I'd like to share this game for those that haven't seen it.  Its my first attempt at grayscale (I'm using my own engine) and music.  Its definitely my biggest project to date.

Pyoro



Anyway, I've finally finished a beta version of the next and final release, which I think is an order of magnitude better than the first.  So I'm looking for a few people who would be willing to help me beta test this awesome new version!  You'll get to play it before anyone else!  All you have to do is play the game a bunch then report bugs to me and answer some questions.  The main problem is that I need to find a good balance between easiness and being too frustrating.  Let me know if you're interested.  The reason this is kinda secretive is that there are unlockable features and surprises I don't want to ruin before the actual release.

I've already made a lot of improvements, but let me know what you think would make it better.  Thanks!