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.

Yeah, in my app the shadow registers are free game (the interrupt routine preserves them). As for using IX, it depends on where it is used, because something like ld a,(ix+n) is 19 t-states, versus 7 for ld a,(hl).

Cool, I hope that helps! It turns out that people like Iambian and tr1p1ea have been using this technique for years! Here are a few more routines that could probably still be optimised:
;RectangleErase can be optimised to be much faster if you make it its own routine using cpl \ and (hl) for logic. Currently, it uses RectangleOR \ RectangleXOR
;Included Routines
;======================
;Inputs:
;     B = Height
;     C = Width
;     D = X (leftmost)
;     E = Y (upper)
;RectangleBoxEraseFill
;  Draws a box with a black border, interior is erased.
;  Returns B-2, C-2, D+1, E+1
;RectArrowXOR
;  Draws an arrow pointing right with XOR logic
;  Returns BC,DE unchanged
;RectangleMenu
;  Draws a box with rounded edges
;  Returns D+1,C+2, B and E unchanged
;RectangleOR
;  Draws a black rectangle
;  Returns BC,DE unchanged
;RectangleXOR
;  Inverts the region of the screen
;  Returns BC,DE unchanged
;RectangleErase
;  Draws a white rectangle
;  Returns BC,DE unchanged

RectangleBoxEraseFill:
     call RectangleOR
     inc d
     inc e
     dec b
     dec b
     dec c
     dec c
     jp RectangleXOR
RectArrowXOR:
     push de
     push bc
     ld a,b
     cp c
     jr c,$+3
       ld b,c
     ld c,1
;B is now the smaller of the two
;C is 1
     call RectangleXOR
     inc d \ inc e
     djnz $+5
     pop bc
     pop de
     ret
     djnz $-10
     jr $-5
RectangleMenu:
     call RectangleErase
     push bc \ push de
     inc e \ dec b \ dec b
     call RectangleXOR
     pop de \ pop bc
     inc d \ dec c \ dec c
     jr RectangleXOR
RectangleErase:
     call RectangleOR
RectangleXOR:
;Inputs:
;     DE is (x,y)
;     BC is (h,w)
;Outputs:
     push de
     push bc
     call RectMain
     jr nz,$+11
       ld a,c
       xor (hl)     ;logic
       ld (hl),a
       inc hl
       djnz $-4
       jp EndRect
     ld d,a        ;number of columns before last col
     ld e,b
     ld a,(rect_FirstByte)
     ld c,a
xorrectcol:
     ld b,e        ;height
     push hl
xorrectloop:
     ld a,(hl)
     xor c          ;logic
     ld (hl),a
     inc hl
     djnz xorrectloop
     pop hl
     ld c,64
     add hl,bc
     ld c,-1
     dec d
     jp m,endrect
     jr nz,xorrectcol
     ld bc,(rect_LastByte)
     jp xorrectcol
RectangleOR:
;Inputs:
;     DE is (x,y)
;     BC is (h,w)
;Outputs:
     push de
     push bc
     call RectMain
     jr nz,$+11
       ld a,c
       or (hl)     ;logic
       ld (hl),a
       inc hl
       djnz $-4
       jp EndRect
     ld d,a        ;number of columns before last col
     ld e,b
     ld a,(rect_FirstByte)
     ld c,a
orrectcol:
     ld b,e        ;height
     push hl
orrectloop:
     ld a,(hl)
     or c          ;logic
     ld (hl),a
     inc hl
     djnz orrectloop
     pop hl
     ld c,64
     add hl,bc
     ld c,-1
     dec d
     jp m,endrect
     jr nz,orrectcol
     ld bc,(rect_LastByte)
     jp orrectcol
EndRect:
     pop bc
     pop de
     ret
