nedoPC.org

Потратил я немного времени, чтобы посмотреть какую-либо техническую информацию по этим
самым клавиатурам с RS-232 интерфейсом: Palm portable keyboard и Apple Newton Keyboard...

Заинтересовало, поскольку по ASCII Serial keyboard я тут в первый заход ничего путного не нашел.
Теперь хоть знал - что конкретно искать, хотя задачу это сильно не облегчило - уходит эта информация,
ссылки битые, на других ссылках уже и информация другая...

Но по Palm portable keyboard я некоторую техническую информацию нашел!
http://wb9kzy.com/palm.htm ; http://www.splorp.com/pdf/stowawayhwref.pdf

В мануале stowawayhwref.pdf расписаны особенности RS-232 интерфейса к Palm и приведена
таблица кодов: Key Code Matrix.

При взгляде на таблицу, возникает мысль, что Palm portable keyboard - это не ASCII Serial keyboard, и, возможно,
в драйвере придется сделать перекодировку либо в скан-коды, либо - сразу в ASCII-коды.

Насколько я успел посмотреть, в тексте драйвера NTKEY2LX.COM какая-то перекодировка вроде тоже есть...


P.S. По драйверу NTKEY2LX.COM см. предыдущую страницу.

Попробовал подключить клавиатуру (Palm) по rs232 (использовал только GND и RXD контакты, питание 3v от palm кпк).
Драйвер NTKEY2LX.COM ни как не реагировал на нажатия
Попробовал "послушать" что принимает com port через приложение DataCom- терминал порта, реакция на нажатия клавиш есть (хоть что-то...).
На разные кнопки показываются различные символы (обычно 3, по типу: DDD ... /// FFF ), т.е. можно забиндить как-то по таблице эти символы к реальным кнопкам.
И получается вы правы, в терминале должны выводиться ASCII символы, а показываются как есть, то что пришло от клавиатуры.

Настройки подключения такие ставил COM 1, скорость 9600, bit-1.

А вы можете заставить приложение DataCom-терминал порта показывать то, что принимает, в HEX-виде?
Ну типа 0А, 0С, 1В ... вот это меня зело смущает: "обычно 3, по типу: DDD ... /// FFF ".

Но, согласно мануалу, похоже, что их действительно дожно быть 3:

А X и Y - берутся из таблицы в моём предыдущем посте.

В общем - задача решаемая: что выдаёт клавиатура - известно (хотя неплохо и проверить).
Образец написания драйвера есть - если что непонятно - смотреть у Р. Джордейна.

Примерная суть работы драйвера (кратко):
1. При старте драйвер проверяет, не был ли он запущен уже (в коде это есть).
2. Если драйвер запущен впервые, он подменяет прерывание INT 9 клавиатуры на прерывание от COM-порта - эта программа внутри самого драйвера.
3. Драйвер устанавливаеся резидентно (есть такая функция).

4. Если пришло прерывние от COM-порта - попадаем в код нашего драйвера.
5. Проверяем не было ли ошибок COM-порта (см.у Р. Джордейна.)
6. Если нет ошибок читаем код из буфера COM-порта.
7. Перекодируем код клавиши.
8. Сохраняем полученное значение в кольцевой буфер клавиатуры.

9. Если драйвер запущен повторно, он выдаст сообщение и не установится.
10. Если драйвер запущен с нужным ключом, он вернет на место прерывание INT 9 клавиатуры и завершит работу.

Как-то так...

То, что другие программы не будут работать, это не волнует. Гораздо хуже, когда другие программы вредят твоей программе подменяющей INT 9. DOS-овые эмуляторы В.Пыхонина и А.Дёмина не подменяли обработчик INT 9 к тому же ещё нуждались в русификаторе, причём большая часть русификаторов конфликтовала с этими эмуляторами.

А я в своих эмуляторах РК и ОРИОНА для MSDOS в 90-тые ставил свой обработчик на вектор INT 9 и функциями MSDOS и ROM-BIOS для ввода с клавиатуры и вывода на экран вообще не пользовался. Из-за этого, кстати, никакие программы получения копии экрана не работают. В режиме отладчика на экран VGA выводил мой цветной графический драйвер на 64 символа в строке (т.к у меня плохое зрение и я всегда предпочитаю более крупные буквы) русские буквы выводились без русификаторов. Потому проблем с эмуляцией клавиатуры ни на Win 98, ни на Win ME не было.

И на Win XP проблем тоже не было до 2017 года. Пока я недавно не стал пользоваться Punto Switcher-ом. А он оказался наглым и каким-то образом вредит. Я полагаю, что он сам нагло и постоянно во времени восстанавливает вектор INT 9 на себя, потому что иногда вообще в запущенном с ним эмуляторе не работают клавиши в режиме монитора отладчика эмулятора (в режиме монитора эмулятора INT 9 восстановлен на тот, что был на момент старта эмулятора), но это бывает редко и влияет только в режиме отладчика.

А вот в режиме эмуляции (при входе в режим эмуляции ставится свой INT 9) с загруженным Punto Switcher-ом - всегда проблемы. Нажимаешь на клавишу в программе ОРИОНА, - 0.5-2 секунды нет реакции, а затем выскакивает сразу десяток букв. Это делает невозможным пользование эмулятором.

Причём мой обработчик INT 9 ставится не цепочечно, а только на себя. Потому никакой Punto Switcher или другая программа не должна влиять, она не получает управления по нажатиям. Но влияет. Это значит, что он нагло восстанавливает INT 9 на себя.

Из-за этого для пользования эмулятором приходится выгружать Punto Switcher. А он постоянно нужен, т.к я уже привык переключать РУС-ЛАТ левым и правым шифтами (одновременное нажатие CTRL+Shift, то что в Windows по умолчанию неудобно). Причём, что нагло, в настройке Punto Switcher-а можно указать программы при работе которых Punto Switcher не должен работать и как-либо влиять. Но это не работает, возможно имеется ввиду, что такая услуга Punto Switcher-а работает только для программ Windows, не MSDOS.

Подскажите что-нибудь по борьбе за INT 9, чтобы чужие программы Windows не влияли на мои программы.

Мне кажется, я поступил, как поступает упомянутый вами Punto Switcher - отбирал INT 9 у QBasic-а.
Я ему приделывал всплывающее меню, более привычное для программ Windows:



Всё, что я делал - подробно расписано вот здесь:
http://www.nedopc.org/forum/viewtopic.php?p=97419#p97419

Единственное, что могу добавить, отобрав INT 9 у QBasic-а, я еще патчил в нём, кажется,
несколько байт на некотором удалении от входа в его собственное INT 9.
Зачем-то это было надо: кажется, чтобы он не делал повторно то, что я уже сделал в своём INT 9.

Lavr, Большое спасибо за такое подробное описание драйвера

Попробовал подключить клавиатуру без КПК и проверил что клавиатура шлет в HEX
Тестировал с помощью программы COMMCHK.EXE (Commchk v1.8 Serial protocol analizer), запускал с параметрами: COMMCHK -I 1 -B 9600 -P N -W 8 -S 1
* программу прикрепил

Подключал вот так:
Palm keyboard pin = rs232

7 - GND = GND
9 - Vout = +3.2V-5v (battery)
10 - RxD = RS-232 RxD
14 - RTS = LOW after HIGH will activate keyboard (if Vout on)

Потыкал разные клавиши, вот такой результат:
Action = Responce

On keyboard connect, after LOW => HIGH on RTS = fa fd
1 = 00 80 80
2 = 01 81 81
3 = 02 82 82
4 = 04 84 84
5 = 05 85 85
q = 09 89 89
w = 0a 8a 8a
shift = 58 d8 d8
enter = 41 c1 c1
space = 17 97 97
del = 50 d0 d0
up = 49 c9 c9
down = 52 d2 d2
left = 51 d1 d1
right = 53 d3 d3
backspace = 32 b2 b2
tab = 19 99 99

Пока такие проблемы клавиатурой:
1) Чтобы клавиатура активизировалась после подачи питания, нужно на 14pin(RTS) подать LOW потом HIGH - пока вручную прикрутил включатель on\off
Как я понял что то похожее происходит в исходнике (988 строка, функция init_com):

