Over the weekend i finished my first real assembly program!
It's a game replica of the Lights Out handheld game released by Tiger Toys in 1995. The objective is to turn all lights off (to black). Since i didn't make a scrambling routine yet you have to scramble it yourself. Use the arrow keys move and enter to turn on/off the lights. I've tried it on TI-83+ (Emulated) and TI-84+ and it runs just right.

I really feel good. Learning assembly has taught me a lot, and given me a good bit of brainteasers. Now that i've got the basics i just want to do more and more by myself! Dithcing those B_CALLs and making my own routines, making something amazingly complex, or just optimize routines.

This code is not optimzed, it's more like soulutionized, wich means the solutions work.

Source:
http://guttula.com/LightsOut.asm.txt
.8xp:
http://guttula.com/LightsOut.8xp

I learned from z80 assembly for absolute beginners, so I have not read about generating random numbers. Thanks for the tip, I'll take a looksies. I left the run indicator there because then i feel safe about my program running and not having crashed (has happened way often during developing).

Why 4x4? because 16x16 sprite routines are easy to make, and it nicely divides the screen.   But maybe the extra challenge is the reason to make a 5x5.

And if you only want 16 values, you can just "and $F" (and %00001111) and your "random" number will be limited to 0-15

If you did 5x5, you could also just use 8x8 sprites and add some other things around the border. Also, i'm not sure how you store the current status of a square, but if you used 2 bytes where each bit represented one square, you could easily check to see if the player has beaten the game or not just be checking if both bytes = 0.

And another idea: leave the cursor as it is, but also add in thepenguin's idea where you use a 4x4 (or 5x5) grid on the calculator keypad. Then, when you press that button the cursor will jump there and change the lights accordingly.

I just loaded it up to my calc and it's really nice! I would recommend not using _GetKey, though. Try pressing [2nd]+[On] while running your program and see what happens Generally you would use direct input, but here _GetCSC would also be quick enough. If you use direct input, you'll need to add a delay, otherwise the cursor will move too quickly!

Also, if you notice, you really don't even need sprites here. You're only drawing two different bytes to the screen: %10101010 and %01010101. You could just load %10101010 into a, draw that twice, move down a row, cpl (a faster and smaller way of doing xor $FF, so it will turn %10101010 into %01010101) and repeat 15 times. The main loop of your sprite routine will probably be smaller than the size of your 16x16 sprites!

Another tip is that often times if you're going to be editing a byte in RAM it'll be faster and smaller to load it into hl first. If more than one area will use it, you can load hl before jumping to that routine, for example your key checking routine:
DoKeyAction:
LD HL,Cursor
CP kLeft
JR NZ,RightKeyAction

LeftKeyAction:
LD A,(HL) ;load cursor column
DEC A ;smaller than cp 1, and also serves to decrease a :)
RET Z ;if Column=1 dont got left, it'll go off the grid
LD (HL),A ;1 byte, 7 T-States. Loading into an address is 3 bytes (1 byte for the opcode and 2 bytes for the address)
RET ;KeyAction is done: return to main loop

RightKeyAction:
CP kRight
JR NZ,UpKeyAction
LD A,(HL) ;load cursor column (we loaded Cursor into HL above)
CP 4
RET Z ;if Column=4 dont got right, it'll go off the grid
INC A
LD (HL),A
RET ;KeyAction is done: return to main loop
And in your main loop, you push HL which is a nice idea to save a little space, but why not do it like this:
LD HL,Cursor ;xorDraw active Sprite
LD B, (HL)
INC HL
LD C, (HL)
LD HL,ActiveSprite
PUSH HL ;save HL (sprite pointer) and BC (sprite coordinates)
PUSH BC
CALL XorDrawSprite ;aguments in BC and HL, as supposed to

B_CALL _GrBufCpy ;draw the current status and active square
B_CALL _getKey
CP kClear
JR Z,GameEnd
CALL DoKeyAction
POP BC
POP HL ;xorDraw active Sprite (on old location, so its ereased)
CALL XorDrawSprite? All in all your code is nice and well organized, though i might switch ix and hl around in your sprite routine just 'cuz ix is so slow and takes up more space. Either way, it's a nice first project and i look forward to seeing what else you've got planned!

I guess it'll help out with your battery life. I never knew about the _GetKeyRetOff B_CALL before. I don't think i'll ever actually use it, but it's nice to know