As the word width of BESM-6 was 48 bits, it was possible to use two byte widths for characters - 8-bit and 6-bit. The standard 8-bit bytes were used most often, and a 6-bit encoding was used in symbol tables of object files, allowing to have 8 significant characters in external names.
There were several 8-bit character encodings used in BESM-6:
It is the latter one that I'll describe first.
Unlike the IBM encoding for punchcards that used one column - 12 bits - per character, which had to be converted into an internal byte-based representation, the GOST punchcard encoding was 8-bit (actually, 7 bit with odd parity), was "horizontal", matched the internal character representation (modulo parity), and allowed up to 120 characters per punchcard.
The bit order in bytes was natural, highest bit first, so it was relatively easy to read punchcards by looking at the bit patterns. This skill was quite useful, because it was the only way to find out the content of a punchcard without passing it through the computer: nothing was printed on top of punchcards, unlike the IBM ones.
The only byte with even parity allowed on a punchcard was 000, and it was ignored. The space character had its own encoding (017).
There was no distinction between Latin letters and Cyrillic letters with the same glyph.
Here is the table of the GOST UPP encoding. Put the mouse pointer over a colored cell with a character for its description (some cells with white backgrounds also have descriptions):
|characters that had exact ASCII/ISO counterparts|
|characters that had conventional ASCII/ISO counterparts|
|characters that had no established ASCII/ISO counterpart|
|ASCII/ISO characters that had unofficial de facto GOST encodings|
As you can see, the character set is heavily skewed toward mathematical symbols: so much that there is no question mark! It has not even occurred to people who were designing the character set that the character 0133 (factorial sign) is also the exclamation mark, and adding the question mark would be appropriate.