и если подключить com DTR к RTS клавиатуры, то она тоже включится

В драйвере для определения клавиши используется 2 байта, а в palm клавиатуре 3 байта:
Нажимаем 8-бит отправляется:
• Первый бит - 0 если нажата клавиша
• След 4 бита: Y номер из таблицы
• Еще 3 бита: X номер из таблицы
Когда отпускаем клавишу, отправляется все тоже самое(8-бит) но первый бит 1 (!)
И еще важно, если отпускаем клавишу и не нажато не одной другой клавиши, последние 8-бит отправляются еще раз (поэтому и получается 1 = 00 80 80)

Для питания использую 3.7v аккумулятор, возможно получится питать от COM (безопасно ли это?)

Думаю, проблемы получится решить и тогда будет готовый ms dos rs232 драйвер для Palm клавиатур

Вот здесь я забыл один момент, хотя он в принципе очевиден:
4. Если пришло прерывние от COM-порта - попадаем в код нашего драйвера.
5. Проверяем не было ли ошибок COM-порта (см.у Р. Джордейна.)
6. Если нет ошибок читаем код из буфера COM-порта.
7. Перекодируем код клавиши.
8. Сохраняем полученное значение в кольцевой буфер клавиатуры.
8'. Выходим из аппаратного прерывания. (IRET)

