Полигон-2

Краткое изложение последующих 8-ми страниц, включая предысторию в вольном толковании

Начиная с 286-х IBM PC в составе материнской платы появился "контроллер клавиатуры" (сокращенно KBC - KeyBoard Controller). Это большая 40-ножечная микросхема, похожая на Bios, только побольше.
Первоначально в качестве KBC использовался контроллер общего назначения Intel 8042 со специальной прошивкой.
Позднее, когда KBC стали применяться массово, Intel стала производить 8042 уже с прошитой программой. Появилось множество уже прошитых клонов. Самые известные - Amikey, LT38C41, W83C42, Jetkey. Более подробный список на rom.by
Основной функцией KBC является преобразование последовательного асинхронного интерфейса АТ клавиатуры в параллельный.
Т.е. информация из клавиатуры приходит побитно по двум линиям - Data (данные) и Clock (тактирование), а процессору "предстаёт" побайтно. Причём уже в виде ASCII кодов, в порте 60h.
Помимо этого, KBC "нагружен" и другими функциями. Самые важные из которых - программный Reset и управление Gate A20.
Также к KBC подключены разные джамперы, которыми задаётся работа компьютера на этапе загрузки BIOS - "Color/Mono", "Turbo", "Keylock", "Объём RAM".

В компьютерах IBM PS/2 к тому же самому KBC подключили "PS/2 мышь". Это потребовало смены прошивки и схемы подключения.
Физически протокол PS/2 никак не отличается от АТ. Это тот же самый асинхронный последовательный интерфейс с двумя линиями - Data и Clock (плюс питание +5В и "земля"). Информация, передаваемая от мыши, конечно отличается.
Ниже схемы включения контроллера клавиатуры для АТ и PS/2 режима:

Что характерно, остальной части компьютера абсолютно всё равно, в каком режиме работает KBC. Взаимодействие с клавиатурой не меняется никак. Это всё тот же порт 60h для данных и порт 64h для управления и получения информации о состоянии KBC.
Естественно, PS/2 мышь будет работать только в режиме PS/2 KBC.
Контроллеры клавиатуры с поддержкой PS/2 режима (это Amikey-2, Holtek HT6542B, VIA VT82C42N и др.) обратно совместимы с АТ контроллерами. И сами определяют режим работы (АТ или PS/2) по схеме включения.

Идея переделки состоит в том, чтобы изменить схему включения KBC с АТ на PS/2. При необходимости заменить сам контроллер, если установленный не поддерживает режим PS/2.

Схема переделки:
Синим цветом - то, что исходно уже есть на материнской плате. X1.1 и X1.2 - панелька под контроллер клавиатуры. Старый контроллер вытаскиваем. Вставляем новый с обвязкой. Сажаем на 36-ю ногу IRQ12 перемычкой на материнской плате.
Черным цветом - то, что добавляем.
Вместо инверторов 7406 используются обычные smd транзисторы типа 3904.


В железе, на текущий момент:


Как видно, помимо установки нового KBC и обвязки нужно соединить проводом ноги 36 KBC и D5 разъёма ISA. Это сигнал аппаратного прерывания Irq12, которым KBC сигнализирует процессору о приходе данных от мыши.

Помимо аппаратной переделки необходима программная поддержка со стороны BIOS.
ЧСХ поддержка PS/2 мыши существует во всех BIOS с древних времён (появления IBM PS/2), но отключена.
Для Award BIOS существует отличная программа Modbin, которая понимает даже старые версии Bios.
На 486-й с Award Bios модификация успешно проделана, поддержка PS/2 мыши в Bios включена, PS/2 мышь работает.)))

Для редактирования старых AMI Bios существует туева куча версий программы AmiBCP. Причем под каждую версию биоса своя версия AmiBCP и никто эти версии в глаза не видел. Список версий.

Поэтому возник вопрос, как добавить программную поддержку PS/2 мыши не трогая биос.
Мною написан драйвер PS2SUPP rev.1.0.2, который эту поддержку добавляет.
26.01.18 добавил версию 1.0.2c, которая проверяет 3-й бит в первом байте пакета от мыши (он всегда должен быть =1), и если он не равен 1, сбрасывает мышь. Он немного больше по размерам, чем предыдущий. В памяти занимает на 16 байт больше.
Достаточно запустить этот драйвер перед запуском драйвера мыши.
Работает в DOS и версиях Windows - надстройках над DOS (Win 3xx, Win9x).
Удобнее всего поставить запуск драйвера поддержки PS/2 мыши в autoexec.bat.

К сожалению, не работает в Win NT и других осях, которые не базируются на DOS.

Пока всё.
Сейчас занимаюсь улучшением аппаратной части.

;============================================================
; Начало исходного сообщения
;============================================================
Интерфейс PS/2 нужен, чтобы можно было подключать оптическую мышь.

Коллеги, есть какие-то соображения по этому поводу?
Можно ли это сделать?
Имеет ли смысл?
Как лучше делать?
Может кто-то уже делал такое?
Вообще, стоит ли этим заниматься?

Видел на картинках плату в разъём клавиатурного BIOS, в который вставлялся собственно клавный BIOS и была гребенка для PS2 мыши

Rio444
Вот сейчас гуглю, не могу нагуглить.... т.е. это была платка небольшая, котоаря втыкалась в ДИП40 вместо клавного биоса, а на ней самой был клавный биос (тоже в дип40) и что-то еще из логики, ну и 5пин гребенка под PS/2.

IdeaFix написал:

[q]

и что-то еще из логики

[/q]

7405 нужна была, либо 7407, в зависимости от прошивки.

Прерывание от ps/2-мышки на irq12 протаскивать надо. В 386 только клавиатурное разведено до 8042.

Rio444
Зависит от цены и совместимости.... мне было бы интересно полдюжины если оно было бы совместимо с моими платами и не сильно бы урезало возможности системы (в плане ISA слотов и пр). А насчет ISA и того что DIP40 будет мешать платам, у меня есть такие платы, которым DIP40 штатно стоящий на плате мешает В основном это мультикарты, у которых ком дб25 и гейм порт на плате - широко...

На последней странице указанной мной темы есть картинка сборки контроллера на панельке. Т.е. если панельки ранее не было - высотка будет так или иначе штатной (панелька+микросхема)

Идейно правильной я считаю была бы разработка ISA платы специально под
это дело. Даже стало жаль что мышь на машинах такого класса мне не нужна
абсолютно Да и на основной машине мышь только для интернета...

Rio444 я могу понять когда не искушенные в ПК посетители моего бложика, получившие помощь по вопросам 771 мода начинают задавать сложные вопросы, на которые у меня нет ответов, но тут-то уважаемое комьюнити должно однозначно оценивать плинтусный уровень моих знаний Поучаствовать я могу только материально. К тому же, материальные ресурсы хоть ограничены, но есть, а вот временных нет

По поводу конструктива - можно же и не выпаивать ничего - напаять соплей с тыльной стороны платы или вовсе сделать "накладку" с тыльной стороны, как иной раз и именитые производители делали в случае исправления багов разводки. Тут конструктив имхо не так важен - руки с конструктивом развязаны совершенно, а вот потенциальный мод биоса и задействование одновременно дип40 и иса и куча других проблем... кстати, авард на 486pci коллеги вроде победили.

i8088
Под дип40 есть почти готовый проект которым можно вдохновляться, под PCI есть даже китайские адаптеры, которыми можно вдохновляться, или просто их купить, а под ISA придётся что-то изобретать полностью самостоятельно. Уровень у меня, как уже говорил выше, плинтусный, но мне задача с ISA платой кажется куда более комплексной, но конечно и более изящной.

IdeaFix написал:

[q]

По поводу конструктива - можно же и не выпаивать ничего - напаять соплей с тыльной стороны платы или вовсе сделать "накладку" с тыльной стороны

[/q]

Скорее всего не получится. Там смысл в замене контроллера без поддержки PS/2 на контролер с поддержкой.
И часть сигналов в принципе по-другому идёт. То есть, надо будет не только добавлять, но и перерезать какие-то дорожки.

Rio444 написал:

[q]

Там смысл в замене контроллера без поддержки PS/2 на контролер с поддержкой.

[/q]