RectMain:
;Inputs:
;     DE is (x,y)
;     BC is (h,w)
;Outputs:
;     returns z if it is all in one column, else it returns the number of columns
;     HL points to the start byte
;     (rect_FirstByte), (rect_LastByte)
;     A is negative the number of columns
;     BC is (h,w)
;
;If it is a single column wide, C is the mask, B is the height
     ld a,d
     and %11111000
     ld h,0
     rla \ rl h
     rla \ rl h
     rla \ rl h
     ld l,a
     ld a,d
     ld d,0
     add hl,de
;HL points to the byte it will start on
     push hl
     ld d,a
     push bc
     call ComputeByte
     ld (rect_FirstByte),a
     ex (sp),hl
     ld a,d
     cpl
     and 7
     inc a
     ld b,a
     ld a,l
     sub b
     ex (sp),hl
     call ComputeByte
     cpl
     ld (rect_LastByte),a
;last and first byte are computed   
     ld a,d
     and %11111000
     ld e,a
     ld a,d
     add a,c
     and %11111000

     pop hl
     ex (sp),hl
     ld bc,(DrawBufPtr)
     add hl,bc
     pop bc

     sub e
     rrca
     rrca
     rrca
     and %00011111
     ret nz
     ld de,(rect_FirstByte)
     ld a,d \ and e
     ld c,a
     xor a
     ret
ComputeByte:
     and 7
     ld b,a
     ld a,80h
     jr z,$+5
       rrca
       djnz $-1
     add a,a
     dec a
     ret
I also made some text display routines, but they are pretty complicated, so I will have to organise them before posting.

That is an excellent idea! So the code would look like:
     ld ix,gBuf+128
     ld b,64
shiftrightloop:
     srl (ix-128) \ rr (ix-64) \ rr (ix) \ rr (ix+64) \ inc ixh  ;100
     rr (ix-128) \ rr (ix-64) \ rr (ix) \ rr (ix+64) \ inc ixh   ;100
     rr (ix-128) \ rr (ix-64) \ rr (ix) \ rr (ix+64)  ;92
     dec ixh \ dec ixh \ inc ix ; 26
     djnz shiftrightloop
     ret
That is 21210 t-states, which is much nicer!

Ahh good old buffer changeup . Its always good to change things up, since as you have realised ... you can get some good improvments out of it! .

Great set of routines btw .

Ok, I finished it:
#define DWAIT in a, ($10) \ or a \ jp m, $-3

copySetup:
        di
        ld hl, $9900
        ld de, $9901
        ld bc, $100
        ld (hl), $98
        ldir
       
        ld a, $C3
        ld ($9898), a
        ld hl, interrupt
        ld ($9899), hl

        ld a, $99
        ld i, a
        im 2

        xor a
        out (03), a ;don't use halt

        ld a, $A0 ;64 t-state timer
        out ($30), a
        ret

; hl is the buffer to use
interruptCopy:
        nop
        ld a, $C9
        ld (interruptCopy), a ;safeguard against running twice
        ld e, $20
       
nextColumn:
        DWAIT
        ld a, e
        out ($10), a
        cp $2E
        jr nz, notDoneYet
        xor a
        ld (interruptCopy), a
        ex af, af'
        exx
        ret ;returns with interrupts disabled
notDoneYet:
        inc e
        DWAIT
        ld a, $80
        out ($10), a
        ld bc, 64*256+$11
        ld a, 3
        out ($31), a ;this is 3*64 = 192 t-states per write
        out ($32), a ; you can refine this, but 192 is probably good
        ex af, af'
        exx
        ei
        ret

interrupt:                      ;19 + 10
        ex      af, af'         ;4
        exx                     ;4
        out     ($31), a ;11 a = 3
        outi                    ;16
        jr      z, nextColumn   ;7
        exx                     ;4
        ex      af, af'         ;4
        ei                      ;4
        ret                     ;10
                                ;93 total

First of all, this only works in 15 MHz. It is actually worse in 6 MHz mode than the regular methods. To use this, call copySetup once, and then call interruptCopy whenever you need to update the screen. It won't let you run it again if it's still updating the screen (this would be bad) so that's good. The only downside is that you can't use interrupts (including getCSC) and you can't use HALT.