I have had this idea since my first attempt at an OS, but I ran into a few problems. Basically, I wanted to store the graph buffer in columns because I thought it would be very useful for drawing tiles and updating the LCD. Then I started thinking about line drawing, circle drawing, and anything that would cross a byte boundary and I realised that some routines would take a major hit to speed.

I am working on a project and I am still trying to decide if it would be beneficial to organise the screen in this manner. Here is an example of a tile drawing routine using the current buffer setup:
drawtile:
;DE points to the sprite data
;BC = (y,x)
; draw an 8x8 tile where X is on [0,11] and Y is on [0,7]
     ld a,b
     add a,a
     add a,b
     add a,a
     add a,a
     add a,a
     ld h,0
     ld b,h
     ld l,a
     add hl,hl
     add hl,hl
     add hl,bc
     ld bc,(DrawBufPtr)
     add hl,bc

     ld bc,12
     ld a,8
       ex de,hl   ; 32
       ldi        ;128
       ex de,hl   ; 32
       add hl,bc  ; 88
       inc c      ; 32
       dec a      ; 32
       jr nz,$-7  ; 91
     ret
And here is how it looks the other way:
drawtile:
;DE points to the sprite
;BC = (y,x)
;X*64
     or a
     ld a,c
     ld l,0
     rra
     rr l
     rra
     rr l
     ld h,a
;y*8
     ld a,b
     add a,a
     add a,a
     add a,a
     add a,l
     ld l,a
     ld bc,(DrawBufPtr)
     add hl,bc
     ex de,hl
     ld bc,8
     ldir
     ret
The former is 565 t-states 33 bytes, the latter is 281 t-states 28 bytes. There are ways to optimise both routines for speed. If you have ever written your own LCD updating routine, you probably already realized just how straight forward this would make the routine (and if we had no LCD delay, it would amount to basically 12 iterations of ld b,64 \ outir). We typically don't need to optimise for speed with such an LCD update because most of the time, the code is waiting for the LCD to respond before moving to the next byte. However, if you are doing something like grayscale or interleaving another routine with the LCD update (like drawing a tilemap at the same time), this gives you even more time to do more complicated things with the LCD, putting your 'waste cycles' to more use.

Sprite Drawing
The reason for why some drawing will be so easy is that each 8 columns of pixels is 64 bytes which is much nicer to work with than a row of pixels being 12 bytes. We also see a huge boost in performance when moving down or up a pixel because that only requires an increment or decrement of a pointer, instead of adding 12 each time. However, now we get the same problem when moving left or right across byte boundaries. This means that sprite routines could take a hit, but let's see how far we can remedy this.

This will be a very simple routine to XOR an 8x8 sprite to the gbuf:
PutSprite8x8:
;Note: No clipping.
;Inputs:
;     BC = (x,y)
;     IX points to the sprite
;     1871 worst-case
     ld a,b
     and $F8
     ld h,0
     rla \ rl h
     rla \ rl h
     rla \ rl h
     ld l,a
     ld a,b
     ld b,0
     add hl,bc
     ld bc,9340h
     add hl,bc
;HL points to the first byte to draw at
     and 7
     jr nz,crossedbound
       push ix \ pop de
       ld b,8
         ld a,(de)
         xor (hl)
         ld (hl),a
         inc hl
         inc de
         djnz $-5
       ret
crossedbound:
     ld b,a
     dec a
     ld (smc_jump1),a
     ld (smc_jump2),a
     ld a,1
       rrca
       djnz $-1
     dec a
     ld e,a
     ld c,8
;E is the mask
;IX points to the sprite
;HL points to where to draw
drawloop1:
     ld a,(ix)
     .db 18h      ;start of jr *
smc_jump1:
     .db 0
       rlca
       rlca
       rlca
       rlca
       rlca
       rlca
       rlca
     and e
     xor (hl)
     ld (hl),a
     inc ix
     inc hl
     dec c
     jr nz,drawloop1
     ld c,56
     add hl,bc
     ld a,e
     cpl
     ld e,a
     ld c,8
drawloop2:
     ld a,(ix-8)
     .db 18h      ;start of jr *
smc_jump2:
     .db 0
       rlca
       rlca
       rlca
       rlca
       rlca
       rlca
       rlca
     and e
     xor (hl)
     ld (hl),a
     inc ix
     inc hl
     dec c
     jr nz,drawloop2
     ret
That actually turns out to be pretty fast, so if you need to draw sprites, this is still a viable buffer setup.

LCD Updating
As promised, the routine to update the LCD is fairly straight forward:#define     lcddelay()  in a,(16) \ rlca \ jr c,$-3
     ld a,5
     out (16),a
     lcddelay()
     ld a,80h
     out (16),a
     ld hl,9340h
     lcddelay()
     ld a,20h
col:
     out (16),a
     push af
     ld bc,4011h
