Re: [Freedos-user] MKEYB related stuff
>> how should a KEYB scancode->keycode driver react to copdepage
>> changes, and how are these communictated?
> Well, first of all the keyboard driver should detect the current
> Code Page on installation and not just assume one.
codepage is a display thing, essentially it's the table how to convert
8-bit bytes into a visable character set, and mostly unrelated to the
way the keyboard driver converts scancodes into bytes.
with an US keyboard driver,
pressing the '7' key (scancode 0x08) results in '7'.
pressing the '7' key while holding SHIFT results in '&'.
pressing the '7' key while holding AltGr results in nothing.
with an GR keyboard driver,
pressing the '7' key (scancode 0x08) results in '7'.
pressing the '7' key while holding SHIFT results in '/'.
pressing the '7' key while holding AltGr results in '{'.
> And, the KEYB
> program should work with multiple code pages when it can.
they all do. they always produce the same byte values öäüÖÄÜ whatever
the codepage.
of course a brasilian KEYB might produce different values for á then a
french KEYB (I don't know), but they still produce the same value
consistently.
> DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to
> inform KEYB so it can change its mapping.
please provide an example where this is necessary AND plausible.
> Unless the tables are in a "public" format, the data contained in
> the tables is irrelevant.
> The reason that other TSR's (at least mine) may need to know what
> the keyboard mapping looks like is because they need to do an
> "ASCII-to-Scancode" lookup.
nope. you intend to do "ASCII-to-Scancode" lookup, then feed these
scancode to the KEYB program, in the hope that this KEYB program
converts it back to the same ASCII character that you started with.
there's a BIOS call for this:
KEYBOARD - STORE KEYSTROKE IN KEYBOARD BUFFER (AT/PS w enh keybd only)
AH = 05h
CH = BIOS scan code
CL = ASCII character
use '2' as scancode. compatible with 99,95% of al existing
applications.
otherwise you have to implement what the KEYB program does in reverse
direction. not only different scancodes with different shift states,
but also dead keys: á is produced by hitting ´, then a; à is produces
by holding SHIFT, hitting `, hitting a, releasing SHIFT.
for the german keyboard at least ;)
or
AH = 05h
CH = 02h
CL = à
int 0x16
> My SCANCODE program, e.g., "types" scancodes automatically (it is
> useful for creating "macros"), but the user can tell SCANCODE what
> to "type" with ASCII codes. To do this, SCANCODE needs to know what
> scancode(s) to type (what physical key(s) on the keyboard to press)
> to generate the ASCII code the user wants to see. For example, if
> you tell SCANCODE to type a "Z" it will press the shift-key, press
> the "z", release the "z", then release the shift-key. But, it needs
> to know where the Z key is on the keyboard to do that, and the Z key
> is in different places (different scancodes) depending on the
> keyboard layout and, in some cases, the code page.
yes that's complicated. how about sending 'Z' to the program?
> Another kind of TSR that needs to know is a TSR that has some sort
> of "hot-key" to enter into the TSR as it is running to make
> configuration changes. My CLOCK and SERIAL programs do this. TSR's
> usually (though not always) monitor scan codes for hot-keys rather
> than ASCII codes, but the user usually enters the hot-key as an
> ASCII code. The current versions of CLOCK and SERIAL simply assume
> the keyboard is a standard US QWERTY layout, but I'm in process of
> changing them to be "keyboard-layout aware").
there are enough 'non-controversial' keys to use for hotkey; just use
B-X and avoid Q.
Tom
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
On 07/10/2021 15:43, tom ehlert wrote:
DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to
inform KEYB so it can change its mapping.
please provide an example where this is necessary AND plausible.
In Poland, there were a few codepages used during the DOS era. The two
main ones were CP911 ("Mazovia") and CP852. The character mappings are
different, for instance "ą" (ALT+a) is byte 0xA5 in CP852, while in
Mazovia it is under 0x86. Most polish programs could be configured to
output their content in one of the codepages, but some were hard-coded
to either Mazovia or CP852. In such cases, a mode con cp select was
required -- in such case, a non-smart keyb driver would not be aware of
the change and keep emitting byte codes for the initial codepage it was
configured for.
Mateusz
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
Hallo Herr Mateusz Viste,
am Donnerstag, 7. Oktober 2021 um 17:00 schrieben Sie:
> On 07/10/2021 15:43, tom ehlert wrote:
>>> DISPLAY.SYS calls INT 2F.AD81h when the Code Page is changed to
>>> inform KEYB so it can change its mapping.
>> please provide an example where this is necessary AND plausible.
> In Poland, there were a few codepages used during the DOS era. The two
> main ones were CP911 ("Mazovia") and CP852. The character mappings are
> different, for instance "ą" (ALT+a) is byte 0xA5 in CP852, while in
> Mazovia it is under 0x86. Most polish programs could be configured to
> output their content in one of the codepages, but some were hard-coded
> to either Mazovia or CP852. In such cases, a mode con cp select was
> required -- in such case, a non-smart keyb driver would not be aware of
> the change and keep emitting byte codes for the initial codepage it was
> configured for.
thank you very much for explaining this as I (as a german) have no experience
at all with DISPLAY, codepages and friends. in particular not with 2
codepages, different from 437, *at the same time*.
were these 2 layouts dynamically switchable (and actually
switched), or would one computer select one of the 2 codepages at
setup time, and usually remain so for the rest of their lives?
Tom
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
> codepage is a display thing, essentially it's the table how to > convert 8-bit bytes into a visable character set, and mostly > unrelated to the way the keyboard driver converts scancodes into > bytes. The Code Page and the Keyboard layout are not unrelated at all -- they are HIGHLY related. Mateusz provided a Polish example, but probably the more common one is the Euro symbol. Cod Page 850, which was the "original" one for western Europe, didn't have a Euro symbol -- the Euro didn't even exist when when the Code Page was first developed. Code Page 858 is Code Page 850 with the "dotless i" (ASCII code 213 or D5h) character replaced by the Euro symbol. In other Code Pages the Euro symbol is not in the same place as it is on 858, and many Code Pages don't have the Euro symbol at all. KEYB needs to know what ASCII code is (or even if there is one on the current Code Page) for the Euro symbol if the user presses the appropriate keys to generate the Euro symbol. US/English-only users almost never even need to worry about these kinds of things. BTW, there are also Code Pages for printers which are managed by PRINTER.SYS, but that is even a much bigger can of worms than keyboard layouts and display Code Pages. > of course a brasilian KEYB might produce different values for á then > a french KEYB (I don't know), but they still produce the same value > consistently. No, they don't, unless they are using the same Code Page. > please provide an example where this is necessary AND plausible. See above. A user who speaks/writes in multiple languages would need/want something like this. E.g., Thraex, who has been helping some people (including me) recently with language translations, speaks/writes English, French, and Turkish. I've never inquired of him exactly how he manages the different languages on the same computer (and he may not even do that in DOS -- I'm not sure). Even though the vast majority of users will not have issues, there are some users who would need/want the ability to change things around. In my case, I swap things around for testing to try and make my programs are "international friendly" if there's a way to do it. I wasn't as concerned about this in the past as I am now, but it seems like a good way to go. > nope. you intend to do "ASCII-to-Scancode" lookup, then feed these > scancode to the KEYB program, in the hope that this KEYB program > converts it back to the same ASCII character that you started with. Do it merely "hoping" that it will work? I need to KNOW it will work before I start "typing" anything that can potentially screw up something the user is doing. > there's a BIOS call for this: > KEYBOARD - STORE KEYSTROKE IN KEYBOARD BUFFER (AT/PS w enh keybd > only) ... Uh, no, that won't help. That provides a scan code AFTER it has already been pressed, and only works with scan codes that produce ASCII codes -- not all of them do. Plus, you can have situations where there is not a unique set of ASCII/scan code combinations. E.g., ASCII 13 (Carriage Return) can be generated by Enter, Grey Enter (on the NumPad), Ctrl-M, Alt-013, and maybe other ways too. If the user tells me to "type" an ASCII 13, which key(s) do I use? > otherwise you have to implement what the KEYB program does in > reverse direction. not only different scancodes with different shift > states, but also dead keys: á is produced by hitting ´, then a; à is > produces by holding SHIFT, hitting `, hitting a, releasing SHIFT. > for the german keyboard at least ;) Exactly. That's why I need to know what the keyboard layout is, including things like dead keys. There are also some keyboard layouts with more than one mode (like various Hebrew, Cyrillic, & Greek ones) where there is a "Latin/English Mode" and a "Foreign Mode" and pressing the "a" key when it's in Foreign Mode doesn't generate an "a". > yes that's complicated. how about sending 'Z' to the program? Because some programs don't look at the "Z" -- they look only at the scan code and don't even care about the "Z". You're correct that most programs only look at the "Z", but SCANCODE will work both with programs that do and those that don't. SCANCODE can even "type" the correct keystrokes it takes to switch the keyboard between the English and Foreign modes (Ctrl-Alt-F1 & Ctrl-Alt-F2) which you can't do with ASCII codes. > there are enough 'non-controversial' keys to use for hotkey; just > use B-X and avoid Q. No, there are enough controversial keyboard layouts to make it a big problem. The main keyboard layouts I'm aware of that are VERY different than "common" keyboards are Dvorak, Dvorak Left-hand, Dvorak Right-hand, Colemak, Bulgaria (BG) 241, and Turkey (TR) 440. They are not commonly used, but there are DOS drivers for them (in FD-KEYB) and they are used by some people. There are also keyboards where even the number keys at the top of the keyboard are different, not just the letter keys.
Re: [Freedos-user] MKEYB related stuff
> Plus, you can have situations where there is not a unique set of > ASCII/scan code combinations. E.g., ASCII 13 (Carriage Return) can > be generated by Enter, Grey Enter (on the NumPad), Ctrl-M, Alt-013, > and maybe other ways too. If the user tells me to "type" an ASCII 13, which > key(s) do I use? the user told you to type ASCII 13. why don't you 'type' 0x13 using INT16, AH=05h? use scancode 0x02 and send complains to me? in addition, many keyboard handlers were able to produce 'keys' by holding down ALT and hitting 3 decimal keys to produce a 'ASCII' code. your attempt to the problem is just wrong. if a user calls SCANCODE -some options "ÄÖÜà" the best solution that "ÄÖÜà" survives the the back and forth translation is to use INT 16, AH= 5 > Exactly. That's why I need to know what the keyboard layout is, > including things like dead keys. as there are no standards about 'keyboard translation tables', you would have to carry all this information in your SCANCODE tsr. > There are also some keyboard > layouts with more than one mode (like various Hebrew, Cyrillic, & > Greek ones) where there is a "Latin/English Mode" and a "Foreign > Mode" and pressing the "a" key when it's in Foreign Mode doesn't generate an > "a". I still think that SCANCODE some options 'a' should send 'a' to my program, whatever the codepage is. > No, there are enough controversial keyboard layouts to make it a > big problem. The main keyboard layouts I'm aware of that are VERY > different than "common" keyboards are Dvorak, Dvorak Left-hand, > Dvorak Right-hand, Colemak, Bulgaria (BG) 241, and Turkey (TR) 440. > They are not commonly used, but there are DOS drivers for them (in > FD-KEYB) and they are used by some people. There are also keyboards > where even the number keys at the top of the keyboard are different, > not just the letter keys. Knowledge of the current keyboard layout > is an important, not a trivial, thing. good luck with that. I don't think that is solvable in 8-bit land. and xxDOS is very much 8-bit land. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
On 07/10/2021 18:47, tom ehlert wrote: were these 2 layouts dynamically switchable (and actually switched) They were actually not switchable, mainly due to their implementation: CP852 was provided by "mode con cp" through MS-DOS, while the Mazovia codepage was usually loaded through a custom TSR (maz.exe comes to mind). Hence "switching" required to unload maz.exe and run the appropriate mode con cp prepare/select combo. And that's what I was doing whenever I needed to use a program that was assuming CP852. But now, since Mazovia and CP852 are both supported by FreeDOS, they can be easily switched without relying on any exotic TSRs. The full story is that when the IBM PC came to Poland, it wasn't handling Polish glyphs at all, so Poles had to come up with their own codepage when creating their IBM PC clone (Mazovia 1016). It was first burned in custom ROMs, and later - with VGA cards - loaded to the VGA memory through TSRs. Then, later, Microsoft/IBM decided to support Polish, and did so by cramming most of east-European glyphs into CP852... Which not only led to a poorly usable codepage (garbled Norton Commander semigraphics!), but also introduced chaos in the way Poles were exchanging text. Some started using the Microsoft 852 page, since it was meant to be the "new standard", and others kept using Mazovia since it was superior and well-established... Ah, those good times. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
> On 07/10/2021 18:47, tom ehlert wrote: >> were these 2 layouts dynamically switchable (and actually >> switched) > They were actually not switchable, mainly due to their implementation: > CP852 was provided by "mode con cp" through MS-DOS, while the Mazovia > codepage was usually loaded through a custom TSR (maz.exe comes to > mind). Hence "switching" required to unload maz.exe and run the > appropriate mode con cp prepare/select combo. And that's what I was > doing whenever I needed to use a program that was assuming CP852. > But now, since Mazovia and CP852 are both supported by FreeDOS, they can > be easily switched without relying on any exotic TSRs. > The full story is that when the IBM PC came to Poland, it wasn't > handling Polish glyphs at all, so Poles had to come up with their own > codepage when creating their IBM PC clone (Mazovia 1016). It was first > burned in custom ROMs, and later - with VGA cards - loaded to the VGA > memory through TSRs. > Then, later, Microsoft/IBM decided to support Polish, and did so by > cramming most of east-European glyphs into CP852... Which not only led > to a poorly usable codepage (garbled Norton Commander semigraphics!), > but also introduced chaos in the way Poles were exchanging text. Some > started using the Microsoft 852 page, since it was meant to be the "new > standard", and others kept using Mazovia since it was superior and > well-established... Ah, those good times. so there would be 2 polish keyboard layouts: PLMAZ and PL852. still no way to communicate this between KEYB and DISPLAY and PRINTER. maybe just switch to Windows/Linux and UTF-whatever ;) Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
> the user told you to type ASCII 13. why don't you 'type' 0x13 using > INT16, AH=05h? use scancode 0x02 and send complains to me? I'm not actually "complaining" about MKEYB since KEYB is available and does things "correctly" -- so there's no need for me to use MKEYB. In fact, as a user, I live in the US and there's no need for me to even use FD-KEYB except for testing. Why would I assume I should use Scancode 02h and not some other Scancode? That's the point -- in at least some cases, the user would also need to tell me which Scancode to use, but they can also JUST tell me the Scancode since I don't even care about the ASCII code. Some programs treat Ctrl-M very different than Enter while others don't know the difference. With SCANCODE, the user can tell me to "type" Enter or Ctrl-M and it does EXACTLY that. Again, what I'm trying to do is make it easier for the user, not necessarily easier for me. You can also provide the Scancodes directly to SCANCODE if you want (the very first versions of SCANCODE from a long time ago required that). The ASCII codes are there to make it easier for the USER to use the program. > in addition, many keyboard handlers were able to produce 'keys' by > holding down ALT and hitting 3 decimal keys to produce a 'ASCII' > code. I think they all do that (or at least should do that). SCANCODE will "type" the keys that way also when it's required (like when it doesn't think there's another keystroke combination on the keyboard that will work). You can also tell it specifically to type as an Alt-NumPad combination. SCANCODE is actually far more flexible in what you can do with it than the other keyboard-stuffing programs. > the best solution that "ÄÖÜà" survives the the back and forth > translation is to use INT 16, AH= 5 No, not unless you (in at least some cases) also provide the appropriate Scancodes to go along with the ASCII codes. I also know some programs will accept almost any Scancode (it doesn't even need to be "correct"). > as there are no standards about 'keyboard translation tables', you > would have to carry all this information in your SCANCODE tsr. There are no standards about how the translation tables are laid out, but there are absolutely standards about what each keyboard layout is supposed to accomplish, which is what matters. SCANCODE doesn't actually need to keep the information in the TSR itself. The Scancodes are stored in a buffer, and they are "typed" later as they are needed. After all the keys have been "typed", SCANCODE removes itself from memory when it detects that it is safe to do so. SCANCODE can "type" the keys milliseconds or months later than when the TSR is installed in memory. The TSR monitors things like screen contents and time delays and even other keystrokes so the keys are "typed" at the correct time. So, the installation part of SCANCODE needs to know the ASCII-to-Translation tables, but the TSR itself does not. In addition, this means that the state/environment of the computer (including things like the current keyboard layout or code page) may be different when the keys are "typed" than it is when the TSR is installed into memory, and the directions the user provides to SCANCODE as to what Scancodes to type when need to take all that into account. SCANCODE can do anything a keyboard-stuffing program can do (at least any that I've seen), but it doesn't work the other way. SCANCODE can also be difficult to use, and allows you to automate almost any process that normally requires you to sit in front of a keyboard and "babysit". The way SCANCODE does things is not the WRONG way to do them -- it is certainly different than what you're used to, but is also far more powerful. Allowing the user to enter ASCII codes as input parameters just make it easier for the USER. > I still think that > > SCANCODE some options 'a' > > should send 'a' to my program, whatever the codepage is. It will, but it does it by "typing" the appropriate keystrokes from the keyboard (whatever those are) instead of just sending an "a" with an arbitrary Scancode attached. For example, if the keyboard is currently in Foreign mode where there is no "a", it can temporarily switch the keyboard into English mode, type the "a", and switch back to Foreign mode again, or it can do the Alt-NumPad thing, or even something else. It simulates exactly what you would do if you were sitting at the keyboard, not what happens after the computer is done "processing" and "translating" what you would do if you were sitting at the keyboard. Those are very different things. In many cases it doesn't matter which way you do it, but in other cases it does. And when it does matter, SCANCODE is the only program that will work. > good luck with that. > I don't think that is solvable in 8-bit land. and xxDOS is very much > 8-bit land. It's already done. SCANCODE has been doing it for years. It is not 100% by a
