Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've seen many text mode BIOS setup screens in Japanese. Recently I've even seen windows XP setup in Japanese. MS-DOS had Japanese versions too. Real DOS mode, not windows command promt!

Japanese BIOS setup

One typical text mode screen has the size of 80x25. With Japanese character took as large as double normal Latin character width, the maximum number of Japanese characters that can be displayed at the same time on screen is about 1000. So we need 2000 code points to display the left and right part of the characters.

As default text mode can only display 256 characters, but the first 128 is used for ASCII, so usable ones are limited to the high 128 code points. If needed we can expand it to 512 but this still can't support enough code points for the display. I always wonder how they managed to display the large character set with such limited number of characters.

apanese XP installer

Text mode in Linux seems to use graphics mode driver because it can display unicode and has much more color. But I can't explain how they to it in MS-DOS and BIOS screens.

EDIT: I've even found a Japanese text input for DOS

Japanese IME

There are Korean in text mode too!


VMWare Korean DOS

share|improve this question
You are probably not looking at Japanese "characters", i.e. kanji, but rather hiragana or katakana, which do have Unicode mappings. – sawdust Sep 20 '13 at 9:51
@sawdust: look at the picture above and you'll see that it can display not only all kana but also Kanji – Lưu Vĩnh Phúc Sep 20 '13 at 13:09
Note that the page you likely took the OS/2 installer screenshot from says right next to the screenshot that "the graphical text mode support was initialized almost immediately when booting OS/2". Key word graphical. – Michael Kjörling Jul 18 '14 at 15:15
@MichaelKjörling it's not only OS/2 but MS-DOS and BIOS setup programs have this ability in text mode too – Lưu Vĩnh Phúc Jul 18 '14 at 20:23
up vote 3 down vote accepted

The normal "80x25 characters" mode is actually 720x350 pixels (meaning that each character cell is 9 pixels wide by 14 pixels high). Double-width character modes ("40x25") can either simply interpolate this to the larger width by doubling each column to save on video content memory (cutting the required amount of video content memory in half), or use additional glyph memory and an identical amount of video content memory to increase the character cells to 18*14 pixels.

Fairly early on (I think it was done when EGA was introduced), support for user-defined character glyphs was added to the IBM PC's text display mode.

The normal text mode of the IBM PC is simply a sequential 4000 bytes of video content RAM at a particular address. These are read as one byte of character attributes (originally blinking, bold, underline etc.; later re-used for foreground and background colors and blinking/highlight, hence the limitation to 16 colors in text mode) and one byte describing the character to be displayed. The actual glyph to be displayed for each character byte value is stored elsewhere.

This means that as long as you can make do with 256 distinct glyphs on the screen at any one time, and each glyph can be represented as a 9x14 one-bit bitmap, you can simply replace the glyphs in memory to make the characters appear differently. In part, this was one portion of what mode con codepage select did on DOS. This is relatively trivial.

If you need more than 256 distinct glyphs but can live with the reduced number of glyphs on screen, you can go with a 40x25 scheme with double-width (18 pixels wide) glyphs. Assuming that the total amount of video content RAM is fixed and assuming that you can increase the glyph bitmap memory, you can move to using two bytes out of every four bytes to represent one on-screen glyph, giving you access to 2^16 = 65,536 different glyphs (including the blank glyph). If you feel daring, you could even skip the second attribute byte which gives you access to 2^24 ~ 16.7M different glyphs. Both of these approaches rely on special software support, but the hardware and firmware portion should be pretty easy to do. 65,536 glyphs at 18x14 one-bit pixels works out to about 2 MiB, a sizeable but not insurmountable amount of memory at the time. 256 glyphs at 18x14 one-bit pixels is about 8 KiB, which was absolutely reasonable even in the first half of the 1980s when EGA was developed and introduced.

Basic US English needs at least 62 dedicated glyphs (numbers 0-9, letters A-Z in upper and lower case) so you have something like 180-190 glyphs to play with if you also want to be able to display US English text at the same time and go with 8 bits per glyph. If you can live without simultaneous US English support, which you might choose to do in a resource-constrained environment such as the early IBM PC architecture, you have access to the full number of glyphs.

