Back in the 'awake world', and I agree with the conclusion of ylp88 - double clocking the E line would add the extra nibble, and that is technically possible with my code ...<code><pre><font size=2>SendDataByte:
pins = byte & %11110000 | rsbit ; Put MSB out first
PULSOUT E,1 ; Give a 10uS pulse on E
pins = byte * %00010000 | rsbit ; Put LSB out second
PULSOUT E,1 ; Give a 10uS pulse on E
rsbit = RSDATmask ; Send to Data register next
RETURN </code></pre></font> If the E bit in the 'rsbit' variable were set when the routine was called, this could cause an E pulse in the 'pins=' commands as well as the PULSOUT's.
Why it appears that only the MSB was being double clocked is a mystery at present, and especially so as previous debugging shows 'rsbit' has correct values when the routine is called.
That $BF works could also be explained away by this phenomena; the cursor is set wrong, extra E clocking forces a byte to be written in the non-displayed part of the LCD's memory, when the "W" comes to be displayed, the cursor will have moved to where it should have been using a $C0 command.
One would expect other occurances of double E clocking, and that would be expected to have also shown up as problems, and there's no logical reason as to why there's only a noticeable problem with $C0 and a posibly hidden problem with $BF.
Technical may be right that there is some problem with the module, although I'm not at present entirely convinced of this. There could be other interactions going on which we aren't identifying yet, maybe some low resistance or capacitive short, but I'm only guesing wildly.
Faced with such a problem in a commercial environment the next course of action is to get a scope or logic analyser and start observing and analysing exactly what is being put out on the bus to the LCD. Without that, I'm not sure how to proceed, as we're only seeing half the picture.