The kernel first tries to figure out what symbol is meant by any given user byte, and next where this symbol is located in the current font.
The kernel knows about 5 translations of bytes into console-screen symbols. In Unicode (UTF-8) mode, the UTF-8 code is just converted directly into Unicode. The assumption is that almost all symbols one needs are present in Unicode, and for the cases where this does not hold the codes 0xff** are reserved for direct font access. When not in Unicode mode, one of four translation tables is used. The four tables are: a) Latin1 -> Unicode, b) VT100 graphics -> Unicode, c) PC -> Unicode, d) user-defined.
There are two character sets, called G0 and G1, and one of them is the current character set. (Initially G0.) Typing ^N causes G1 to become current, ^O causes G0 to become current.
These variables G0 and G1 point at a translation table, and can be changed by the user. Initially they point at tables a) and b), respectively. The sequences ESC ( B and ESC ( 0 and ESC ( U and ESC ( K cause G0 to point at translation table a), b), c) and d), respectively. The sequences ESC ) B and ESC ) 0 and ESC ) U and ESC ) K cause G1 to point at translation table a), b), c) and d), respectively.
The sequence ESC c causes a terminal reset, which is what you want if the
screen is all garbled. The oft-advised echo ^V^O will only make G0
current, but there is no guarantee that G0 points at table a).
In some distributions there is a program reset(1) that just does
echo ^[c.
If your termcap entry for the console is correct (and has an entry
:rs=\Ec:), then also setterm -reset will work.
The user-defined mapping table can be set using mapscrn(8).
The result of the mapping is that if a symbol c is printed, the symbol
s = map[c] is sent to the video memory. The bitmap that corresponds to
s is found in the character ROM, and can be changed using setfont(8).