Адаптер мыши PS/2 в стандарт мыши Марсианка

[reddie]

Можно же опрашивать нормально, а не раз в кадр. Весь опрос -- BIT+BNE, это около полусотни тактов. Примерно четверть экранной строки. Мелочи. Можно хоть каждую десятую строку опрос делать

Можно, вот только в реальной программе, загружающей проц, скажем, игра с кучей графики либо прога с активными расчетами, проблематично вырывать проц из середины таких вычислений/процедур. Это не вывод курсора мышки раз в кадре и последующий "афк" с циклическим опросом, пока проц ничем другим не занят. Прерывания от мыши решают эту проблему, но возникает другая, со стеком:

что значит -- "прерывания портят стек", с чего бы это? И что значит "использовать стек, как регистр"?

Вот это и значит. На БК можно юзать SP не по прямому назначению, а в качестве обычного регистра, если стандартных R0-R5 не хватает. Да, это требует запрета прерываний или, как минимум, кусок кода должен успеть восстановить SP до их прихода. Что вполне реально между 50Гц кадровыми, но в случае непредсказуемых мышиных прерываний невозможно. А применяется такой приём не так уж и редко. В основном, конечно, в демках, но что мешает задействовать SP в играх, если это ускорит работу? В таком случае опрос мыши допустим только по КС, что в случае Марсианки фактически лишено смысла.

И ещё: к Марсианке можно приделать переходник на реверсивных счётках с сохранением совместимости с оригинальным интерфейсом. Который будет снимать проблему с потерей импульсов.

Так это и планируется, чтоб имеющие оригинальную мышь могли её превратить в "кемпстон-мышь", пусть и с некоторыми потерями (нет колеса скролла и лишь две кнопки вместо трёх). Собственно, моя схема и есть набор счётчиков плюс кой-какая логика, обычная пассивная мышь от Амиги/Спектрума работает в ней напрямую. Для Марсианки же придётся добавить формирователь сброса после "двига" мышой, в остальном схемы идентичны. Если бы для БК сразу сделали такой контроллер, наподобие Nippel Card для Агата, сейчас не пришлось бы изобретать велосипеды по даунгрейду PS/2 мышей в убогое поделие под названием УВК.

пока устроит варант с эмуляцией марсианки из PS/2 мыши, это гораздо быстрее реализовать, и полезно будет и для БК и для Агата

Как вариант закоса под оригинал - да, имеет право на жизнь. Но по функционалу я уже прошелся =)
Народ просто не понимает всей выгоды, что объяснимо, т. к. пользовались лишь тем, что было. Это как у Жванецкого: "для советского гражданина, не носившего импортные ботинки, и наши ботинки - вот такие! " (большой палец вверх)

[Advertiser]

[electroscat]

Как вариант закоса под оригинал - да, имеет право на жизнь. Но по функционалу я уже прошелся =)
Народ просто не понимает всей выгоды, что объяснимо, т. к. пользовались лишь тем, что было. Это как у Жванецкого: "для советского гражданина, не носившего импортные ботинки, и наши ботинки - вот такие! " (большой палец вверх)

Цена копии "марсианки" и скорость ее изготовления на несколько порядков ниже новой версии мыши как для БК так и для Агата. Не заю как на БК, а на агат точно никто софт править не будет, в сообществе фанатов Агата все очень архаично и консервативно, по этому там лучше просто повторить реальные девайсы, максимум используя для них мышь PS/2. На счет БК судить не берусь, но вроде у БК программеров и без того заделы на будущее необьятные, вряд ли они горят желанием вставлять новые драйвера в софт из прошлого. Ну и по Жванецкому, если "наши" ботинки можно купить с зарплаты несколько пар, а на "импортные" копить десять месяцев,.... При всем при том, что и в "наших" и в "импортных" в целом ходить реально, примерно с такой же скоростью и с такими же усилиями... то возникает вопрос, зачем нужны импортные ?!?

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

