The LCD delay is long, and sometimes there's nothing to do while it's delaying, so you have to use a routine that waits until the LCD is ready. In LCD-heavy programs, like a grayscale game, tons of time is wasted in such routines. The most common routine that I learned from @thepenguin77 is:
label: ;T-states
  IN A,($10) ;11
  AND %10010000 ;7
  JR NZ,label ;7/12
;6 bytes, destroys A
This routine is okay, but it might be improvable.  If you can use only bit 7 instead of both bit 7 and 4 (which is what I'm not sure about), these would work:
label:
  IN A,($10) ;11
  RLA ;4
  JR C,label ;7/12
;5 bytes, destroys A
That one is a bit better, but if you want to optimize for speed:
  LD C,$10 ;7
label:
  IN (C),A ;12
  JP M,label ;10
;7 bytes, destroys A/C
;If C is already equal to $10, you can skip the
;load instruction and save 2 bytes/7 T-states.
;If you are okay with using undocumented
;instructions, IN (C) would preserve A
These look like they're really helpful routines to help save a bit of space and to save a few T-states, which will really add up when you're writing to the screen 768+ times in a row. The second one in particular might work really well with a grayscale program. If you move around some instructions, then you only need to load $10 into C once, and then you can go through your whole screen-writing routine without having to do so for every delay.

@Sue Doenim : your second routine should use "jr c,", not "jr nz,". I usually go with the second method unless I can get $10 in C, then I use the "in a,(c)" method. I also optionally use compiler directives so the user can use undocumented instructions.

For example, in Grammer, I define my LCDDelay routine as:
in a,(16) \ rla \ jr c,$-3

But one of my favorite tricks that many people don't use (and you'll see in many of my projects) is that if I am only doing full-screen LCD updates and I don't need interrupts, then at the beginning of my program I disable interrupts and write 80h to port 16 (or BFh to port 16 if you are doing it the weird way). Then I can skip that entire step in my LCD update routine, since I write column-by-column and that internal LCD counter is automatically reset to the desired initial value by the end of my routine.

It doesn't save much, but it does save space (you almost certainly don't need to worry about an LCD delay between initializing with 80h and the first time you update the LCD), and you save a non-zero number of clock cycles each update, so it really is a "free" optimization.

Oh wow, I hadn't realized that!
EDIT: I saw this on that page:

NOTE: The contents of this port should NOT be less than 0Ch or the LCD driver will no longer respond.

I'm not adding anything to the discussion, but I just wanted to drop in and say hello thePenguin77. It's nice to see you're still around(and lurking at least ).

I'm not adding anything to the discussion, but I just wanted to drop in and say hello thePenguin77. It's nice to see you're still around(and lurking at least ).

I still exist This thread sent me an email with the @mention which is why I appeared. I've been considering to drop by omnomirc sometime to talk to people. I don't know when it's busy these days.

(P.S. This is what I work on now. Also, I tend to go by bcov77 on other platforms if you feel like googling.)