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

[Improver]

Ещё как важно! Этим absolute addressing мы сразу убиваем возможность выставить mouse курсор в произвольное место по желанию (софта), или, скажем ограничить зону действия мыши некоей областью.

Вовсе нет. Ничто не мешает управлять настройками контроллера с Вектора, отправляя на него соответсвующие команды, тут даже половинки порта С хватит. Можно даже прикинуть, что будет проще -- отправить при необходимости команду "перемести курсор в Х,У" или заниматься вычислениями координат по приращениям каждое прерывание, да ещё и с проверкой коллизий... И мне кажется, что выигрыш будет не на стороне упрощённого контроллера.

В общем, с точки зрения софта, работа в absolute mode будет мукой. Это если мы примем, что контроллер разрулит все указанные выше проблемы (большинства из которых просто нет в relative mode по определению)

Разрулит, даже не сомневайтесь. Самая простая ардуинка сейчас мощнее Вектора, так почему бы это не использовать? А будет ли это мукой или спасением -- только практика покажет.

ЗЫ. И это ещё при том, что для нормальной точности в режиме высокого разрешения придётся дважды лазить в порт зачем-то.

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

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

Согласен, поэтому и предлагаю обойтись минимальной обработкой в контроллере.

Да, но следует учесть, что упрощение разработки эмулятора в итоге выливается в усложнение написания программ для Вектора, которое может дать непеодолимый барьер его внедрению.

[Advertiser]

[PPC]

Плата за все равно - придется передавать в два раза больше данных между контроллером и вектором.

Поддерживаю. Как бы мы не делали, с мультикартой или без, затыка - 8-битные регистры PPA. Поэтому max 7 бит смещения + 1 бит знака в relative mode имеет смысл для обоих видеорежимов. Не знаю, сколько накопится за 20ms между IRQ, но думаю надо будет сильно мышью дрыгать в одном направлении чтобы переполнило. Это предел контроллер должен на себя взять (ты уже писал)

[KTSerg]

Поддерживаю. Как бы мы не делали, с мультикартой или без, затыка - 8-битные регистры PPA. Поэтому max 7 бит смещения + 1 бит знака в relative mode имеет смысл для обоих видеорежимов. ...

Я уже писал ранее, в стандартном протоколе ps/2-мыши передаётся 8 бит смещения.
Бит направления находится в одном байте с кнопками.

[PPC]

Я уже писал ранее, в стандартном протоколе ps/2-мыши передаётся 8 бит смещения.
Бит направления находится в одном байте с кнопками.

Ну нам никто не мешает попробовать урезать до 6 бит как тут кто-то про БК упоминал, и хранить кнопку и направление в одном байте. Это то контроллер может на себя взять. Тогда всё уложится в 2 чтения портов (если колесо не надо читать).

[ivagor]

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

Тут уже надо переходить к конкретным цифрам, которых у меня в полном виде нет. Грубые прикидки такие:
1. Текущий вариант KTSerga - в районе 5000+ тактов на опрос. Очень много (можно ускорить), поэтому контроллер хотелось бы, но я согласен даже на такой вариант, т.к. он уже реализован в железе и работает.
2. Вариант с параллельной передачей от контроллера. Тут смотря как считать и что считать, но пусть будет 200-300 тактов. Разница между абсолютным и относительным (вектор сам будет считать абсолютные) - ну тактов 100, ну пусть даже 200, зато можно использовать для любых задач.

[svofski]

Плата за все равно - придется передавать в два раза больше данных между контроллером и вектором.

Я сам больше за приращения. Но разница между приращениями и абсолютными в общем отсутствует. Даже если они 8 битные с переполнением, это все равно то же самое. Проблема только если в контроллере будет насыщение, тогда это вообще никуда не годится.

[ivagor]

разница между приращениями и абсолютными в общем отсутствует. Даже если они 8 битные с переполнением, это все равно то же самое. Проблема только если в контроллере будет насыщение, тогда это вообще никуда не годится.

Отметаем насыщение - не будет залипаний, это хорошо. Но если 8 битные абсолютные с переполнением, то при определенном сочетании условий возможны "метания". При 16 битах вызвать метания вряд ли возможно.

[svofski]

Отметаем насыщение - не будет залипаний, это хорошо. Но если 8 битные абсолютные с переполнением, то при определенном сочетании условий возможны "метания". При 16 битах вызвать метания вряд ли возможно.

По моим оценкам добиться метаний будет непросто -- или программа будет слишком редко опрашивать, или мышка полетит с третьей космической. Как пруф -- мышка у коммодора 64 фактически передает постоянно проворачивающееся положение условного колеса. Забыл разрядность АЦП-а, но он там точно в пределах 8 бит. Коммодор 64 не знаменит своими мышовыми способностями, но нам и до него пока как пешком до луны.

Так почему все-таки просто приращения нельзя? Вроде миллиарды человеко-часов пользования мышей с приращениями (за вычетом тех, что на коммодоре 64) говорят о том, что приращения работают.

[ivagor]

Так почему все-таки просто приращения нельзя

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

[PPC]

Если прикинуть 16-битный режим c приращениями в 1м приближении (по 2 чтения порта на координату), мы ломаем копья вокруг примерно 92х тактов в ISR (плюс необходимость прочесть PPA порт C для кнопок)

84 * 2 = 168 тактов в ISR

 (дважды)
DB (lxi h)
axis: DW 0
in
mov c,a
in
mov b,a
dad b
shld axis

против 76 тактов при 8-битных приращениях

lxi h,yx
in
add m
mov m,a
inx h
in
add m
mov m,a

Really?