А в этом и смысл, мышка ps/2 и клавиатура работают через одни регистры, у них только прерывание различается.

Anonymous написал:

[q]

Rio444 написал:

[q]

Истина где-то рядом(с) 7406.

[/q]

Это высоковольтовая, 30в (оно зачем надо?), полный аналог 7405 по выводам. 7407 - без инверсии, потому и написал о зависомости от версии прошивки.

[/q]

7406 - рекомендации производителей. В типовых схемах именно она. Хотя, наверное, можно поставить и 7405.

Anonymous написал:

[q]

Rio444 написал:

[q]

Как понял, главная загвоздка - поддержка биосом. Если поддерживает, то всё ОК. Если нет - нужно писать свой обработчик прерывания от мыши. Насколько понял, никто его ещё не написал.

[/q]

Все полноценные ОС используют после загрузки свой драйвер, биос после запуска ядра идёт отдыхать. Гляньте мою древнюю тему про оживление безбиосной промплатки.

[/q]

Возможно, начиная с Windows NT. Win9x использует прерывания Bios.

Контроллер определяет, в каком режиме он работает (АТ или PS/2) по схеме включения. Для остальной части компьютера режим работы контроллера значения не имеет. Разве что, в режиме АТ невозможна работа мыши PS/2. Клавиатура работает одинаково в обоих режимах.
Подключение контроллера в режиме АТ (из даташита на VT82C42):

В режиме PS/2:

i8088, круто! Откуда исходники?
Посоветуйте хорошую книгу по программированию на ассемблере.
В частности, чтобы было рассказано, как писать TSR программы.

Господа, если все так сложно, не проще сделать com-ps2 конвертер и не париться? Вот тут все есть - http://www.vogons.org/viewtopic.php?f=46&t=42862

Звиняйте. Диагональное чтение подвело. Ну а есть же уже отовые платы isa на ps/2 mouse, они работают как то или нет на старых системах?

Mihail1810 написал:

[q]

Ну а есть же уже отовые платы isa на ps/2 mouse

[/q]

боюсь что нет
на pci есть

Rio444 написал:

[q]

Это как? Можно поподробнее?

[/q]

NOTE: two bits in the command byte controls the operation of the aux port
(mouse port): the aux port disable bit (bit 5) and the aux port interrupt (IRQ 12)
enable bit (bit 2)


Rio444 написал:

[q]

Фряха биос полностью игнорирует?

[/q]

Не то чтобы полностью, но можно заставить игнорировать. Например,
цитата из psm.c версии 8.4 (с которой пишу)
\t/*
\t * The PnP BIOS and ACPI are supposed to assign an IRQ (12)
\t * to the PS/2 mouse device node. But, some buggy PnP BIOS
\t * declares the PS/2 mouse device node without an IRQ resource!
\t * If this happens, we shall refer to device hints.
\t * If we still don't find it there, use a hardcoded value... XXX
\t */

Для 486 удобнее всего версия 4.11 - с одной стороны достаточно современная (и легкая в установке), с другой стороны вполне работает на 16MB RAM. И можно ставить даже на 386, хотя это неоптимально, но
работает.

Я правда никогда ранее не вдавался в работу мышей (ну Вы это уже поняли, но общие соображения таковы.

Rio444 написал:

[q]

Для ISA есть только Bus Mouse. Внешне похожа, но совсем не то. Сейчас встречаются очень редко и в основном шариковые

[/q]

да - есть Microsoft, Logitec только штырьков там больше чем в PS/2, поэтому что их упоминать

i8088 написал:

[q]

Просто не хватает места для
корпуса инвентора с открытым коллектором, я правильно понял?

[/q]

Да, это одна из главных причин.
Вторая - доступность 7406. Если в DIP исполнении их ещё можно найти, то в SOIC гораздо сложнее. Даже в чипе с дипом только на заказ. С ибея ждать долго.
Да и нужна ли там ИС? Разве транзисторы не справятся?

i8088 написал:

[q]

Ошибок не нашел

[/q]

Спасибо! Буду собирать.

Попробуйте, протестировать можно во FreeBSD (ему этот DOS севис реального режима до лампочки).

Кстати, я подумал, мышь должна и в NT4 работать (2000 поставить на 486 трудно).

Относительно включения mouse part в 8042 и размаскирования
8259 мне понятно, а вот взаимодействие IRQ12 -> INT74 -> драйвера ps2 mouse мне пока что не очень ясно.

Rio444 написал:

[q]

А NT 3.51? Она больше по возрасту подходит.

[/q]

Попробовать можно. Ядро и идеология по идее не сильно отличается. Только - он поддерживает PS2 mouse (я не помню)? Я его ставил один раз очень давно...

i8088 написал:

[q]

8259 мне понятно, а вот взаимодействие IRQ12 -> INT74 -> драйвера ps2 mouse мне пока что не очень ясно.

[/q]

INT33 - драйвер мыши для прикладного ПО, реализуется в TSR драйвере (условный mouse.com), но INT74 - обработчик прерываний контроллера - реализован в биос соответствующим драйвером, который предоставляет API INT15, а mouse.com использует либо RS232 для COM-мышей, либо API INT15 функция C2 для PS/2 мышей

POINTING DEVICE BIOS INTERFACE ( http://www.ctyme.com/intr/int-15.htm ):

Int 15/AX=C200h - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - ENABLE/DISABLE
Int 15/AX=C201h - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - RESET
Int 15/AX=C202h - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - SET SAMPLING RATE
Int 15/AX=C203h - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - SET RESOLUTION
Int 15/AX=C204h - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - GET TYPE
Int 15/AX=C205h - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - INITIALIZE
Int 15/AX=C206h - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - EXTENDED COMMANDS
Int 15/AX=C207h - SYSTEM - POINTING DEVICE BIOS INTERFACE (PS) - SET DEVICE HANDLER ADDR
Int 15/AX=C208h - SYSTEM - POINTING DEVICE BIOS INTERFACE - WRITE TO POINTER PORT
Int 15/AX=C209h - SYSTEM - POINTING DEVICE BIOS INTERFACE - READ FROM POINTER PORT

По сути обычный драйвер мыши ставит свой калбэк через Int 15/AX=C207h, а биос драйвер в обработчике INT74 дергает этот калбэк (см ps2aux.inc строки 360-381 и 460-462)

Необходимо загружать драйвер реализующий INT15 API, в виде TSR, в случае когда его нет в биосе. Это всё в теории конечно.
Собственно такой драйвер и надо написать чтобы всё взлетело на 386. Можно вдохновляться вышеупомянутым ps2aux.inc

Но, конечно, проблема физического размещения платы-расширения добавляет изрядную ложку дёгтя во всю затею.

А в чём состоит сакральный смысл оптической мыши?

Rio444 написал:

[q]

Впаять панельку и бросить перемычку на IRQ12 уже не сложно.

[/q]

Я подумал о случае когда контроллер расположен под платами расширения ISA как, например, на Baby AT 386 материнках. В этом случае высота переходника не позволит его использовать

Коллеги, ну нет проблем с "высотой". Ну совсем нет.

Вот смотрите... это плата в базе и BIOS у неё родной. И плата расширения - канонический трезубец девятитысячный:
https://pp.userapi.com/c639228...tcUyxY.jpg

Ну не садится и всё тут

И платы с клавиатурным контроллером в панельке в этом месте "не совместимы" с большим количеством видеокарт и мультикарт. Но кто-то переживает по этому поводу? Нет, все молча берут другую видеокарту или мкультяху или молча перевтыкают карту в другой слот, который не пересекается с микросхемой. Ведь так?

К тому же, в теме по ссылке есть и реализация навеской на макетке и реализация ВНУТРИ панельки и своё что-то соорудить с тыльной стороны никто не мешает.

Вы же умные... не отвлекайтесь на форму, давайте быстрее прототип Я б купил!

Rio444 написал:

[q]

В разных программах (преимущественно в играх под DOS; в NC и Windows это менее заметно), путём:
1) прямолинейно, медленно и плавно двигать мышью с разные стороны. Убедиться, что курсор движется по экрану также плавно, без "заеданий" и скачков,
2) резко начинать движение мышью, резко менять её направление движения, резко останавливать. Убедиться, что курсор на экране не отстаёт от мыши и не продолжает движение, когда она уже остановилась.