row:
     lcddelay()
     outi
     jr nz,row
     lcddelay()
     pop af
     inc a
     cp 2Ch
     jr nz,col
     ret

Note that if you are only ever doing fullscreen updates (or at least full columns) and you are always using the same increment mode, you can leave the first part of that code in a setup portion of your code:
     .org 9D93h
     .db $BB,$6D
Start:
     ld a,5        ;set the increment mode, only needs to be done once
     out (16),a
     lcddelay()
     ld a,80h    ;set the row pointer, only needs to be done once, since the LCD update routine leaves it where it started.
     out (16),a
Main:

<code>

UpdateLCD:
     ld hl,9340h
     ld a,20h
col:
     out (16),a
     push af
     ld bc,4011h
row:
     lcddelay()
     outi
     jr nz,row
     lcddelay()
     pop af
     inc a
     cp 2Ch
     jr nz,col
     ret

Pixel Plotting
;GetPixelLoc
;Inputs:
;     BC =(x,y)
;     DE is the buffer on which to draw
;Outputs:
;     Returns HL pointing to the byte where the pixel gets plotted
;     Returns A as a mask
;     NC returned if out of bounds, else C if in bounds
     ld a,c \ cp 64 \ ret nc
     ld a,b \ cp 96 \ ret nc
     and $F8
     ld h,0
     rla \ rl h
     rla \ rl h
     rla \ rl h
     ld l,a
     ld a,b
     ld b,0
     add hl,bc
     add hl,de
;HL points to the first byte to draw at
     and 7
     ld b,a
     ld a,1
     inc b
     rrca \ djnz $-1
     scf
     ret
Now to set the pixel, use or (hl)  \ ld (hl),a or use xor to invert, and to erase, cpl \ and (hl) \ ld (hl),a.

Final Analysis
It turns out that most drawing is faster and that my original fears were just based on me being too accustomed to one way of doing things. Line drawing, circle drawing, and rectangle drawing are all faster (lines and circles just because it is faster to locate a pixel, rectangles because it just works fantastically). Sprites, tiles, and LCD updating work out great. However, there is one area that does in fact take hit and that is scrolling the screen. Shifting up and down is still relatively easy, but shifting left and right will be slower and more complicated. Shifting up or down is just shifting the whole buffer 1 byte instead of 12, which is the same speed. Here is shifting right:
     ld hl,9340h     ;gbuf
     ld de,64
     ld c,e
loop:
     or a
     ld b,12
       rr (hl)
       push af \ add hl,de \ pop af
       djnz $-5
       dec h \ dec h \ dec h
       inc l
       dec c
       jr nz,loop
     ret
That is now half the speed of what it is for the current gbuf setup. We can cut out 9828 t-states if interrupts are off, though, but that is still a huge hit to speed.

Aside from that, I like the idea of organising the buffer this way.

EDIT: Modified a few routines to be smaller, no speed change, though.
EDIT2: Added a link to the rectangle routines below.

That looks pretty awesome.
I guess this is a redraw every frame aligned map ?

Thanks! And I do not know what you mean. It redraws whenever an animated tile goes to its next frame and it only draws to 8x8 regions (so there are 96 tile locations on the screen). For my purposes, this is enough (I will be using smooth-scrolling in the way Pokémon games did it by scrolling in a whole tile, 1 pixel at a time). However, for a project such as what Hot_Dog had in mind, it would be useful to have an option for drawing the map at any pixel offset.

Also, I just compared my sprite drawing routine to the one in Axe and my speed estimate was really far off (I massively overestimated how long it would take). Anyways, my method did turn out faster >.>

Necrobump o_O

I just googled "how fast are sprite drawing routines TI-84+" to see if anybody has already done some calculations when I found this page again and it actually happens to be relevant. I completely forgot about this, but I am glad I found it!

In one of my projects, I have it so that my interrupt routine and the interrupt table are in the app (I know this sounds like a bad idea and I need to be sure not to swap out the page without turning off interrupts). The interrupt is actually what I use to handle LCD updating and drawing the tilemap. All I have to do is write the tileset pointer, tilemap location, width, and height to a spot in RAM, and as well, the current (X,Y) offsets into the map. Then set a flag saying that it is in tilemap mode, and another flag saying that the tilemap needs to be rendered and the interrupt will render it. Since the interrupt is also handling the keyboard, my code uses a bunch of halt instructions, ensuring that the tilemaps are updated smoothly. The other tasks include animating the tiles and if any tiles move to a new frame, the tilemap is automatically updated on the LCD. This is an example code and the screenshot of it:
Continue:
     call whilekey
     call loadtestmap
moveloop:
     halt
     ld a,(curkey)
     or a
     jr z,moveloop
     cp 15
     jp z,softreset
     cp 9
     jr nz,testmove
testtileevent:
       jr moveloop
