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

[UncleDim]

все три порта "ПУ"

а не слишком ли жирно для одной мыши-то?

[ivagor]

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

Мне представляются приемлемыми два варианта:
1. Максимально простой, который KTSerg уже реализовал.
2. Его сравнительно простая адаптация с микроконтроллером, который возьмет на себя преобразования последовательный<->параллельный.
При этом в вектор передаются нативные данные с мыши, что является проверенным универсальным решением. Передавать абсолютные координаты с насыщением = ограничивать область применения мыши для копеечной экономии в тактах векторовского софта в части задач (и непреодолимых проблем в других задачах), это я уже повторяюсь. Компромиссным вариантом является добавление абсолютного режима в качестве дополнительного, программно переключаемого.

[KTSerg]

а не слишком ли жирно для одной мыши-то?

Ну так-то оно конечно ряха у мыши может и треснуть...
Но если есть желание ускорить опрос мыши (контроллера) то как минимум два порта точно будут заняты, а если есть желание командовать мышью, и при этом нет желания переключать режим порта ввод/вывод, то снова будут заняты все три:
"А" вход - чтение данных из мыши
"В" выход - команды управления контроллером
"С" вход/выход - сигналы управления/состояния

Конечно, при подключении мыши без контроллера достаточно 4 бит порта "С". Но довольно большой расход ресурсов процессора на опрос мыши по последовательному интерфейсу.

[UncleDim]

нет желания переключать режим порта ввод/вывод

не для этого ли придуман mode 2 в 8255, раз уж цепляем контроллер?

[Improver]

Периодически всплывает мнение, что мышь должна иметь возможность (восприниматься Вектором) работать как джойстик.
Честно говоря, я мало играл джойстиком, но мне кажется его преимущество, держать контакты замкнутыми, достаточно долго.
Тогда как у мыши, так не получится ни при каком раскладе. Так как эмуляция "нажатия контактов" зависит от физического перемещения мыши. Значит у "джойстика" из мыши будет постоянный "дребезг контактов". Приемлемо ли это?
Скорее всего это ограничит применяемость такой имитации.
Или я не прав?

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

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

Пока что у меня такая идея:
- порты А и В -- координаты курсора, или эмуляция сигналов джойстика (УСПИД -- порт А, ПУ -- порт В и С). Ну или относительное перемещение, для страждущих.
- порт С, т.к. он позволяет разделить себя на два по 4 бита, использовать, например, так: на кнопки можно отдать 2 бита (10-"левая", 01-"правая" и 11-"средняя"), и два бита колесо и для режима 512 (0х -- бит для 512, 11 -- колесо крутится вверх, 10 -- колесо вниз). А вторые 4 бита использовать для управления, возможно управлять придётся передачей нескольких байт...
Ну это для примера, можно и по-другому всё распределить -- как будет удобнее.

а не слишком ли жирно для одной мыши-то?

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

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

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

Ограничений там не будет, можно реализовать всё, что угодно. И... "копейка рупь бережёт".

[KTSerg]

не для этого ли придуман mode 2 в 8255, раз уж цепляем контроллер?

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

[Advertiser]

[ivagor]

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

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

[KTSerg]

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

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

[ivagor]

мне кажется ответ на этот вопрос уже был.

Я задал два вопроса (по сути они одинаковые, вернее в их реализации при абсолютных координатах с насыщением одна и та же пробдема) и ответа на них я не видел.

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

Да можно вобще курсором на клавиатуре двигать, я же не спрашивал как еще можно организовать интерфейс.

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

Ладно ребята, если и автору железа и потенциальному программисту не понятно, что я пишу, наверно проблема во мне. Завершаю свое участие в данной теме, чтобы не засорять тему и не мешать.

[UncleDim]

если порт "С" будет занят управлением портом "А", то снова порт "В" понадобится.

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