[/q]

Включил XT, снова подергал мышку в VC... ощущения абсолютно прозрачное, как и на основном 4-х ядерном компе.
К слову, даже на основном компе с графикой 1280x720 - тоже курсор перепрыгивает через 10-20 пикселей, при быстром движении по кругу. Это заметно на глаз.
Конвертор, точно также перепрыгивает несколько символов в VC. Это проблема низкого разрешения самой мышки (300dpi?)

Если человеку не знать, что перед ним находится, то возникает ощущения, что это обычный эмулятор XT под 4-х ядерном. Другими словами, конвертор абсолютно прозрачен. Стартует мгновенно и застопаривается мгновенно. Полная синхронизация мышечной реакции и глазной обратной связи. Т.е. ты знаешь, что курсор остановится "вот в этом месте". Рисовать "МонаЛизу с истеричной улыбкой" не пробовал. Лень


Нашел под XT игрушку с высоким разрешением.. да-да, это Warlords с 640x200, мыша там изначально не удобная, как и на COM-вских... Железная привычка играть на клавиатуре и использовать hot-key.. Но мыша там обязательна, чтобы попасть в кнопки "ok".


Нашел еще SimCity, да-да, на XT тоже работает. Графика 640x350. Построил городок и обнаружил неудобства в том что "большая клетка" может промахнуться в другую сторону (строишь дорогу и пошла вверх на 1 клетку, а я хотел по горизонтали, на картинке видно этот "квадратный курсор"). Игрушка сама по себе не удобна, из-за отсутствия привычной формы "курсора мыши".

Покупал за 300 руб. Забыл шариковую мышку как страшный сон

Из минусов:
1) ужасный хвост для внешнего питания 5v, как в Flash-DOM-овских хвостов с 5 вольтом. Сам блок микроскопический, а этот хвост болтает как гремучая змея..
2) Требуется ISA плата с COM-портом. С другой стороны, нет конфликтов на програмном уровне, Все программы думают что это стандартная COM-мыша. Полностью аутентичный COM-протокол.

Из плюсов:
1) "а что такое шариковая мышь?"

Rio444 написал:

[q]

Невозможно плавно менять скорость.

[/q]

Если речь идет "ускорения" то это ответственность несет драйвер мыши, управляется из командной строки. К слову, с этим проблем тоже не наблюдаю.

Я так понимаю, что нужно проверять в 3D-шутере, подобия Descent - где нужно быстро и точно наводить на цель.
Для таких случаев, у меня 486 на плате 4dps, у него и так есть PS/2
Кстати, рекомендую в Wolf3D играть только на конвертере, идеально работает и быстрый захват на цель. А не клавиатурой. Играл на быстром 286-25мгц.


Rio444 написал:

[q]

у его алгоритма проблема не с отзывчивостью, а с плавностью перемещения....

[/q]

Откуда эти сведения? думаю паника преувеличена

[q]

Также попробуйте плавно, равномерно двигать курсором горизонтально, вертикально, под углом 45 градусов.

[/q]

Подвигал...

Rio444 написал:

[q]

Из анализа исходного кода прошивки. Часть пакетов от мыши PS/2 теряется и не доходит по порта COM.

[/q]

Вполне возможно. У COM-овских протоколов ограничено до 9600 1200 бодов. А PS/2, наверное, больше.

Могу только заверить, что "скачет в другую сторону" не замечал за последние 2 года (я изредка включал XT). Поэтому паника слегка преувеличена

Но никто-ж не запрещает изобретать новое. В любом случае, аутентичность теряется в обеих случаях (конвертор или новый 8042 c ISA-платой).
P.S. Интересно потом сравнить в лоб: конвертор или New8042. И где эта разница обнаружится.

Ekb написал:

[q]

Могу только заверить, что "скачет в другую сторону" не замечал за последние 2 года (я изредка включал XT). Поэтому паника слегка преувеличена

Но никто-ж не запрещает изобретать новое. В любом случае, аутентичность теряется в обеих случаях (конвертор или новый 8042 c ISA-платой).
P.S. Интересно потом сравнить в лоб: конвертор или New8042. И где эта разница обнаружится.

[/q]

Хорошая шариковая COM мышь на хорошем коврике более точно передаёт движения, чем оптическая через конвертер.
Хотя, возможно, долю погрешности вносит сама оптическая мышь. Как-нибудь попробую с другой.
"New8042" будет работать точно так же, как обычный PS/2 порт на любой материнской плате.
Никаких задержек или преобразований не добавляется.

Про "скачет" возможно я неточно выразился. Появляется дискретность движений. То есть, вместо того, чтобы перемещаться плавно, попиксельно, курсор может на мгновение остановиться, потом "перепрыгнуть" сразу на два пикселя. Это заметно только если очень медленно двигать мышью. Либо не настолько медленно, но почти вертикально или почти горизонтально. При быстрых резких перемещениях что-то заметить очень сложно.

В каких-то программах это более заметно, в каких-то менее. Видимо сами программы вносят какую-то задержку на обработку входящих данных о перемещении мыши. И по-разному их обрабатывают. В теме о конвертере я писал, что наиболее заметны артефакты в игре "Цветные линии" (Lines). В Norton Commander заметить что-то практически невозможно. В Windows95 на уровне ощущений чувствуется небольшая рассинхронизация движения руки и курсора на экране. С оптической мышью, подключенной в PS/2 ощущения рассинхронизации не возникает.

[q]

В некоторых источниках пишут, что эта функция

[/q]

не позволяет реализовать задержку меньше 976 мкс, если речь про это:
http://vitaly_filatov.tripod.com/ng/asm/asm_026.13.html

[q]

что будет, если длительность меньше

[/q]

Надо разбираться как она внутри работает, чтобы проверить это.

[q]

В частности, как реализовать задержку 15мкс?

[/q]

Ровно не получится, но вряд ли вам наносекунды будут принципиальны
Самому запрограммировать таймер 8254 на нужную частоту прерываний и ловить IRQ0
https://en.wikibooks.org/wiki/...rval_Timer
Нужный делитель - 18.


Как различные ОС к такому отнесутся - ничего обещать не могу.

Сам с ним не развлекался, а примеры кода есть здесь:
http://wiki.osdev.org/Programmable_Interval_Timer
Там хорошая простыня

Rio444 написал:

[q]

как реализовать задержку 15мкс?

[/q]

Думаю, это самое реальное из всего возможного (подпрограмма задержки из BIOS PC/XT):



WAITF    PROC  NEAR      ; FIXED TIME WAIT ROUTINE HARDWARE CONTROLLED - NOT PROCESSOR
                  ; ENTRY:
                  ; (CX) = COUNT OF 15.085737 MICROSECOND INTERVALS TO WAIT
                  ; MEMORY REFRESH TIMER 1 OUTPUT AT THE DMA CHANNEL 0 ADDRESS REGISTER USED AS REFERENCE.
                  
                  ; EXIT:
                  ; AFTER (CX) TIME COUNT (PLUS OR MINUS 31 MICROSECONDS)
                  ; (CX) = 0    
  
      PUSH  AX        ; SAVE WORK REGISTER (AH)
      SHR    CX,1      ; DIVIDE 15us COUNT DOWN TO 30us COUNT
      ADC    CX,0
      JCXZ  WAITF9      ; EXIT IF COUNT WAS ZERO OR ONE

      OUT    DMA+12,AL    ; CLEAR THE DMA BYTE POINTER FLIP/FLOP
WAITF1:
      PUSHF          ; SAVE INTERRUPT STATE
      CLI            ; BLOCK INTERRUPTS TILL NEXT CHANGE
WAITF3:               ; WAIT FOR REFRESH ADDRESS CHANGE
      IN    AL,DMA      ; READ CURRENT ADDRESS LOW BYTE
      AND    AL,11111110B  ; DISCARD LOW BIT (30us)
      CMP    AH,AL      ; DID VALUE JUST CHANGE
      MOV    AH,AL      ; SAVE NEW/OLD VALUE INCASE IT DID
      IN    AL,DMA      ; READ HIGH BYTE (AND IGNORE)
      JE    WAITF3      ; WAIT FOR A CHANGE IN ADDRESS BITS

      POPF          ; RESTORE INTERRUPTS
      LOOP  WAITF1      ; DECREMENT CYCLES COUNT TILL COUNT END