With some trickery you could probably mix and match the two schemes, too.

I don't know how it was actually done but both of these are viable schemes for how to get particularly limited-character-count "fancy" alphabets onto a plain IBM PC screen in text mode that I can come up with just sitting in front of Stack Exchange for a moment. It's perfectly possible that there are additional graphics modes that make this easier in practice.

Also, keep in mind the distinction between text mode and graphical mode displaying text. If you are in graphical mode, perhaps through VESA which is pretty universally supported, you're on your own as far as drawing character glyphs go but you also have a lot more freedom in how to draw them. For example, I'm pretty sure the text-based parts of Windows NT (which is the product family Windows XP belongs to) use a graphical mode to display text, including the Windows NT 4.0 boot screen and BSODs.

share|improve this answer
You may see that there are normal width Latin characters beside double width Japanese/Korean ones so it can't be 40x25 double width mode. Therefore you can't combine 2 bytes of every 4 bytes to represent the glyph. Using bit 3 of the foreground color you can represent 512 glyphs at the same time but still not enough if the characters fill most of the screen – Lưu Vĩnh Phúc Sep 20 '13 at 14:20
@LưuVĩnhPhúc You could repossess the high bit, or use any number of possible other tricks to mix multibyte-requiring characters with singlebyte ones. I still think the answer is to recognize the statement made in the opening paragraph: even when showing characters, at some level you are still dealing with pixels, and those pixels can be worked with even though perhaps not directly. – Michael Kjörling Sep 20 '13 at 14:30
I know all the text-based and the graphical-mode-displaying-text thing, just confuse how they have enough code points for multibyte as left and right part require 2 code points. But from what you said I've thought of another way of doing it. I think your answer is acceptable – Lưu Vĩnh Phúc Sep 21 '13 at 0:33

This is simplifying what @Michael Kjörling is saying.

In text mode, you have "screen memory" that has 1 byte per onscreen character that tells the adapter what character appears in each screen position. (There are also "attribute" bytes that tell the adapter what color and things like underline, blink, etc.).

The adapter uses this byte to index into another "character table" that has the small 8x12 or whatever bitmap of the character. DOS calls this character table a code page.

Starting with CGA, you can tell the adapter to get the character table at a specific place in the adapter's RAM. Each adapter has a character ROM that has the default "font" for that card (which is the standard IBM font), but you can tell the adapter to switch to a location in RAM and put your own images there.

As long as the software knows what's going on, the codes in screen memory that point to the images in the character table do not have line up with any ASCII codes, though it's easier if they do. You'll notice there's screen memory codes (and character table shapes) for 1-31 which are unprintable ASCII characters - but by writing to screen memory directly (fond memories of DEFSEG = &HB800 : POKE 0,1 in GW-BASIC to change the upper most character to a smiley come to mind) you can still display them.

So displaying other languages is fine, if you can put the right images into the adapter's RAM and have the necessary software support.

share|improve this answer
Was it as early as CGA? I must be getting old. (To my defense, I did write that answer largely from memory, and haven't actually used those techniques even for fun in like forever.) – Michael Kjörling Sep 20 '13 at 17:17
I think you're right after looking into it, it was EGA. – LawrenceC Sep 20 '13 at 18:14
I know we can change the text font by changing the pointer, I've learnt how to do it years before, just don't know how they can represent the double byte character set, as 256 or 512 code points can't even hold enough the maximum number of different characters on screen, not counting the whole complex charset – Lưu Vĩnh Phúc Sep 21 '13 at 0:38

You need a graphic mode instead of a hard-coded text mode so that unicode text glyphs can be displayed. Then you set MS-DOS to use a unicode font and change the language mapping to use that.

share|improve this answer
No, look at the images I posted, it's real DOS mode, not command promt in windows – Lưu Vĩnh Phúc Sep 20 '13 at 13:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.