Вектор06Ц, клава и мышь PS/2 через "ПУ"

[svofski]

Один раз достаточно написать процедуры для ввода и вывода и следить больше не нужно.
Но по-моему 8255 уже дает все, что нужно как раз примерно для такого обмена: порт А в режиме 2 (двунаправленные данные), порт B в режиме 0 (адрес), порт C[3:7]- гандшейк для порта А.

[Advertiser]

[ivagor]

Мне кажется проще выделить один порт на запись, а другой на чтение, чтобы не заниматься двунаправленным обменом через A. Или для экономии портов (и возможно совместимости с другими устройствами подключенными к ПУ) все же переключать направление обмена, для мыши и клавиатуры это сравнительно малозатратно.

[PPC]

Должно быть просто и быстро. Направление настраивается один раз и больше не трогается. Думаю, при разумно сделанном контроллере, фулл даплекс режим нибблов порта C вообще будет не востребован. Кидаем номер регистра в порт (A или B) настроенный в режиме запись потом либо туда же пишем Дату Туташхию либо читаем данные из порта (B или A) настроенного на чтение. На запись получается регистр-секвенсер. На чтение, 2 разных порта. Не стоит направления переключать. Это лишние такты проца. Итого 256 регистров. Их разрядность можно оговаривать, но в первом приближении, пусть будут все по 8 бит.

ЗЫ. Биты третьего двунаправленного порта можно завести под status/control самого контроллера. Типа:
ожидание чтения (данных)
ожидание записи (данных)
keep in reset
discard command (типа игнорировать последний выбранный регистр).

Но это плюшки уже

[svofski]

Дату Туташхию

Оценил

[KTSerg]

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

[Improver]

будет-ли он полностью совместим с уже существующим стандартом джойстика по подключению и управлению

Правильное замечание. Можно и нужно сделать возможность переключения контроллера в режим такой совместимости, кнопкой и/или программно.

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

[KTSerg]

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

Всё будет зависеть от того, как будет реализовано общение контроллера с мышью и с Вектором.

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

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

Вот какие-то такие мысли в голову лезут...

[ivagor]

Контроллер должен сам регулярно опрашивать мышь и копить приращения по X и Y (и желательно колесо). Если при обращении вектора текущее накопленное приращение больше байта, то нужно выдать максимум и вычесть его из накопленного приращения.

- - - Добавлено - - -

Кстати, использование контроллера с накоплением в нем приращений позволяет вектору опрашивать мышь не по прерываниям.

[Improver]

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

[KTSerg]

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

Ну, это просто может быть одной и плюшек, т.е. для "координат курсора" просто отдельные "регистры" контроллера выделить.
Если к девборде есть исходники хаба для usb-мыши/клавы, то думаю именно usb имеет смысл юзать, а не ps/2.
Хотя, судя по реализации на длугих железках, usb реализован на прерываниях, можно наверное и от Вектора запрос потерять.
Для принятия таких решений, нужно конкретное железо знать/ковырять.