WAITF9:
      POP    AX        ; RESTORE (AH)
      RET            ; RETURN (CX)= 0

WAITF    ENDP



Извините за формат - тегов CODE что-то не вижу на форуме...

Думаю, канал 0 DMA - единственное, что на старых компьютерах может более-менее надежно выдавать подобные интервалы, причем крайне маловероятно, чтобы кто-то решил его перепрограммировать (хотя такие примеры тоже знаю). Перепрограммировать 8253 категорически не рекомендую - несовместимость с чем-нибудь практически гарантирована...

[q]

Извините за формат - тегов CODE что-то не вижу на форуме...

[/q]

{code}


WAITF  PROC  NEAR  ; FIXED TIME WAIT ROUTINE HARDWARE CONTROLLED - NOT PROCESSOR
; ENTRY:
; (CX) = COUNT OF 15.085737 MICROSECOND INTERVALS TO WAIT
; MEMORY REFRESH TIMER 1 OUTPUT AT THE DMA CHANNEL 0 ADDRESS REGISTER USED AS REFERENCE.

REM Oни есть. Но их нужно вводить ручками.
{/code}

Соотв. фигурные скобки меняем на квадратные.

justontime, этот код для XT, но в AT машинах канал DMA0 освободился от функции регенерации памяти.
Соответственно, для требуемой нам AT читать DMA регистры уже не годится.
А во всех ли интересующих нас AT (286-486) канал 0 канал 1 8253 (с DMA он уже не связан) настроен на период 15мкс,
чтобы можно было его использовать? Надо будет проверить.

upd
Исправил, напутал номер канала 8253

Приоритетно для машин 286, 386, 486-х.
Если заработает на XT - не страшно, но и не принципиально.
Для пентиумов не нужно, для них материнка без поддержки PS/2 - экзотика.

Вообще, первая мысль была - использовать тупой цикл, со счетчиком.
Вопрос только, где брать начальное значение счетчика? Оно будет зависеть от скорости процессора.
Это начальное значение можно считать на этапе инициализации (т.е. только один раз).
Но нужен какой-то таймер, который работает на всех вышеуказанных машинах, и работает одинаково.
Возможно ли использовать канал 0, таймера 8253/8254 (он же - системный таймер)? Только не ждать, когда он "тикнет", а прочитать содержимое счетчика и подождать, когда оно уменьшится на 18 (см. выше пост pahan) - это и будут требуемые ~15мкс.

i8088 написал:

[q]

Канал 0 слишком медленно настроен (коэфф деления 65536), 1 тик ~54.9ms

[/q]

Rio444 написал:

[q]

Только не ждать, когда он "тикнет", а прочитать содержимое счетчика и подождать, когда оно уменьшится на 18 (см. выше пост pahan) - это и будут требуемые ~15мкс.

[/q]

i8088, извинения излишни.
Значения счетчика из таймера можно читать непосредственно?
in al, 040h ?
Ничего не собьётся? Всегда ли он работает?
Нужно ли предварительно делать "Access mode" = lobyte only ?

[q]

Bits Usage
6 and 7 Select channel :
0 0 = Channel 0
0 1 = Channel 1
1 0 = Channel 2
1 1 = Read-back command (8254 only)
4 and 5 Access mode :
0 0 = Latch count value command
0 1 = Access mode: lobyte only
1 0 = Access mode: hibyte only
1 1 = Access mode: lobyte/hibyte
1 to 3 Operating mode :
0 0 0 = Mode 0 (interrupt on terminal count)
0 0 1 = Mode 1 (hardware re-triggerable one-shot)
0 1 0 = Mode 2 (rate generator)
0 1 1 = Mode 3 (square wave generator)
1 0 0 = Mode 4 (software triggered strobe)
1 0 1 = Mode 5 (hardware triggered strobe)
1 1 0 = Mode 2 (rate generator, same as 010b)
1 1 1 = Mode 3 (square wave generator, same as 011b)
0 BCD/Binary mode: 0 = 16-bit binary, 1 = four-digit BCD

[/q]

i8088 написал:

[q]

Я только рекомендую не использовать 386+ инструкции, для совместимости с 286.

[/q]

Вы зря переживаете. Я и 8086 инструкции плохо знаю. 386+ для меня вообще темный лес.

i8088 написал:

[q]

По ссылке pahan как раз есть пример, думаю ответы на все Ваши вопросы -да.

[/q]

Не нравится мне пример по ссылке:read_PIT_count:
  pushfd
  cli
  mov al, 00000000b    ; al = channel in bits 6 and 7, remaining bits clear
  out 0x43, al         ; Send the latch command

  in al, 0x40          ; al = low byte of count
  mov ah, al           ; ah = low byte of count
  in al, 0x40          ; al = high byte of count
  rol ax, 8            ; al = low byte, ah = high byte (ax = current count)
  popfd
  ret
Он устанавливает собственный режим работы канала 0, нарушая работу системного таймера.

Я бы сделал
mov al, 00010110b
out 043h,al
in al,040h
Т.е. принудительно установил бы чтение/запись только младшего байта. Остальное без изменений.

[q]

к сожалению командный регистр - WO, что не позволяет сохранять настройки.

[/q]

У 8254 есть команда write-back.

[q]

принудительно установил бы чтение/запись только младшего байта

[/q]

[q]

Значения счетчика из таймера можно читать непосредственно?
in al, 040h ?
Ничего не собьётся?

[/q]

Есть риск, что он перейдёт через 0 и тогда задержка в эти моменты сильно увеличится. Но скорее всего придётся для получения адекватной производительности (см. ниже для примера чтения всех байт). В остальном - ОК.

[q]

Нужно ли предварительно делать "Access mode" = lobyte only ?

[/q]

В теории, кто-то может и поменять режим за то время, что мы к нему обращаемся. Безопаснее ставить.

[q]

прочитать содержимое счетчика и подождать, когда оно уменьшится на 18

[/q]

Можно, но стоит серьёзно подумать, 1)насколько нам нужна такая точность (ровно 15 мкс), 2) на каких процах и 3)в каких режимах мы будем наш код использовать. Потому что на всех 486 и топовых 286-386 всё это спокойно прокатит, на младших 386 в реальном режиме (чистый DOS) - да, в режиме виртуального 8086 (DOS-окно из-под Windows) - впритык, на младших 286 даже в реальном режиме вряд ли уложимся.

Считаем время выполнения инструкций
(данные отсюда - http://www.cs.dartmouth.edu/~m...c/x86.html) только для считывания текущего значения счётчика таймера 8253 (а значит, этот код повторится ещё как минимум 1 раз, + сравнение(2-2-1 такт), +цикл после сравнения(не меньше 7-не меньше 7-3), +служебные команды, если это будет подпрограммой (cli/sti/push/pop/ret)):
mov al, 0xD2
out 0x43, al
in al,0x40
mov ah,al
in al, 0x40
rol ax,8 - считали текущее значение канала 0
mov bx,ax - и запомнили его

В тактах проца это всё займёт:
286 - 2+3+5+2+5+13+2=32 такта (на частоте 8-25 МГц)= 4 мкс-1,3 мкс
386 - 2+10(4..24..24)+12(6..26..26)+2+12(6..26..26)+3+2=43 такта в реальном режиме/25-85 в защищённом/85 в V86 (на частоте 16-40 МГц)= 2,7/1,6/5,3 мкс - 1,1/0,6/2,1 мкс
486 - 1+16(11..31..29)+14(9..29..27)+1+14(9..29..27)+2+1=39 тактов в реальном режиме/34-94 в защищённом/88 в V86 (на частоте 25-133 МГц)= 1,6/1,4-3,8/3,5 мкс - 0,3/0,3-0,7/0,7 мкс

pahan написал:

[q]

Есть риск, что он перейдёт через 0 и тогда задержка в эти моменты сильно увеличится.

[/q]

Предварительно проверяем, что текущее значение >18 (лучше с запасом - больше 30). Если меньше, ждём (считываем повторно, пока не станет >18, т.е. не пройдет через 0).

pahan написал:

[q]

1)насколько нам нужна такая точность (ровно 15 мкс)

