Полигон-2

pahan написал:

[q]

Есть риск, что он перейдёт через 0 и тогда задержка в эти моменты сильно увеличится.

[/q]

Предварительно проверяем, что текущее значение >18 (лучше с запасом - больше 30). Если меньше, ждём (считываем повторно, пока не станет >18, т.е. не пройдет через 0).

pahan написал:

[q]

1)насколько нам нужна такая точность (ровно 15 мкс)

[/q]

Если реальная задержка будет 15...30мкс, думаю это устроит. Это задержка между появлением флага переполнения буфера мыши в контроллере и появлением данных в выходном регистре. Не знаю, почему именно 15мкс. Это значение в исходнике Sergey Kiselev XT биос. Он, вероятно, скопировал из исходников Award bios.

pahan написал:

[q]

2) на каких процах

[/q]

От самого младшего 286 (8МГц?), до самого старшего 486 (AMD 5x133@160)

pahan написал:

[q]

3)в каких режимах мы будем наш код использовать. Потому что на всех 486 и топовых 286-386 всё это спокойно прокатит, на младших 386 в реальном режиме (чистый DOS) - да, в режиме виртуального 8086 (DOS-окно из-под Windows) - впритык, на младших 286 даже в реальном режиме вряд ли уложимся.

[/q]

Код инициализации - из под чистого DOS (если стоит Win95, то до её загрузки, из autoexec.bat). Сама задержка - вероятно и DOS, и Windows. Но Win95 ставят только на 386 и выше (лично я предпочитаю от 486-х).

Исходя из Ваших дальнейших расчетов
pahan написал:

[q]

286 - 2+3+5+2+5+13+2=32 такта (на частоте 8-25 МГц)= 4 мкс-1,3 мкс

[/q]

думаю нормально. Эта часть быдет выполнять только в чистом DOS.

pahan написал:

[q]

Есть риск, что он перейдёт через 0 и тогда задержка в эти моменты сильно увеличится.

[/q]

Это как раз не страшно, тк складывать текущее знасение с 18 мы тоже будем с переполнением.

Пример.
Текущее значение счетчика (младший байт) == 0xF0
Запоминаем, складываем с 18 , 0xF0 + 0x12 = 102
Перенос вызовет установку флага CF, но на это не обращаем внимания.
Ну и собственно ждем, когда счетчик достигнет значения 0x02

Это чем-то похоже на относительные внутрисегментные безусловные
переходы в x86: смещение перехода задается формально в пределах -32768
+32767, но "дотянуться" до любого адреса внутри сегмента не проблема.

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


Rio444 написал:

[q]

От самого младшего 286 (8МГц?),

[/q]

Первый 286 - 6MHz. PC/XT полюбому в пролете, там совсем другой
интерфейс клавиатуры и сама клавиатура. Ну за исключением очень
редких нестандартных XT с AT клавиатурой.

Rio444 написал:

[q]

Т.е. 18 надо вычитать, а не прибавлять.

[/q]

Ой да, забыл, что счет в обратную сторону, мои извинения!

Но сути дела это не меняет.

Пример
Исходное значение 0x04
Вычисляем, чего ждать 0x04 - 0x12 == 0xFFF2 (старшие FF это я перенос обозначил)
На флаг CF не обращаем внимания, и ждем когда счетчик достигнет 0xF2

PS. Если бы КД канала 0 был бы не 65536, то переустановку счетчика при
переходе через 0 пришлось бы учитывать, и код был бы более сложным.

Rio444 написал:

[q]

Не может такого быть, что счетчик не достигнет 0xF2, а "перескочит" его, когда будет
очередное считывание? Если процессор медленный. И, видимо, надо будет запрещать аппаратные
прерывания, иначе они сильно исказят расчет.

[/q]

При медленном CPU я думаю возможно, тогда ловить не равенство, а что число в счетчике ниже
чем рассчитанное (сравнивать беззнаково!).

К примеру (просто первое, что сходу пришло в голову, это не проверялось, возможны
грубые ошибки!)

======================================================================
DELAY_CONST EQU 18

mov al, 00010110b
out 043h, al
in al, 040h
mov bl, al
sub bl, DELAY_CONST (в bl вычисляем значение окончания задержки)

delay_ch0: in al, 040h
cmp al, bl ;(в bl у нас рассчитанное ранее значение)
jbe stop_delay_ch0 ;(сравнение беззнаковое!)

;; здесь должна быть дополнительная проверка, если к примеру у нас рассчитанное
;; конечное значение 0x01, CPU задержался, и в счетчике уже к примеру 0xff
;; Здесь я совсем не уверен в корректности моего решения (проверка чисел как
;; знаковых, если беззнаковая проверка дала "добро" на продолжение цикла и считанное
;; значение отрицательно (0x80-0xff), а конечное положительно. Надеюсь, что до 0x7f
;; запаздывание из-за CPU (положительные знаковые числа не дойдет).

cmp al, 00h ; просто для устанавки флагов
jns delay_ch0 ;проверка, что считанное значение положтельно, если да, то продолжаем цикл

; если мы здесь, то имеем считанное значение отрицательное, проверяем конечное значение
cmp bl, 00h
; если имеем ситуацию, когда конечное значение (bl) положительно, а текущее (al)
; отрицательно, то выходим из цикла
jns stop_delay_ch0

jmp short delay_ch0

stop_delay_ch0: ;эдесь процедура (код) задержки кончается
======================================================================

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

Для проверки можно сделать простую програму с бесконечным циклом из этой задержки, и
направить вывод например в LPT порт (например после каждой задержки иннвертировать
данные в 378h). И наблюдать осциллографом длительность импульса и паузы на линиях данных
LPT. Я так проверял реальные задержки во FreeBSD.

======================================================================
LPT_DATA_PORT EQU 0378h

mov dx, LPT_DATA_PORT
in al, dx
xor al, 0ffh ;инвертируем
out dx, al
======================================================================

После исполнения такой программы в цикле системные часы отстанут, но для проверки
это несущественно, особенно если цикл бесконечный.

Роман, для отладки пока уберите отключение прерываний
в процедуре задержки.

Я как освобожусь, тоже посмотрю. Процедура задержки
будет полезна и в других проектах.