Полигон-2

i8088 написал:

[q]

Я только рекомендую не использовать 386+ инструкции, для совместимости с 286.

[/q]

Вы зря переживаете. Я и 8086 инструкции плохо знаю. 386+ для меня вообще темный лес.

i8088 написал:

[q]

По ссылке pahan как раз есть пример, думаю ответы на все Ваши вопросы -да.

[/q]

Не нравится мне пример по ссылке:read_PIT_count:
  pushfd
  cli
  mov al, 00000000b    ; al = channel in bits 6 and 7, remaining bits clear
  out 0x43, al         ; Send the latch command

  in al, 0x40          ; al = low byte of count
  mov ah, al           ; ah = low byte of count
  in al, 0x40          ; al = high byte of count
  rol ax, 8            ; al = low byte, ah = high byte (ax = current count)
  popfd
  ret
Он устанавливает собственный режим работы канала 0, нарушая работу системного таймера.

Я бы сделал
mov al, 00010110b
out 043h,al
in al,040h
Т.е. принудительно установил бы чтение/запись только младшего байта. Остальное без изменений.

[q]

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

[/q]

У 8254 есть команда write-back.

[q]

принудительно установил бы чтение/запись только младшего байта

[/q]

[q]

Значения счетчика из таймера можно читать непосредственно?
in al, 040h ?
Ничего не собьётся?

[/q]

Есть риск, что он перейдёт через 0 и тогда задержка в эти моменты сильно увеличится. Но скорее всего придётся для получения адекватной производительности (см. ниже для примера чтения всех байт). В остальном - ОК.

[q]

Нужно ли предварительно делать "Access mode" = lobyte only ?

[/q]

В теории, кто-то может и поменять режим за то время, что мы к нему обращаемся. Безопаснее ставить.

[q]

прочитать содержимое счетчика и подождать, когда оно уменьшится на 18

[/q]

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

Считаем время выполнения инструкций
(данные отсюда - http://www.cs.dartmouth.edu/~m...c/x86.html) только для считывания текущего значения счётчика таймера 8253 (а значит, этот код повторится ещё как минимум 1 раз, + сравнение(2-2-1 такт), +цикл после сравнения(не меньше 7-не меньше 7-3), +служебные команды, если это будет подпрограммой (cli/sti/push/pop/ret)):
mov al, 0xD2
out 0x43, al
in al,0x40
mov ah,al
in al, 0x40
rol ax,8 - считали текущее значение канала 0
mov bx,ax - и запомнили его

В тактах проца это всё займёт:
286 - 2+3+5+2+5+13+2=32 такта (на частоте 8-25 МГц)= 4 мкс-1,3 мкс
386 - 2+10(4..24..24)+12(6..26..26)+2+12(6..26..26)+3+2=43 такта в реальном режиме/25-85 в защищённом/85 в V86 (на частоте 16-40 МГц)= 2,7/1,6/5,3 мкс - 1,1/0,6/2,1 мкс
486 - 1+16(11..31..29)+14(9..29..27)+1+14(9..29..27)+2+1=39 тактов в реальном режиме/34-94 в защищённом/88 в V86 (на частоте 25-133 МГц)= 1,6/1,4-3,8/3,5 мкс - 0,3/0,3-0,7/0,7 мкс

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 пришлось бы учитывать, и код был бы более сложным.