[/q]

Если реальная задержка будет 15...30мкс, думаю это устроит. Это задержка между появлением флага переполнения буфера мыши в контроллере и появлением данных в выходном регистре. Не знаю, почему именно 15мкс. Это значение в исходнике Sergey Kiselev XT биос. Он, вероятно, скопировал из исходников Award bios.

pahan написал:

[q]

2) на каких процах

[/q]

От самого младшего 286 (8МГц?), до самого старшего 486 (AMD 5x133@160)

pahan написал:

[q]

3)в каких режимах мы будем наш код использовать. Потому что на всех 486 и топовых 286-386 всё это спокойно прокатит, на младших 386 в реальном режиме (чистый DOS) - да, в режиме виртуального 8086 (DOS-окно из-под Windows) - впритык, на младших 286 даже в реальном режиме вряд ли уложимся.

[/q]

Код инициализации - из под чистого DOS (если стоит Win95, то до её загрузки, из autoexec.bat). Сама задержка - вероятно и DOS, и Windows. Но Win95 ставят только на 386 и выше (лично я предпочитаю от 486-х).

Исходя из Ваших дальнейших расчетов
pahan написал:

[q]

286 - 2+3+5+2+5+13+2=32 такта (на частоте 8-25 МГц)= 4 мкс-1,3 мкс

[/q]

думаю нормально. Эта часть быдет выполнять только в чистом DOS.

pahan написал:

[q]

Есть риск, что он перейдёт через 0 и тогда задержка в эти моменты сильно увеличится.

[/q]

Это как раз не страшно, тк складывать текущее знасение с 18 мы тоже будем с переполнением.

Пример.
Текущее значение счетчика (младший байт) == 0xF0
Запоминаем, складываем с 18 , 0xF0 + 0x12 = 102
Перенос вызовет установку флага CF, но на это не обращаем внимания.
Ну и собственно ждем, когда счетчик достигнет значения 0x02

Это чем-то похоже на относительные внутрисегментные безусловные
переходы в x86: смещение перехода задается формально в пределах -32768
+32767, но "дотянуться" до любого адреса внутри сегмента не проблема.

А о задержке - я думаю это носит рекомендательный характер, для
совместимости со всеми устройствами и выдерживать его прям точно до
микросекунды нет необходимости, и исходники это подтверждают.


Rio444 написал:

[q]

От самого младшего 286 (8МГц?),

[/q]

Первый 286 - 6MHz. PC/XT полюбому в пролете, там совсем другой
интерфейс клавиатуры и сама клавиатура. Ну за исключением очень
редких нестандартных XT с AT клавиатурой.

Rio444 написал:

[q]

Т.е. 18 надо вычитать, а не прибавлять.

[/q]

Ой да, забыл, что счет в обратную сторону, мои извинения!

Но сути дела это не меняет.

Пример
Исходное значение 0x04
Вычисляем, чего ждать 0x04 - 0x12 == 0xFFF2 (старшие FF это я перенос обозначил)
На флаг CF не обращаем внимания, и ждем когда счетчик достигнет 0xF2

PS. Если бы КД канала 0 был бы не 65536, то переустановку счетчика при
переходе через 0 пришлось бы учитывать, и код был бы более сложным.

Rio444 написал:

[q]

Не может такого быть, что счетчик не достигнет 0xF2, а "перескочит" его, когда будет
очередное считывание? Если процессор медленный. И, видимо, надо будет запрещать аппаратные
прерывания, иначе они сильно исказят расчет.

[/q]

При медленном CPU я думаю возможно, тогда ловить не равенство, а что число в счетчике ниже
чем рассчитанное (сравнивать беззнаково!).

К примеру (просто первое, что сходу пришло в голову, это не проверялось, возможны
грубые ошибки!)

======================================================================
DELAY_CONST EQU 18

mov al, 00010110b
out 043h, al
in al, 040h
mov bl, al
sub bl, DELAY_CONST (в bl вычисляем значение окончания задержки)

delay_ch0: in al, 040h
cmp al, bl ;(в bl у нас рассчитанное ранее значение)
jbe stop_delay_ch0 ;(сравнение беззнаковое!)

