Просмотр полной версии : Speccy mouse
Splinter
09.08.2005, 07:37
Есть интересная тема. Можно придумать что нибудь с оптической мышью, что бы подключить ее к спеку как кемпстон мышь, желательно работающую с обычным драйвером Kempston Mouse ?
Оптическая она или механическая разницы нет.
А для ZX-MultiCARD это также справедливо?
А для ZX-MultiCARD это также справедливо?
Следует наверное ответить более расширенно. Принцип действия мыши не имеет значения если вести связь по стандартному интерфейсу, а не через припаивание проводников к оптопарам. На PC, а мышь от другой платформы вам вряд-ли удасться достать, есть 4 типа интерфейсов:
BUS-Mouse - пассивная мышь, найти уже крайне сложно, но подключается в сущности проводками к оптопарам;
COM-Mouse - активная, встречаются и с колесиком, к сожалению программно-аппаратной поддержки на Спектруме практически не имеет (только в Профи);
PS/2-Mouse - активная, наиболее распространенная, и теперь благодаря Caro, еще и поддержанный, как Kempston-mouse, девайс. 90% продаваемых мышей (шариковые, оптические, с и без колесиков) имеют именно этот интерфейс. Так что его и следует использовать, IMHO;
USB-Mouse - активная, но ввиду сложности поддержки, да и цены самой мыши, не поддержанная (да и ненужно это) мышь.
И в Скорпионовском контроллере клавиатуры есть ее поддержка.
Я когда то в Фидо кидал схему подключения COM-mouse на основе AT89C2051.
Могу кинуть и сюда, но думаю это уже не актуально.
Почему же, очень даже интересно, ну хотя-бы в познавательных целях.
Скорее не сложности а дороговизны, поскольку для ее подключения нужен HOST-контроллер, например SL811HS, стоимость которого порядка 150 р.
Ну, а сигналы самого HOST-контроллера, помимо этого надо "перелопачивать" в сигналы Kempston-mouse. В общем сложно, дорого и ненужно.
Ну, а сигналы самого HOST-контроллера, помимо этого надо "перелопачивать" в сигналы Kempston-mouse. В общем сложно, дорого и ненужно.
Ну уж пардон, при цене усб-хоста в 150р это далеко не 'дорого'! Я бы сказал, что это просто дёшево. Хотя небось это 'чудо' не решает софтово-протокольных проблем, так что трах в полный рост.
Возможно и другие программы, разработанные до последнего
времени не будуть корректно работать с таким контроллером.
Какие будут предложения?
Предложения такие - колесу быть по-любому! И пофиг на глюкодромы, в нормальных прогах мыша включается принудительно! =)
С т.з. удобства для кодера - чем больше битов под колесо, тем лучше. Например, 7 или вообще 8.
Какие будут предложения?
Камиль как прописать новую прошивку на твоем контроллере?
чем больше битов под колесо, тем лучше. Например, 7 или вообще 8
IMHO, избыточно. Колесико крутится пальцем и много импульсов за период опроса насчитано не будет. Кроме того в ситуациях когда колес будет >1 или кнопок >3 порты могут еще и пригодиться.
Можно с помощью программы FBPRG через LPT порт IBM-ки.
Надо будет только спаять шлейфик от LPT к ISP-разьему контроллера.
Схему шлейфа кинь мне плиз если не сложно! Ну или суда!
IMHO, избыточно. Колесико крутится пальцем и много импульсов за период опроса насчитано не будет.Тут я согласен, 4-х бит конечно вполне достаточно.
Кроме того в ситуациях когда колес будет >1 или кнопок >3 порты могут еще и пригодиться.Для двухколесных мышей в IBM-ском стандарте прописано, что одно из колес дает изменение на один бит, другое на два.
Посколку обычно одновременно их не крутят, так можно их распознать.
Кнопок больше трех я думаю нет смысла закладывать.
Кнопок больше трех я думаю нет смысла закладывать.
По большому счету согласен, но если они будут наличествовать, то и поюзать захочется. Как вариант, можно реализовать программное перенаправление дополнилельных клавиш на горячие клавиши (комбинации) CS+1, CS+0, Space и т.п.
Как вариант, можно реализовать программное перенаправление дополнилельных клавиш на горячие клавиши (комбинации) CS+1, CS+0, Space и т.п.В портах мышки то их куда выдавать - на биты порта #FEDF?
Тогда надо с этим определится.
Пока я в порт #FEDF выдаю все единицы.
В без-контроллерной схеме подключения доработанных мышей,
этот порт дублирует содержимое порта #FADF.
Э...э... Народ! Давайте выдвать туда же, куда и левую и правую кнопки! Скажем на 01bit это у нас - lmb/rmb дальше идет mmb, wheelup, wheeldown и все. Какие проблемы? Ведь колесико крутится с щелчками, которые и есть типа нажатия на типа кнопочку. Правильно я дмаю ? И поддержать это - лёхко!
Схему шлейфа кинь мне плиз если не сложно! Ну или суда!
байтбластер не канает чтоль? сам атмели чем пишешь?
В принципе есть еще свободный порт #FEDF можно туда выводить информацию от колеса.
тут один момент, он касается не железа, а программ, которые будут использовать колесо:
в некоторых схемах мыши, порт #fedf идентичен порту кнопок. т.е. новые программы должны будут учитывать этот момент, скажем недостаточно проверить #fedf<>#ff для обнаружения колеса.
вообще вопрос конечно спорный куда и сколько битов выводить, но все уже обсуждалось в фидо давно и под вариант с кнопочным портом вроде даже есть софт, и более того кажется есть плугин для shalaev'a с такой поддержкой
байтбластер не канает чтоль? сам атмели чем пишешь?
Пишу , но тут другое дело, ибо у меня Камилевская мышь уже есть, а ISP у Атмела немножко другой.
IMHO, избыточно. Колесико крутится пальцем и много импульсов за период опроса насчитано не будет. Кроме того в ситуациях когда колес будет >1 или кнопок >3 порты могут еще и пригодиться.
Нифига не избыточно! В самый раз! На надо будет гонять биты по аккумулятору и расширять знак! Взял новое, взял старое, вычел, получил знаковое смещение. А с 4 битами? Двигать и знаки расширять... Нафик.
Э...э... Народ! Давайте выдвать туда же, куда и левую и правую кнопки! Скажем на 01bit это у нас - lmb/rmb дальше идет mmb, wheelup, wheeldown и все. Какие проблемы? Ведь колесико крутится с щелчками, которые и есть типа нажатия на типа кнопочку. Правильно я дмаю ?
Неправильно. Самое простое - когда колесо 8 битами в отдельном порту сидит. Всё остальное - экономия на спичках для хардварщика и лишняя головная боль для каждого кодера, кто колёсико поюзать захочет.
Прошивка v.3.1 для контроллера мышки на базе AT90S2313.
-------------------------------------------------------
1. Работает с любыми мышками PS/2.
2. Эмулирует Кэмпстон-маус.
3. Автоматически распознает подключение 3D-mouse.
4. При подключении обычных мышек выдает в порты:
#FADF - <1111>1<MS><LS><RS>
#FEDF - то же самое
#FBDF - <X-8бит> (вправо увеличение кода)
#FFDF - <Y-8бит> (вверх увеличение кода)
5. При подключении 3D-mouse:
#FADF - <Z-4бита>0<MS><LS><RS>
#FEDF - <11111111>
#FBDF - <X-8бит> (вправо увеличение кода)
#FFDF - <Y-8бит> (вверх увеличение кода)
6. При одновременном нажатии левой и правой кнопок
их привязка к битам порта #FADF меняется местами.
Примечание:
1. <MS> - средняя кнопка;
2. <LS> - левая кнопка;
3. <RS> - правая кнопка;
4. При не нажатой кнопке 1, иначе 0.
-----------------------------------------------------------
пост со схемой:
http://zx.pk.ru/showpost.php?p=1602&postcount=7
прошивка:
http://zx.pk.ru/attachment.php?attachmentid=2126
Самое простое - когда колесо 8 битами в отдельном порту сидит. Всё остальное - экономия на спичках для хардварщика и лишняя головная боль для каждого кодера, кто колёсико поюзать захочет.
8 бит это расход "железных" ресурсов, как непосредственно микросхем (если это делать не на контроллере), так и на портах. В самих пакетах передаваемых от мыши под колесико отведено 4 бита.
А вот растрачивать "железные" ресурсы, потому что "головная боль" это уж извените...
Для контроллера мышки, выполненного на AT90S2313
написал прошивку, которая позволяет работать с мышками
стандарта Microsoft Intellimouse, тоесть с колесом.
Отображение информации о колесе производится в 4-х
старших битах порта #FADF (вроде так договорились).
Я уже не помню в чём суть, но этот вопрос поднимался
в fido7.real.speccy ещё дцать лет назад и пришли к консенсусу по данному вопросу в контексте плюрализма мнений... Желающие
в гугле могут найти абсолютно всё.
Порт #FADF -- это кнопки? Да, вроде, именно так.
Для того, что бы можно было в программе на Спектруме
отличить мышку с колесом от обычной мышки заложил
признак типа в бит 3 этого же порта.
Если бит 3 = 0, мышка с колесом, иначе обычная.
Сразу столкнулся с проблемой. Boot от SMT, который
входит в состав его эмулятора, мышку с колесом
игнорирует. Как оказалось при запуске он проверяет
старшие 5 бит порта #FADF и если они не 1, считается
что мышка не подключена.
Значит это кривой бут. Потому как на счёт алгоритма
определения наличия мыши или её контроллера давно
и чётко сказано: ОПРЕДЕЛИТЬ НАЛИЧИЕ МЫШИ
_НЕВОЗМОЖНО_.
НЕВОЗМОЖНО!!!.
Возможно только определить её отсутствиет. То-есть можно
для какой-то конфигурации сказать: мыши точно нет. Или можно
сказать: мышь, возможно, есть. А есть ли она точно сказать нельзя.
Поэтому предлагается простое решение -- если мышь возможно существует, то она включается. Иначе -- отключается. А если
мыши в действительности не существует, но она включена (возможно существует) -- ни к чему страшному это не приведёт. Потому как
автоопределитель определяет возможность наличия мыши по двум
простым фактам:
1. Мышь стоит на месте.
2. Кнопки отжаты.
(3. Колесо не крутится).
При описанных выше условиях отсутствие мыши ничему не мешает.
Из сказанного следует ещё одна вешь: назначение бита 3 не определено, но опять же ВОЗМОЖНО это кнопка.
Следовательно -- должна быть отжата.
Возникает вопрос -- как отличить мышь с колесом от мыши без
колеса. А никак. Отсутствие колеса никому не мешает -- оно ж
не крутится.
Тут ещё сейчас прозвучат предложения, давайте выведем колесо
на 8-битный порт. Это чушь и абсолютный бред. 4-х бит более
чем достаточно. Достаточно, в действительности, 2-х событий
поступающих от колеса (менее 2-х бит): движение вперёд и
движение назад. Вряд ли юзер сможет крутить колесо со скоростью
50 событий в секунду. А уж 16*50 -- точно не сможет.
Возможно и другие программы, разработанные до последнего
времени не будуть корректно работать с таким контроллером.
Какие будут предложения?
bit3=1. И зарезервировать под 4-ю кнопку. А что -- на моей все 5
есть и ещё колесо.
Неправильно. Самое простое - когда колесо 8 битами в отдельном порту сидит. Всё остальное - экономия на спичках для хардварщика и лишняя головная боль для каждого кодера, кто колёсико поюзать захочет.
Да что там 8-битами, давайте сразу аппаратный скроллер и аппаратный же курсор. Остальное всё фигня... Чего на спичках
экономить.
А на самом-то деле. Кондратьевскую схему контроллера помнишь?
Вот и найди там место под лишний порт. И 4-битный счётчик
проще поставить один, чем каскад из двух. Когда это нафиг не нужно.
А сделать авто-загрузку через спектрум никак?
... на счёт алгоритма
определения наличия мыши или её контроллера давно
и чётко сказано: ОПРЕДЕЛИТЬ НАЛИЧИЕ МЫШИ
_НЕВОЗМОЖНО_. Что касается BOOT от SMT, то пожалуй там сделано по принципу
- если в порту кнопок старшие 5 бит = 1, значит ВОЗМОЖНО контроллер мышки установлен.
При этом проверяются и клавиши клавиатуры и порты мышки.
А иначе проверяется только клавиатура.
Правда в этом случае такой boot не примет контроллер с колесом.
bit3=1. И зарезервировать под 4-ю кнопку. А что -- на моей все 5
есть и ещё колесо.Пожалуй это разумно.
По-моему в данном случае нужно реализовывать технологию Plug & play. В контроллере SMUC уже пытались решить эту проблему путем установки номера версии в двух портах. Но мне этот способ не нравится тем, что в некоторых компьютерах с не жесткой дешифрацией портов, из портов версии можно считать всё, что угодно, хотя самого контроллера и нет.
8 бит это расход "железных" ресурсов, как непосредственно микросхем (если это делать не на контроллере),
1-2 мсх погоду сделают? Чай не китай и не миллионные тиражи.
так и на портах. В самих пакетах передаваемых от мыши под колесико отведено 4 бита.
Вот заодно и есть чем заняться контрольнику - до 8 бит довести.
А вот растрачивать "железные" ресурсы, потому что "головная боль" это уж извените...
Аргументируй?
Тут ещё сейчас прозвучат предложения, давайте выведем колесо
на 8-битный порт. Это чушь и абсолютный бред. 4-х бит более
чем достаточно. Достаточно, в действительности, 2-х событий
поступающих от колеса (менее 2-х бит): движение вперёд и
движение назад. Вряд ли юзер сможет крутить колесо со скоростью
50 событий в секунду. А уж 16*50 -- точно не сможет.
4 и 2 бита - чушь и абсолюный бред. Ведь более чем достаточно 1 бита.
Да что там 8-битами, давайте сразу аппаратный скроллер и аппаратный же курсор. Остальное всё фигня... Чего на спичках
экономить.
Давайте. Может хоть тогда граф. система спека приблизится хоть чуть-чуть к ц64.
А на самом-то деле. Кондратьевскую схему контроллера помнишь?
Вот и найди там место под лишний порт. И 4-битный счётчик
проще поставить один, чем каскад из двух. Когда это нафиг не нужно.
Я помню схему, где контроллер работает с мышой и пишет 3 байта в 3 ИР22. Которые при помощи ровно одной ИД7 читаются компом (сам такое делал). И мне было бы совершенно не в падлу припаять 4ую ИР22, чтобы выводить в неё колесо.
Я помню схему, где контроллер работает с мышой и пишет 3 байта в 3 ИР22. Которые при помощи ровно одной ИД7 читаются компом (сам такое делал). И мне было бы совершенно не в падлу припаять 4ую ИР22, чтобы выводить в неё колесо.
Ну да. Всего лишь переразвести плату и собрать всё заново. При том что
оно не лезет теперь в существующий габарит...
Что касается BOOT от SMT, то пожалуй там сделано по принципу
- если в порту кнопок старшие 5 бит = 1, значит ВОЗМОЖНО контроллер мышки установлен.
При этом проверяются и клавиши клавиатуры и порты мышки.
А иначе проверяется только клавиатура.
А допустим это так. А в порту координат мышь хаотически катается.
Если она возможно включена будет в программе, юзер не сможет
ей пользоваться. Вон в PROFI было как: вместо мыши читались
часы (512ВИ1).
Правда в этом случае такой boot не примет контроллер с колесом.
Пожалуй это разумно.
Это дико неразумно. Давно уже разобрали вопрос со всех
сторон. Начилие мыши определить невозможно. Если программа
пытается это делать -- проблемы будут, однозначно.
4 и 2 бита - чушь и абсолюный бред. Ведь более чем достаточно 1 бита.
Недостаточно. Есть 3 состояния или сигнала: колесо катится вперёд,
колесо катится назад, колесо стоит на месте. Итого 2 бита -- вот их
действительно достаточно при соответствующей частоте опроса.
bit3=1. И зарезервировать под 4-ю кнопку.
Пожалуй это разумно.
Это дико неразумно.Я имел ввиду оставить bit3 порта #FADF для дополнительной кнопки.
Недостаточно. Есть 3 состояния или сигнала: колесо катится вперёд,
колесо катится назад, колесо стоит на месте. Итого 2 бита -- вот их
действительно достаточно при соответствующей частоте опроса.
Однако вот на старых писюканских мышках хватало 1 бита - причём на 2д-движения и кнопки. Парадокс?!
Ну да. Всего лишь переразвести плату и собрать всё заново.
Я вот к скорпу мег припаял без переразводки, однако...
При том что
оно не лезет теперь в существующий габарит...
В какой-такой габарит? Где стандарт на этот габарит?
Однако вот на старых писюканских мышках хватало 1 бита - причём на 2д-движения и кнопки. Парадокс?!
Это речь про COM-портовые мыши? Если да, так может вернемся в "каменный век" и будем поток байт PS/2 мыши (а еще лучше USB:) ) читать через магнитофонный порт:)
1-2 мсх погоду сделают?
Использовать "железное" решение, где можно обойтись десятком строк на асме, это перебор...
Вот заодно и есть чем заняться контрольнику - до 8 бит довести.
Зачем расходывать железные ресурсы? Если так поступать так может и магнитофонный сигнал вогнать в сдвиговый регистр и считывать байтами. Два нибла объеденить в один байт это что высший пилотаж программирования?
Аргументируй?
Читайте выше.
при соответствующей частоте опроса по 2 бита на 3 оптопары и 2 бита на кнопки - 8 бит. всё влезает в один порт, из м/с только усилители, дешифратор адреса и буферный элемент :) :)
Это речь про COM-портовые мыши? Если да, так может вернемся в "каменный век" и будем поток байт PS/2 мыши (а еще лучше USB:) ) читать через магнитофонный порт:)
Конечно. А зачем городить железо там, где можно обойтись десятком строчек на асме?
Использовать "железное" решение, где можно обойтись десятком строк на асме, это перебор...
Скупой платит дважды. В данном случае только скупой - это железячник, а платит за него матюками и т.д. - каждый кодер и юзер. =)
Зачем расходывать железные ресурсы?
То есть программные можно (процессор жрать), а железные (2 мсх на века) нельзя?
Если так поступать так может и магнитофонный сигнал вогнать в сдвиговый регистр и считывать байтами.
А не мешало бы. Хардварный модулятор и демодулятор. ФИФО буфер и всё - интеррупт-дривен. Тогда бы загрузка могла идти параллельно любой операции (игры в гаму, работе васика, етц). Яркий пример - конроллер дисковода. Там кста модулятор и демодулятор спрятаны в вгшке, а вот фифо и интеррупт дривен (иди дма + интеррупт) нету. А в амиге есть. В итоге - какие извраты нужны на спеке чтобы ПРОСТО проиграть музу параллельно ТОРМОЗНОЙ подгрузке и как всё замечательно на амиге.
Два нибла объеденить в один байт это что высший пилотаж программирования?
Это расход тактов кадра, которых и так не хватает.
Читайте выше.
Прочитал опять. Не увидел, причём, даже стона типа '2 мсх - этож на бакс дороже!'. Т.е. аргументов у тебя не наблюдается что-то.
при соответствующей частоте опроса по 2 бита на 3 оптопары и 2 бита на кнопки - 8 бит. всё влезает в один порт, из м/с только усилители, дешифратор адреса и буферный элемент :) :)
Кста на амиге так мыши и сделаны - оптопары и компараторы. Токо вот в самом компе стоит хардварный контроллер, который преобразует квадратурную модуляцию в 8битные координаты (кемпстон мауз бтв - клон амижного интерфейса по принципам считывания перемещения мыши).
Кста на амиге так мыши и сделаны - оптопары и компараторы. Токо вот в самом компе стоит хардварный контроллер, который преобразует квадратурную модуляцию в 8битные координаты (кемпстон мауз бтв - клон амижного интерфейса по принципам считывания перемещения мыши).
Имхо именно этот вариант самый рулез по плавности и качеству перемещения стрелки.Сравнивал контроллер от Скорпиона с COMовской мышью и собраннаю
схему из формата с пассивной мышью.выбор был в пользу второго варианта.например при быстром шевелении комовской мышью стрелка просто прокручивалась на месте практически в любых прогах чего не было с пассивным вариантом.Правда Камилевский вариант не юзал.
А вопрос такой: чтоб мне поиметь колесо на своём контролеере я так понимаю в контроллере надо допаять ещё один счётчик и подмешать его в младшие биты порта кнопок,так?
Имхо именно этот вариант самый рулез по плавности и качеству перемещения стрелки.Сравнивал контроллер от Скорпиона с COMовской мышью и собраннаю
схему из формата с пассивной мышью.выбор был в пользу второго варианта.например при быстром шевелении комовской мышью стрелка просто прокручивалась на месте практически в любых прогах чего не было с пассивным вариантом.
Только афаир форматовский контроль амигоподобной мыши всё равно с косяком - реагирует только на каждую 4ую смену состояния оптопар мыши. Я делал на МК - он каждую смену сёк и было отлично! =)
Кстати ещё - для комовской мышки я на МК делал интерполяцию! Т.е. стерелка ездила всё же плавно по экрану, несмотря на мегатормознутость коммыши. Подозреваю, что такого в принципе нету у Камиля (интерполяции) =))
А вопрос такой: чтоб мне поиметь колесо на своём контролеере я так понимаю в контроллере надо допаять ещё один счётчик и подмешать его в младшие биты порта кнопок,так?
Ага, только вроде как в старшие и реагировать будет на каждый 4ый щёлк колесом по той же причине =))
Только афаир форматовский контроль амигоподобной мыши всё равно с косяком - реагирует только на каждую 4ую смену состояния оптопар мыши.
А просвяти где там сабака порылась?а в Кондратьевском тоже этот косяк имеется
или какой есть контроль правильный (не на МК!)
вот ведь... хотел пошутить, а оказывается, так и надо - 2 бита на координату :-)
А просвяти где там сабака порылась?а в Кондратьевском тоже этот косяк имеется
или какой есть контроль правильный (не на МК!)
Честно говоря, не особо себе представляю 'кондратьевскую схему'. Но если квадратурные сигналы с оптопар идут один на тактовый вход счётчика, а другой на реверсивный вход - то оно самое. Считать будет только по одному фронту на тактовом входе, то есть 3 остальных фронта пропадают. Да ещё и туда-сюда не в фазе будет считаться. Да и аут-оф-спек для щёчиков многих реверсивных, когда сигналы таким макаром меняются одновременно на тактовом и реверсивном, как мыша их будет менять (см. датые шиты).
Решения 2 - первое это на ПЛМке или тонне рассыпухи собрать схему, которая на каждый фронт будет реагировать, второе - поставить МК чтоб сёк эти фронты. Второй вариант самый реальный, как я уже и говорил - я так делал.
На моем скорпионовском контроллере мыши стоит ПЗУ объемом 4 кб (2732). А что если перепрошить эту микросхему? Можно ли сделать в ней поддержку колеса и PS/2?
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot