Don't learn assembly first. At least learn Axe before that.

Most of us assembly programmers started with asm, personally i never learned any Axe.

My vote is go for what you want any language can be hard if you dont work on understanding it. I started with asm and honestly I am a horrible coder of Ti-Basic and axe I suck at them frankly.

Learn what you think you will enjoy most. They all have there pluses and minuses ^^

I agree with this. I suck at TI-BASIC and switched to asm as soon as i found out about it. Really, as Hayleia mentions, learning assembly (or Axe) first will prevent you from trying to use/depending on high-level concepts too much in your assembly code and help you to think like the processor, a little more streamlined. I can't comment much on Axe, but there are a lot of very impressive games programmed in it. Besides, i think that learning assembly would help you tremendously in Axe, you'd have a better idea of what exactly each command does, it's speed, size, etc. Once you get a basic grasp of the language (which really doesn't take that long) you can just start talking to other programmers, asking questions, looking through source code, etc. and you'll be writing cool games and programs in no time

If you want to learn BASIC then Axe then asm, go for it, just don't feel limited to that order or put off by the supposed difficulty of Axe and asm. I think it takes the same amount of time to learn TI-BASIC really well as it does to learn assembly/Axe, and maybe even longer to be good enough to do a lot of the cool things BASIC programmers do! Axe/asm folks are always excited to see new programmers come around and are anxious to help out.

CoBB's tutorial is pretty good: http://sgate.emt.bme.hu/patai/publications/z80guide/

Other than that, here's what i wrote at Cemetech:
Some things that can be helpful to understand to be able to start writing fun games quickly:
-indirection
-what buffers are and why/how to use them
-direct input
-tilemapping
-how the LCD is mapped: 1 byte = 8 pixels. This complicates drawing individual pixels a bit but means your sprites will be much smaller in size.
-bit shifting commands, absolutely necessary once you want to start making games that scroll smoothly and also very useful for optimizing
-storing and accessing data in tables

Assembly uses an assembler, i use spasm. Essentially you just run the source file through spasm and it outputs a .8xp. The assembly mnemonics correspond directly with the z80s commands, the assembler just converts the mnemonics into assembly opcodes (hex) as well as making a lot of other things easier for you, for example calculating addresses so you don't need to count how many bytes there are to jump to the right address and lots more.

If you have any questions, please ask! I don't think it's as difficult as people think (it was my first language, after English) it just takes a little while to get used to thinking differently.

Check out this topic:
http://ourl.ca/18085

There's a file called 8xp28xv.exe which should do that for you, and FloppusMaximus mentioned that their TIpack should also do that (which also includes the source): http://www.ticalc.org/archives/files/fileinfo/399/39967.html

I believe on the ez80 instructions all generally fit into one t-state, or rather due to the way the ez80 is set up it can pipeline/decode instructions in advance and execute them within one t-state. On the z80, each cycle takes 3-6 t-states and i assume it's basically the same on the ez80. For example:
xor a takes one machine cycle of 4 t-states.
add a,3 takes two machine cycles, the first is 4 t-states and the second is 3, altogether 7 t-states.
add hl,de takes three machine cycles, the first two are 4 t-states and the third is 3, altogether 11 t-states.
add ix,de takes four machine cycles, three cycles of 4 t-states and the last one is 3, altogether 15 t-states.
ld (ix+4),a takes 5 M cycles, 4 t-states for the IX prefix, 4 more to read the opcode, 3 t-states to read the offset, 5 to add the offset and read a, 3 t-states to write a to the address.
rl (ix) takes six M cycles, amounting to 23 t-states. I'm not sure what each each cycle amounts to, i think first you've got the IX prefix (4 t-states), then the opcode (4 t-states), then the offset (here, +0, 3 t-states), i don't know what the others might be.

So i think on the ez80, these M cycles will be prefetched/decoded while the previous instruction/cycle decodes/executes (each instruction must be fetched, decoded, then executed) so that they can be immediately executed when the previous instruction ends.

EDIT: Also, i was just thinking about how convenient add hl,imm16 would've been. It'd save you from having to destroy bc/de.