;; здесь должна быть дополнительная проверка, если к примеру у нас рассчитанное
;; конечное значение 0x01, CPU задержался, и в счетчике уже к примеру 0xff
;; Здесь я совсем не уверен в корректности моего решения (проверка чисел как
;; знаковых, если беззнаковая проверка дала "добро" на продолжение цикла и считанное
;; значение отрицательно (0x80-0xff), а конечное положительно. Надеюсь, что до 0x7f
;; запаздывание из-за CPU (положительные знаковые числа не дойдет).

cmp al, 00h ; просто для устанавки флагов
jns delay_ch0 ;проверка, что считанное значение положтельно, если да, то продолжаем цикл

; если мы здесь, то имеем считанное значение отрицательное, проверяем конечное значение
cmp bl, 00h
; если имеем ситуацию, когда конечное значение (bl) положительно, а текущее (al)
; отрицательно, то выходим из цикла
jns stop_delay_ch0

jmp short delay_ch0

stop_delay_ch0: ;эдесь процедура (код) задержки кончается
======================================================================

Прерывания да, запретить обязательно! По любому будет видно при отладке, с первой
попытки такие вещи обычно не работают.

Для проверки можно сделать простую програму с бесконечным циклом из этой задержки, и
направить вывод например в LPT порт (например после каждой задержки иннвертировать
данные в 378h). И наблюдать осциллографом длительность импульса и паузы на линиях данных
LPT. Я так проверял реальные задержки во FreeBSD.

======================================================================
LPT_DATA_PORT EQU 0378h

mov dx, LPT_DATA_PORT
in al, dx
xor al, 0ffh ;инвертируем
out dx, al
======================================================================

После исполнения такой программы в цикле системные часы отстанут, но для проверки
это несущественно, особенно если цикл бесконечный.

Роман, для отладки пока уберите отключение прерываний
в процедуре задержки.

Я как освобожусь, тоже посмотрю. Процедура задержки
будет полезна и в других проектах.

Я проверял на плате XT IBM5160 (у нее таймер 8253) - при программировании канала 0 даже
тем же значением 0x36h (lsb/msb), режим 011, таймер просто перестает считать и системное
время стоит.

Если не трогать 0x43, то чтение канала0 исправно возвращает LSB/MSB (меняющиеся).

В исходниках IBM BIOS делается отключение прерываний от таймера при программировании
маскированием входа 8259. Ядумаю надо сделать также.

pahan написал:

[q]

А в каком режиме он стоит (access mode)? Потому что если в lobyte/hibyte - всё ОК, он будет ждать след. байта. А режим мы проверить не можем, потому что зачем-то тестируем на XT (таймер 8253), а не AT (8254).

[/q]

Он стоит в режиме hi/lo 011, при записи того-же режима получаем останов
счетчика и поочередно получаем hi/lo одинаковые (те например 0xe4 0xf2
0xe4 0xf2 0xe4 0xf2 итд).
При переводе в режим LSB - всегда одно значение.


pahan написал:

[q]

Обсудили же, что XT не трогаем и сами лезете на ней тестировать

[/q]

Меня интересует универсальная процедура задержки, к PS2 вопросу это не
относится. Насколько я понял, у Rio444 на AT получилось то же самое.

Rio444 написал:

[q]

Что такое "LSB", "MSB"?

[/q]

Да этоя по привычке, low status byte, high status byte,.
MSB вообще мой глюк
Здесь это не статус конечно, просто режим младший байт старший байт.


Rio444 написал:

[q]

Сильно странно это. Таймер вообще не должен стоять.
---

[/q]

Да, меня тоже это заинтересовало, неожиданно. Для пользователя
проявилось это в том что системное время "стало"

MSB аббревиатуру я где-то встречал, поэтому и на автомате написал.
Сейчас не могу вспомнить где, наверно действительно main

Ошибка оказалась простейшей!

Просто после изменения режима счетчика (даже если записывается тот же
режим, что был) нужно заново загрузить значения коэфф деления, у нас 65536,
соответственно записываем 0

Из исходников IBM

\tMOV\tAL,36H\t\t\t; SEL TIM 0,LSB,MSB,MODE 3
\tOUT\tTIMER+3,AL\t\t; WRITE TIMER MODE PEG
\tMOV\tAL,0
\tOUT\tTIMER,AL\t\t; WRITE LSB TO TIMER 0 REG
\tOUT\tTIMER,AL\t\t; WRITE MSB TO TIMER 0 REG


Пока это не сделать, соответствующий счетчик будет стоять.

По окончанию задержки обязательно восстановить исходный hi/lo режим,
хотя можно и работать в режиме hi/lo, не меняя режим на lo

IBM тоже использует обозначения LSB/MSB применительно к байтам!

А кстати, можно не отбрасывать старший байт, тогда максимальная
задержка будет 55ms, и процедура будет более универсальной.
Но точность малых задержек будет хуже, тк процессору больше работы.

Rio444 написал:

[q]

Если не трогать 043h, в каком порядке идут байты? Сначала Low, потом High?

[/q]

Да, но режим 0x36 все же стоит установить, тк нет гарантии, что какая-либо
программа/процедура не читала счетчик ранее, и могла оставит в состоянии,
когда первым (в нашей процедуре) будет MSB.

MSB/LSB обозначения можно узаконить, они упоминаются в официальной
Intel manual по 8253

Моя идея с отлавливанием запаздывания оказалась неверной, новый вариант попробовать
ловить изменение старшего байта если конечное значение положительно. Но очень много
команд, и после latch нужно заново ставить режим, чтобы заново началось изменение
счетчика (я все проверял на 8253). Надо еще подумать.

Кстати, loop цикл с выводом в LPT порт на IBM 5160 дает меандр
с длительностями импкльса и паузы примерно 11мкс.

Вообще может быть удобнее использовать канал 2, его можно останавливать (замемто
latch) через логику PPA (или ее аналог в AT)? Временно перепрограммировать на 65536,
а на выходе вернуть назад, но это увеличит задержку. Надо подумать.

Rio444 написал:

[q]

Если только канал 2 уже ни для чего больше не используется.

[/q]

Штатно он в основном для диагностического speaker используется.

Если какая программа использует его для измерения времени, то по
любому сама и программирует.

А штатно егоо функция например подавать гудки (тот же DOS), я не
уверен что он программирует его заново каждый раз. Ну можно по выходе оставлять настроенным на 1000Hz

Во всех руководствах по ассемблеру это самый используемый канал,
все примеры обычно на нем строятся.

Я еще подумаю.

Очень просто, но очень неточно. Даже значение в Ah не инициализируют.
Перед WAITF1 должно быть:
IN  AL,PORT_B
MOV  AH,AL
Возможно именно этот алгоритм используется в int 15h функция 86h.

Посмотрите вот такой вариант:

; Расчет значения счетчика для задержки 15мкс
; Выходное значение cx = значение счетчика для цикла с задержкой 15мкс
; Если cx = 0 - ошибка
  timer equ 040h    ; Используем таймер 0
  xor cx,cx  ; Обнуляем счетчик
  cli    ; Запрещаем прерывания
  in al,timer
  mov bh,al
  in al,timer
  mov bl,al  ; Теперь в bh, bl у нас два подряд считанных значения из тамера. Младший байт и старший байт. Порядок значения не имеет.
        ; Это начальные значения, с которыми будем сравнивать
start_loop:
  inc cx  ; Увеличиваем на 1 счетчик
  jz exit_15us  ; Если счетчик = 0, т.е. прошло 65536 циклов, то выходим. Ошибка.
  xchg  bl,bh  ; Меняем местами bh и bl. В первом цикле в bl 1-й принятый байт, во втором 2-й, опять 1-й, снова 2-й и т.д.
  mov ah,bl  ; То же самое теперь в ah
  in al,timer
  sub ah,al  ; Вычитаем новое значение в счетчике из начального
  cmp ah,18  ; Если разница > 18
  jb start_loop  ; Повторяем цикл
exit_15us:  
  mov word [const_15us],cx  ; Сохраняем рассчитанное значение
  sti    ; Включаем прерывания
const_15us: dw 0
  
; Теперь сам цикл с задержкой. Из-за того, что прерывания не отключаем, реальная задержка может быть больше 15мкс
  mov word cx,[const_15us]  ; Задаём начальное значение счетчика
loop_15:
  xchg  bl,bh  ; Фиктивные операции, которые бесполезны, но вносят такую же задержку, как в расчете начального значения счетчика
  mov ah,bl  ; Фиктивная
  in al,timer  ; Фиктивная
  sub ah,al  ; Фиктивная
  cmp ah,18  ; Фиктивная
  jb next_15  ; Фиктивная
next_15:  
  dec cx  ; Уменьшаем на 1 счетчик
  jnz loop_15  ; Если он не равен 0, повторяем цикл

На 386DX-40 получилось на выходе 10 циклов. Что вполне неплохо. На 286-й конечно точность будет очень низкая.

i8088 написал:

[q]

Те Вы предлагаете сделать пре-калибровку, а потом всюду использовать найденную константу?

[/q]

Собственно я так изначально предлагал
Rio444 написал:

[q]

Вообще, первая мысль была - использовать тупой цикл, со счетчиком.Вопрос только, где брать начальное значение счетчика? Оно будет зависеть от скорости процессора.Это начальное значение можно считать на этапе инициализации (т.е. только один раз).Но нужен какой-то таймер, который работает на всех вышеуказанных машинах, и работает одинаково.

[/q]

i8088 написал:

[q]

Цикл у Вас в конце лучше сделать так

[/q]

Смысл в том, что сохраняется число тактов на один проход цикла. Весь код совпадает, только меняется порядок инструкций, и inc cx меняется на dec cx.
Будут ли по числу тактов loop и dec(inc) cx jnz равноценны?

Осциллограф далеко и барахлит, поэтому проверил программно:
org 0100h
; Расчет значения счетчика для задержки 15мкс
; Выходное значение cx = значение счетчика для цикла с задержкой 15мкс
; Если cx = 0 - ошибка
  timer equ 040h    ; Используем таймер 0
  xor cx,cx  ; Обнуляем счетчик
  cli    ; Запрещаем прерывания
  in al,timer
  mov bh,al
  in al,timer
  mov bl,al  ; Теперь в bh, bl у нас два подряд считанных значения из таймера. Младший байт и старший байт. Порядок значения не имеет.
        ; Это начальные значения, с которыми будем сравнивать
start_loop:
  inc cx  ; Увеличиваем на 1 счетчик
  jz exit_15us  ; Если счетчик = 0, т.е. прошло 65536 циклов, то выходим. Ошибка.
  xchg  bl,bh  ; Меняем местами bh и bl. В первом цикле в bl 1-й принятый байт, во втором 2-й, опять 1-й, снова 2-й и т.д.
  mov ah,bl  ; То же самое теперь в ah
  in al,timer
  sub ah,al  ; Вычитаем новое значение в счетчике из начального
  cmp ah,18  ; Если разница > 18
  jb start_loop  ; Повторяем цикл
exit_15us:  
  mov word [const_15us],cx  ; Сохраняем рассчитанное значение
  sti    ; Включаем прерывания
  
  mov ah, 09h
  mov dx, start_string
  int 21h      ; вывод строки на экран

  xor cx,cx
start_main_loop:
  call delay_15us
  call delay_15us
  call delay_15us
  call delay_15us
  call delay_15us
  call delay_15us
  call delay_15us
  call delay_15us
  call delay_15us
  call delay_15us
  loop start_main_loop
  
  
  mov ah, 09h
  mov dx, end_string
  int 21h      ; вывод строки на экран  
  
  int 20h ; Выходим из программы


delay_15us:  ; Подпрограмма задержки 15 микросекунд
  mov word dx,[const_15us]  ; Задаём начальное значение счетчика
loop_15:
  xchg  bl,bh  ; Фиктивные операции, которые бесполезны, но вносят такую же задержку, как в расчете счетчика
  mov ah,bl  ; Фиктивная
  in al,timer  ; Фиктивная
  sub ah,al  ; Фиктивная
  cmp ah,0  ; Фиктивная
  jb next_15  ; Фиктивная
next_15:  
  dec dx  ; Уменьшаем на 1 счетчик
  jnz loop_15  ; Если он не равен 0, повторяем цикл
  ret
  
const_15us: dw 0
start_string: db 'Program start$'
end_string: db 10,13,'Program end$'
С метки start_main_loop находится цикл, который выполняется 65536 раз, в каждом цикле 10 раз вызывается задержка 15мкс.
Расчетная задержка = 15мкс*65536*10 = 9 830400 мкс = 9,83 секунд
Интервал считаем между появлением на экране сообщений Program start и Program end.
По секундомеру получилось 11,3 секунды. Что вполне неплохо коррелирует. Т.е. реальная задержка (с учетом затрат времени на call и ret) получается ~17мкс.

i8088 написал:

[q]

[/q]

Спасибо!
Дя, обломчик с int 15 86h.
Странно, что в большинстве источников не указан такой принципиальный момент.

Но, по большому счету, в TSR программе вообще нельзя использовать int.

Роман, поздравляю с первым вариантом программы!!


Rio444 написал:

[q]

В процессе инициализации размаскировываю прерывание Irq12, но к концу программы какая-то хрень снова его маскирует.
Не могу понять какая. Сейчас перед выходом из программы приходится повторно его размаскировывать.

[/q]

Это под чистым DOS делается? По идее кроме драйвера мыши
заниматься манипуляциями с irq12 некому? Он уже загружен при
запуске программы?

Вроде все логично.

Относительно маскирования - а может быть какое-то действие в
программе вызывает маскирование, как побочный эффект (вызов
какой-либо функции BIOS, хотя в TSR это ограничено)?

А если попробовать в программу через определенные интервалы
вставлять чтение регистра маски secondary int controller, 0a1h ?
И в debug пронаблюдать, когда происходит маскирование?

i8088 написал:

[q]

Относительно маскирования - а может быть какое-то действие впрограмме вызывает маскирование, как побочный эффект (вызовкакой-либо функции BIOS, хотя в TSR это ограничено)?

[/q]

Тоже об этом подумал. Но это ещё не TSR (точнее не резидентная часть) , это инициализация, которая выполняется один раз, как обычная программа.

i8088 написал:

[q]

А если попробовать в программу через определенные интервалывставлять чтение регистра маски secondary int controller, 0a1h ?И в debug пронаблюдать, когда происходит маскирование?

[/q]

Что-то подобное попробую сделать.

pahan написал:

[q]

[q]

Но как пишут в источниках, биос мождет хранить там и другие данные.

[/q]

Не "может", а обязательно будет. И формат её не стандартизирован...

[/q]

Если "будет", то это ещё проще. В этом случае область EBDA уже выделена. И можно использовать её готовую.
Но пока на платах без поддержки PS/2 она отсутствует в принципе. В ячейке BDA, хранящей указатель на EBDA - "0000h".

Причина отключения irq12 оказалась весьма нетривиальной.
Помехой послужила операция чтения статусного регистра 8042: "in al,064h".
Если размаскирование irq12 выполнить после этой операции, то всё работает.
Если до - irq12 по-прежнему отключено.
Вот участок кода с "in al,064h":
kbc_wait_aux_full:
  push  cx
  xor  cx,cx
.1:
  in  al,kbc_status_reg  ; kbc_status_reg = 064h
  test  al,kbc_stat_obf
  loopz  .1    ; Если буфер клавиатуры свободен, идем дальше
  or  cx,cx
  pop  cx
  jz  .error    ; Закончились попытки, ошибка
  test  al,kbc_stat_aobf  ; Проверяем, есть ли данные в буфере мыши
.error:
  ret
Для размаскирования irq12 вставлял код:
  push ax
  mov al,0Dh ; Только для проверки, в данной системе исходно 1Dh
  out 0A1h,al
  pop ax
Сразу не понял в чем дело.
Между этими операциями не должно быть никакой связи.
Видимо причина в том, что контроллер прерываний слишком тормознутый, и, если после операции записи в него, через короткое время следует операция с другим портом (или именно 064h??), он не успевает считать данные.
Эксперимент это подтвердил. Если в Debug запускать сразу весь участок кода - маска прерываний не меняется. Если в режиме трассировки (когда появляются паузы) - всё работает.

Буду пробовать. Не хватает времени плотно заняться. Приходится урывками.

UPD
Не могу повторить утренний результат.
Запуск pa2supp.com вызывает маскирование irq12 (маска 1Dh), даже если оно было ранее замаскировано (маска 0Dh).
В Debug код
mov AL,0D
out A1,AL
in AL,64
in AL,A1
работает как ни в чем не бывало.
Т.е. в результате в регистре AL = 0D, как и должно быть.
Хотя утром он не работал. Или я был не внимателен.
В коде основной программы место работающего фрагмента кода включения irq12 тоже "гуляет".
В нескольких попытках оно сначало оказалось перед строкой in al,064h, потом "вернулось" на то же место, что и утром - после этой строки.
В общем, ничего не понимаю.

Остаётся забить на эту проблему и включать irq12 в конце кода.

Немного не совсем по теме, но все же, возвращаясь к вопросу задержки.

Обнаружил любопытный эффект на плате IBM 5150 с таймером 8253 от AMD, образца 1983 года.
Простое чтение счетчиков канала 0 без latch приводит к резкому понижению коэффициента деления,
особенно при больших исходных коэффициентах. Так, при делителе по умолчанию (65536) просто
после чтения (в debug) порта 0x40, коэффициент деления канала 0 становится равным 2!
Проверялось осциллографом. При чтении с latch чтение нормальное.

Столь малые КД для канала 0 ведут к зависание машины (слишком высокая частота IRQ0).

Те просто:
debug
-i 40
и все, машина стала.

На IBM 5160 c таймером 8253 от Intel (плата выпуска 1986года) такого не наблюдалось,
я эксперименты в этой теме делал с ней.

У кого есть IBM 5150, большая просьба проверить проверить чтение порта 0x40!

Нашел ещё одну ошибку.
Теперь работает
Пока не выкладываю, программа ещё сыровата. Надо ещё тестировать и оптимизировать. Но если кто-то оперативно повторит схему, пишите - поделюсь, в состоянии "как есть". Заодно потестируете.

Проверял:
- i486DX2-66, чипсет Sis471, BIOS Award 4.50, родной KBC LT38C41,
- AMD 386DX-40, чипсет PC Chips "Chip 11", Bios AMI ver. 2.11, KBC Sa6042A

Драйверы разные, включая драйверы от A4, Genius, Microsoft.
Windows 3.11 сама "подхватывает" мышь, без всяких драйверов.
Остаётся проверить на Win9x.

Отрицательный момент. Win NT 3.51 мышь не видит. Хотя должна полностью игнорировать BIOS.
По всей видимости, ей не хватает размаскированного прерывания Irq12 и/или наличия мыши в списке оборудования в области данных BIOS 40:10h.

Код для размаскирования/добавления очень простой и короткий. Но не знаю, куда и как его вставить до загрузки Win.

i8088 написал:

[q]

найти DDK для NT3.51

[/q]

https://winworldpc.com/product/windows-sdk-ddk/nt-3x

Rio444 написал:

[q]

Мне видится более интересным вариант модификации MBR. Делают же это как-то вирусы?

Другие, возможные варианты:
- дополнение кода bios в ПЗУ,
- отдельное ПЗУ (например на сетевой карте).

[/q]

Все варианты возможны, кстати модификация BIOS для Award (если достаточно размаскировать IRQ12
итп, те есть отлаженный код) довольно простая.

Надо или внедрится в POST jump table (после настройки 8259, на место dummy,онми всегда есть)
Или добавить ISA module в BIOS, с помощью CBROM (это менее надежно).

[q]

С этим вопросом перекликается другой, очень интересный. Возможно ли создание контроллера PS/2 мыши на отдельной ISA плате?

[/q]

Основная здесь сложность (если не требовать спец драйвера, те если контроллер kbd+mouse по
стандартным адресам, и также минимум доработок платы), это полностью отключить встроенный
контроллер, те сть весь функционал переложить на ISA плату.

Возможно, достаточно изъять 8042 из панели, или если он запаян, организовать посоянно RESET или
отсутствие выборки #CS для него. (8042 - не совсем 8048, он специально предназначен для работы в
составе микропроцессорных систем, есть изменения, в виде наличия A0 и CS в частности).
Если он подключен к шине данных ISA без дополнительных буферов (типа LS 245, это легко
проверить), то изымания должно быть достаточно, тк вместо встроенного быдет выбираться внешний,
а дешифратор буден на ISA плате, те ситуации когда на шине ISA окажутся два устройства по одному
адресу, не должно быть.

