Fixing FreeDOS Keyboard Layout and Codepage Mismatches

If keys produce the wrong characters, the problem is almost always one of two genuinely separate layers, and fixing only one can turn a partially-correct setup into a differently-broken one.

The two layers that must agree with each other

The keyboard layout, set through KEYB, maps physical scan codes (which key was pressed) to character codes — it says nothing about how that character is drawn on screen. The active codepage and loaded screen font decide which glyph actually appears for a given character code. Change the keyboard layout without also matching the codepage, and a key can produce a character code the current font renders as the wrong symbol entirely, even though the keyboard mapping itself is functioning exactly as configured.

KEYB’s actual syntax

KEYB layoutName[,[codepage][,filename]] [/ID:nnn]

For example, KEYB SP,858 loads the Spanish physical layout and starts in codepage 858; omitting the codepage argument leaves KEYB checking whatever DISPLAY.SYS and the system are already using. The /ID:nnn switch exists specifically for layouts that have more than one physical keyboard variant, disambiguating which one you mean by numeric identifier.

Preparing and selecting a codepage with MODE

MODE CON CP PREPARE=((860) C:\FREEDOS\CPI\ega9.cpx)
MODE CON CP SELECT=860

MODE’s CODEPAGE keyword (abbreviated CP) with PREPARE (abbreviated PREP) loads a specific codepage’s glyph data from a .CPX font file into a hardware code page buffer; SELECT (abbreviated SEL) then actually activates it for display. Both steps are necessary — preparing a codepage without selecting it leaves the previous codepage still active on screen.

The order that actually matters

Boot with a minimal configuration first and note whatever KEYB, CHCP, MODE, COUNTRY, and display-driver settings are currently active. From that known-clean baseline, load country information, then CPI/font support via MODE, then the keyboard layout via KEYB, in that documented order — loading KEYB before the codepage it expects is prepared is a common way to end up with a layout that’s technically active but rendering through stale glyph data. Confirm every filename and path referenced actually exists on your specific installed FreeDOS edition, since CPI file sets and paths can differ between distributions and versions.

Testing beyond the obvious cases

Test plain letters and punctuation first, then AltGr key combinations, then box-drawing and extended characters, and finally any application that switches video modes internally, since a mode switch can sometimes reset codepage state the application isn’t expecting. Keep an emergency boot-menu option with no localization drivers loaded at all — a malformed COUNTRY.SYS or KEYB line in your primary configuration should degrade to an unlocalized-but-working keyboard, not leave the machine unable to boot to a usable prompt at all.

The fourth piece people forget: NLSFUNC

Beyond COUNTRY, KEYB, and MODE, full National Language Support depends on a fourth component: NLSFUNC, which loads the country-specific information COUNTRY.SYS provides and makes it available to applications and other DOS utilities that query it directly, rather than just applying it to the shell’s own date, time, and currency formatting. Skipping NLSFUNC doesn’t usually break basic keyboard input or codepage rendering, but it can leave specific applications that query country data programmatically falling back to defaults that don’t match the rest of your otherwise correctly localized configuration — worth loading alongside the other three whenever an application’s own locale behavior doesn’t match what COUNTRY.SYS and KEYB are already reporting correctly at the shell level.

Document the exact working combination of KEYB layout, codepage number, and CPI filename you land on once everything tests correctly — reconstructing it from memory months later, after a reinstall or a new machine, is considerably harder than re-reading a few saved lines.

Related:

Sources: