OS/2, eCS & ArcaOS - Technical > Hardware

USX keyboard layout

<< < (3/3)

Alfredo Fernández Díaz:
OK, I did a simple experiment.

I have attached a file containing all 62 non-7-bit ASCII, single characters that can be typed with the USX layout, leaving combining characters out for the moment being. (You need to view it while using CP1004, so you can see that characters look like their descriptions.) I tried converting it to other popular codepages:

-If you convert it to codepage 850, only both single quotation marks are lost. To be expected, since CP1004 was an extension to CP1004, but not one USX explores in depth.

-If you convert it to codepage 932, only 12 characters survive as double-byte, and I don't know in what health (¬, €, ƒ, £, and ¢ all get converted to the same thing), so I wouldn't hold the greatest expectations for the moment being. Conclusion/question: even if a USX/932 were feasible to build as it stands, would it be worth the hassle just to be able to type 12 more characters than you can type under CP932 using US103?

I would need to have a look at the DCP stuff in a real Japanese system.

Alex Taylor:
Thanks.

To answer your previous question: codepage 932 is an implementation of the Shift_JIS encoding with a few IBM extensions that probably don't need to concern us here.

* https://en.wikipedia.org/wiki/Shift_JIS
* https://en.wikipedia.org/wiki/Code_page_932_(IBM)Note that on OS/2, contrary to what the above pages say, codepage 932 is an alias for codepage 943 (not 942), meaning it's compatible with the JIS X 0208:1983 standard.  (However, this also means it does not include the single-byte tilde, backslash or logical-not characters like codepage 942 does.)

Have to run; I'll answer your latter question later.

Alex Taylor:
To follow up on your last question: my main concern wasn't being able to use the UX keyboard under codepage 932. It was the inability to use it at all (even for 850) when specifying it as the keyboard layout in CONFIG.SYS.

However, it does look as if using the WPS keyboard object lets me select it subsequently, even though I get a warning popup.

Trying to use UX specific key combinations in a command prompt after doing this seems to work under codepage 850. Under codepage 932, I just get garbage glyphs in place of any non-ASCII character (as I normally get for double-byte characters, given this is not a DBCS system). 

If KEYBOARD.DCP were to be modified for UX+932, I would probably suggest replacing any unsupported character with ? or similar.  I'm not really sure it's needed at this point, though.

Alfredo Fernández Díaz:
It's been like ten years since I last dealt seriously with Japanese OS/2, so sometimes it is hard to remember where you got information on some stuff, or that it is not always in an IBM book that no one has a copy of anymore ;)
Thank you for the pointers for CP932, Alex.

On a different note, please note that "UX" (which you just mentioned) is not the same as "USX", although both keyboard layouts are dubbed "US international". That, as listed in the Keyboard object in System Setup, does not mean USX but UX, so I take UX was the one you meant in your first post on this thread? Anyway, even if their "international" characters are laid out on top of different keys, they're both equivalent in the following aspects:

-The current MCP2/ArcaOS GA DCP only have USX/UX definition tables built for codepages 437, 850, 859, and 1004, and thus not all the characters are available if you use a different one, e.g. CP932.
-On my US ArcaOS test systems with CODEPAGE=850,932 both USX and UX load just fine from the command line with "KEYB US" or USX (but with a warning re: CP932), or if you specify them in your "DEVICE=KBD,XX,?:\OS2\KEYBOARD.DCP" line in config.sys.
-The popup message you get when selecting UX from the Keyboard object is equivalent to the KEYB warning in a command line session CHCPed to CP932. It simply means that you get no translation table to display your characters under CP932, or get one for CP437. It should then be no surprise that you get garbage when you use the keyboard to produce any characters absent from CP932.
-If you take out any USX/UX characters that are absent from CP 932, you get the US 103 keyboard layout with a handful of extra characters on top, so I would say probably not worth the effort to define new DCP tables for USX/UX to cover CP932.

Alfredo Fernández Díaz:

--- Quote from: Alfredo Fernández Díaz on March 22, 2023, 08:31:58 pm ---
--- Quote from: Daniel Carroll on February 14, 2018, 06:43:47 am ---There are also hints of USY and USZ keyboards in the files that don't seem to actually exist as if someone stopped work suddenly. Or I could be totally wrong...
--- End quote ---
You are about "USY" and "USZ" keyboards: there is no such thing.
--- End quote ---
No, I was wrong too -- you were only partially wrong about USY and USZ ;)

There are definitely no such things in KEYBOARD.DCP. However, since keyboard layout is established globally even though VIO and PM sessions use separate definitions of each layout, using different indexing and IDs, there must be a communication mechanism. I.e., if you set the layout from the command line it tells the PM about it, and the other way around (but that is not interesting right now). That is why you were right to look at KEYB.COM and I was wrong to ignore it because I thought you must have found random strings in a binary file. Well, no!

Indeed KEYB contains a table that associates its own VIO layout identifiers as defined in KEYBOARD.DCP with PM keyboard layout indexes. So when you tell KEYB to load say SP, it looks for SP in KEYBOARD.DCP and loads it (SP172, actually) from KEYBOARD.DCP, then looks that up in this internal table, and tells the PM to switch to such-and-such keyboard layout.

A quick look (with keen eyes) to KEYB.COM reveals the following VIO / PM keyboard layout ID associations:

VIO    PM
ar470 28, 27
ar    21, 20
ba    37
be    02
bg    2C, 2D
br274 22
br    1D
by    5B, 5A
ca    3A
cf    03
cz    17
gr    06
de453 3C
de    06
dk    04
ee    3F
gk220 26, 25
gk    24, 23
sp    0E
es    0E
su    0F
fi    0F
fr120 13
fr    05
hr    1A
hu    19
he    1F, 1E
is458 3E
is    1C
ic    1C
it142 14
it    07
la    08
lt    4C
lv    4E
mk    2E, 2F
nl    09
no    0A
pl457 34
pl    1B
po    0B
ro    2B
ru443 35, 36
ru441 32, 33
ru    35, 36
sg    0D
sf    0C
sk    18
sl    2A
sq    38
sr    30, 31
sv    10
th    43
tr440 29
tr    16
ua    5D, 5C
uk168 15
uk    11
usdv  49
usdvl 4A
usdvr 4B
usx   FA
usy   FB
usz   FC
us    12
ux    39

Lo and behold, there are your USX, USY, and USZ! Furthermore, "FA" is indeed the ID of one of the many (150+) available PM keyboard layouts, and a glance at its contents reveals it is actually the USX keyboard layout for PM. (And in case you wondered, all the others are valid associations as well, so this is no coincidence.) Unfortunately, there are no PM keyboard layouts with the IDs FB or FC, just like there are no USY or USZ layouts defined in KEYBOARD.DCP.  :-\

Navigation

[0] Message Index

[*] Previous page

Go to full version