ПК Специалист + манипулятор мышь

[CityAceE]

В журнале "Моделист-Конструктор" №2 за 1994 год была опубликована схема подключения манипулятора мышь.

https://pic.maxiol.com/thumbs2/1750832080.780858384.mousetext.jpg (https://pic.maxiol.com/?v=1750832080.780858384.mousetext.jpg&dp=2) https://pic.maxiol.com/thumbs2/1750832103.780858384.muuseschematic.jpg (https://pic.maxiol.com/?v=1750832103.780858384.muuseschematic.jpg&dp=2) https://pic.maxiol.com/thumbs2/1750832125.780858384.mousesoftware.jpg (https://pic.maxiol.com/?v=1750832125.780858384.mousesoftware.jpg&dp=2)

По схеме неясно что за тип мыши такой. Ближе всего - Bus Mouse, то там отсутствует сигнал RESET.

https://pic.maxiol.com/thumbs2/1750832342.780858384.mousebus.jpg (https://pic.maxiol.com/?v=1750832342.780858384.mousebus.jpg&dp=2)

1994 год - Специалист к этому времени, скорее был уже мёртв. Сильно сомневаюсь, но вдруг кто-то знает софт, который под этот манипулятор успели написать?

[b2m]

Есть тема на соседнем форуме: http://www.nedopc.org/forum/viewtopic.php?t=9361 (читать осторожно, пропуская выпады необоснованной агрессии лавро-тролля).

[CityAceE]

Дизассемблер опубликованного в МК дампа:



; Программа для тестирования мыши из журнала МК 2'94
; Написана под Монитор за авторством В. Доможирова - МК 5'91, МК 8'91, МК 9'91, МК 11'91

device zxspectrum48

org 0 ; Адрес загрузки

; Стандартные подпрограммы Загрузчика
CLS equ 0xC010 ; Очистка экрана. Цвет задаётся в ячейках 8FFA и 8FFB
DELAY equ 0xC190 ; Задержка. Длительность задаётся в регистре B

; Стандартные подпрограммы Монитора
PRN_SYM equ 0xC809 ; Вывод символа на экран. C - выводимый символ
PRN_HEX equ 0xC815 ; Вывод на экран байта в шестнадцатеричном виде. A - выводимый байт
PRN_MSG equ 0xC818 ; Вывод сообщения на экран. HL - адрес начала

; Адреса ППИ
PPI_RUS equ 0xFEFF
PPI_B equ 0xFEFD

; Адрес внешней программы
EXT_PROC equ 0x8870 ; Выход в неизвестную внешнюю программу

; Ячейки Монитора В. Доможирова
MON_Y equ 0x8F84 ; Адрес курсора (9000...BFFF) первая ячейка из двух
MON_X equ 0x8F85 ; Адрес курсора (9000...BFFF) вторая ячейка из двух

startprog:
ld hl, msg_03
call PRN_MSG

ld a, 0x80
ld (PPI_RUS), a
ld a, 0xff
ld (PPI_B), a
cpl
ld (PPI_B), a

mouse_01:
ld a, 0x82
ld (PPI_RUS), a
nop
nop
ld a, (PPI_B)
ld c, a
ld a, 0x80
ld (PPI_RUS), a
ld a, 0xff
ld (PPI_B), a
cpl
ld (PPI_B), a

ld a, c
and 0x10
cp 0
jp z, EXT_PROC

ld a, c
and 0x20
cp 0
call z, CLS

ld a, c
and 1
cp 0
jp nz, mouse_02

ld a, (coord_y)
dec a
ld (coord_y), a

mouse_02:
ld a, c
and 4
cp 0
jp nz, mouse_03
ld a, (coord_y)
inc a
ld (coord_y), a

mouse_03:
ld a, c
and 2
cp 0
jp nz, mouse_04
ld a, (coord_x)
inc a
ld (coord_x), a

mouse_04:
ld a, c
and 8
cp 0
jp nz, mouse_05
ld a, (coord_x)
dec a
ld (coord_x), a

mouse_05:
ld a, (coord_x)
ld hl, msg_02
call PRN_MSG
call PRN_HEX

ld a, (coord_y)
ld hl, msg_01
call PRN_MSG
call PRN_HEX

ld a, (coord_x)
and 0xfc
rra
rra
add a, 0x90
ld (MON_X), a

ld a, (coord_y)
rla
rla
rla
ld (MON_Y), a

ld c, "+"
call PRN_SYM

ld b, 0xff
call DELAY
call DELAY
call DELAY
call DELAY
call DELAY

jp mouse_01
; ---------------------------------------------------------------------------
msg_01:
db 0x1b, "Z", 0x64, 0x0a ; ESC+Z: прямое позиционирование курсора, следом идут координаты Y и X
db "MOVE "
db 0x01, 0x12 ; 0x01 - первый символ двухбайтной передачи, 0x12 - код символа стрелки вверх-вниз
db " "
db 0x00 ; Маркер конца строки

