ivagor,
а если запустить tst8253, потом что-то другое из пакета тестов, а потом снова tst8253?
- - - Добавлено - - -
KTSerg, просто первая команда в обработчике прерываний обычно всегда DI. Она однобайтная и вполне вписывается в несколько тактов.
Вид для печати
ivagor,
а если запустить tst8253, потом что-то другое из пакета тестов, а потом снова tst8253?
- - - Добавлено - - -
KTSerg, просто первая команда в обработчике прерываний обычно всегда DI. Она однобайтная и вполне вписывается в несколько тактов.
Провёл эксперимент на реал Векторе (02).
Написал программку:
.org 0
EI
HLT
JMP 0
.org 38h
RET
.
Это просто цикл прерываний.
Результат такой:
Через 4 такта после фронта "F50Гц", "INTE" падает в "0" и отключает "INT".
INTE восстанавливается в "1" через 44 такта.
Если убрать EI (заменить NOPом, или вроде пробовал JMP 0001) - прерывания никогда не наступают.
Если вставлять "NOP" между HLT и JMP 0 - это приводит к тому, что каждый NOP задерживает восстановление INTE на 4 такта.
Если заменить
RET
на
EI
RET
т.е. разрешить прерывания сразу после перехода к ним, то INTE восстанавливается через 20 тактов.
Т.е. INTE - падает в 0 (запрет прерываний) как программный, так и аппаратный выходной сигнал процессора, поскольку я не использовал DI, а он сам срабатывал.
И разрешать прерывания на Векторе нужно программно - обязательно (если они нужны).
Вроде на процах Мега есть специальная команда выхода из прерывания, которая кроме обычного RETURN сама выполняет ещё и EI, но я опять-же могу путать... склероз аднака... :(
ага.. значит хоть в этом у меня нет расхождения.
А почему так? Тесты вроде ваши. Вы полностью прописываете все регистры или что-то забываете?
А на реальном Векторе есть возможность так же запустить tst8253 после других тестов?
- - - Добавлено - - -
KTSerg,
ну тогда значит сам процессор принудительно выдает DI при наступлении прерываний, а обработчик прерываний значит обязан выполнить EI перед выходом, чтобы вновь разрешить прерывание.
Запускал сейчас через загрузчик (ЛВС) эти тесты в указанной последовательности.
Каждый раз результаты как на картинках.
С учётом того, что на ВИ53 не заведено системного сброса, можно сделать предположение, что указанные тесты корректно его перепрограммируют на реал. Векторе.
Получается, что модель ВИ53 где-то глючит.
- - - Добавлено - - -
Однако, это не отвечает на вопрос почему Exolon так глючит у меня.
- - - Добавлено - - -
ivagor,
а дайте ссылки на ваши тесты. Или лучше сюда залейте чтобы все в одно место.
Я протестирую их у себя и может тогда будет ясно (с вашей помощью) где у меня проблемы.
chkvi53_2, chkvi53_weirdbinbcd. Но эти тесты не сильно важны для нормальной работы классических программ, в основном пробовал детектить эмулятор. Для второго теста нет результата реального вектора.
Результат с реала Вектор-06Ц: 2014
http://i75.fastpic.ru/thumb/2016/022...29b634740.jpeg
Вложение 56139
Из-за чего такое смещение в tst8253?
Посмотрел код этого теста...
Ничего "страшного" там не увидел, просто в режиме делителя тактовой частоты, и в одном и том-же цикле считываются значения делителя. Даже не знаю, что этим тестом можно проверить... он (ВИ53) ведь с тактовой частотой процессора от одного генератора/делителя синхрой питается... Даже если изменить общую частоту (12МГц), тест по любому должен показать эти-же самые циферки...
Или я чего-то не понимаю... ???
Тест может показать точность эмуляции самой ВИ53 и процессора (правильность длительности - в тактах, выполнения некоторых команд).
Но если в своей сборке использовать уже готовые модели (блоки/модули), то...
В доке (брошурке) на ВИ53 сказано, что новые значения для делителя принимается не сразу после записи...
Может он уже чего "медленно" считал, и не сразу на "новый режим" вышел, поэтому и сдвиг...
Exolon заработал. Пришлось написать новую модель ВИ53 с нуля.
KTSerg,
тем не менее этот тест показывает одну недокументированную особенность. Нигде в даташитах не сказано, что при работе с однобайтным счетчиком, другой байт обнуляется. Вот в модели от svofski он не обнуляется, и потому если данный тест запустить после других тестов, получаются неправильные значения, в отличие от реала.
Я в своей модели обнуляю, и тест работает всегда одинаково.
Правда, данные всё так же сдвинуты. Но это, я думаю, из-за сдвига фазы частоты таймера.
Крут. Молодца, разобрался в проблеме.
По сдвигу данных в тесте, не уверен, что фаза частоты могла бы дать такую погрешность, тут явно либо рано, либо поздно начинает считать относительно записи в него начальных значений...
Может эмуляция проца не точная, ну например команда записи в порт выполняется не положенные ей количество тактов, а в один, потом просто задержки... Ну или что-то в этом духе...
KTSerg,
Я сильно сомневаюсь в неточности модели процессора, поскольку использую модель, основанную на реверсе реального кристалла.
Я сейчас доделываю ВИ53, а потом попробую разобраться.
Может в тесте используется прерывание 50гц и этим объясняется задержка.
Не, в этом тесте первой командой идёт DI, и больше они не разрешаются. Так что в самой программе задержек ни каких не должно быть. Смущает стабильность сдвига значений, это должно однозначно на что-то указывать...
Посмотрел код теста I8253 , в нём запись и чтение значений счётчиков синхронизированы с прерываниями.
Может действительно на результат (сдвиг) прерывания как-то влияют... но это возможно только если есть какая-то ошибка в эмуляции схемы... возможно.
- - - Добавлено - - -
Попробуй ради интереса вот этот тест, загружать его нужно с адреса 0000.
Я добавил в начало ожидание прерывания и переход к тесту после прерывания.
Хотя ожидание нужно было воткнуть непосредственно перед работой с ВИ53, а так там ещё экран очищается...
KTSerg,
придется изменить систему загрузки для этого теста. .c00 - это стандартное расширение для Вектора для загрузки с 0 адреса?
- - - Добавлено - - -
в общем, твой тест выдает числа начиная с 15.
- - - Добавлено - - -
подвигал я фазу частоты таймера - не помогло. Прочно начинается с 15.
вот эта конструкция:
как бы не совсем понятная. Если дается комманда LATCH ( 0 -> port8 ), то согласно даташиту надо считывать 2(!) байта (ибо какой смысл делать latch для одного единственного байта), а считывается только 1 байт. В общем-то это не нарушает алгоритм моей модели, ибо при latch счетчик отправленных байтов сбрасывается.Код:L2 XOR A,A
OUT (#08),A
IN A,(#0B)
PUSH AF
DEC B
JP NZ,L2
Еще один момент, который не освещен в даташите - это момент того самого latch. Непонятно когда именно происходит фиксация считываемых данных: при комманде latch или при считывании первого байта.
- - - Добавлено - - -
Я говорю что вижу на экране. На экране первое число 15 (не F). Числа шестнадцатеричные, но без h.
- - - Добавлено - - -
то же самое.
Поскольку считывание происходит сразу после программирования таймера, то очистка экрана тут неважна. Прерывания запрещены - и этого достаточно для 100% повторения.
В этом тесте программируется только младший байт счётчика и считывать старший не имеет смысла, он всегда будет 00.
Когда происходит фиксация, это ты скоро выяснишь :)
На счёт стандартности расширения с00 - както не задумывался, поставил "на автомате"... надо у гуру спросить где посмотреть список всех стандартных для Вектора расширений.
Разница между файлами с расширениями rom и r0m - первые грузятся с 100h, вторые с 0h.
- - - Добавлено - - -
Кстати, сейчас смотрю даташит на 82с53, там написано, что сигнал (вход) GATE влияет на счётчики (старт, рестарт и пр.), а он по схеме вектора зависит от сигнала F50Гц (КСИ)...
Может в этом собака порылась... ???
Ох ни фига-себе...
GATE на ВИ53 это системный сброс Вектора... т.е. аппаратный сброс на ВИ53 заведён, только на пересчёт во время работы он не сможет повлиять (т.к. его нет во время работы)...
хмм.. только сейчас заметил.. а значения у меня 2 раза медленнее уменьшаются.
Так.. тут наступает недокументированная особенность.
В режиме меандра счетчик уменьшается 2 раза быстрее разве?? Я вижу что в модели от svofski счетсик уменьшается на 2 за каждый тик.
Но в доках нигде не сказано что счетчик должен так уменьшаться. Там лишь сказано что первая половина out = 1 а вторая половина out =0.
Где правда??
- - - Добавлено - - -
сомнительная польза от этого.. Пнуть возможно зависший таймер?
KTSerg,
можешь сделать фотку с экрана реального вектора с одним из твоих последних тестов?
Правда в том, что результирующая частота на выходе должна быть одинаковой, как в режиме делителя частоты, так и в режиме меандра. А вот как это достигается, это уже второй вопрос. В режиме меандра таймеру приходится срабатывать в два раза чаще, поэтому счётчик уменьшается в два раза быстрее, т.е. на 2 за один такт. Причём, если делитель нечётный, то один полупериод будет на 1 такт длиннее, т.е. в первом полупериоде первый такт уменьшит счётчик на 1, а во втором полупериоде младший бит сбросится в 0 уже при загрузке счётчика.
b2m,
судя по tst8253.txt - это ваш тест. tst8253.jpg - это с реального Вектора фотка?
Да, я просил, чтобы это запустили на реальном векторе, когда были непонятки с режимом меандра.
На моём картинка полностью совпадают с фоткой приложенной к тесту.
- - - Добавлено - - -
На диаграммах к режиму 3 , так и нарисовано, что значение счётчика уменьшается на 2 каждый тактовый импульс.
Фиксация происходит при команде latch. Точнее, при этой команде устанавливается флаг, который запрещает обновление регистра считываемых данных значением счётчика. После чтения нужного количества байт флаг сбрасывается и этот регистр опять обновляется каждый такт. Если не давать команду latch, то может получиться так, что старший байт считается уже после изменения счётчика и он будет на 1 меньше ожидаемого. Например в момент чтения младшего байта в регистре было 0500, а в момент старшего уже 04FF, и программа получит ложное значение счётчика 0400.
- - - Добавлено - - -
По поводу того, что происходит, если в режиме двух байт после команды latch будет считан только один байт, а затем снова будет дана команда latch, тестов не проводилось. На мой взгляд, вторая команда latch ничего не даст, и считается предыдущее значение.
b2m,
ну зачем latch нужен объяснять мне не надо. Вроде не совсем глупый ;)
- - - Добавлено - - -
диаграмма в англязычной книге на 8253 имеет пронумерованные такты с шагом 1 для режима 3.
Но я уже понял что в реальности идет уменьшение на 2 за такт. Я уже переделал и теперь практически совпадает. Начинается с 0A вместо 0С. Что уже почти совпадает.
Вот, фотка из книги:
Вложение 56178
- - - Добавлено - - -
да, это понятно.. Я еще не тестировал на пограничные условия свою модель ВИ53.
- - - Добавлено - - -
b2m,
кстати, по поводу инициализации.
В моей модели сделано так: после записи Control Word, счетчик останавливается и ждет первой записи в счетчик (обоих байтов, если выбран 2-байтный режим записи). После чего начинается счет.
А как в реале? В даташите на этот счет ничего не сказано.
А вот из того, что я смотрел...
Я это написал, чтобы было понятно, что в любом случае считывается не само значение счётчика, а его копия.
Я вот тут сейчас подумал, и мне показалось, что счёт всё-таки начинается сразу после загрузки счётчика, просто в регистр для чтения данные попадают на 1 такт позже, т.к. обновление и счётчика, и регистра происходит по одному тактовому импульсу.
- - - Добавлено - - -
Это более правильная картинка.
Должна быть ещё картинка с нечётным делителем, там числа типа такие: 5 4 2 4 2 5 4 2 4 2 ...
- - - Добавлено - - -
Вроде во всех даташитах сказано, что счёт останавливается после загрузки управляющего слова. И это, кстати, достаточно часто используется, чтобы выключить звук в компах, где gate постоянно разрешён, а выход идёт напрямую на динамик.
Попробовал вставить NOPы.
Если вставить между перед OUT, или между OUT и IN разницы в показаниях не будет. Так что значение для чтения фиксируется на OUTе.
Я в английском не силён, может тут есть что полезное.
- - - Добавлено - - -
Чё он их так уменьшает? :(
KTSerg,
Скрин ну очень мелкий чтобы читать. Выложи лучше книжку сюда. Видно очень подобное описание 8253.
- - - Добавлено - - -
нашел этот даташит:
http://pdf.datasheetarchive.com/inde...IH00054971.pdf
- - - Добавлено - - -
еще один нашел:
http://www.sharpmz.org/download/8253.pdf
Ага, первый - это именно тот файл из которого я давал скрины.
мыло, мочало - начинаем всё сначала...
Придется перечитать даташиты что я нашел. Вот уже вычитал важное уточнение: Note that the internal counters are reset to 0000H during control word setting.
- - - Добавлено - - -
я так понял из новых доков, что значение счетчика при чтении всегда на такт раньше чем реальное значение. Видимо, поэтому у меня начинается с 0A вместо 0C.
- - - Добавлено - - -
у меня возник вопрос про это однотактовое отставание.
Не могу найти ответ в доках.
1) Что происходит в тех режимах в конце, когда счетчик дотикивает до 0 и останавливается? Читаемое значение останавливается на 1 или через такт тоже становится 0?
2) При загрузке начального значения, читаемое сразу выставляется и не меняется 2 такта или выставляется через такт?
- - - Добавлено - - -
С tst8253 разобрались. Теперь правильно показывает.
а вот тест I8253 из того же пакета тестов:
Вложение 56184
Отсутствуют значения 01 и 05, при том, что остальные значения правильные.
А должны ли 01 и 05 присутсвовать, если GATE всегда 1? В этих режимах счет запускается фронтом GATE.
Судя по диаграммам:
Новое значение заносится в регистры при следующем спаде тактовой частоты после записи этого значения в счётчик.
Если при очередном спаде такта достигается 0, значение счётчика сразу обновляется.
Если заносится нечётное значение, 0 и 1 на выходе имеют разную длину (на 1 такт).
На диаграммах указаны значения счётчика без младшего бита (стр.724 файла где сканы страниц).
Видимо для определения достигло ли значение счётчика минимального значения младший бит учитывается...
Не могу сообразить...
Получается так, если при очередном вычитании 2 из счётчика результат 0, то в счётчик заносится значение, которое в него записывали (может быть не чётным). А если получилось FFh (перенос - на единицу меньше 0-ля) то в счётчик заносится значение на 1 меньше чем записывали (чётный вариант значения - без младшего бита)...
KTSerg,
я не понял на какой вопрос ты отвечал ;)
Вроде ничего такого я не спрашивал.
По поводу значений я разобрался. В доке от Сименса написано, что читаемое значение всегда на шаг отстает от реального.
И вопрос был про то, что получается в этом отстающем значении при пограничных условиях (начало и конец).
Еще в доках от ОКИ написано, что значение 0 никогда не считывается. Что подразумевает, что счет останавливается на 1, при реальной остановке на 0.
Но у меня нет реального железа чтобы проверить это.
- - - Добавлено - - -
Если про 3 режим: то там оказалось всё проще. Если значение нечетное, то от него отнимается либо 1 (out=1) либо 3 (out=0), а далее по два до нуля.