upd.
В оригинальной AT буфер есть, отделяющий внутреннние устройства, от устройств на ISA. Тогда правильнее контроллер по нестандартным адресам, со своим драйвером.

Rio444 написал:

[q]

Не совсем понял, как это влияет?

[/q]

Даже если отключить контроллер KBC, буфер двунаправленный может быть будет
выбран при обращении к портам KBC, и будет передавать логические единицы на ISA.


Rio444 написал:

[q]

Помимо обслуживания мыши и клавиатуры, KBC, как минимум, управляет А20 Gate и программным Reset.

[/q]

Черт, я совсем забыл за это! Тогда да, полная замена KBC без проводов от ISA платы невозможна.


Rio444 написал:

[q]

Наверное, проще оставить существующий KBC, но отключать его, когда идёт обращение к портам 60h и 64h, выделяя команды для мыши и клавиатуры. Причем очень оперативно. Наверное, с помощью ПЛИС. Так, чтобы команды, связанные с А20 Gate и Reset продолжали работать.

[/q]

По моему это несколько громоздко и не очень надежно, опять таки не на всех платах 8042 в явном виде...

Мне все же кажется, правильнее делать платы по нестандартным адресам, со своим
драйвером, специально для мыши, это будет пригодно и для плат, где нет "настоящего" 8042.

