а не слишком ли жирно для одной мыши-то?Цитата:
Сообщение от KTSerg
Вид для печати
а не слишком ли жирно для одной мыши-то?Цитата:
Сообщение от KTSerg
Мне представляются приемлемыми два варианта:Цитата:
Сообщение от Improver
1. Максимально простой, который KTSerg уже реализовал.
2. Его сравнительно простая адаптация с микроконтроллером, который возьмет на себя преобразования последовательный<->параллельный.
При этом в вектор передаются нативные данные с мыши, что является проверенным универсальным решением. Передавать абсолютные координаты с насыщением = ограничивать область применения мыши для копеечной экономии в тактах векторовского софта в части задач (и непреодолимых проблем в других задачах), это я уже повторяюсь. Компромиссным вариантом является добавление абсолютного режима в качестве дополнительного, программно переключаемого.
Ну так-то оно конечно ряха у мыши может и треснуть...Цитата:
Сообщение от UncleDim
Но если есть желание ускорить опрос мыши (контроллера) то как минимум два порта точно будут заняты, а если есть желание командовать мышью, и при этом нет желания переключать режим порта ввод/вывод, то снова будут заняты все три:
"А" вход - чтение данных из мыши
"В" выход - команды управления контроллером
"С" вход/выход - сигналы управления/состояния
Конечно, при подключении мыши без контроллера достаточно 4 бит порта "С". Но довольно большой расход ресурсов процессора на опрос мыши по последовательному интерфейсу.
не для этого ли придуман mode 2 в 8255, раз уж цепляем контроллер?Цитата:
Сообщение от KTSerg
Прав. Первые реализации мыши на Векторе так и работали, и были не очень удобны в этом плане, если не ошибаюсь -- где-то я видел об этом статью...Цитата:
Сообщение от KTSerg
Пока что у меня такая идея:Цитата:
Сообщение от KTSerg
- порты А и В -- координаты курсора, или эмуляция сигналов джойстика (УСПИД -- порт А, ПУ -- порт В и С). Ну или относительное перемещение, для страждущих.
- порт С, т.к. он позволяет разделить себя на два по 4 бита, использовать, например, так: на кнопки можно отдать 2 бита (10-"левая", 01-"правая" и 11-"средняя"), и два бита колесо и для режима 512 (0х -- бит для 512, 11 -- колесо крутится вверх, 10 -- колесо вниз). А вторые 4 бита использовать для управления, возможно управлять придётся передачей нескольких байт...
Ну это для примера, можно и по-другому всё распределить -- как будет удобнее.
Если контроллер не будет предполагать одновременного подключения с ROM-диском, джойстиками или чем-то ещё -- то не жирно. В любом случае весь разъём ПУ будет занят, нет смысла ужиматься в портах.Цитата:
Сообщение от UncleDim
- - - Добавлено - - -
Ограничений там не будет, можно реализовать всё, что угодно. И... "копейка рупь бережёт". :)Цитата:
Сообщение от ivagor
Когда-то давно, я искал инфу на этот режим работы. Но или не нашел, или не разобрался, или он не подошел для моих нужд... уже не помню.Цитата:
Сообщение от UncleDim
Точно знаю, что никогда этим режимом не пользовался.
Там для управления портом "А" чето много от порта "С" отгрызают... не знаю точно.
А если порт "С" будет занят управлением портом "А", то снова порт "В" понадобится.
Возвращаемся обратно к разбитому корыту, от чего уходили, к тому и вернулись.
Влажу в чужой диалог, но мне кажется ответ на этот вопрос уже был.Цитата:
Сообщение от ivagor
Перемещение карты или поворот перса осуществляется при выходе координат мыши за пределы карты или окна, при наличии бордюра или шторки (вокруг карты или окна). Либо смещение и разворот продолжаются до тех пор, пока координаты мыши имеют минимальное/максимальное значение. Соответственно для остановки смещения/разворота достаточно отодвинуть курсор мыши от края экрана. При таком варианте, для длительного смещения или разворота, даже мышкой не нужно двигать, достаточно подогнать курсор к самому краю экрана. Ну, это конечно софт должен понимать, чё нужно делать.
Ну это я так понял, возможно ошибаюсь.
Я задал два вопроса (по сути они одинаковые, вернее в их реализации при абсолютных координатах с насыщением одна и та же пробдема) и ответа на них я не видел.Цитата:
Сообщение от KTSerg
Да можно вобще курсором на клавиатуре двигать, я же не спрашивал как еще можно организовать интерфейс.Цитата:
Сообщение от KTSerg
- - - Добавлено - - -
Ладно ребята, если и автору железа и потенциальному программисту не понятно, что я пишу, наверно проблема во мне. Завершаю свое участие в данной теме, чтобы не засорять тему и не мешать.
Так А двунаправленным будет, с учетом трех свободных линий порта С - через А можно будет читать из контроллера хошь координаты, хошь приращения, хошь скан-коды,... и управлять контроллером через него жеЦитата:
Сообщение от KTSerg
Это и был ответ, извиняюсь за своё путанное описание, но KTSerg его выше совершенно правильно разъяснил, более подробно и не скажешь...Цитата:
Сообщение от ivagor
- - - Добавлено - - -
Я тут предложил несколько другой вариант -- там все порты однонаправленные могут быть.Цитата:
Сообщение от UncleDim
Честно говоря, я действительно не совсем понимаю о чём идёт речь, возможно я не представляю, что такое "при абсолютных координатах с насыщением", конкретно, что такое "насыщение" в данном контексте.Цитата:
Сообщение от ivagor
Думаю, для нового софта, нет проблемы получать от мыши готовые координаты курсора, и используя их, реализовать смещения и развороты.
Мне кажется, могут возникнуть проблемы, если захочется интегрировать мышь в уже готовый софт, в котором курсор может спокойно стоять на крайних координатах экрана, а смещение экрана инициируется через попытку сместить курсор за пределы экрана. Т.е. например стоит курсор в координате Х=0, а для сдвига экрана нужно нажать клавишу влево, т.е. попытаться сместить курсор за пределы экрана. Ведь контроллер мыши, выдающий готовые координаты не позволит такого сделать.
Вот интересно, есть-ли какой-то софт для Вектора, например графического редактора, в который можно было-бы попытаться интегрировать мышь, желательно без проблем глобального масштаба ?
В гаф. редакторах наиболее затратная по времени процедура, это заливка, интересно, во время заливки прерывания отключаются ?
- - - Добавлено - - -
Кстати о расположении мыши на "ПУ".
Вспомнился "сюрприз", обнаруженный мной в штатном загрузчике .02-го Вектора.
А конкретно, что в нём есть работа с ВВ55, расположенной по адресам F0-F3 (если кто-то не видел эту тему).
И раз в штатном ПЗУ эта ВВ55 используется, значит её можно считать "штатным железом". ;)
Перевесить мышь туда, и "ПУ" снова освободится...
Можно перевесить, но только на реалах там нет ВВ55А, надо будет ещё и её подключать.Цитата:
Сообщение от KTSerg
т.е. была уже достаточно широко распространенная периферия, так? а какая? любой новодел не должен по идее ей мешать..Цитата:
Сообщение от Improver
Если вопрос про использование ВВ55 на портах F0-F3, то кроме меня, вроде ни кто не сообщал, что где-то встречал упоминания об этом железе.Цитата:
Сообщение от UncleDim
Вот тема про его обнаружение:
https://zx-pk.ru/threads/28939-syurp...l=1#post954099
Если кратко, обнаруженный ВВ55 - это скорее всего аналог порта "ПУ", для загрузки ПО (32КБ) при старте Вектора, из альтернативного "внешнего ПЗУ".
Поскольку этот порт ВВ55 использовался в штатной прошивке, но в самом Векторе он отсутствовал, то можно предположить, что это был отдельный модуль, скорее всего, подключаемый к разъёму "ВУ".
Возвращаясь к нашей теме мыши... поскольку её подключение к разъёму "ПУ" ни как не влияет на работу Вектора при старте (опросе периферии на ПУ), то и перенос мыши на адреса гипотетически существовавшего (ВВ55) "внешнего ПЗУ", ни как не должно никому помешать.
При этом освободится разъём "ПУ" для подключения другого железа.
Да, переносу адресов мыши в этот диапазон никак не помешает (и поможет) наличие кода в загрузчике 02-го, но, чисто теоретически, в некий счастливый момент в результате археологических изысканий или новодела может появится тот самый картридж для ВУ, и вот тогда это может стать проблемой... Может просто выбрать и принять в качестве стандарта для мыши любой свободный диапазон портов, если уж решим освободить ПУ?Цитата:
Сообщение от KTSerg
Мне кажется, что если оставить от колеса прокрутки только признак/направление вращения, то это резко ухудшит его использование, поскольку "чувствительность" будет напрямую зависеть от частоты опроса мыши.Цитата:
Сообщение от Improver
Предположим, что мышь опрашивается в прерываниях, значит от колеса прокрутки получим максимум 50 позиций смещения за 1 секунду, тогда как при получении значения вращения, могли-бы за ту-же секунду теоретически получить до 350-ти позиций вращения.
Получается, что будет не важно, быстро крутил колесо, или медленно, больше 50-ти смещений не получишь. Приходим к варианту "мышь в режиме джойстика" - использовать можно, но не удобно :( нет пропорциональности, чувствительности к активности использования элементом управления :(
Не стоит забывать, что Вектор -- это не большой ПК, он просто физически не сможет обработать столько смещений. Если, допустим, на каждое смешение делать сдвиг текста на одну строку, то 10 смещений в секунду -- это максимум его возможностей (исходя из скорости вывода ~800 символов в секунду в лучшем случае).Цитата:
Сообщение от KTSerg
(полуOFF) есть мнение, что через ВУ можно "отобрать" у вм80 всё, все "потроха" Вектора (и, соответственно, "отдать" их кому-то более шустрому).Цитата:
Сообщение от Improver
Сдвиг текста - частный случай. В МикроДосе вообще применение мыши затруднено, так как курсор привязан к командной строке.Цитата:
Сообщение от Improver
Только в текстовых редакторах есть некая свобода.
Но я говорил про возможность использования в играх и в прикладных задачах, где нужно будет сдвинуть/изменить значение какого-то параметра. Вот тут и будет морока с чувствительностью.
- - - Добавлено - - -
Ну, скорее не "отобрать" а "перехватить" для возможной параллельной обработки.Цитата:
Сообщение от UncleDim
И не всё и не сразу.
Где-то было обсуждение, что в простом Векторе сталкивались с проблемой, с адресами внешних устройств, с адресами до 0Fh, а в 02-ом такой проблемы нет. Или я что-то путаю...
В общем не всё так однозначно.
Для колеса скорее частый. :)Цитата:
Сообщение от KTSerg
Для таких случаев, когда нужно точно знать, насколько и куда прокрутили колесо, можно сделать ещё один режим контроллера, например, так: когда зафиксировано вращение колеса в порт А пишется не координата мыши, а насколько был поворот -- в любом случае Вектор не сможет отслеживать и курсор, и колесо. Ну или выдавать данные по колесу на запрос отдельной командой в порт С, т.е. увидели бит, что колесо прокрутили -- запросили в С и считали из А куда и на сколько.Цитата:
Сообщение от KTSerg
Пока колесо крутится, не возможно будет узнать бит для 512 ?Цитата:
Сообщение от Improver
Да, получается так... Вообще, это ещё не стандарт, можно всё переиграть, например, сделать сообщения колеса как написал выше, а четвёртый бит использовать только для 512.Цитата:
Сообщение от KTSerg
Оказалось, что Арканоид, очень легко адаптируется для подключения мыши.
Конечно, в заставку не влезал, ни каких доп. меню, просто мышь дублирует клавиатуру.
Правда перемещение мыши пропорциональное, скорость движения каретки зависит от скорости перемещения мыши.
Если есть желающие... модифицированный Арканоид прикрепил к первому сообщению этой темы.
https://zx-pk.ru/threads/30224-vekto...=1#post1003249
Мышь PS/2 подключена к "ПУ" по схеме из первого поста, мышь по прежнему подключена в "разъём клавиатуры", т.е. в "ПУ" задействованы: РС1,РС2,РС5,РС7.
По поводу управления.
ЛКМ - дублирует "пробел".
ну и вправо/влево соответственно.
Перемещение мыши вверх/вниз - не обрабатывается.
ПКМ - делит скорость перемещения мыши на 2, каретка начинает двигаться со скоростью примерно как от клавиатуры.
СКМ - возвращает оригинальную скорость перемещения мыши, каретка начинает шустро бегать.
Вроде в теме про Пенсил только про Пенсилы разговор, а я тут про вообще. Что если все-таки приделать на ПУ последовательный порт с FIFO, а лучше два? Железно можно равняться на стандартный 16550, на практике можно его эмулировать микроконтроллером. Реалистично Вектор наверное сможет обрабатывать максимум 4800 бит/c (исхожу из глубины фифо и частоты прерываний Вектора).
"ПУ" довольно удобен для исследований железа, но на практике он уже слишком перегружен девайсами.Цитата:
Сообщение от svofski
Столкнулся с этим когда мышь к Пенсилу подключал. Там есть функционал вывода на принтер, а он как известно к "ПУ" подключен. Уже конфликт оборудования гарантирован.
С другой стороны, у "ПУ" конечно значительное преимущество перед другими вариантами подключения - это простота для повторяемости желающими, так как собрать схему подключения к "ВУ" значительно сложнее.
Но если с железным СОМ-ом заморачиваться, то лучше сразу его на "ВУ" вешать.
Я пока мышь ковырял, уже подумывал выделить отдельный порт и повесить его на "ВУ". На нём может висеть 4 линии эмулирующие выход с ОК. Хоть c ps/2 экспериментируй, хоть с i2c.
Я глубоко идейно поддерживаю этот тезис, но я уже один раз навешивал на "ВУ" и мне показалось, что это невыносимо затратная морока даже для одержимого фаната Вектора. Вероятность того, что устройство на "ВУ" будет реплицировано, если только это не ComboDevice, исчезающе мала. Поэтому я даже больше за примитивный PS/2 на ПУ как сейчас, чем за настоящий компорт на ВУ.Цитата:
Сообщение от KTSerg
Оптимистичный прогноз, а почему не 2400 бит/с ?Цитата:
Сообщение от svofski
Если что, уже делал попытки собрать com-порт для Вектора, но до практической сборки так и не дошло...
4800 бит/c ~ 480 байт в сек, делим на 50 получается 9.6 байт за прерывание. Получается, что FIFO глубиной 16 символов не будет переполняться, если не пропускать прерывания.Цитата:
Сообщение от KTSerg
Мышки по-моему работают на 1200.
- - - Добавлено - - -
Без буфера по-моему нет смысла пробовать.Цитата:
Сообщение от Improver
Можно сделать буфер на стороне контроллера -- в любом случае сейчас комовских мышей не найдёшь, надо как-то делать преобразование ps2 <-> com, там и добавить буфер.Цитата:
Сообщение от svofski
Да я понимаю.Цитата:
Сообщение от svofski
Тоже считал: 50 (прерываний в сек.) * 16 (байт, буфер fifo) * 8 (бит) = 6400 бит/с. Соответственно ближайший меньший стандарт 4800.
Было бы интересно прикинуть, максимально возможную скорость, которую может потянуть Вектор, если подключить 16550 к "ПУ", с учетом всех потерь на управление портом 55-ым.
Я ещё не изучал 16550, не знаю, нужно ли постоянно читать регистр статуса (необходимость постоянно переключать направление порта), чтобы узнать состояние буфера, или достаточно подключить выход "INTRPT" на вход порта "С", тогда часто переключать направление портов не нужно будет.
16550 это и есть UART с буфером. Я на всякий случай уточню -- что идея подключения компортовской мышки не столько ради упрощения, сколько ради обобщения. Если есть компорт, который Вектор может полноценно использовать, то к нему можно подключить мышь, а можно модем или терминал, или другой Вектор.Цитата:
Сообщение от Improver
Адаптер ps/2 на serial -- задача решенная уже много раз. Ну просто например: https://hackaday.io/project/27575-ps...ouse-converter. Но ps/2 в наше время тоже как-то уже грустно. Если б я сам загорелся идеей, я бы взял rp2040-zero и сделал адаптер USB-мышки и клавиатуры с помощью pico-pio-usb. Но я точно не буду.
Погуглил про СОМ-мыши.Цитата:
Сообщение от svofski
Подключать СОМ-мышь к Вектору не имеет ни какого смысла.
Если ps/2-мышь можно настроить, чтобы сообщала смещение только по запросу, то СОМ-мышь тупо шлёт данные при перемещении, не интересуясь, принимают эти данные или нет. Не нашел инфы, про интервалы между пакетами. Не понятно, как часто СОМ-мышь отправляет данные. Но подозреваю, что Вектор задолбается разгребать спам от СОМ-мыши.
- - - Добавлено - - -
Получается, что в случаях, когда программа не критична, что мышь ест 30% времени, подойдёт и простая в подключении ps/2.
На Арканоид я очень удачно наткнулся :) там ресурсы тратятся фактически только на перемещение каретки и шарика.
Для программ, более критичных к времени и размеру драйвера - ни куда не деться от контроллера, который будет работать с мышью, и готовить для Вектора данные, в виде, наиболее удобном для чтения/применения.
Что ж тут непонятного. 1200 7N1: 1200/9/50, значит за прерывание может прийти максимум 3 байта и это верхняя оценка с запасом.Цитата:
Сообщение от KTSerg
Микрософтовский протокол шлет обновления примерно 40 раз в секунду по три байта за посылку. Кнопки + два байта со знаком + битик синхронизации. Вот тут нарисована картиночка: https://roborooter.com/post/serial-mice/
Это как раз то, что самодельный контроллер все равно пришлось бы заставить делать, только уже сделано за нас.
У меня складывается впечатление, что за одно прерывание, 3 байта не успеют полностью приняться.Цитата:
Сообщение от svofski
Поскольку нет синхронизации в виде запрос/ответ, то должен быть дополнительный буфер принятых данных, из которого будут вылавливаться пакеты.
Почему-то не вдохновляет.Цитата:
Микрософтовский протокол шлет обновления примерно 40 раз в секунду по три байта за посылку. Кнопки + два байта со знаком + битик синхронизации. Вот тут нарисована картиночка: https://roborooter.com/post/serial-mice/
Это как раз то, что самодельный контроллер все равно пришлось бы заставить делать, только уже сделано за нас.
Делать СОМ-мышь из usb или ps/2-мыши, что-бы потом маяться со спамом данных, которые валятся без запроса.
Для интеграции мыши в игры, это слишком заморочисто.
Делать/использовать два контроллера для мыши, что-бы получить данные, на интерпретацию которых нужно дополнительно тратить ресурсы... мне кажется это перебор.
Разумеется нужен буфер. Я говорю с первого сообщения про буфер и в каждом сообщении повторно привожу его характеристики в расчетах.Цитата:
Сообщение от KTSerg
Я пожалуй сдаюсь. Разочаровался в своей способности излагать мысли.
А я то думал, что речь шла о fifo внутри 16550.Цитата:
Сообщение от svofski
Но его не достаточно, чтобы корректно принять данные от мыши. И я сказал, что дополнительно к fifo в 16550, нужен ещё один кольцевой fifo для корректного вылавливания пакетов.
Я именно о нем и говорю. Ты можешь объяснить почему его недостаточно для того, чтобы принять три байта? Тебя смущает то, что три байта будут приходить необязательно все вместе и их нужно складывать в программный буфер? Это тривиальная задача.Цитата:
Сообщение от KTSerg
Да, я предвзято отношусь у потоку данных СОМ-портов.Цитата:
Сообщение от svofski
Меня нервирует, что отправленный блок данных, может приходить кусками разной длины, а два отдельно отправленных блока данных, могут объединяться в приёмном буфере в непрерывную цепочку данных.
Это конечно не касается конкретно мыши, где блок всего 3 байта. Хотя и с ней будет точно так-же.
Но принимать даже эти несчастные 3 байта кусками в разных прерываниях, это тоже не фонтан.
Я понимаю, что вылавливать их не такая уж сложная задача. В конце концов, приняв 5 байт, мы гарантированно имеем один целый пакет, и его уже можно анализировать.
Просто не вижу в этом особого смысла. Зачем собирать два контроллера и потом возиться с дикой мышью, когда можно сделать сразу то, что нужно Вектору, что-бы освободить его от лишних хлопот, и получать от контроллера мышиные данные в нужном виде.
Поэтому я остаюсь приверженцем синхронизации, и получения только запрошенных данных.