Судя по описанию - stowawayhwref.pdf - должно быть вполне безопасно до +5В.
Обычно COM-порты строятся так, чтобы выдерживать короткое замыкание на любой линии.
Надеюсь, что у HP 200lx COM-порт тоже способен это выдержать.
Есть только один нюанс: стандартный COM-порт выдает на линии от +/-12 В до +/-3В.
Померяйте сначала - если в пределах +/-5В сигналы, то питать клавиатуру можно, хотя и осторожно:
не подавать на неё -5В (т.е. питание от COM-порта подавать через диод Шоттки).
Если на линиях будет +/-12 В - сделать через диод и малый резистор, а в параллель клавиатуре -
стабилитрон на 3.6...4.7В и параллельно с ним - электролит.

Я выкроил немного времени и почитал исходник драйвера NTKEY2LX.ASM - в принципе все основные
части драйвера в нём есть - надо только внимательно разобраться в них и изменить лишь то, что
касается приема и перекодировки кода от клавиатуры.

За одно взглянул я, что за зверь "Hewlett-Packard серии LX" - там MS-DOS 5.0 сидит в ПЗУ?

Ссылка на stowawayhwref.pdf подохла, если кому он нужен, то есть здесь:
http://www.umlib.com/brand/HP/category/PDA/model/Jornada%20928/document/540662

Было у меня что-то похожее 15 лет назад



Но только для старых Пальмов где тръу-RS232

Да вот я всё и ищу, по какому протоколу (или соглашению) работают Serial клавиатуры через этот самый тръу-RS232...
Или хотя бы через IrDA - мне думается, должно быть похоже...

Но единственная правдоподобная информация, которую нашел, это для вот этой Palm portable keyboard.
Кстати, через USB-RS232 переходник эти клавиатуры, как пишут, тоже работают.

Нет никакой информации (или я не нашел), какие коды должна выдавать Serial keyboard в RS232, если
включить в Винде вот эту поддержку:

Есть ещё вот такой вариант соглашения, какие коды должна посылать Serial keyboard по RS232.
К сожалению, это не настоящая Serial keyboard, а конвертер PS/2 Keyboard to RS232 Serial Keyboard.

Я так думаю если эти клавки требут собственных драйверов, то стандарта не существует - все делали свое собственное что во что горазд...

To есть, так получается, что ASCII Serial KeyBoard - это "кто во что горазд"?
Я так не думаю... и вот по какой причине.

Есть сайт разработчика драйвера для различных устройств на СОМ-портах, работающих по протоколу RS-232:
232key - free RS-232 to keyboard software

У них есть страничка поддерживаемых уникальных устройств:
https://www.232key.com/documentation/index.html

Так вот среди уникальных устройств - ридеры штрих-кодов, умные весы и прочие похожие гаджеты.
Клавиатур я там не нашел, а искал - хотел почитать мануал какой-либо обыденной Serial KeyBoard.
Выходит, что Serial KeyBoard-ы работают более-менее стандартно и идентично...

Собственно, при нажатии на клавишу, они должны послать код ASCII символа на ней.
Возникают трудности и разночтения лишь со всякими специальными и служебными клавишами.

На одном форуме я читал, жалуется пользователь "клавиатура не передаёт у него код для переключения
РУС/ЛАТ..."
Но ведь такого ASCII-кода нет! Есть условная комбинация клавиш. А коды клавиш Alt и Shift
ASCII-клавиатуры просто не передают...

Соглашусь с предыдущим оратором, что ASCII-клавиатуры не передают кодов Shift и Alt, используя нажатия этих клавиш только унутре себя и выдавая только ASCII-коды. Однак, если перейти к AT-PS/2 -клавиатурам, то скан-коды Shift и Alt передаются в явном виде, что я и использовал в http://rw6hrm.qrz.ru/adapter.htm (кроме альта, он пока не нужен). Можно почитать документ https://techdocs.altium.com/display/FPG ... Scan+Codes (пока он ещё доступен).
Если кому-то будет скушно или дорого покупать готовую конструкцию адаптера, то он может использовать исходники на Си из моей ссылки, только переделав вывод с параллельного на СОМ-порт-подобный (если памяти пика хватит).

Да дело не в адаптере и не в его цене... меня конкретно интересует, что понимает вот этот
драйвер Венды, когда включается галка "Поддержка альтернативных устройств" на COMx.



Я предполагаю, что по умолчанию (а подробностей нигде нет) он должен понимать стандартную ASCII Serial KeyBoard, ибо такие существовали, даже от IBM...

Но возникает ряд вопросов: как, примеру, ASCII Serial KeyBoard передаст код от клавиши [PrntScreen]?
Или тот же [Ctrl]+[Alt]+[Del] как ASCII Serial KeyBoard сможет передать?