Попробовал скомпилить скетч из первого сообщения под NodeMcu V3 - другого ничего нет... И не завелось. Не знаю в чем проблема, есть подозление что ардуино подпорченное, ибо 6,7,8 и 11 пинами не смог управлять при проверке (запускал на каждый из пинов меандр, типа помигать диодом, перебором пинов при компиляции, когда компилил на 6,7,8 и 11 пины такой же эффект как при запуске "перепининного" скетча для эмуляции Марсианки, раз в секунду в ком порт выводится информация и все.., когда меандр выводится, то есть программа работает - в COM информация не выводится.), програмки которые должны были выводить на эти пины меандр, не завелись. В целом, я вообще не специалист по ардуино, это вторая поделка на платформе, и первая не завелась, точнее не заработала как следует,. По этому таки подозреваю, что моя платка не исправна.
Из этого возникает вопрос, предже всего наверное к автору темы, под какую ардуину писался скетч ? То есть, какой наиболее подходящий девайс заказывать под опубликованный скетч ?

Прошу прощения за оффтоп, наверное нужно к ардуинщикам обратиться )))

[Sandro]

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

Не мешают. Кстати, я посчитал. Проверка на движение мыши занимает 64 такта и ноль регистров.

Вот это и значит. На БК можно юзать SP не по прямому назначению, а в качестве обычного регистра, если стандартных R0-R5 не хватает. Да, это требует запрета прерываний или, как минимум, кусок кода должен успеть восстановить SP до их прихода.

Можно. Но редко нужно. Хотя я совсем недавно так делал. Кстати, без запрета прерываний и гонки с лучом. А потом переписал так, что остались свободные регистры и стало быстрее. Так что этот частный случай не являетсся серьёзным аргументом.

Что вполне реально между 50Гц кадровыми, но в случае непредсказуемых мышиных прерываний невозможно. А применяется такой приём не так уж и редко. В основном, конечно, в демках, но что мешает задействовать SP в играх, если это ускорит работу? В таком случае опрос мыши допустим только по КС, что в случае Марсианки фактически лишено смысла.

Так это и планируется, чтоб имеющие оригинальную мышь могли её превратить в "кемпстон-мышь",

Не это. Кемпстон не нужен. Можно отложить чтение мыши на попозже, совсем нехитрым способом. И не изменяя ни строчки в софте.

[electroscat]

под Агат, между прочим, есть вменяемый "родной" олдскул контроллер под Марсианку, если интересует работа на нём. Почитать про него и мышу можно на сайте по Агатам: http://agatcomp.ru/agat/Hardware/Key_Joy/MouseUVK.shtml там и схемы, и все техническо-софтовые подробности. Другое дело, что сейчас и мышка, и сам этот контроллер перешли в разряд музейных эспонатов. Но контроллер можно спаять самому из той же рассыпухи, что и исходный, а вот где взять пассивную мышку... довольно легко переделываются шариковые PS/2, если у кого завалялись. А главное - под этот контроллер на Агате есть софт.

Про Агат я в курсе, там идея шире, реализовать на одной плате контроллер мыши от Nippel и часы реального времени, и чтобы не отходить от стандартного решения, тоже желательно получить эмуляцию "марсианки"... Работать это правда будет только на Агате 9, т.к. за основу возьмется контроллер от Nippel, и часы от них же, а все это только на А9 работает. Да и в целом, я на Агате 7 не видел ни одного приложения с использованием мыши, а для Агат 9 много.

Меня все таки пока устроит варант с эмуляцией марсианки из PS/2 мыши, это гораздо быстрее реализовать, и полезно будет и для БК и для Агата.

[reddie]

я посчитал. Проверка на движение мыши занимает 64 такта и ноль регистров

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

Можно отложить чтение мыши на попозже, совсем нехитрым способом. И не изменяя ни строчки в софте

Только за тридцать лет почему-то никто это не осуществил.
Имею в виду полноценную мышь, а не УВК.

Цена копии "марсианки" и скорость ее изготовления на несколько порядков ниже новой версии мыши

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

[electroscat]

Ну и где же они, дешёвые мыши для БК, наводнившие рынок?

Если я разберусь с ардуино, то можно будет подключить обычную ps/2.. при цене ардуино в 300 рублей и ps/2 мыши в 100- весьма себе альтернатива...

[reddie]

Если я разберусь с ардуино, то можно будет подключить обычную ps/2.. при цене ардуино в 300 рублей и ps/2 мыши в 100- весьма себе альтернатива...

Плюс цена разъёма СНП, не в воздухе ж оно будет висеть возле компа =)) вполне вариант, почему б нет.
Внизу страницы, где предложения схожих тем, есть топик об адаптере PS/2 мыши для Коммодора. Тема аж 2009 года, устройство уже тогда было. Неужели Коммодор, который ни я, ни кто-либо ещё из друзей-знакомых в моём городке в глаза не видел, популярнее БК?