msg_02:
db 0x1b, "Z", 0x6e, 0x0a ; ESC+Z: прямое позиционирование курсора, следом идут координаты Y
db "MOVE "
db 0x01, 0x1d ; 0x01 - первый символ двухбайтной передачи, 0x1d - код символа стрелки влево-вправо
db " "
db 0x00 ; Маркер конца строки

msg_03:
db 0x1b, "L" ; ESC+L: Установить окно во весь экран дисплея
db 0x1b, "P" ; ESC+P: Установить цвет символов светящимися точками, а цвет фона не светящимися точками
db 0x1f ; ^_: CLEAR - Очистка экрана и перевод курсора "Домой"
db 0x00 ; Маркер конца строки

coord_y:
db 0x0c

coord_x:
db 0x42

; Мусор для совпадения с журнальным дампом
db 0, 0x39, 0, 0x39, 0, 0x39, 0

endprog:
savebin "mouse.bin", startprog, endprog - startprog

[CityAceE]

Я совершенно не смыслю в схемотехнике и не могу по схеме понять как оно реализовано, но с программной точки зрения очень странно выбран адрес порта. Дело в том, что по адресам F800-FFFF уже сидит стандартная ВВ55. Как они впихнули по пересекающимся адресам (FEFC-FEFF) ещё одну? Или же тут используется решение с дополнительным дешифратором из МК 2'89? Или как оно работает?

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

[Serg6845]

Или же тут используется решение с дополнительным дешифратором из МК 2'89?

он самый и есть. как раз в той схеме из 2/89 порт В свободен.



Сама схема, очевидно, ценности не представляет, но представляет ценность диапазон портов, выбранных ещё 30 с лишним лет назад.

там сплошной разброд и шатание. с дополнительным дешифратором например не будет работать тест-ПЗУ Рюмика - потому что оно ломится в дианазон FFFC-FFFF, не будет работать shell от Vinxru - потому что ломится в диапазон если не ошибаюсь F800-F803, возможно еще что-то. вот что мешало использовать адреса FF00-FF03 из авторского ПЗУ?


А программ под мышь всё равно, насколько я понимаю, пока нет.


мне ни одной не попадалось.

[CityAceE]

там сплошной разброд и шатание. с дополнительным дешифратором например не будет работать тест-ПЗУ Рюмика - потому что оно ломится в дианазон FFFC-FFFF, не будет работать shell от Vinxru - потому что ломится в диапазон если не ошибаюсь F800-F803, возможно еще что-то. вот что мешало использовать адреса FF00-FF03 из авторского ПЗУ?
Думаю, что невеликая проблема пропатчить весь подобный софт на стандартные адреса FF00-FF03.

[CityAceE]

Что ж, внимательное изучение обсуждения этого же самого вопроса на форуме NedoPC привело меня к заключению, что двигаться в этом направлении - это тупиковый путь. Программ под это дело так и не появилось. Да и достоверное не смогли определить, что же за мышь такая была у автора статья. Всё только на уровне предположений. Так что необходимо переизобрести подключение мыши к Специалисту. Софта всё равно нет, так что мы ничем не ограничены.

В качестве манипулятора предлагаю использовать мышь стандарта PS/2. Конечно, USB-мышь была бы предпочтительнее, но насколько я понимаю, PS/2 будет проще подключить.

По части адресации лучше выбрать диапазон F000-F7FF, но с дополнительным дешифартором, делящим область на 16 участков. Область F000-F07F занята авторской ВВ55А (программатор, принтер, SD). F400-F407F с лёгкой руки Pyk занята AY. Под мышь предлагаю задействовать F500-F57F:



; F500 - кнопки
; F501 - X
; F502 - Y
; F503 - колесо


К сожалению, оперативно внедрить это дело ни в эмулятор, ни в FPGA не получается. Emu80 в принципе не имеет поддержки мыши, так что нужно будет начинать с его серьёзного перелопачивания. А по части FPGA есть целая очередь других задач.

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

https://pic.maxiol.com/images2/1752734045.780858384.mouse.png

Я не силён в схемотехнике, но может быть можно адаптировать какое-то готовое решение, например, со Спектрума?

[Serg6845]

Я не силён в схемотехнике, но может быть можно адаптировать какое-то готовое решение, например, со Спектрума?

