Ting,

I'll bet your example is "test code" so i won't be to rigerous but...

I would suggest avoiding the interrupt processing to get this code up in the foreground as it looks somewhat convoluted to me. I would start simply init'ing the LCD, then progress to output to the LCD and using the Interrupt port pin in a "polling" mode to change messages.

If you do this you would, perhaps, more rightly find the best way to implement interrupts to allow message selection (i.e. seting a Update LCD flag with a MSG Index value which the foreground could use to update the LCD).

Regarding the "style" of the example provided:

1) Your Int routine should jump to it's point of entry (i.e.)

org 13
ljmp LCD_Interrupt

This is because you have code over-writing another interrupt vector which could erupt by accident or design.

2) Also all of the processing you do in your interrupt could cause problems if you have other concurrent processes occuring. It is more common to move data or init variable and to set a flag so the foreground performs the action (although there are always reasons to do otherwise). The example shown stays in a constant loop so for it's sake it doesn't matter but i doubt you really want to do it this way.

3) The ACALL to H_2 is needless (in the example) as you could just "fall-thru". This is also true for H_3.

4) An interrupt should save any foreground resource used to avoid contamination (not needed in your endless loop but ...) don't forget saving the PSW at the eruption of the interrupt.

There is more but i suggest an incremental "scratch" write doing progressively more as you get more comfortable with assembly.

Also use a simulator (if you are not already) as it will allow you to understand the implication of the interrupt code (path length, and resource implications).

regards,
p