testmove:
     ld hl,(yoffset)
     ld de,(xoffset)
     dec a
     jr nz,$+3
       inc hl
     dec a
     jr nz,$+3
       dec de
     dec a
     jr nz,$+3
       inc de
     dec a
     jr nz,$+3
       dec hl
     ld (yoffset),hl
     ld (xoffset),de
     jr moveloop

In order to make this code better for more general use, it would have to have the interrupt reside in RAM and make it easy for the user to link their own interrupt code.

I am still working on refining the tilemap routine and sprite routines (as you could probably tell from the Google search). However, here is all of the code in my interrupt currently, as well as relevant subroutines and a little documentation (I didn't have it prepared):
This code is still under construction and I am working out a lot of details. For example, I plan to have 3 layers-- the tilemap, and a masked layer on top of that (for things such as the player sprite and NPCs). I also have been thinking about storing to the graph buffer differently and organising it in columns, but I am still in the process of analysing the respective performance gains and hits. (which is what the original Google search was for). If anybody knows, I have 3297 t-states for my worst case drawing of an 8x8 sprite with XOR logic and 236 t-states for drawing a tile ^^. Shifting the LCD for smooth scrolling is what I am really worried about.

EDIT: Also, the tilemap and tileset:
testmap: ;23 wide, 13 tall
 .db 3,3,3,3,3,3,3,3,3,3,3,3, 3,3,3,3,3,3,3,3,3,3,3
 .db 3,0,0,1,1,1,0,0,0,0,0,4, 0,0,0,0,0,0,0,0,0,0,3
 .db 3,0,0,1,1,1,2,2,2,0,0,3, 1,0,0,0,1,0,1,7,1,0,3
 .db 3,0,0,1,1,1,2,2,2,0,0,3, 7,0,0,0,7,0,0,1,0,0,3
 .db 3,5,5,5,0,0,2,2,2,0,0,3, 1,7,1,7,1,0,0,7,0,0,3
 .db 3,5,5,5,0,0,0,0,0,0,0,3, 7,0,0,0,7,0,0,1,0,0,3
 .db 3,5,5,5,0,0,0,0,0,0,0,3, 1,0,0,0,1,0,1,7,1,0,3
 .db 3,3,3,3,4,3,3,4,3,3,3,3, 0,0,0,0,0,0,0,0,0,0,3
 .db 3,0,1,2,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,3
 .db 3,3,4,5,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,3
 .db 3,6,7,8,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,3
 .db 3,9,10,11,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,3
 .db 3,12,13,14,0,0,0,0,0,0,0,0, 0,0,0,0,0,0,0,0,0,0,3

#define addtile(tile,evolve,dur) .dw tile \ .db (evolve-TileData)/4,dur

TileData:
tile_blank:    addtile(blank,  tile_blank,  0)
tile_flower1:  addtile(flower1,tile_flower2,16)
tile_grass:    addtile(grass,  tile_grass,  0)
tile_bush:     addtile(bush,   tile_bush,   0)     ;a small tree (8x8)
tile_vine:     addtile(vine,   tile_vine,   0)     ;instead of that silly tree to cut down
tile_water1:   addtile(water1, tile_water2,10)

tile_water2:   addtile(water2, tile_water1,10)
tile_flower2:  addtile(flower2,tile_flower1,16)


blank:
 .db 0,0,0,0,0,0,0,0
flower1:
 .db $44,$AA,$44,$00,$22,$55,$22,$00
flower2:
 .db $22,$55,$22,$00,$44,$AA,$44,$00
grass:
 .db $00,$66,$55,$33,$00,$66,$55,$33
bush:
 .db $18,$34,$4A,$85,$8B,$76,$18,$3C
vine:
 .db $91,$7E,$52,$89,$91,$4A,$7E,$89
water1:
 .db $44,$AA,$11,$00,$22,$55,$88,$00
water2:
 .db $11,$AA,$44,$00,$88,$55,$22,$00

BlackTile:
     .db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF


EDIT: On a semi-offtopic note, why is there no TI-84 Plus C (color) Silver Edition reference nor info on TI-BD?

I think it is because none of the main contributors have one yet

I have some potential bugs and suggestions:
I tried to upload an image and it is instead recognising it as a duplicate. I think it is because the starting frames are identical.

Suggestions:
The ability to delete ore replace old images. I am currently keeping a project updated in my signature with a single screenie, so it would be cool to be able to update it in the image uploader and have it updated in my signature. I now have a few duplicate uploads cluttering the "previous uploads" which is why I was suggesting the delete option.

I noticed that yesterday :[ I do hope it can be put back online.

Hmm, you cannot get CopyProg to work? What isn't working? I tried the line reading and that works, and copying from one var to another worked for me, as well as the GetName instruction works for programs and whatnot (I just tested it and there is an issue with strings and whatnot, but it still returns strings in an appropriate format).

Maybe if the user is pressing [DOWN], skip the delay? Nice job, by the way!