The other routine is just a plain rectangle (non-filled) drawing routine. I don't bother SMC'ing the or (hl), just the ld (hl),a. What it does is draw the first and last pixels of the line/border outside of the main loop then either draws (ld (hl),a) all pixels in between or skips (nop's) them all. It's a bit larger so unless the speed is that important you might be better off drawing two filled rectangles with the other routine, one OR'd and a slightly smaller one XOR'd.

Also, i just realized i don't need the "or a" after "ex af,af'" since the flags should still be preserved from the "and $7", so we can delete that.

It's interesting to see how our syntax/style differs even on bits of code that do exactly the same thing

And if you don't mind sacrificing just a few clocks (altogether maybe between 8-64), maybe you could try this and save 2 bytes:
ComputeByte:
and 7
ld b,a
ld a,$FF
ret z
  srl a ;or or a \ rra
  djnz $-2
ret

That's a cool trick with the add a,a \ dec a. My first go at it only handled multiples of 8 and looked like this:
;b = # columns
;c = # rows
;d = starting x
;e = starting y
rectangle_filled2:
ld a,d ;a = starting x coord
ld l,e ;ld hl,e
ld h,0 ; ..
ld d,h ;set d = 0
add hl,de ;starting y * 12
add hl,de ;x3
add hl,hl ;x6
add hl,hl ;x12
rra ;a = x coord / 8
rra ;
rra ;
and %00011111 ;starting x/8
ld e,a ;
add hl,de ;add x
ld de,gbuf
add hl,de ;offset in gbuf
ld a,b ;b = no columns
rra
rra
rra
and %00011111 ;no. columns / 8
ld b,a
ld a,12
sub b
ld e,a
ld d,0
rectangle_loop_y:
push bc
rectangle_loop_x:
ld (hl),$FF
inc hl
djnz rectangle_loop_x
pop bc ;restore c (# columns)
add hl,de ;move down to next row
dec c
jr nz,rectangle_loop_y
rectangle_end:
retMuch smaller and faster, but certain cases (for example, a rectangle less than 8 pixels wide, 2 byte rectangles, etc.) seemed like they were going to bump up the size quite a bit and what I wanted was to write it more for size than speed since it's not being used in any time-critical areas of the game (mostly in menus and the battle engine). How do you handle cases where, say, a rectangle doesn't fill an entire byte?

The gbuf bit is also pretty creative (i guess you could also just add a,$40) but unfortunately wouldn't work out since it's being written for the 83 as well, though i guess a simple define would do. Yep:
#ifdef TI83P
GBUF_LSB = $40
GBUF_MSB = $93

.org progstart-2
.db $bb,$6d
#else
GBUF_LSB = $29
GBUF_MSB = $8E
.org progstart
#endif
;...
rra ;a = x coord / 8
rra ;
rra ;
and %00011111 ;starting x/8 (starting byte in gbuf)
add a,GBUF_LSB
ld e,a ;
ld d,GBUF_MSB ;
add hl,de ;hl = offset in gbuf...works just fine for the 83/+

I hope deeph doesn't mind, if you feel like checking their project out it's over at yAronet: http://www.yaronet.com/posts.php?s=153983

EDIT: Here's a version that draws vertically (here b = height and c = width) which seems to be slightly faster (and's the same size):
#ifdef TI83P
GBUF_LSB = $40
GBUF_MSB = $93
#else
GBUF_LSB = $29
GBUF_MSB = $8E
#endif

;b = # rows
;c = # columns
;d = starting x
;e = starting y
rectangle_filled_xor:
ld a,$AE ;xor (hl)
jr rectangle_filled2
rectangle_filled_solid:
ld a,$B6 ;or (hl)
rectangle_filled2:
push de
push bc
ld (or_xor),a ;use smc for xor/solid fill
ld a,d ;starting x
and $7 ;what bit do we start on?
ex af,af'
ld a,d ;starting x
ld l,e ;ld hl,e
ld h,0 ; ..
ld d,h ;set d = 0
add hl,de ;starting y * 12
add hl,de ;x3
add hl,hl ;x6
add hl,hl ;x12
rra ;a = x coord / 8
rra ;
rra ;
and %00011111 ;starting x/8 (starting byte in gbuf)
add a,GBUF_LSB
ld e,a ;
ld d,GBUF_MSB ;
add hl,de ;hl = offset in gbuf
ex af,af' ;carry should be reset and z affected from and $7
ld d,a
ld a,%10000000
jr z,$+6
rra
dec d
jr nz,$-2
ld e,12
rectangle_loop_x:
push af
push bc
push hl
ld c,a
rectangle_loop_y:
or_xor = $
or (hl) ;smc will modify this to or/xor
ld (hl),a
ld a,c
add hl,de
djnz rectangle_loop_y
pop hl
pop bc
pop af
rrca
jr nc,$+3
inc hl
dec c
jr nz,rectangle_loop_x
rectangle_end:
pop bc
pop de
ret
EDIT: Small optimization

Wow, that's just incredible! The text feature is a really nice touch.

What do you have in mind for the menus?