Я тут почитал - ISA плата по стандартным адресам не будет работать,
тк чтение по адресам 0h -0ffh (при наличии устройства) не распрстраняется на шины расширения.


Rio444 написал:

[q]

Что если использовать плату, которая ОС будет видна как упомянутая выше "Bus Mouse"?
А фактически это будет переходник с "Bus Mouse" на PS/2 мышь.

[/q]

Насколько помню, Bus Mouse это просто несколько линий портов ввода-вывода, и запрос прерывания. В принципе возможно, только
такая мышь не может программироваться (если только в обработчике
OS это не имитируется возможностью изменения скорости итп), те это похоже на переход с клавиатуры AT
на XT Протоколы надо будет изучить очень тщательно, для написания
программы ля MK.

Только по скорости - не будет ли ситуации как с COM->PS2.
ISA конечно быстрее COM, но протокол BUS Mouse не вносет ли ограничения?

Win95 после запуска драйвера подхватила PS/2 мышь легко и непринужденно, причем ещё на этапе установки.

Поздравляю с написанием полезной программы!!

Осталось еще, что доделать, вопросы нерешенные итп?

Предлагаю в первом посте написать то, что достигнуто + фотки. Иначе 8 страниц - не осилю читать

Ekb написал:

[q]

Предлагаю в первом посте написать то, что достигнуто + фотки. Иначе 8 страниц - не осилю читать

[/q]

Наконец наступил этот "вечер", добавил в первый пост.

Поигрался вчера с Win95. Предполождения подтвердились.

Если исключить (или не включать) мышь в список оборудования по адресу 0040:0010h, то при загружке Win: "Мышь не обнаружена, COM мышь можете подключить прямо сейчас".

Если не размаскировать Irq12, то вроде всё нормально, мышь обнаруживается, Win загружается, но компьютер не реагирует ни на мышь, ни на клавиатуру. Выходной буфер 8042 заполняется, а освободать его некому. Irq12 не срабатывает, int 74h не вызывается.

Если "отключить" обработку Irq12 (int 74h), то мышь вполне себе работает. Что тоже логично. Было бы глупо, если бы Win из защищенного режима вызывала обработчик реального режима. То есть Windows полностью подменяет обработчик int 74h своим.
Правда, есть одно но. Если вы перезагрузите Windows в "режиме эмуляции MS-DOS", то штатный обработчик Windows работать не будет. Он работает только в защищенном режиме. Драйверы мыши тоже работать не будут.

Если отключить обработчик int 15h служб C200...C207, то происходит ровно тоже, что и в самом первом случае: "Мышь не обнаружена, COM мышь можете подключить прямо сейчас". Причем, Windows использует при загрузке все восемь служб, начиная с C200 и заканчивая C207. Если вместо любой из них поставить заглушку, возвращающую аппаратную ошибку мыши, то результат всегда одинаков.

Возвращаясь к вопросу Win NT. Конечно выяснившиеся обстоятельства несколько затрудняют задачу. Но после MBR следуют как минимум несколько свободных, ни под что не используемых секторов (в моём случает 63 по 512кБ), так что есть, где развернуться))))
Если найдутся желающие - велкам в личку. Поделюсь всеми наработками.

Rio444 написал:

[q]

Залил эпоксидным клеем.Залил эпоксидным клеем.Залил эпоксидным клеем.

[/q]

А с какой целью заливали то? Сопутствующие темы про эпоксидку читал...
Если шлейф отходящий зафиксировать - так его отдельно приклеить можно.
Если схему заизолировать - лак и кисточка в руки
Не в плане надежности Вашей схемы, но любое покрытие ремонтопригодность снижает

Rio444 написал:

[q]

Там есть очень ненадежные с механической точки зрения места

[/q]

Классическая эпоксидка конечно добавит толщины для прочности, но сама по себе она тоже вещь весьма хрупкая.
Был какой-то вариант для ремонта обуви, типа лопнувшие подошвы клеить.
Сам не пробовал, потому марку не подскажу, но от знакомых положительные отзывы слышал.
Клей именно на эпоксидной основне имелся ввиду...

Rio444 написал:

[q]

20, 38, 39, 40* ноги припаяны к дорожкам на краю платы,

[/q]

Это в любом случае штучное изделие.
Намотайте на ножку тонкий проводок, его и на плату заведите (а потом всё вместе пропаять).
Ну а в текущей ситуации ИМХО вопрос не в припое, а насколько крепко дорожка к плате держится.
Если при пайке не перегревать, то не оторвутся они. Вы же не советском гетинаксе делаете...

А можно фоточку реализации проводника между контроллером и ISA слотом? Или такого уже нет?

Обещанное фото.

Резистор не мой, был изначально.
Плата та же самая, что на фото выше.

IdeaFix написал:

[q]

Понятно. Ну и ISA слот при этом функционален.

[/q]

Конечно функционален.
И если вернуть назад обычную микросхему контроллера, всё работает как обычно.
Подключение Irq12 с ISA никак не мешает.
Более того, коллега с вогонс утверждает, что на всех его платах контроллер уже изначально подключен к IRQ12.
Либо я его неправильно понял.

круто! осталось подключить к usb... валяется у меня Cherry MХ5000 из далекого 1996 года.

Rio444 написал:

[q]

Что подключить?

[/q]

я неверно выразился. подключить АТ к USB, но это мало того, что совершенно отдельный контроллер так еще и далеко от темы СТАРЫХ плат, сорри я начал читать тему с конца.

Rio444, это все волна увлечения механикой. у меня периодически возникает идея допилить старушку черри

justontime написал:

[q]

[/q]

В первую очередь USB flash. Также мышь.

justontime написал:

[q]

Тогда не понимаю насчет требуемого жуткого быстродействия компьютера. Для USB flash уже есть адаптер

[/q]

Не вникал в этот вопрос.
Только на собственном опыте знаю, что если в USB воткнута флешка, в системах уровня Pentium I и даже старше, снижаются результаты тестов.
Если с этой флешкой производятся операции чтения-записи, расходуется значительный ресурс процессора.
Подобные отзывы слышал от других участников форума.

justontime написал:

[q]

Для мыши можно сделать плату на базе 5-долларового микроконтроллера (плюс, скорее всего, некоторая обвязка).

[/q]

Т.е. готовое устройство будет стоить не менее 10$.
В чем смысл, если за 100-200 руб. можно купить б/у оптическую PS/2 мышь, а за ~300 руб. новую или универсальную, с переходником?