Hi all,
this is just an idea for a VGA text mode console improvement which would
provide us with 512 char fonts with little functionality loss.
Basically we perform a bit inversion of the font bitmap, and then map
foreground to background and background to foreground. If we turn off the
blink bit allowing high intensity background colours then we end up with
16 foreground colours, 8 background colours, no blink and no high
intensity background colours. Since both blink and bg high intensity are
seldom used (since you can (not quite) never be sure if you'll get one or
the other) we end up with a 16fg/8bg/512char font situation. Everything
works as expected except for direct memory access through vcs/vcsa, these
would need to be nibble swapped in the colour area, but then with 512 char
fonts these aren't exactly really supported anyway... What do you think?
Cheers,
MaZe.
On Tue, 4 Nov 2003 18:20:06 +0100 (CET) Maciej Zenczykowski wrote:
> this is just an idea for a VGA text mode console improvement which would
> provide us with 512 char fonts with little functionality loss.
>
> Basically we perform a bit inversion of the font bitmap, and then map
> foreground to background and background to foreground. If we turn off the
> blink bit allowing high intensity background colours then we end up with
> 16 foreground colours, 8 background colours, no blink and no high
> intensity background colours. Since both blink and bg high intensity are
> seldom used (since you can (not quite) never be sure if you'll get one or
> the other) we end up with a 16fg/8bg/512char font situation. Everything
> works as expected except for direct memory access through vcs/vcsa, these
> would need to be nibble swapped in the colour area, but then with 512 char
> fonts these aren't exactly really supported anyway... What do you think?
Unfortunately, this won't work, because the standard VGA text mode
uses funny tricks to convert 8x16 font bitmaps in memory to 9x16
bitmaps for real display (some graphic characters from the original
IBM charset are specially handled by the hardware).
However, for the framebuffer console (where we don't have hidden 9th
pixel column) this could be useful - it is certainly better to lose
high-intensity background (which almost nobody uses) than
high-intensity foreground (which is used much more often). Probably
this can be performed without actually inverting anything...
PS: I really use high-intensity background colors in VIM (though I
rarely run in in the console these days).
> Unfortunately, this won't work, because the standard VGA text mode
> uses funny tricks to convert 8x16 font bitmaps in memory to 9x16
> bitmaps for real display (some graphic characters from the original
> IBM charset are specially handled by the hardware).
True, forgot about this (not so) little detail. In 9pixel-wide font
modes, the 9th pixel for all chars is taken to be background, except for
0xC0..0xDF, where (if enabled) the 9th column is a copy of the eighth.
Basically this means my idea would work only in 8-pixel wide font modes
(which are probably still used quite a bit, on laptops especially - I'm
using a 100x40 video mode on my 800x600 LCD display with 8x15 font).
> However, for the framebuffer console (where we don't have hidden 9th
> pixel column) this could be useful - it is certainly better to lose
> high-intensity background (which almost nobody uses) than
> high-intensity foreground (which is used much more often). Probably
> this can be performed without actually inverting anything...
In framebuffer mode we should theoretically have no problem supporting any
number of characters we want. As long as we don't use direct video memory
access thru vcs/vcsa were programs expect 8-bit characters we can keep
even 16-bit (or 32) chars in memory (probably in unicode) - this of couse
increases the size of the font we need to keep resident in memory, but
we'd almost be rid of one level of font-mapping...
> PS: I really use high-intensity background colors in VIM (though I
> rarely run in in the console these days).
:)