единственно логичным вариантом выглядит kempston mouse. на чем реализовывать переход в USB/PS2 - вопрос открытый. есть такой интересный проект -Hidman (https://github.com/serisman/HIDman-mini), может оттуда что приколхозить...

[RW9UAO]

мы тащим
https://github.com/harbaum/FPGA-Companion/blob/main/SPI.md
там всё.... что касается USB HID.
работу с картой надо переделывать в обратную сторону.

[CityAceE]

А вот тут ИИ мне подсказывает, что для подключения мыши к Специалисту отлично подойдёт недорогая плата RP2040, которая имеет на борту USB-хост и достаточное количество GPIO контактов, которые можно запрограммировать как нашей душе угодно:



Специалист RP2040
------------- -------------
A0–A15 o──────[1k]──────▶ GPIO0–15 (IN)
D0–D7 o──────[470]──────◀▶ GPIO16–23 (IN/OUT with Hi-Z)
/RD o──────[1k]──────▶ GPIO24 (IN)
GND o────────────────� �� GND


Также есть готовая библиотека TinyUSB, которую нужно будет слегка подрихтовать под наши нужды.

Ну а я продолжаю готовиться к появлению грызуна на платформе:


https://plvideo.ru/watch?v=_Els1vYDsdkE

[CityAceE]

Свершилось!


https://rutube.ru/video/a2e5ef51a04f3f0f98f2e5737beef343/

[CityAceE]

В общем, как выяснилось, не все мыши одинаково полезны. Несмотря на то, что протокол вроде как один, но мыши ведут себя по-разному. То есть, есть некоторые стандартны, но их несколько. У меня из 4-х мышей заработали только 2 со стандартной ардуиновской библиотекой. Перепробовал несколько. Одна из них подтянула ещё одну мышь. Но одна мышь вот просто ни в какую! Это A4Tech OP-720. И что интересно, это абсолютный новодел, который я копил может быть с год назад, и у него на хвосте именно разъём PS/2. Эта мышь прекрасно работает в режиме STREAM (когда она сама генерирует передачу данных), но шлёт нули в режиме REMOTE (когда отвечает на запросы). Для нашего случая STREAM не годится, нужен именно REMOTE. Что я только не делал, и какие эксперименты только не ставил - не отдаёт дельты и кнопки, но при этом отдаёт статус и колесо. В итоге накопал инфу, что частенько мыши A4Tech и некоторые другие капризны к протоколу, и нужно вбивать костыли, чтобы добиться от них данных. Однако есть прекрасный альтернативный способ, который называется "STREAM-triggered REMOTE", когда на время запроса мышь кратковременно переводится в STREAM, получаются данные и потом снова блокируется от неё передача. Так сделано для капризных мышей в ранних драйверах Linux. В итоге мне удалось завести все имеющиеся у меня мыши. Ну как удалось? Они все шлют корректные дельты, кнопки и колесо в консоль для визуального контроля. Но совместить эту логику с протоколом Специалиста у меня не получается - отваливаются две моих мыши. Обе MicroSoft Explorer: одна 3.0A, вторая 4.0. Это особый род мышей с наворотами, которые требуют отдельной "магической" последовательности разрешения (200, 100, 80), чтобы перевести их в стандартный режим. И такая инициализация проходит, и в консоль отправляются правильные данные, но не в Специалист. Честно говоря, я уже устал. Поэтому хотел бы в личке пообщаться с кем-то, кто хорошо шарит в С/C++ и сможет помочь понять, что не так.

[CityAceE]

Ладно, понимаю, что придётся всё решать самому. Просто поделюсь тем, что накопал.

В нашем случае можно накостылить что-то со STREAM-режимом, но решение получается совершенно нестабильным. Сбивается синхронизация обмена с мышью, потому что всё время приходится отвлекаться на передачу данных в Специалист. Эта передача ломает тайминги протокола PS/2. В результате приходят битые пакеты. Валидировать можно только принимаемый байт. А отследить начало пакета нет никакой возможность, потому что начало пакета никак не помечается, при этом поток данных идёт непрерывно. Можно лишь по каким-то косвенным данным ПРЕДПОЛАГАТЬ, что вот это и есть начало нового пакета. Я пробовал разные методы. Например, мы знаем, что в байте статуса 3-й бит всегда должен быть 1, и что колесо не может передавать значения больше, чем +3 и меньше, чем -3. Плюс ещё можно сравнивать с предыдущими значениями и т.д. Какие-то из фильтров дают более-менее приемлемый результат, но по итогу всё равно проскакивают ошибочные пакеты, которые похожи на настоящие (проходят сквозь фильтры), но таковыми не являются. А это значит, что бывают случайные нажатия кнопок и/или перескакивания мыши. На текущий момент у меня закончились мысли, как сделать стабильный опрос мышей в режиме STREAM. А это значит, что моя единственная мышь A4Tech OP-720 с разъёмом PS/2 не будет работать. И не потому что я её как-то не так инициализирую и опрашиваю, а потому что она так устроена. Выяснилось, что есть и другие мыши с подобным поведением, и не только у A4Tech. Необходимо это иметь ввиду.

Хорошая новость в том, что если мышь полноценно поддерживает REMOTE-режим, то её можно заставить стабильно работать со Специалистом. Три остальных своих мыши (USB/PS2) я работать заставил. Никаких случайных нажатий кнопок, никакого дрожания курсора. Потребовались небольшие доработки в скетче и драйвере на Специалисте.

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

Вот такие дела...

[goodboy]

для подключения мыши к Специалисту отлично подойдёт недорогая плата RP2040
раньше такое делали на PIC`е. например PIC16F628A
https://devstratum.ru/hardware/amiga-1200-03-kontrollery-ps-2-klaviatury-i-myshi-proshivka-fdd-gotek