Sweet, walking engines are always the funnest to make .

Spelli has taken over, possessed everyone cept me! Prolly cause my nick mesmerizes him! .

@tr1p: Yes walking engines are the funnest to make and this was the first one that I made

But all that fun will end when I finish the demo cause then it is back to the sprites, sprites, and more sprites

Yea sorry if you don't think this is moving forward at a good rate or is dead but it is not because I am trying to learn Assembly and will be trying to develop this in ASM instead of TI-BASIC so I can have more features and also SPEEEEED

Yea I don't plan on doing it in the next month maybe next year or two cause it is very hard I have one question to ask you though if you can help me but how do you get the adress of a label like my_label:

my_label is the address.  When the assembler assembles, it goes through line by line, and at the same time totals up how many bytes have been used by the program so far.  A label simply tells the assembler to remember how many bytes the label is from the beginning, and then translate it into an actual address when the assembler starts converting everything into raw binary/hex.  You don't have to worry about it yourself

however:
;header goes here
progstart: ;beginning of program, 0 bytes from $9d95 <-ASM program starting point
.db 0,0,0,0,0,0 ;define some bytes
my_label: ;label
 inc a ; command

Relative to progstart, what is the RELATIVE address of my_label?
answer:
7

I guess to sum it up, all I'm saying is that the actual value of the memory address is never actually needed.  You just need the name of the label and the assembler takes care of everything else for you.  However, it can be useful to take advantage of labels when you want to do self modifying code.  More on that later.

sorry if that was a bit complicated

http://nwps.ws/~dragonfire/Asmin28/lesson/day13.html#vct once again has a very nice explanation of vector tables (what you want), look up tables, and jump tables.

Keep in mind that if your table is stored in RAM (saferams for example), you can also change the values stored in the table.  This form of self modifying code is useful, but you can shoot yourself in the foot if you're not careful.  in general, SMC is frowned down upon, but it can definitely save size and speed in RAM programs.

As for your speed issues, there is no multithreading atm for z80 calcs.  You must design your code to deal w/ that.  Basically, if the person moves, just move them a bit, go check on the AI, and then loop everything from teh beginning again.  The speed of the z80 + ASM will allow you to cycle through the player and AI rather quickly, provided you make sure the event handlers are not too complicated.  If you end up doing too much during one key press, you don't have time to get to the AI.

#1 tip:  don't use bcalls!  they are generally bulkier because they are a part of the TIOS, and are designed to handle events w/ many possible cases.  Write your own or borrow someone else's code, provided you understand how it works, relatively well.

Also Iline:

http://www.geocities.com/calcul831415/help/83psysroutines.zip is the official TI system routines guide for 83+ series calcs.  It has basically all the bcalls you'll want.  It explains what they do, as well as inputs, outputs, and registers destroyed.  A bit of warning though, iirc, some of the routines have incorrect info, but it'd probably appear obvious if the emu crashed.

my suggestion is that if you're only drawing horizontal and vertical lines, write your own routine that only does those.  It will be much faster because it doesn't have to check for clipping, calculate slope, mess around too much with pointer arithmetic, etc.  It'd probably be faster than iline.  Otherwise, look for a line routine on TI calc.

btw, questions are always good.  I don't mind pointing you in the right direction, and eventually you'll figure out where to look for answers, and you probably won't need to ask questions

Any routine is simply a section of code that you call or jump too, but it can also find away back.  When you use a bcall, you basically jump to the code stored in ROM, and at the bottom there is a way for the rom call to return back to the place where it was code and continue running from there.

Routines and data are generally put after the main routine.  The main routine should typically be a closed loop.  The main function will control entry and exit of the program.  In between, it directs how your subroutines(bcalls, functions, what ever you want to call them) will be used to achieve the goal.  Sometimes data should be put w/ code, provided there's no way for the calc to proceed to the data and treat it as executable.

Typically:

lable_routine_name:
;some code here
;typically you use the registers and do something w/ them, assuming the program put in the right inputs
ret

And in your main program:

;load inputs into registers
call lable_routine_name
;when the routine is done, it comes back here and does next command

It's as simple as that.

if you read the instruction set provided in ASMin28, it will explain how call simply means push pc <-program counter/address of current command, jp lable_routine_name

ret <- pop "some register pair", jump there.  It'd not exactly what those two do, but that's the gist of it.