I might enter this into the competition, provided I have enough time to work on it I've been working at it on and off, and so far I've put in about 10 hours into it (I did a lot of staring blankly at my calculator .__.)

Anyways, it uses 4 assembly programs at the moment.
-Shift a portion of the screen up 6 pixels
-Shift a portion of the screen down 6 pixels
-Plot the tilemap for monster zones (tilemaps are 72 bytes, using this method)
-Draw the actual map

It uses 3x3 "tiles" on the graph screen (they aren't actual tiles, its just that you move 3 pixels at a time and everything is based on 3 pixels). The first two assembly programs are just to make scrolling through the item menu more visually appealing.

The battle engine is kind of lacking in almost all areas, but I plan to add to it as a build the game up a bit more. I just threw together a quick one to make sure the monsters worked and stuff. 18 monsters are programmed, the last three are bosses, though, so you can only face the first 15, normally.

37 items are currently in the item menu with plans to add more. Only the first 10 actually do anything, at the moment

There are very few graphics. There is also no way to obtain items, except for the first 5 you start with or through cheating.

Almost all of this was programmed in the three hours that I was waiting for laundry. The rest occurred between yesterday and today. Yesterday I added in the rest of the monsters and items that are there, now, today I added the two assembly programs and I made a map maker that generated assembly code (I wrote it in BASIC, too )

Over all, I am kind of having fun with this, programming mostly in BASIC I am still not doing any hardcore programming, though, so this is a nice way to ease back into stuff.

By the way, this is a continuation of a series I made and lost about 5 years ago Hopefully this will help me to revive it as I lost almost all desire to make RPGs since then.

Oh, also, the houses have a symbol above the door way. The symbol tells what house it is, but currently, there is no code for each of the house types. Instead, it just goes back to the main program loop.

EDIT: I have now added in the code for the merchant, so you can buy items. Not all items are for sale, though! Now on to the blacksmith stuff >.>
EDIT2: Okay, so now I have fleshed out the save file to be a 122 element list and it is 1112 bytes. Since it is also stored to L1 while the game is being run, that takes up 2222 bytes of RAM. I could write another small ASM program to save/load pieces of data, but is that too much ASM involvement? If I do that, the main save file will be 137 bytes and I can load only the pieces I need into L1, saving possibly 2000 bytes or so of RAM.

Hmm, I feel like this is my call, since it is a contest entry

In preparation for a presentation, I wrote a quick program to show the cellular automata rule for Langton's Ant. Basically, if the "ant" is over an ON pixel, the ant turns right, if it is on an OFF pixel, the ant turns left. Then the ant inverts the pixel and moves a pixel in the new direction. It leads to some very complex patterns and has been used to make pseudo-random number generators. I left it running for over 2.5 million iterations yesterday and it was still chaotic (with 1 ant). Try watching 2 ants over time

This is a Grammer program and the world is 64x64 pixels, and is toroidal (basically, the world wraps in all directions, so if you go off the edge of the screen, it wraps around to the other side).

As was noted by Sorunome and I am sure others, BatLib's introduction of GroupHook caused a mysterious bug with graphing. It seemed to cause undesired shading of graphs causing some interesting effects. After chasing through the code, I found that it was caused by copying the GroupHook code to the end of TempSwapArea. I had never seen documentation of this anywhere, so as I experiment further, I hope I can provide the information. Until then, i need to find some other 65 byte chunk of free ram that I'm not already using.

A few years ago, I was approached with a program idea. The programmer wanted a few special functions that seemed best fit for an assembly program. I finally got the motivation to really work hard at it and in the past week I totally rewrote it implementing some really cool features.

• First, BASIC programmers will have access to as many as 10 drawing buffers.
• There are also a handful of drawing commands that can be done on these buffers
• None of the buffers use User RAM
• All calc models have access to at least 3 buffers
• The TI-83+SE, and all TI-84+ models have access to all 10
• The models with access to all 10 buffers also have access to all of there extra RAM pages, not normally accessible
• Strings, sprites, pictures, and other types of data can be backed up to this extra RAM (ranging from almost 9000 bytes to >90 000 bytes of extra RAM)

I am not going to release this program until I have been given the go ahead by the person who made the request, but one important thing that I do want to leave with you all is this:

I have put the Grammer project on hold for a bit. I wanted to try out other projects and ideas before I try to go further. I plan to use much of the code from this program in the next Grammer version. I have a file system, data retrieval, and data storage that works fully with all the available RAM. I plan for the final Grammer OS to give programmers access to everything on their calculators, including their RAM, whether it is 32KB, 48KB, or 128KB.

Also, here is a screenie

As a note, the variables STRING0 and STRING1 are stored as strings because of the .1, not because of their names. I could name a string "GUYScheckTh1sOwt.It's a string!" When it returns 1, it means it was stored successfully, when it returns 5, it means the variable already exists.

---

EDIT:

I was given the okay to release. For those that want to just give it a try, I will upload some info and the program. Since it is still being developed, nothing has been finalised, so syntax will likely change. In other words, don't make any super awesome programs that rely on this version! Playing with it should be enough.

As I mentioned int he Grammer 2 topic, I should be starting Grammer 3 in about two weeks if I am on schedule (1 year after Grammer 1 was started). Because this is the time that I will be without internet, if you have any ideas, post them here, I will make a copy of it, and I will reference it while I am working on the program. In the plans for Grammer 3 since the start:

It will be a two page app
It will have a legacy mode for older Grammer programs
It will have a built in program editor
It will allow for custom command sets (up to 16 packages that contain their own functions).

• This will mean you can have a floating point math command set, linking command set, and others
• I might bring this down to 8 possible sets at a time
• These will be defined at the beginning

Source code will be "tokenised" like on the TI-89. This will help speed it up massively.
There will be specific variable types like sprites, fonts, and strings

I am thinking of adding in standard 32-bit math.
4-level grayscale and 3-level gray
More tile map options
Proper sprite clipping (I've already got the code planned)

If you guys can think of any good ideas, please post. For the editor, what would make things easier? I will be writing a menu system, so I will probably include customisable menus, quick keys, and other things. Maybe I should make a search function? Search and replace? Since Grammer will have so much control, errors will be completely handled by Grammer, so if you press ON for example, Grammer will take it to the Grammer editor, not the program editor.

I feel like I have made a topic about this before, but I am not sure... I cannot find it anywhere.

Anyways, jsj795 had a great idea for a program back in January that will prove useful to others, too, I am sure.

What it does:
At its core, it copies a program in RAM or Archive to a temp program. Temp programs get automatically cleaned up by the OS (deleted) when all programs are finished running. it also has the functionality to delete programs and temprograms, just in case.

Notes:
When you copy to the temp program, any existing program or temp program with the same name will get deleted!

How to use it:
All arguments are passed in Ans. Currently, there are no outputs. The syntax for copying a var is:
"<<original>>:<<copy>>":Asm(prgmTPROG
So for example, say you want to copy prgmRAWR to prgmZZTEMP1:
"RAWR:ZZTEMP1
Asm(prgmTPROG
Notice that unlike some of my other programs, you don't need a type byte for these. Also note that a colon separates the names.
To delete a program, put a minus sign before the name:
"-ZZTEMP1
Asm(prgmTPROG
But that isn't all! Say you want to do a bunch of things at once. Simply put them all in one string and run the program:
"RAWR:ZZTEMP1:-HELLO:WORLD:MEOW:-BRIDGE:-THEGAME
Asm(prgmTPROG
That copies RAWR tot he temp prog ZZTEMP1, deletes prgmHELLO, copies prgmWORLD to temp prog MEOW, deletes prgmBRIDGE, and deletes prgmTHEGAME.

So what is the size of this lovely program? 172 bytes. That's it. Have fun.

More notes:
If you try to copy a program that doesn't exist, those two arguments get ignored. If you try to delete a variable that doesn't exist, that argument also gets ignored.

EDIT: Uploaded a faulty version, originally. This version is fixed.

When I first discovered the ti83plus.inc file provided by TI, I went through and played with all the RAM equates that I thought would do something. For the newer folks that don't know me well, I started my assembly programming days by programming in hex, so I had a knack for playing with hex codes. Anyways, I saw a few peculiar gaps in RAM and then one that gave me the most reward was the one between 843Fh and 8445h. What struck me as odd was the fact that there were 4 bytes unaccounted for, so I played with them and I made a very fun program:

So what was in the secrets of these bytes? These bytes were counters, but the one at 8442h was the one that you could really take advantage of. When a key is not being pressed, it has a value of 50. As you hold a key down, that decrements until zero. If it is a repeating key and the counter hits zero, it "presses again" so to speak and resets the counter to ten and repeats in this way. The above example is a getkey hook that checks the counter and updates it itself. This is also a feature I put in several programs including BatLib.

However, that ws not the only thing I discovered in playing around. I also made a program to simulate keypresses. The user passes a value through Ans and that key is simulated. For example, Enter has a key code of 9 (these are the same keycodes that you use in Grammer, Axe, and a number of other programs). So to simulate Enter, you do 9:Asm(prgmKS. unfortunately, that just causes the program to be executed over and over (until you press some other key). However, this also lets you open up menus and whatnot, too. What I figured out is that when you add 56 to the keycode, that is like pressing [2nd] and then the key and add another 56, you get [alpha] press. Some of these codes are also replaced with things to clear your RAM, display prgmA (even if you don't have it) and others.


So why did I make this topic now? To be honest, I was looking for a way to redraw the homescreen because I couldn't find a bcall to do it. I just simulated [2nd][mode] on my way out which costs 5 bytes and only 20 cycles

EDIT: Added the proggies seen in the screenshot. Also, I would like to note that I added the RAM equate 8442h on WikiTI a while ago and called it keyDelay if anybody is interested.

A few are curious about my Tic-Tac-Toe algorithm, so here it is First, I would like to give credit as well to Michael Macie. We designed this last year for a linear algebra project and it is very beautiful indeed I have modified it a bit to make it work even better with matrix row operations.

First: In Tic-Tac-Toe, there are 9 positions and 8 wins. What we did is something that we have seen nowhere else and makes things amazingly less complex. As in, a child with rudimentary math skills might be able to get it. Each position we label as a to i like this:
a  b  c
d  e  f
g  h  i

We then assigned a matrix of win contributions to each position. I changed this to using a row of 8 elements. So, in my example, we can do:
[[D1,H1,H2,H3,V1,V2,V3,D2]] where D1 is the main diagonal, H1~H3 or horizontal wins, V1~V3 are vertical wins, and D2 is the other diagonal. If a position corresponds to a win, give it a 1, like so:

[a]=[[1,1,0,0,1,0,0,0]]
[b]=[[0,1,0,0,0,1,0,0]]
...
Et cetera. Now, reform this into a giant 9x8 matrix. This matrix remains constant. Here is where the actual algorithm come in :D Get ready...

Now, the game matrix starts clean, with 0s: [[0,0,0,0,0,0,0,0]]. These are the wins. Now, say player one selects position [a]. Add its matrix to the game matrix and you get [[1,1,0,0,1,0,0,0]]. Player two will subtract from the game matrix, so it tries to:
1) Make a -3
2) Make as many -2s as possible without leaving any 2s. If you leave 2 -2s, this will make a trap for next turn. If you leave a 2, then X will win next turn.
3) Make as many 2s into 1s if you cannot do any of that. Remember, a 2 now will turn into a 3 the next move and 3 means X got 3 in a row!

See how beautiful that is? For X, it follows the same algorithm, but use the negative of any of the numbers :) The really nice part is that:
-You can easily include random choices of moves  that fit the highest criterion.
-When the game is over, use the winning matrix and any 3s or -3s are wins, so you will know exactly where to strike through for wins!

Now, I would post my tic-tac-toe program, but I apparently never saved my final version (which was in english instead of french and had the bugs fixed). Instead, I will show you a screenie :)