Most microcomputers treat character codes and screen codes
differently. This is because they serve different functions and
arranging them both the same would compromise the functionality or
implementation of one or the other.
The function of a screen code is to encode, at a position in the frame
buffer, what particular glyph should be shown by the video system at
that position on the screen. Additionally the code may include
information modifying the display of the glyph, such as a bit
indicating whether the glyph should be displayed in positive (white on
black background) or inverted (black on white background) form.
The patterns to generate the glyphs are usually stored in ROM (though
sometimes RAM) and looked up by address. If the screen code directly
encodes the (usually low portion of) the address in some of its bits
this makes simpler the hardware doing the lookup of the glyph from the
screen code. This is desirable to reduce both the hardware cost and
the complexity of the system. (The reason cost reduction is desirable
is obvious. Reducing complexity reduces the time spent on design and
debugging and also reduces the chance that a bug will go out in the
This tends to make screen codes map fairly closely to the hardware
used to generate the glyphs. For example, if there are 64 glyphs
available in the system (typically numbers, punctuation and upper-case
letters), they're likely to be stored at addresses whose lowest six
bits are hexadecimal $00 through $40 (binary xx000000 through
You'll note a difference if you compare the above to the ASCII
character set encoding, where this range, with all the bits
above the lowest six set the same, covers either:
- the (non-printing) control characters, punctuation and numbers
($00-$40), with no letters at all, or
- the upper case and lower case letters (and a bit of different
punctuation), with no numbers at all.
Character codes have two characteristics that are generally different
from convenient screen code numberings as described above.
First, they almost invariably have non-printing control characters
which, instead of requesting that a glyph be printed, request some
other action on the part of the printing device. For example, in ASCII
LF ($0A) character generally indicates to a printer or screen
that it should print subsequent characters on the next line.¹ Control
characters are also often used as instructions to code that is
processing characters; ASCII
NUL ($00) is often used to signal the
end of a string, for example.
Control characters are unnecessary in screen codes, however, and a
non-printing code simply wastes space in the list of screen codes.
Second, it's common to want to use a standard character set and
encoding (e.g., ASCII or Unicode UTF-8) for compatibility and easy
data interchange with other systems.
Using a standard fixes the codes you can use, and often in a way
inconvenient for use as screen codes, as we saw with ASCII in the
So, for the reasons described above, generally screen codes are easier
to do in one way, and character codes in another. Fortunately this is
not difficult to handle: most microcomputers provide a small routine
that will convert character codes to screen codes. A routine to "print
a character" is generally wanted anyway, since it lets commonly used
logic such as "print a character just after the last one printed on
the screen" be handled in one place (which also avoids co-ordination
problems between different routines that both print), so adding this
conversion is usually a trivial cost.
¹This is a simplified example; what the control characters do is
often far more complex and system-dependent than described here. But
the general idea is the same.