[electroscat]

Да, с моей ардуинкой что то не так, на всех распиновках пины 6,7,8,11 присутствуют, и должны использоваться, а в моей их нет, и по мимо этого, вместо того который по схеме 6й - работает скетч, скомпилированный на 10 пин.. В общем, закзал несколько Arduino Nano, они максимально близки к оригиналу, оригинал был на Меге 328p. Получу - продолжу исследования. Покупать в россии по 600р - то что можно купить в китае за 350 - не намерен, подожду пару - тройку недель... И понятно стало теперь, почему не завелся предидущий проект, проверяйте соответствие "пользовательских" пинов на китайских платках ))

[electroscat]

Пришли ардуинки, скомпилил скетч, чутка его по пинам переделал, ну то такое.. Ввел резет в ардуино, но пока с ним ничего не делаю. А придется. Ибо мышь, скорее всего из за отсутствия координации с БК имеет всего 3 положения по вертикали и 5 по горизонтали. Ну и по факту работает примерно как джойстик, только джойстик имеет одно по факту положение по горизонтали и вертикали, из за того, что я не могу так быстро нажать и отжать его по оси )))... Прилагаю видео сего факта (мыши из ардуино), и прошу немного направить... Вопрос в чем, вот приходит на марсианку резет, сбрасывает триггеры в ноль. В этот момент происходит перемещение, содержимое триггеров меняется, и сохраняется таким до следующего резета, правильно я понимаю? Или например, движение в другую сторону может поменять содержимоне триггеров и без резета? Ну и сам драйвер мыши на БК, как он работает? Вот он послал резет, и сразу после этого снимает биты порта, и потом не обращается в порт до следующего резета, или как то по другому? Может кто то подробненько и кратенько помочь ?

Ссылка на видео о работе мыши тут...

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

На сколько я понимаю, нужно по сигналу резет создать прерывание, по которому нужно сбросить выходы X+\- и Y+\- в нули, и следующим шагом дать туда текущее значение снятые с мыши, и потом до следующего резета все это зафиксировать? Правильно я понимаю ?

[reddie]

движение в другую сторону может поменять содержимоне триггеров и без резета

Исходя из схемы - все четыре направления (вверх/вниз/влево/вправо) могут быть активированы одновременно.
То бишь повозив мышу без ресета, получим четыре единички, и корректная процедура опроса, получив такие "координаты", курсор вообще двигать не станет.
На практике же это маловероятно, т.к. частота опроса куда больше, чем физическая реальность успеть дернуть мышу в обе стороны между сбросами.

драйвер мыши на БК, как он работает? Вот он послал резет, и сразу после этого снимает биты порта

Ну, начать стоит с разделения на опрос по прерыванию от мыши (через блок КМ) и без прерывания. Какой вариант планируется эмулировать?
Если с прерыванием от мыши - вызов драйвера означает, что мышь сдвинули. Читаем данные и следом посылаем сброс. Все, диалог с портом окончен (упрощенно).
Если без прерывания от мыши (по таймеру или другим способом) - читаем данные и посылаем сброс, только если есть изменения (был сдвиг).
Иначе постоянный сброс (дерганье бита в порту) будет создавать пищание в ковоксе на тех машинах, где он подключен.

по сигналу резет создать прерывание, по которому нужно сбросить выходы X+\- и Y+\- в нули, и следующим шагом дать туда текущее значение снятые с мыши, и потом до следующего резета все это зафиксировать?

Не совсем. Прерывание возникает по факту сдвига мыши (вариант с подключением через КМ) или не возникает вовсе (напрямую в порт УП).
Вызванный прерыванием или другим способом драйвер должен считать данные, обработать, послать сброс в порт, если было прерывание, - либо см выше.
Обратно ничего посылать не нужно, это физически разные порты. Да, есть блок нагрузок для замыкания, но с ним мышь вообще не заработает, насколько понимаю.


Все это мысли теоретика, ибо вживую с мышью не работал =)) Но освоенная информации по БК дает повод думать, что все изложено верно.
И еще: шина в БК инверсная, то бишь единички это ноли и наоборот. Как на входных портах, так и на выходных. Думаю, это тоже важно.