Wow, how does that work??
Well... that is a fair question. 
It looks simple, but in reality it needs quite some tricks:
Practically the routine locates the 2x2 text area on the screen where the cursor is. Then it copies the outlook of these fonts and places those to 32-byte buffer. After that it considers these 4 copied characters as 12x16 graphics mode and uses AND mask to make a shadow and OR mask to make a shape on top of them with correct offset. Then these 32-bytes are copied over the first 4 unused characters (those funny faces + card suits in European character set). Then these copied characters are used to replace the characters that were originally identified. When cursor moves, real characters are written again over copied ones in VRAM and all of this repeats again.
Personally I think that SKiLLa's plan is very good. We don't need full color support. We need fast text editor that responds now and not after some screen draw delay.
BTW SKiLLa: If you want ready made, documented, well designed 480x192 accurate mouse routine in assembly, that that is especially designed for (SCREEN 0) 80x24 character text mode, just send me mail... I love your idea.
And I fully agree with his plan and your statement, just in case he later wants to offer a slower but perhaps richer in features version alternative...
I agree so much that for MSXIRC, when I was asked to improve it so it could run on all UNAPI devices and perhaps improve some stuff, I was asked to add color support and decided not to, it is so fast as is, which is way more important for an IRC client
Just leaving the door open in case an alternative version enters his plans, but fully agree that text mode is the way to go for the main (and perhaps only) version
