Просмотр полной версии : Реверс-инжиниринг УКНЦ (1515ХМ1&2, 1801ВП1, 1801ВМ2)
Страницы :
1
2
3
[
4]
5
6
7
А если мне не нужен спрайтовый механизм?
Да как ни крути, установка адреса планов никак не должна автоматически загружать планы из памяти.
И, конечно, опционально иметь автоинкремент.
Еще остается под вопросом проверка на коллизию с окончанием записи в планы 1 и 2, которая, как видно из схемы, не проверяется. Т.е. более длинные команды - запись в регистр октета, и адреса планов проверяются, а запись в регистр планов 1 и 2, которая имеет нулевую задержку по RPLY, но при этом занимает дополнительный цикл CLCA, не проверяется.
Надо проверить, что будет, если эта команда еще не закончилась, а к контроллеру поступил новый запрос.
- - - Добавлено - - -
Я так думаю, что предполагается, что процессор просто не успеет в течение цикла CLCA запросить следующее чтение у контроллера.
Да как ни крути, установка адреса планов никак не должна автоматически загружать планы из памяти.
А когда же должна? При чтении регистров данных?
А когда же должна? При чтении регистров данных?
Да.
Да.
Так сделали, чтобы РД читались быстрее. Занесли в РА адрес, далее контроллер ПП его сам передаёт видеоконтроллеру, он читает данные и передаёт контроллеру ПП. Остаётся прочесть РД. А так при чтении РД будут запрашиваться данные через видеоконтроллер, придётся ждать.
Так чтение данных ОЗУ при чтении РД сделано в контроллере ЦП, регистры 0176640/0176642. Но тут к самому контроллеру прикручена память, никакого запроса через видеоконтроллер делать не надо.
Так сделали, чтобы РД читались быстрее. Занесли в РА адрес, далее контроллер ПП его сам передаёт видеоконтроллеру, он читает данные и передаёт контроллеру ПП. Остаётся прочесть РД. А так при чтении РД будут запрашиваться данные через видеоконтроллер, придётся ждать.
И так, и так придется ждать, т.к. ПП приостанавливается, пока не будут прочитаны регистры планов 0, 1, 2.
И так, и так придется ждать, т.к. ПП приостанавливается, пока не будут прочитаны регистры планов 0, 1, 2.
Сам ПП не приостанавливается. Приостановится может обращение к ОЗУ, а если программа исполняется в системном ПЗУ, то особых проблем нет.
- - - Добавлено - - -
Я думаю, что комбинацию сигналов RQ, CC0, CC1 можно расшифровать, как Request (о чем всем и так понятно) и Command_Code_0 и Command_Code_1.
Об этом давно говорили большевики (https://zx-pk.ru/threads/30964-revers-inzhiniring-bmk-1515khm1-2.html?p=1071578&viewfull=1#post1071578).
- - - Добавлено - - -
То, о чем 35 лет подряд мечтали миллионы УКНЦ'шников (в лице 5-10 особенно заинтересованных форумчан) свершилось! Загадка записи в раритетные регистры полностью разгадана!
Titus, а когда вы узнали про раритетные регистры? 35 лет назад?
- - - Добавлено - - -
Titus, ещё просьба по описанию записи в регистр октета и регистр адреса планов.
1. Регистр октета. Не расписаны назначения CLCA3_F0 и CLCA3_F3. И на диаграмме почему-то CLCA2_F4 вместо CLCA3_F3.
2. Регистр адреса планов. Не расписаны назначения CLCA4_F0, CLCA4_F4 и CLCA4_F5. И на диаграмме почему-то CLCA2_F5 вместо CLCA4_F5.
Причесал, исправил, сделал схему красивенькой.
1515ХМ1-032-Optimized - rev 43.pdf (https://yadi.sk/i/vOY0B2dtw31cxw)
1515ХМ1-032-Optimized - rev 43.sch (P-CAD 2006) (https://yadi.sk/d/JVxgCXHFdx8brg)
- - - Добавлено - - -
1. Регистр октета. Не расписаны назначения CLCA3_F0 и CLCA3_F3.
F0 - разрешает шинам D и A работать на вывод.
F3 - сброс автомата
- - - Добавлено - - -
2. Регистр адреса планов. Не расписаны назначения CLCA4_F0, CLCA4_F4 и CLCA4_F5.
F0 - разрешает шине A работать на вывод.
F4 - разрешает запись в регистры планов 1 и 2.
F5 - сброс автомата.
- - - Добавлено - - -
Titus, а когда вы узнали про раритетные регистры? 35 лет назад?
Нет, несколько лет назад, на форуме)
- - - Добавлено - - -
Об этом давно говорили большевики.
Значит общее поле сознание дает одинаковые результаты)
- - - Добавлено - - -
Сам ПП не приостанавливается. Приостановится может обращение к ОЗУ, а если программа исполняется в системном ПЗУ, то особых проблем нет.
Работу из ПЗУ я вообще не рассматриваю, т.к. с точки зрения программиста оно для меня не интересно, т.к. оно написано уже сто лет назад. Я пишу программы, которые работают из ОЗУ. А оно приостанавливается, а значит и приостанавливается ПП.
Работу из ПЗУ я вообще не рассматриваю, т.к. с точки зрения программиста оно для меня не интересно, т.к. оно написано уже сто лет назад. Я пишу программы, которые работают из ОЗУ. А оно приостанавливается, а значит и приостанавливается ПП.
Ну как посмотреть. Из ваших же тестов на одной из моих УКНЦ:
MOV (R0),R1 - 36 тактов
MOV R1,(R0) - 36 тактов
MOVB R1,(R0) - 48 тактов
Запись 177010 - 32 такта
Запись 177012 - 36 тактов
Запись 177014 - 28 тактов
MOV (R0),R1 - 36 тактов
MOV R1,(R0) - 36 тактов
MOVB R1,(R0) - 48 тактов
Это запись откуда и куда? Просто в память ПП?
Это запись откуда и куда? Просто в память ПП?
Да, в память ПП. Эти результаты показывает ваш тест TSPSPD.
Странно, что запись в регистр адреса планов быстрее, чем в регистр плана 0.
Что же касается скорости, то моя теория подтверждается.
Записывая в 177012 (регистр плана 0), мы записываем один байт. При этом нам надо еще сделать запись в регистр адреса планов, а это еще 32 такта. Итого, имеем 36+32=66 тактов на байт.
А если мы записываем в память, то получаем 36 тактов на 2 байта, т.е. 18 тактов на байт.
Почувствуйте разницу 18 тактов против 66.
Я привел эти данные для того, чтобы показать, что запись в регистр адреса не будет тормозить процессор. Так как она проходит быстрее, чем прямая запись в ОЗУ. При записи в РА контроллер ПП будет делать свои дела, а процессор свои. Здесь у вас тест написан для команды MOV R1,(R0). Команда занимает одно слово и здесь будет работать предвыборка. Это значит, что пока происходит дешифрация команды, уже будет читаться следующая. Уже потом будет запись в РА, но следующая команда уже прочитана и начинается её дешифрация.
Я привел эти данные для того, чтобы показать, что запись в регистр адреса не будет тормозить процессор. Так как она проходит быстрее, чем прямая запись в ОЗУ. При записи в РА контроллер ПП будет делать свои дела, а процессор свои. Здесь у вас тест написан для команды MOV R1,(R0). Команда занимает одно слово и здесь будет работать предвыборка. Это значит, что пока происходит дешифрация команды, уже будет читаться следующая. Уже потом будет запись в РА, но следующая команда уже прочитана и начинается её дешифрация.
Тут надо рассматривать тему, зная точную растактовку ВМ2. Но все равно запись слова экономичнее, чем запись двух байт по одиночке через регистры.
Надо написать простейшие тесты, которые это покажут.
- - - Добавлено - - -
А про предвыборку я и забыл. Тогда понятно, почему запись в регистр плана 0 медленнее, чем запись в регистры октета и адреса планов. У двух последних сразу идет ответ RPLY, а при записи в регистр плана 0, RPLY только в конце записи.
Тут надо рассматривать тему, зная точную растактовку ВМ2. Но все равно запись слова экономичнее, чем запись двух байт по одиночке через регистры.
Тут и без тестов ясно, что быстрее. Я просто хотел сказать, что запись в РА не особо будет тормозить процессор, что ваши тесты и показали. Ну и разработчики контроллера ПП в данном случае всё правильно сделали - произошла запись в РА, они отпускают шину и далее всё остальное делает контроллер ПП.
Ну и разработчики контроллера ПП в данном случае всё правильно сделали - произошла запись в РА, они отпускают шину и далее всё остальное делает контроллер ПП.
Эти люди явно знали про конвейер)
- - - Добавлено - - -
Тут надо еще, конечно, учесть, что сам процессор достаточно тормозной по сравнению с контроллером, и даже эти многократные пересылки из памяти в регистры планов, начинают выглядеть незначительными на его фоне.
Эти люди явно знали про конвейер)
Это тест так написан, что предвыборка работает на полную катушку. А если команда будет с доступом в ОЗУ, например MOV (R1)+,(R0), либо с нарушением предвыборки - MOV (R1)+,@#177012. Здесь результаты будут уже другими.
- - - Добавлено - - -
Тогда понятно, почему запись в регистр плана 0 медленнее, чем запись в регистры октета и адреса планов. У двух последних сразу идет ответ RPLY, а при записи в регистр плана 0, RPLY только в конце записи.
Для записи планов 1 и 2 контроллер ПП даёт задание видеоконтроллеру, ну и сразу же освобождает шину. А при записи плана 0 он пишет в своё ОЗУ, потому и отвечает RPLY, когда всё закончится.
Дополнение к описанию регистров:
Все остальные регистры, а именно:
SYS_CON (177054, регистр управления адресным пространством),
INK_COL (177016, регистр кода цвета точки),
MASK (177026, регистр маски),
PAPER_LOW и PAPER_HIGH (177020, 177022 - регистры кода цвета фона)
Доступны на чтение и на запись, имеют нулевую задержку доступа и не имеют никакого сложного функционала.
PLANE_ADR (177010, регистр адреса планов)
PLANE0_DATA (177012, регистр данных плана 0)
PLANE12_DATA (177014, регистр данных планов 1 и 2)
Доступны на чтение, имеют нулевую задержку доступа.
Раритетные регистры на чтение недоступны, ответа RPLY не будет.
- - - Добавлено - - -
Titus, Будет время, поправь нумерацию выводов в 120й.
CPU:
DOUTC=>4
DINC=>5
INITC=>9
IAKOC=>8
ARC=>12
RPLYC=>11
PPU:
SYNCP=>30
INITP=>35
DOUTP=>32
A0=>33
A1=>28
Ну и ну, столько ошибок заметил, а то, что не вывел в порт ножку CSP (26) - не заметил)
- - - Добавлено - - -
Зачем нужен выход BS, заведенный на разьем, и устанавливающийся, если адрес выше 0xE000?
Дополнение к описанию регистров:
.........................
INC_COL (177018, регистр кода цвета точки),
MASK (177028, регистр маски),
Наверное всё-таки:
INC_COL (177016, регистр кода цвета точки),
MASK (177026, регистр маски),
Система счисления вроде восьмеричная.
Да и как по чтению регистры данных 177012 и 177014?
Наверное всё-таки:
INC_COL (177016, регистр кода цвета точки),
MASK (177026, регистр маски),
Конечно) Уже глаза слипались) Исправил)
- - - Добавлено - - -
Да и как по чтению регистры данных 177012 и 177014?
Добавил.
- - - Добавлено - - -
Зачем нужен выход BS, заведенный на разьем, и устанавливающийся, если адрес выше 0xE000?
Остался неотвеченным вопрос.
Зачем нужен выход BS, заведенный на разьем, и устанавливающийся, если адрес выше 0xE000?
Остался неотвеченным вопрос.
Оригинальное название BS7, т.е. Bank Select 7, выбор адресов в диапазоне 0160000-0177777. У нас в МПИ назвали ВУ - внешнее устройство. Сигнал выставляется в фазе выдачи адреса, если обращение идёт к внешнему устройству. Это позволяет на внешнем устройстве сделать дешифратор адреса менее сложным, использовать для дешифрации линии AD12-AD00. Были ещё 18-ти и 22-разрядные шины адреса и ВУ устанавливается при обращении к самым старшим 8К адресного пространства.
- - - Добавлено - - -
Добавил.
А можно ещё две диаграммы подправить и написать отсутствующие в описании фазы сигналов.
24-разрядные шины адреса
Наверное, всё таки 22-ух разрядные адреса. Хотя, ЕМНИП, в описании МПИ было упоминание 24-х разрядности, но вроде больше нигде не встречал такого..
А можно ещё две диаграммы подправить и написать отсутствующие в описании фазы сигналов.
В выложенной 1515ХМ1-032-Optimized - rev 43 все уже исправлено.
Что же касается фаз сигналов, то я описывал только важные для понимания сути работы сигналы. Если описывать все, то там еще по странице сигналов на каждое описание добавится.
Наверное, всё таки 22-ух разрядные адреса. Хотя, ЕМНИП, в описании МПИ было упоминание 24-х разрядности, но вроде больше нигде не встречал такого..
Подправил. А 24-разрядная линия адреса вроде была первоначально на VAX'е.
Ну и ну, столько ошибок заметил, а то, что не вывел в порт ножку CSP (26) - не заметил)
Ну тогда уж еще нужна коррекция. Не хватает инверторов на внутренние сигналы:
/DINP
SYNCP
/DINC
SYNCC
В выложенной 1515ХМ1-032-Optimized - rev 43 все уже исправлено.
Что же касается фаз сигналов, то я описывал только важные для понимания сути работы сигналы. Если описывать все, то там еще по странице сигналов на каждое описание добавится.
Жаль. А то с форума очень удобно всё вытащить в Word и распечатать.
А какие-нибудь секреты обнаружены и разгаданы?
Следующим будет видеоадаптер 1515ХМ1-136? По нему сразу вопрос. Он формирует сигнал RAS. Соответственно как контроллеры ПП и ЦП узнают в какой момент выставлять адрес строки. Ведь они же потом выставляют адрес столбца и подают сигнал CAS. И каким образом видеоконтроллер делает регенерацию, у него есть отдельный счетчик, чтобы пробежаться по всем строкам?
А 24-разрядная линия адреса вроде была первоначально на VAX'е.
Тут ничего не могу сказать - по ваксам пока не сильно активно листал доки, тем более по описанию железа. Хотя, когда впервые встретил это дело в описании МПИ (память упорно подсказывает, что там встретил) - тоже подумал, что расширили под ваксы.
Жаль. А то с форума очень удобно всё вытащить в Word и распечатать.
Скорее всего что-то будет еще меняться или дополняться, поэтому эти диаграммы можно считать рабочими материалами, но не финальной редакцией.
- - - Добавлено - - -
А какие-нибудь секреты обнаружены и разгаданы?
Для меня было новостью, что:
1) При записи в регистр адреса планов, читаются все три плана.
2) Работа с регистром октета поделена на две части - часть делается при чтении регистра, часть при записи.
3) Приятной неожиданностью так же было, что при работе с тяжеловесными командами, контроллер отпускает шину, позволяя процессору уже что-то делать.
4) Ну и всякие мелкие нюансы, типа косяков с двойной записью в регистр плана 0 при словной записи.
Больше никаких сюрпризов вроде не было.
- - - Добавлено - - -
Следующим будет видеоадаптер 1515ХМ1-136? По нему сразу вопрос. Он формирует сигнал RAS. Соответственно как контроллеры ПП и ЦП узнают в какой момент выставлять адрес строки. Ведь они же потом выставляют адрес столбца и подают сигнал CAS. И каким образом видеоконтроллер делает регенерацию, у него есть отдельный счетчик, чтобы пробежаться по всем строкам?
Сигнал RAS четко привязан к сигналу PSG, а именно PSG является тактовым для всех операций контроллера ОЗУ ПП.
До регенерации еще не дошел, но похоже, что просто на шину адреса выставляется часть одного из счетчиков.
- - - Добавлено - - -
Мне вот гораздо интереснее, чем может отличаться видеоконтроллер 136 от 036, и контроллеры ПП и ЦП новых и старых версий. Будет прикольно, если вскроется какая-то принципиальная разница.
1) При записи в регистр адреса планов, читаются все три плана.
Это описано в ТО, я это знал. И практические тесты показали, что это так. И это реализовано в эмуляторе UKNCBTL. Единственно, что я не знал, так это что при байтовой записи в РД 0177014, в самом РД меняется только нужный байт, а так видеоконтроллеру передаётся полное слово. Ну в принципе при обмене с видеоконтроллером нет сигнала WTBT.
2) Работа с регистром октета поделена на две части - часть делается при чтении регистра, часть при записи.
Это тоже описано в ТО. Соответственно я знал об этом. Единственно я думал, что при чтении регистра октета 0177024 производится реальное чтение памяти. А оказалось, что нет, просто раскидывается из заранее прочитанных РД 0177012 и 0177014. Также не знал, что при записи в регистр октета реально формируются новые значения РД и они потом записываются. В принципе с аппаратной точки зрения разработчики поступили правильно, раз при записи РА в РД читаются данные из ОЗУ, то с ними и надо делать операции при использовании спрайтового механизма. Дешево и сердито.
Кстати по поводу чтения из регистра октета. С ним я впервые столкнулся с фиктивным чтением команды MOVB. Решил я переделать свой редактор шрифтов FNT, чтобы он работал и в монохромном режиме, который устанавливает драйвер виртуального диска VM для УКНЦ. Так как диск использует старшие 64К из 128К памяти ЦП, то рисовать через 0176640/0176642 нельзя. Надо использовать спрайтовый механизм, который учитывает установки регистра маскирования 0177026. Естественно для вывода я сперва использовал команду MOVB, и весьма удивлялся почему у меня новое изображение накладывается по старому. Применил команду MOV, всё стало нормально. Но сперва был уверен, что регистр октета по другому обрабатывает байтовую запись, а в документации этого не описано.
- - - Добавлено - - -
4) Ну и всякие мелкие нюансы, типа косяков с двойной записью в регистр плана 0 при словной записи.
Будем надеятся, что в 1515ХМ2-002 этот косяк подправили.
Будем надеятся, что в 1515ХМ2-002 этот косяк подправили.
Это легко проверить тестом скорости записи в регистр плана 0. Тест есть. Надо только 2 машины, с 032, и с 002.
Больше никаких сюрпризов вроде не было.
Для меня было сюрпризом, что при записи в раритетные регистры, контроллер ПП делает запрос для записи в видеоадаптер. До этого я считал, что эти регистры внешние, на рассыпухе, а контроллер ПП только формирует сигнал RPLY. Я даже задумывался как на рассыпухе в прототипе организован курсор. Т.к. регистр позиции курсора в раритетных регистрах, то получалось, что есть регистр позиции, счетчик позиции. По сигналам с видеоконтроллера счетчик сбрасывается и инкрементируется, а при равенстве значений и сигнала разрешения курсора вместо изображения выводится цвет курсора.
- - - Добавлено - - -
Это легко проверить тестом скорости записи в регистр плана 0. Тест есть. Надо только 2 машины, с 032, и с 002.
Увы. У меня есть УКНЦ как с видеоконтроллером 1515ХМ1-036, так и с 1515ХМ1-136. Но во всех стоит старый контроллер ПП 1515ХМ1-032.
- - - Добавлено - - -
Мне вот гораздо интереснее, чем может отличаться видеоконтроллер 136 от 036, и контроллеры ПП и ЦП новых и старых версий. Будет прикольно, если вскроется какая-то принципиальная разница.
Вскрытие покажет. Может в контроллере ПП исправили глюк с двойной записью. Да и запись в раритетные регистры можно убрать, они уже не используются в новых видеоконтроллерах.
Это описано в ТО, я это знал. И практические тесты показали, что это так. И это реализовано в эмуляторе UKNCBTL. Единственно, что я не знал, так это что при байтовой записи в РД 0177014, в самом РД меняется только нужный байт, а так видеоконтроллеру передаётся полное слово. Ну в принципе при обмене с видеоконтроллером нет сигнала WTBT.
В EmuStudio реализовано иначе, чем в реальности.
1. При записи в регистр адресов планов, чтение планов в регистры PLANE0_DATA и PLANE12_DATA не производится.
2. При записи в регистры планов, запись в память идет, но данные не сохраняются в регистрах PLANE0_DATA и PLANE12_DATA.
3. Ну и при байтовой записи в регистры планов 1 и 2 записывается только один байт, а второй не трогается.
И при этом ни в какой программе на УКНЦ я графических глюков не заметил)
- - - Добавлено - - -
Для меня было сюрпризом, что при записи в раритетные регистры, контроллер ПП делает запрос для записи в видеоадаптер. До этого я считал, что эти регистры внешние, на рассыпухе, а контроллер ПП только формирует сигнал RPLY. Я даже задумывался как на рассыпухе в прототипе организован курсор. Т.к. регистр позиции курсора в раритетных регистрах, то получалось, что есть регистр позиции, счетчик позиции. По сигналам с видеоконтроллера счетчик сбрасывается и инкрементируется, а при равенстве значений и сигнала разрешения курсора вместо изображения выводится цвет курсора.
Для меня было очевидно, что раритетные регистры внутри 033 контроллера. Оно и логично.
Для меня было очевидно, что раритетные регистры внутри 033 контроллера. Оно и логично.
Для меня сначала было неочевидно. Ведь видеоконтроллер на шину МПИ не выходит.
Для меня сначала было неочевидно. Ведь видеоконтроллер на шину МПИ не выходит.
Гораздо интереснее, если один из владельцев 033 чипа пришлет его на вскрытие (это очередной намек владельцам).
Гораздо интереснее, если один из владельцев 033 чипа пришлет его на вскрытие (это очередной намек владельцам).
Вряд ли. Такую раритетную ЭВМ лучше запустить. Да и владельцы не спешат выкладывать содержимое ПЗУ, что уж тут говорить о вскрытии -033.
Вряд ли. Такую раритетную ЭВМ лучше запустить. Да и владельцы не спешат выкладывать содержимое ПЗУ, что уж тут говорить о вскрытии -033.
По-моему она была подубитая. Да и ПЗУ делятся, только надо в личку попросить.
Думаю, что надо дружно всем уговорить отдать 033, иначе загадка раритетной УКНЦ не будет раскрыта никогда. Документация скудная. Даже эмуляция по ней работает не целиком правильно, т.к. некоторые вещи не описаны.
To Titus.
Еще по 120й.
Нет источников к сигналам INTP и INTC.
Может это INITP и INITC?
Да и ПЗУ делятся, только надо в личку попросить.
В личку я не просил, дал запрос в самой теме про эту УКНЦ. Но мой запрос игнорировали. Titus, а вам дали с условием не выкладывать в общий доступ?
В личку я не просил, дал запрос в самой теме про эту УКНЦ. Но мой запрос игнорировали. Titus, а вам дали с условием не выкладывать в общий доступ?
Да, иначе бы выложил.
- - - Добавлено - - -
Еще по 120й.
Нет источников к сигналам INTP и INTC.
Может это INITP и INITC?
Хорошо, когда кто-то начинает интересоваться темой, сразу ошибки вылезают.
120-я была несколько проходным проектом, т.к. это оптимизация реверса по чужому реверсу. Видимо, побыстренькому делал, вот и позабывал что-то.
Да, иначе бы выложил.
Не очень хорошо поступают, с моей точки зрения. dk_spb выкладывал 135 и 137-ю версии ПЗУ. Я их дизассемблировал, проверил, написал комментарии, конечно не везде. Для полноты картины не хватает 136. Там находятся рисунки символов, описание раскладки клавиатуры, некоторые подпрограммы. Сразу скажу, что эта прошивка кассету ПЗУ и дисковод не использует, скорее всего она какая-то тестовая, ну или действительно для МС-0512.
Еще по 120й.
Нет источников к сигналам INTP и INTC.
Может это INITP и INITC?
Исправленная версия: 1801ВП1-120-Optimized - rev 16.SCH (https://yadi.sk/d/H8roHx1ZoYUWXw)
Из-за того, что внутри ВП1 со многими сигналами работает в инверсном виде (видимо, специфика н-МОП), то их в большом количестве мне приходилось инвертировать приводя в более понятный человеку вид. Разумеется, это большое поля для косяков.
- - - Добавлено - - -
Не очень хорошо поступают, с моей точки зрения. dk_spb выкладывал 135 и 137-ю версии ПЗУ. Я их дизассемблировал, проверил, написал комментарии, конечно не везде. Для полноты картины не хватает 136. Там находятся рисунки символов, описание раскладки клавиатуры, некоторые подпрограммы. Сразу скажу, что эта прошивка кассету ПЗУ и дисковод не использует, скорее всего она какая-то тестовая, ну или действительно для МС-0512.
С моей точки зрения тоже стоит поделится. Но коллекционеры они такие коллекционеры, видимо любят иметь эксклюзив)
Т.е. 136 прошивка это не совсем от раритетной УКНЦ? А почему она тогда заработала в моем эмуляторе, когда я добавил эмуляцию 033?
- - - Добавлено - - -
Напомните, чем 0512 отличалась от 0511 и от раритетной УКНЦ.
Т.е. 136 прошивка это не совсем от раритетной УКНЦ? А почему она тогда заработала в моем эмуляторе, когда я добавил эмуляцию 033?
Она от раритетной УКНЦ. Под раритетной я понимаю УКНЦ с видеоконтроллером 1515ХМ1-033. Но там были полноценная УКНЦ с индексом МС-0511 и сильно обрезанный вариант с индексом МС-0512. От раритетной УКНЦ есть даже ТО, выложено здесь (http://emuverse.ru/wiki/УКНЦ_Техническое_описание_ рототипа). Также проскакивала печатная плата от этой УКНЦ, распиновка разъемов которой полностью совпадает с описанным в ТО. В старой УКНЦ контроллер дисковода был сразу на борту. Та УКНЦ, фото которой выложил xolod, собрана на плате именно от полноценной МС-0511. Но на плате не распаян стык С2, контроллер дисковода, ещё может кое-что по мелочи. Да и прошивки 135-137 соответствуют возможностям именно МС-0512.
В старой УКНЦ контроллер дисковода был сразу на борту.
А почему тогда, если в раритетной УКНЦ дисковод на борту, в прошивке нет работы с диском?
Наверное всё-таки:
INC_COL (177016, регистр кода цвета точки),
Може всё-таки INK_COL? от "ink", чернила.
Може всё-таки INK_COL? от "ink", чернила.
Все так) INK)
А почему тогда, если в раритетной УКНЦ дисковод на борту, в прошивке нет работы с диском?
Ещё раз уточню, что под раритетной УКНЦ я подразумеваю УКНЦ с видеоконтроллером 1515ХМ1-033. Согласно ТО (http://emuverse.ru/wiki/УКНЦ_Техническое_описание_ рототипа), было два варианта - полноценный МС-0511 с контроллером дисковода на борту и обрезанный МС-0512. Так вот прошивка либо от обрезанного МС-0512, либо какая-то тестовая.
Так вот прошивка либо от обрезанного МС-0512, либо какая-то тестовая.
А какой номер у нетестовой прошивки?
А какой номер у нетестовой прошивки?
Кто бы знал. У нас тут много форумчан из Зеленограда, может кто и связан был с НПО "Научный центр", может кто и знает.
Полистал я описание УКНЦ и понял почему ее до сих пор в FPGA нету. По факту нужно 24 битное ОЗУ, доступное сразу от видеоконтроллера, разбитое на два канала 16x64K и 8x64K. В штатные 16-битные SDRAM большинства недорогих отладочных плат сразу так не упакуешь и 192 килобайта это тоже за пределами размеров внутренней памяти младших плисок. Да еще 32 килобайта ПЗУ надо тоже как-то отдавать. Начинать разработку буду на DE2-115, там внутренней памяти хватит на все, потом уже можно думать об оптимизации.
Начинать разработку буду на DE2-115, там внутренней памяти хватит на все, потом уже можно думать об оптимизации.
Так Ynicky уже делает же вроде.
Так Ynicky уже делает же вроде.
Я думаю, Vslav будет делать на структурном описании, так как у него уже есть многое на верилоге. А я хочу сделать на поведенческом описании, где понятна логика, как у тебя в схемах. И чтобы можно было его изменить для дальнейшего усовершенствования УКНЦ, если потребуется.
Подумал что на физическую разделяемую 16-bit SDRAM надо отображение доступа делать кластерами:
+00 cpu word @ 000000
+02 ppu word @ 000000
+04 cpu word @ 000002
+06 empty
+10 cpu word @ 000004
+12 ppu word @ 000002
+14 ppu word @ 000006
+16 empty
Тогда адреса обращений со стороны CPU и PPU просто мапятся сдвигом и инициализацией младших бит, а видеоконтроллер за 8-тактовый пакет сможет вытащить 32 пикселя. И еще есть плюс - PPU можно будеть дать 16-битный доступ в ускоренной версии.
Я думаю, Vslav будет делать на структурном описании, так как у него уже есть многое на верилоге. А я хочу сделать на поведенческом описании, где понятна логика, как у тебя в схемах. И чтобы можно было его изменить для дальнейшего усовершенствования УКНЦ, если потребуется.
Ynicky, поддерживаю - "но два раза это два раза". В том смысле что две разных реализации УКНЦ в FPGA это даже лучше.
Скажите, а вы на какую отладочную плату ориентируетесь? или пока всё чисто лабораторные эксперименты?
- - - Updated - - -
Полистал я описание УКНЦ и понял почему ее до сих пор в FPGA нету.
Я-то думал, это потому что реверса не было, и потому что УКНЦ вообще мало кому была интересна до недавнего времени.
Ynicky, поддерживаю - "но два раза это два раза". В том смысле что две разных реализации УКНЦ в FPGA это даже лучше.
Скажите, а вы на какую отладочную плату ориентируетесь? или пока всё чисто лабораторные эксперименты?У меня две платы. Одна Марсоход 3 с FPGA MAX10 10M50SAE144C8GES. Другая с ALI с Циклоном IV EP4CE40F23C8N. Пока ОЗУ не подключил, поэтому не знаю хватит ли объема внутренней памяти, но на обоих платах есть внешняя SDRAM, которой точно хватит.
Я-то думал, это потому что реверса не было
1801ВМ2 появился уже больше года как, а саму УКНЦ в первом приближении можно накодить по документации (да и ВМ2 можно). Потом уже допилить до точного соответствия по реверсу 1515.
а саму УКНЦ в первом приближении можно накодить по документации
Ну тогда точно работать не будет.
Ну тогда точно работать не будет.
Работать будет, но не точно :) То есть - не в полном соответствии с оригиналом.
Работать будет, но не точно То есть - не в полном соответствии с оригиналом.
Сперва не будет, а после устранения проблем уже не в полном соответствии с оригиналом.
Одна Марсоход 3 с FPGA MAX10 10M50SAE144C8GES
Там 182 блока M9K. Для УКНЦ надо 192, поэтому:
есть внешняя SDRAM, которой точно хватит.
Обдумыванием контроллера которой для построения УКНЦ надо и заняться.
ПЗУ от прототипа УКНЦ Тут. (https://www.dropbox.com/s/w517e5oig1s599a/PreUKNC.zip?dl=0)
Там 182 блока M9K. Для УКНЦ надо 192, поэтому:
Обдумыванием контроллера которой для построения УКНЦ надо и заняться.
Vslav, вопрос, а возможностей девайсов MiST / MiSTer (DE10-Nano + платы расширений) для УКНЦ хватит?
Бонусом тут идёт поддержка набора уже готовых ядер для домашних компьютеров и игровых консолей.
https://github.com/MiSTer-devel/Main_MiSTer/wiki
Vslav, вопрос, а возможностей девайсов MiST / MiSTer (DE10-Nano + платы расширений) для УКНЦ хватит?
Да много каких недорогих плат хватит, если всю память УКНЦ получится на 16-битной SDRAM реализовать. MISTer тоже, конечно, потянет.
Затык в том, что УКНЦ надо 192К памяти, доступ от двух процессоров плюс видеоконтроллер.
Vslav, вопрос, а возможностей девайсов MiST / MiSTer (DE10-Nano + платы расширений) для УКНЦ хватит?
Бонусом тут идёт поддержка набора уже готовых ядер для домашних компьютеров и игровых консолей.
https://github.com/MiSTer-devel/Main_MiSTer/wiki
У MISTERа SDRAM тоже 16bit,
Зато BRAM целых 5,570Kbit., тоесть можно весь RAM и ROM запихнуть в саму FPGA. Но это не спортивно. :v2_dizzy_roll:
Сперва не будет, а после устранения проблем уже не в полном соответствии с оригиналом.
Это поймут не только лишь все)
По документация, а потом уже в неполном соответствии с оригиналом работают эмуляторы.
Тоже, но в железе, я думаю, мало кого заинтересует.
- - - Добавлено - - -
ПЗУ от прототипа УКНЦ Тут.
Теперь надо совершить еще более важный подвиг - отдать ХМ1-033 на реверс)
Очень полезный журнал. Благодаря ему, стало понятно, что я расшифровал схему формирования видеосигнала правильно)
https://pic.maxiol.com/images2/1593117638.531439263.01.png
Тут все видно, что после 288 линий экрана идут 3 пустые строки (строчный синхроимпульс отрицательный), затем идут 3 строки кадрового синхроимпульса, во время которого идут инверсные строчные синхроимпульсы, как мне видится, все же удвоенной частоты. Ну а затем опять 18 строк пустых. Всего 24 строки VBLANK. Все тайминги определил правильно, все строки правильно. Ура) Теперь надо найти стандарт на сихнросмесь, чтобы понять, зачем во время кадрового синхроимпульса, строчные инверсные и удвоенные.
Уточненные времянки строчных и кадрового синхроимпульса:
https://pic.maxiol.com/images2/1596310432.2152434844.01.png
VSYN_V_SYNC - это строчные синхроимпульсы во время кадрового синхроимпульса. Всего 3 периода по 3 синхроимпульса. Итого - 9 синхроимпульсов. Частота импульсов утроена, период не стабилен. Импульсы похожи на уравнивающие синхроимпульсы, но непонятно, зачем такие нестандартные.
VSYN_NO_V_SYNC - это строчные синхроимпульсы во время всех остальных строк. При этом во время кадрового гасящего импульса (3 линии после экрана, 3 линии кадрового синхроимпульса, 18 линий в начале экрана), нет уравнивающих строчных синхроимпульсов с удвоенной частотой. В принципе, оно и понятно, т.к. это необходимо для чересстрочной развертки, но как к этому отнесутся телевизоры - неизвестно.
Итого:
1. Передних уравнивающих синхроимпульсов нет (3 линии в конце экрана).
2. Кадровый синхроимпульс нестандартен, наполнен строчными синхроимпульсами условно утроенной частоты с неодинаковым периодом (3 линии).
3. Задних уравнивающих синхроимпульсов нет (18 линий в начале экрана).
- - - Добавлено - - -
Что касается уровня видеосигнала, то судя по номиналам деталей в схеме, уровень белого действительно около 1В, а уровень черного несколько завышен, около 0.55В (по стандарту 0.3В). Таким образом, мы имеем размах где-то около 0.45В, вместо 0.7В. Это большая яркость изображения, и меньшая контрастность.
Всё прописано в госте - "мутно", но есть
http://docs.cntd.ru/document/gost-7845-92
Нашел ошибочку в реверсе 136-й (особенно это касается Ynicky, который делает FPGA по еще не оптимизированным реверсам).
У элемента A61.2 надо инвертировать выход, а то сигнал WE будет инверсным.
Это справедливо, как для неоптимизированной схемы, так и для оптимизированной.
Обычно на реверс у меня где-то 2-3 ошибки, которые исправляются в процессе оптимизации и проверки. Это весьма неплохой результат, учитывая общее количество элементов и соединений.
Вопрос к PDP-шникам - зачем шины адреса ОЗУ подтянуты через резисторы на +5В? Ведь на этих шинах нет ни одного устройства с открытым коллектором, только комплиментарные выходы. Может быть, чтобы меньше звенели в моменты, когда шина в Z-состоянии?
И еще, не обратил внимания сразу - адреса и данные памяти инвертированы)
ХМ1-136: Растактовка команды записи в регистр планов 1 & 2.
https://pic.maxiol.com/images2/1596384182.2152434844.01.png
Описание:
Операция начинается по команде WRITE_PLANE12 (RQ = 1, CC0 = 1, CC1 = 0). Используется при записи в регистр планов 1&2 (PLANE12, адрес 177014), а также при записи в регистр октета (OCTET_MASK, адрес 177024).
Слот видеоконтроллера:
Такты 4..7 - чтение видеоконтроллером ОЗУ ПП и ЦП.
Слот ПП и ЦП:
Такт 8 - контроллером ПП на шину AG0..AG7 выставляется старшая часть слова данных.
Такт 8.5 - контроллером ПП на шину DG0..DG7 выставляется младшая часть слова данных.
Такт 9..10 - защелкивание данных в регистрах DC_H, DC_L по сигналу A_D_LATCH.
Такты 12..20 - устанавливается сигнал CPU_REQUEST, во время которого блокируется сигнал PSC.
Слот видеоконтроллера:
Такты 12..15 - чтение видеоконтроллером ОЗУ ПП и ЦП.
Слот ПП и ЦП:
Такт 16 - на шину AC0..AC7 выводится младшая часть адреса из регистра PLANE_ADR_L. Сигнал WE установлен, что означает запись в ОЗУ.
Такт 16.5 - на шину DC0..D15 выводятся данные из регистров DC_H, DC_L.
Такт 17 - устанавливается сигнал NRAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса).
Такт 17.5 - на шину AC0..AC7 выводится старшая часть адреса из регистра PLANE_ADR_H.
Такт 18 - устанавливаются сигналы CAS1, CAS2, по которым в ОЗУ защелкивается адрес столбца (старшая часть адреса).
Такт 19.5 - снимается сигнал NRAS, по которому данные запоминаются в ОЗУ.
Такт 20 - завершение операции.
Замечания и особенности работы:
1. За пол-такта до перевода шин адреса AC и AG в Z-состояние, на шину адреса выставляется значение 0x00 (высокие уровни на шине), и уже потом через пол-такта шина переводится в Z-состояние. Вероятнее всего это сделано для уменьшения шума на шине, т.к. в Z-состоянии шина также притягивается через резисторы к плюсу питания.
Однако, в контроллере ОЗУ ПП, работающем на той же шине, такой особенности не реализовано.
2. Отличается логика выставления старшей части адрреса на шины AC и AG (сигнал SEL_ADR_HIGH) для слотов видеоконтроллера, и слотов ПП и ЦП. Смысл этого непонятен, т.к. в слотах ПП и ЦП шины AC и AG в Z-состоянии, и любые внутренние манипуляции с адресами бессмысленны. Возможно, это побочный эффект избыточной логики, которая уже встречалась в данном чипе (проверка наличия одновременно двух сигналов - CLCA и PCLC_8 в F73.2.D69 и E73.D67, хотя эти сигналы абсолютно идентичны).
ХМ1-136: Растактовка команды записи в регистр адреса планов.
https://pic.maxiol.com/images2/1596405571.2152434844.01.png
Описание:
Операция начинается по команде WRITE_PLANE_ADR (RQ = 1, CC0 = 0, CC1 = 0). Используется в первой фазе при записи в регистр адреса планов (PLANE_ADR, адрес 177010).
Слот видеоконтроллера:
Такты 4..7 - чтение видеоконтроллером ОЗУ ПП и ЦП.
Слот ПП и ЦП:
Такт 8 - контроллером ПП на шину AG0..AG7 выставляется старшая часть регистра адреса планов PLANE_ADR.
Такт 8.5 - контроллером ПП на шину DG0..DG7 выставляется младшая часть регистра адреса планов PLANE_ADR.
Такт 9..10 - защелкивание данных в регистрах PLANE_ADR_H, PLANE_ADR_L по сигналу A_D_LATCH.
Такты 12..20 - устанавливается сигнал CPU_REQUEST, во время которого блокируется сигнал PSC.
Слот видеоконтроллера:
Такты 12..15 - чтение видеоконтроллером ОЗУ ПП и ЦП.
Слот ПП и ЦП:
Такт 16 - на шину AC0..AC7 выводится младшая часть адреса из регистра PLANE_ADR_L.
Такт 17 - устанавливается сигнал NRAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса).
Такт 17.5 - на шину AC0..AC7 выводится старшая часть адреса из регистра PLANE_ADR_H.
Такт 18 - устанавливаются сигналы CAS1, CAS2, по которым в ОЗУ защелкивается адрес столбца (старшая часть адреса). В течение активного сигнала CAS, данные с шины DC0..DC15 защелкиваются в регистрах DC_H, DC_L, причем, DC_H защелкивается в инверсном виде.
Такт 19.5 - снимается сигнал NRAS.
Такт 20 - завершение операции.
Замечание:
Команда ХМ1-136 записи в регистр адреса планов (Command Code - WRITE_PLANE_ADR) вовсе не то же самое, что запись в регистр адреса планов для ХМ1-032.
Запись в регистр адреса (PLANE_ADR, адрес 177010) состоит из двух последовательных команд:
1. WRITE_PLANE_ADR - запись адреса планов в видеоконтроллер, и чтение планов 1 и 2 в регистр данных видеоконтроллера.
2. READ_PLANE12 - чтение регистра данных видеоконтроллера контроллером ПП.
- - - Добавлено - - -
1. За пол-такта до перевода шин адреса AC и AG в Z-состояние, на шину адреса выставляется значение 0x00 (высокие уровни на шине), и уже потом через пол-такта шина переводится в Z-состояние. Вероятнее всего это сделано для уменьшения шума на шине, т.к. в Z-состоянии шина также притягивается через резисторы к плюсу питания.
Немного поразмышляв, я понял, что это сделано затем, чтобы разнести по времени изменения на шинах адреса, относительно других процессов, которые в большинстве своем синхронизированы с CLCA, и наступают на пол-такта позднее. Таким же образом разнесена установка данных на шинах АG и DG. На DG данные выставляются на пол-такта позже.
ХМ1-136: Растактовка команды чтения планов 1 и 2.
https://pic.maxiol.com/images2/1596450782.2152434844.01.png
Описание:
Операция начинается по команде READ_PLANE12 (RQ = 1, CC0 = 0, CC1 = 1). Используется во втрой фазе при записи в регистр адреса планов (PLANE_ADR, адрес 177010).
Слот видеоконтроллера:
Такты 4..7 - чтение видеоконтроллером ОЗУ ПП и ЦП.
Слот ПП и ЦП:
Такт 8 - на шину AG0..AG7 выводится старшая часть регистра DC_H в инверсном виде.
Такт 8.5 - на шину DG0..DG7 выводится младшая часть регистра DC_L.
Такты 8..10 - информация с шин AG и DG защелкивается в контроллере ПП, в регистрах PLANE2_DATA и PLANE1_DATA, соответственно.
Такт 16 - завершение операции.
Замечания:
1. При операции записи в регистр адреса планов, старший байт данных планов 1&2 внутри видеоконтроллера хранится в инверсном виде. Очевидно, это сделано для упрощения схемы.
2. Не смотря на то, что между слотом видеоконтроллера и слотом ПП и ЦП, шина адреса AG не переходит в Z-состояние, из-за недоработки в схеме, за пол-такта до слота ПП и ЦП, на шину AG выводится байт 0x00, после чего через пол-такта на шину выводится старшая часть регистра DC_H. Методика, которая изначально была рассчитана на сокращения шумов на шине, в данном случае наоборот порождает лишние шумы.
То, чего так долго ждали миллионы любителей УКНЦ, свершилось!
Последняя из 4 микросхем оптимизирована, причесана и сделана красивой.
1515ХМ1-136-Optimized - rev 42.pdf (https://yadi.sk/i/yg7Z2ot1M2ud-w)
1515ХМ1-136-Optimized - rev 42.sch (P-CAD 2006) (https://yadi.sk/d/S505An22gdIntA)
p.s.: Что еще хорошо бы сделать:
1. Расписать подробно работу видеоконтроллера (выше были диаграммы лишь арбитра ОЗУ ПП и ЦП).
2. Расписать подробно работу контроллера ОЗУ ЦП.
Моделирую горизонтальный счетчик. Почему-то HCTR после значения 799 становится равным 32 вместо 0. И период HBLANK равет 61,44 мкс вместо 64 мкс. Пока не пойму почему. Может я не правильно перевел схему, но проверил и ошибок не нашел.
Моделирую горизонтальный счетчик. Почему-то HCTR после значения 799 становится равным 32 вместо 0. И период HBLANK равет 61,44 мкс вместо 64 мкс. Пока не пойму почему. Может я не правильно перевел схему, но проверил и ошибок не нашел.
Очень странно. Я по своей же схеме моделировал (теоретически на бумажке), после 799 становится 0. Посмотрю еще раз.
- - - Добавлено - - -
Ну вот смотри, у тебя остается включенным разряд D5, т.е. триггер для PCLC_64.
Он управляется элементом G57, который обеспечивает тактовый сигнал при следующих условиях:
1) Разряд D0 переключился из 1 в 0.
2) Разряды D1..D4 равны 1.
3) В разрядах D9.D8 не %11.
Скорее всего у тебя ошибка в элементе J73.2 или на входе G57, к которому он подключен.
Скорее всего у тебя ошибка в элементе J73.2
Точно, забыл описать. И ведь ModelSim при этом не выдал Х!!!
Вопрос по 136й. На вход элемента D68 поступает сигнал /PSC. С таким же названием есть выходной порт P55. Есть внутренний сигнал PSC с выхода элемента B59.B60. Так что должно поступать на D68? То ли выходной порт, то ли сигнал PSC через инвертор.
Вопрос по 136й. На вход элемента D68 поступает сигнал /PSC. С таким же названием есть выходной порт P55. Есть внутренний сигнал PSC с выхода элемента B59.B60. Так что должно поступать на D68? То ли выходной порт, то ли сигнал PSC через инвертор.
Выходные порты внутри ни на что не поступают напрямую.
На этот элемент должен идти сигнал PSC через интвертор, который я забыл сделать)
- - - Добавлено - - -
Какие вообще успехи в моделировании? Что уже реализовал, что заработало?
Какие вообще успехи в моделировании? Что уже реализовал, что заработало?Полностью описал ВП1-120, ХМ2-001, ХМ1-032. Сейчас доделываю ХМ1-136. Моделирую пока не отдельно эти м/с, а проект УКНЦ с одной ПЗУ (о160000). Как допишу 136ю, вместо штатной ПЗУ поставлю свою прошивку с тестами, которые буду еще писать. Пока много времени провожу на даче (т.к. в отпуске).
Полностью описал ВП1-120, ХМ2-001, ХМ1-032. Сейчас доделываю ХМ1-136. Моделирую пока не отдельно эти м/с, а проект УКНЦ с одной ПЗУ (о160000). Как допишу 136ю, вместо штатной ПЗУ поставлю свою прошивку с тестами, которые буду еще писать. Пока много времени провожу на даче (т.к. в отпуске).
Не очень понял для чего нужна своя прошивка с тестами. В меню загрузки УКНЦ есть пункт тестирования, тесты там довольно подробные.
Не очень понял для чего нужна своя прошивка с тестами. В меню загрузки УКНЦ есть пункт тестирования, тесты там довольно подробные.Для проверки по штатным тестам еще далеко. Да и пока проект только наполовину реализован (нет ЦП, ХМ1-039 и др.). Сначала надо отмоделировать то, что есть, по временным диаграммам.
Еще замечу для Ynicky, что счетчики CTR_LINE_ADR_L, CTR_LINE_ADR_H, U20 - с ускоренным переносом. Если их сделать по обычной схеме, будет ай-яй-яй.
Еще замечу для Ynicky, что счетчики CTR_LINE_ADR_L, CTR_LINE_ADR_H, U20 - с ускоренным переносом. Если их сделать по обычной схеме, будет ай-яй-яй.А я их сделал не по обычной схеме, а по поведенческому описанию. А уже синтезатор их переведет в схему (библиотечные элементы) как надо, в зависимости от заданных констрейнов (например рабочая частота).
mk_sCTR_LINE_ADR_L:
process (sPCLC_Q,sLOAD_LINE_ADR_L,sDGIN)
begin
if sLOAD_LINE_ADR_L = '1' then
sCTR_LINE_ADR_L <= sDGIN;
elsif (sPCLC_Q(2) = '1' and sPCLC_Q(2)'event) then
sCTR_LINE_ADR_L <= sCTR_LINE_ADR_L + "1";
end if;
end process;
А я их сделал не по обычной схеме, а по поведенческому описанию. А уже синтезатор их переведет в схему (библиотечные элементы) как надо, в зависимости от заданных констрейнов (например рабочая частота).
Я не разбираюсь в вышеприведенном языке.
А разница между обычным счетчиком и счетчиком с ускоренным переносом большая.
Обычный меняет свое состояние конвейерно, от младших бит к старшим. А счетчик с ускоренным переносом - одновременно. Если не предусмотреть это, то схема может работать некорректно.
счетчик с ускоренным переносом - одновременноСинтезаторы (в том числе и Quartus) так и делают.
Синтезаторы (в том числе и Quartus) так и делают.
К сожалению - нет. Уже не раз синтезировал такие счётчики у себя и порой ловил глитчи на них, потому что биты выставлялись асинхронно новые. Было очень заметно, потому что это было в генераторе видеосигнала, логика сброса счётчиков и формирование сигнала конца строки (для инкремента по Y) была полностью асинхронной - в итоге иногда при запуске на FPGA пролетало 2 инкремента подряд, в итоге видеосигнал не определялся монитором вообще.
Так что, если логика после счётчиков асинхронная - надо делать схему с ускоренным переносом или буферировать.
А приведённый выше код Quartus собирал цепочкой D-триггеров банально - посмотри, что вышло в Post-Fit.
Да, не понятно почему выходные биты идут через комбинаторную логику.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity cnt is
port(ld, clk : in std_logic;
din : in std_logic_vector(2 downto 0);
qout : out std_logic_vector(2 downto 0));
end;
architecture behavior of cnt is
signal sCNT: std_logic_vector(2 downto 0);
begin
process (ld,clk,din)
begin
if ld = '1' then
sCNT <= din;
elsif (clk = '1' and clk'event) then
sCNT <= sCNT + "1";
end if;
end process;
qout <= sCNT;
end;
https://pic.maxiol.com/thumbs2/1596812606.1845267026.cntmap3.jpg (https://pic.maxiol.com/?v=1596812606.1845267026.cntmap3.jpg&dp=2)
- - - Добавлено - - -
А если загрузку сделать синхронной, то выходы от триггеров:
process (ld,clk,din)
begin
if (clk = '1' and clk'event) then
if ld = '1' then
sCNT <= din;
else sCNT <= sCNT + "1";
end if;
end if;
end process;
https://pic.maxiol.com/thumbs2/1596813333.1845267026.cntmap4.jpg (https://pic.maxiol.com/?v=1596813333.1845267026.cntmap4.jpg&dp=2)
Да, не понятно почему выходные биты идут через комбинаторную логику.
Надо смотреть шаблоны. Со счётчиками ещё не имел дело, в основном - блоки памяти. Немного отошёл от шаблона - и усё, вместо использования встроенных блоков памяти - куча триггеров (вплоть до исчерпания максимального количества ЛЭ).
Ну раз такое дело, сделаю счетчики на россыпи.
Да, не понятно почему выходные биты идут через комбинаторную логику.
...
А если загрузку сделать синхронной, то выходы от триггеров:
Вот именно потому что если загрузка асинхронная, то получаем латч и выходы комбинаторикой нагружаем.
Я не очень понимаю, это для моделирования (тогда латчи пофиг) или синтеза? Если синтез, то неужели Квартус не ругается?
Это синтез. И не ругается. Только сообщает о LATCH.
Warning (13004): Presettable and clearable registers converted to equivalent circuits with latches. Registers power-up to an undefined state, and DEVCLRn places the registers in an undefined state.
Warning (13310): Register "sCNT[0]" is converted into an equivalent circuit using register "sCNT[0]~_emulated" and latch "sCNT[0]~1"
Warning (13310): Register "sCNT[1]" is converted into an equivalent circuit using register "sCNT[1]~_emulated" and latch "sCNT[1]~5"
Warning (13310): Register "sCNT[2]" is converted into an equivalent circuit using register "sCNT[2]~_emulated" and latch "sCNT[2]~9"
Это синтез. И не ругается. Только сообщает о LATCH.
Warning (13004): Presettable and clearable registers converted to equivalent circuits with latches. Registers power-up to an undefined state, and DEVCLRn places the registers in an undefined state.
Warning (13310): Register "sCNT[0]" is converted into an equivalent circuit using register "sCNT[0]~_emulated" and latch "sCNT[0]~1"
Warning (13310): Register "sCNT[1]" is converted into an equivalent circuit using register "sCNT[1]~_emulated" and latch "sCNT[1]~5"
Warning (13310): Register "sCNT[2]" is converted into an equivalent circuit using register "sCNT[2]~_emulated" and latch "sCNT[2]~9"
Это и есть "ругается" - оно же явно пишет, что "добавило latch". Если писать всё нормально, такого не пишет.
Titus, выложи, пожалуйста, схемы ХМ2-001, ХМ2-003 в формате пикада, а то в PDF поиск по названиям сигналов не работает.
@Titus, выложи, пожалуйста, схемы ХМ2-001, ХМ2-003 в формате пикада, а то в PDF поиск по названиям сигналов не работает.
Только в 003 я начал некоторый рефакторинг работы с памятью, и еще не закончил. Ничего принципиально не поменялось, поменялась оптимизация и полярности сигналов. И в блоке прерываний тоже)
Описание циклов памяти видеоконтроллера.
Один цикл памяти видеоконтроллера равен 4 тактам PCLK (PCLK - PixelClock). Один такт - это 80нс, или 12.5МГц, или одна точка в высоком разрешении экрана.
Все четные циклы отданы видеоконтроллеру, а нечетные - контроллерам памяти ПП и ЦП, или арбитру ПП и ЦП в составе видеоконтроллера, если это необходимо.
В итоге на 800 горизонтальных точек высокого разрешения (640 видимых точек и 160 точек интервала HBlank) приходится 100 циклов памяти видеоконтроллера. А на один кадр развертки - 100 * 312 = 31200 циклов памяти видеоконтроллера. Учитывая, что за один цикл читается три поля памяти (два плана из ОЗУ ЦП, и один план из ОЗУ ПП), за один кадр видеоконтроллером читается 93600 байт информации.
В дальнейшем, циклом памяти будем называть цикл памяти видеоконтроллера.
Интервал HBlank:
Во время интервала HBlank (точки 640..799, циклы памяти 80..99) для каждой строки происходит два процесса:
1. Регенерация памяти.
2. Считывание новых данных из списка строк ПП.
Причем, считывание новых данных из списка строк ПП происходит в течение всех 312 строк развертки, а не только видимых 288 строк.
Регенерация памяти:
Регенерация памяти происходит прозрачным способом в цикле HBlank (циклы 80..99, всего 20 циклов).
Старший байт адреса - всегда CTR_MEM_ADR_H (регистр адреса строки экрана).
Младший байт адреса изменяется от 0 до 127, и составляется из:
0./VCTR_D3./VCTR_D2./VCTR_D1./VCTR_D0./HCTR_D5./HCTR_D4./HCTR_D3
Таким образом, за каждые 16 линий развертки (0.58мс) будет регенерирована вся память. Исключение составляют линии экрана 304..311 (8 линий развертки), во время которых будет регенерирована лишь половина памяти, после чего начнется следующий кадр, и регенерация возобновится сначала. Таким образом, период регенерации, попавший на последние 8 линий экрана будет длиться не 0.58мс, а 0.29 + 0.58 = 0.87мс. Исходя из вышеперечисленных параметров, подойдет любая память с матрицей 128x512 (т.к. регенерируется только 128 строк памяти), и периодом регенерации >= 0.9мс.
Для ОЗУ ПП циклы 88..95 (8 циклов) - это всегда циклы чтения списка строк экрана.
Таким образом, для ОЗУ ПП:
Циклы 80..87 - это регенерация 8 строк памяти.
Циклы 88..95 - это 8 циклов чтения списка строк.
Циклы 96..99 - это 4 побочных цикла повторной регенерации 4 строк памяти.
Для ОЗУ ЦП:
Циклы 80..87 - это регенерация 8 строк памяти.
Циклы 88..95 - повторная побочная регенерация 8 строк памяти.
Циклы 96..99 - 4 побочных цикла повторной регенерации 4 строк памяти.
Чтение списка строк (циклы 88..95):
Чтение списка строк происходит только из ОЗУ ПП. ОЗУ ЦП в это время повторно регенерируется, как было описано выше.
Адрес элемента списка составляется из битов 15..3 регистра ENTRY_ADR и HCTR_D5.HCTR_D4.HCTR_D3 для четырехсловного элемента списка, и из битов 15..2 регистра ENTRY_ADR и HCTR_D4.HCTR_D3 для двухсловного элемента списка.
Если бит 1 (ENTRY_SIZE) регистра ENTRY_ADR (регистр адреса следующего элемента списка) равен нулю, то циклы 88..91 читают данные в никуда (используется при двухсловном элементе списка).
Если бит 1 (ENTRY_SIZE) равен единице, то в циклах 88..91 читаются два слова четырехсловного элемента списка (используется при четырехсловном элементе списка):
Если бит 2 (ENTRY_DATA_Q2) = 0:
Цикл 88: Чтение регистра CUR_CON_L (младшая часть первого слова регистра управления отображением).
Цикл 89: Чтение регистра CUR_CON_H (старшая часть первого слова регистра управления отображением).
Цикл 90: Чтение регистра DISP_CON_L (младшая часть второго слова регистра управления отображением).
Цикл 91: Чтение в никуда.
Если бит 2 (ENTRY_DATA_Q2) = 1:
Цикл 88: Чтение регистра COL_CON_1_L (младшая часть первого слова регистра управления цветом).
Цикл 89: Чтение регистра COL_CON_1_H (старшая часть первого слова регистра управления цветом).
Цикл 90: Чтение регистра COL_CON_2_L (младшая часть второго слова регистра управления цветом).
Цикл 91: Чтение регистра COL_CON_2_H (старшая часть второго слова регистра управления цветом).
Цикл 92: Чтение регистра МЕМ_ADR_L (младшая часть регистра адреса начала строки).
Цикл 93: Чтение регистра МЕМ_ADR_H (старшая часть регистра адреса начала строки).
Цикл 94: Чтение регистра ENTRY_ADR_L (младшая часть регистра адреса следующего элемента списка).
Цикл 95: Чтение регистра ENTRY_ADR_H (старшая часть регистра адреса следующего элемента списка).
Регистр ENTRY_ADR_L буферизирован. В цикле 94 данные сперва загружаются в регистр ENTRY_ADR_CACHE, а уже в цикле 95 переписываются в ENTRY_ADR_L синхронно с обновлением ENTRY_ADR_H.
Отображение одной строки экрана (точки 0..640, циклы памяти 0..79):
Каждый цикл происходит чтение памяти по адресу CTR_MEM_ADR. Это не зависит ни от разрешения экрана, ни от того, активен ли в данный момент интервал VBlank.
Счетчик CTR_MEM_ADR (адрес строки) загружается из списка строк в конце каждой строки (циклы 92 и 93), и инкрементируется при переходе от одного знакоместа к другому. В зависимости от разрешения экрана - это каждая 8, 16, 32 или 64 точка, что соответствует каждому 1, 2, 4 или 8 циклу памяти. Во время интервалов VBlank и HBlank инкремента не происходит.
Интервал VBlank (строки 288..311):
Интервал VBlank практически не влияет на работу видеоконтроллера, за исключением того, что во время строк 291..293 вырабатытвается синхросигнал V_SYNC, а во время строки 292, и позиции 0..511 (цикл памяти 0..63) выставляется сигнал EVNT (сетевой таймер 50Гц).
Также во время интервалов HBlank и VBlank блокируется инкремент счетчика CTR_MEM_ADR (адрес строки), а видеовыход маскируется, выдавая нули на PL0, PL1, PL2 и Y, и единицы на /P0, /P1, /P2.
Начальное состояние регистров:
В начале каждого кадра по сигналу EVNT (первые 64 цикла 292-й строки) инициализируется содержимое регистров:
1. ENTRY_ADR (регистр адреса следующего элемента списка) = 0x00B8 (курсор выключен, двухсловный элемент списка).
2. ENTRY_ADR_CACHE (буферный регистр для ENTRY_ADR_L) = 0x00 (ненужное действие).
3. CUR_FLIP_TRIGGER - курсор выключен.
4. Регистры палитры COL_CON_1_L, COL_CON_1_H, COL_CON_2_L и COL_CON_2_H инициализируются значениями 0x10, 0x32, 0x54, 0x76 соответственно (все цвета от черного к белому, пониженной яркости).
5. CUR_CON (первое слово регистра управления отображением) = 0x0008 (курсор в 0-й позиции, символьный, цвет черный повышенной яркости).
6. Биты 4 и 5 регистра DISP_CON (второe словo регистра управления отображение) сбрасываются (высокое разрешение), биты 0..2 (эмфазис компонент R, G, B) - без изменения.
Замечание: Если после включения компьютера ни разу не использовать 4-хсловный элемент списка с инициализацией регистра управления отображения, то эмфазис (выделение) цветовых компонент будет установлен как попало.
p.s.: При более рациональном построении видеоконтроллера, гораздо больше циклов памяти могло бы быть отдано ПП и ЦП. Нагрузка на память оправдана только для разрешения 640. В более низких разрешениях память простаивает (циклы чтения идут в никуда). Также циклы памяти HBlank могли бы быть отданы ПП и ЦП.
Titus, не понял отсюда такой момент - влияет ли масштабирование в строке на количество обращений к памяти? Т.е. если все строки будут x2, то значит ли что обращений будет почти вдвое меньше, или столько же?
А, увидел постскриптум, тогда понятно - обращений столько же, экономии нету :-(
А, увидел постскриптум, тогда понятно - обращений столько же, экономии нету :-(
Вообще никакой экономии нет ни от чего) Память насилуется и в хвост, и в гриву, и зачастую половина этого насилия вхолостую.
- - - Добавлено - - -
Каждый цикл происходит чтение памяти по адресу CTR_MEM_ADR. Это не зависит ни от разрешения экрана, ни от того, активен ли в данный момент интервал VBlank.
Вот здесь то, о чем ты спрашивал.
Иными словами, если разрешение 640, то мы для каждого байта экрана делаем одно чтение из памяти. Самый рациональный режим. Если разрешение 320, то мы каждый байт читаем два раза. Если 160, то 4 раза, если 80, то 8 раз.
Вопросы к Titus - у. В ХМ2-001 на элемент Y_MEMORY_A должен приходить инверсный сигнал /INIT или положительный, для обнуления (или установки с учетом выходной инверсии) выхода?
А также сигнал KEY_MISMATCH будет в 1 когда Y_MEMORY_B и Y_MEMORY_C равны?
А также сигнал KEY_MISMATCH будет в 1 когда Y_MEMORY_B и Y_MEMORY_C равны?
Да.
Возможно, я еще что-то переоптимизирую, поменяю где-то полярности и в этой схеме.
- - - Добавлено - - -
на элемент Y_MEMORY_A должен приходить инверсный сигнал /INIT или положительный, для обнуления (или установки с учетом выходной инверсии) выхода?
Да, я думаю, что полярность его перепутана. Надо исправить на INIT.
Особенности работы видеоконтроллера ХМ1-136 по краям кадра на примере режима высокого разрешения 640 точек.
https://pic.maxiol.com/images2/1597243930.2152434844.01.png
Правый край кадра:
Такт 8 (такт 640 HCTR) - Защелкивание в регистрах REG_PLANE0,1,2 последнего байта экрана. Сигнал HBLANK становится активным, но пока что ни на что не действует.
Такт 8-15 - Последовательный вывод точек 0..7 в REG_PAL_ADR.
Такт 15 - По переднему фронту сигнала PSG (при активном HBLANK) устанавливается INIT_BIT_CTR.
Такт 17 - По заднему фронту CLC1 снимается сигнал ENABLE_PLANES.
Такт 18 - Видеопорт выключается.
Левый край кадра:
Такт 8 (такт 0 HCTR) - Снятие сигнала HBLANK.
Такт 15 - Снятие сигнала INIT_BIT_CTR.
Такт 16 - Защелкивание в регистрах REG_PLANE0,1,2 первого байта экрана.
Такт 17 - Установка сигнала ENABLE_PLANES.
Такт 18 - Видеопорт включается.
Реальный вывод изображения задерживается на время 10 пикселей высокого разрешения. Из которых задержка 8 пикселей - это регистры REG_PLANE0,1,2, из которых последовательно выдается регистру палитры 8 пикселей. Задержку на 1 пиксель дает регистр палитры REG_PAL_ADR. И, наконец, задержку на 1 пиксель дает выходной регистр видевыхода REG_VIDEO.
Некоторые дополнения к ХМ2-003.
1. У элемента H40 следует инвертировать выход (внимание для Ynicky, который делает модель по донепричесанным реверсам).
2. Недокументированный и невыведенный выход UNK активен всякий раз, когда идет обращение к регистру, отсутствующему в ХМ2-003. Это может быть, как просто несуществующий регистр, так и любой регистр в составе другого устройства на шине. Устаналивается по DIN/DOUТ, и сбрасывается при снятии SYNC.
3. Недокументированный выход FD (делитель CLK на 1.5, и выдающий 4.16МГц) я думаю, следует расшифровать, как Frequency Divider.
4. Из-за того, что в режиме ST сигнал RPLY выдается сразу же, возможно не исключен конфликт при доступе к какому-либо регистру или ячейке памяти, на который настроена ловушка адреса. Это надо проверять конкретнее.
5. На мой взгляд, ловушку адреса в чип запихнули только потому, что он полу-пустой. Чтобы хоть чем-то его заполнить, сделали ловушку.
У элемента H40 следует инвертировать выход
Он уже с инверсией. Т.е. нужно убрать инверсию?
И еще, наверное, A40.A41 должен быть XOR, а не OR.
Он уже с инверсией. Т.е. нужно убрать инверсию?
Да. Инвертировать инверсию - это ее убрать)
- - - Добавлено - - -
И еще, наверное, A40.A41 должен быть XOR, а не OR.
А он и есть XOR.
=1 - это XOR
1 - это OR
А он и есть XOR.
=1 - это XOR
1 - это OR
У меня на пикадовской схеме 1. Хотя сам элемент XOR.
P.S. После перевода в Altium знак = исчез.
Надо будет все такие элементы проверить.
У меня на пикадовской схеме 1. Хотя сам элемент XOR.
P.S. После перевода в Altium знак = исчез.
Надо будет все такие элементы проверить.
Поставь PCAD 2OO6 и будет тебе щассье.
4. Из-за того, что в режиме ST сигнал RPLY выдается сразу же, возможно не исключен конфликт при доступе к какому-либо регистру или ячейке памяти, на который настроена ловушка адреса. Это надо проверять конкретнее.
Да, конфликт будет, проверял на реальной УКНЦ. Так как ОЗУ медленное, если ловушка настроена на ячейку ОЗУ с выдачей сигнала ПОРТ, то при чтении этого адреса ловушка быстрее отвечает и читается ноль.
Titus, а у меня в вам вопрос по поводу формирования сигнала ST. В оптимизированной схеме ревизии 19 в контроллере прерываний условием для прерывания служит логическое выражение (SYNC & TRAP_CON_Q0 & IRQ_EN) & ADR_EQUAL, построенное на элементах K14 и K13. Т.е. условие для прерывание вырабатывается тогда когда нужный адрес, активен SYNC, установлены разряды 0 и 8 в регистре 0176644. Здесь я полностью согласен. Условие для выработки сигнала ПОРТ (он же ST) должно быть аналогичным, только при сброшенном нулевом разряде регистра 0176644. Собственно элемент K15 и делает это - SYNC & /TRAP_CON_Q0 & IRQ_EN. Но вот далее элемент K16 почему-то условие с K15 и ADR_EQUAL складывает по ИЛИ. Таким образом ST будет выставляться при любом адресе, когда активен SYNC, а также при запрограммированном адресе, независимо от настроек в регистре 0176644. По логике K16 также должен быть элементом 2И.
Но вот далее элемент K16 почему-то условие с K15 и ADR_EQUAL складывает по ИЛИ.
Почему по или? K15 и К16 - оба элементы AND (И) (значок &).
Почему по или? K15 и К16 - оба элементы AND (И) (значок &).
В оптимизированной версии ревизии 19 K16 это 2ИЛИ. Во всяком случае в PDF.
В оптимизированной версии ревизии 19 K16 это 2ИЛИ. Во всяком случае в PDF.
Действительно. На помойку это старье. Сейчас у меня 24-я версия, и я все еще над ней работаю.
Действительно. На помойку это старье. Сейчас у меня 24-я версия, и я все еще над ней работаю.
А подсмотреть можно?
Промежуточная версия, т.к. я ее еще оптимизирую и проверяю.
Через какое время после установки активным SYNC, выдаются сигналы DIN и DOUT? Нужны точные растактовки ВМ2.
Через какое время после установки активным SYNC, выдаются сигналы DIN и DOUT? Нужны точные растактовки ВМ2.
Здесь точного ответа не будет, т.к. в ВМ2 используется сигнал подтверждения адреса AR. Многое зависит от его длительности.
А так по ТО на ВМ2, которое вы и выкладывали, сигнал DIN устанавливается на ближайшем прямом фронте CLCO после получения сигнала AR. Если AR с практически нулевой задержкой, то один такт CLCO. Диаграммы на рис.15, лист 47. Для записи всё дольше - при нулевой задержке AR после выставления адреса через один такт CLCO адрес снимается, через полтакта выставляются данные, и ещё через такт сигнал DOUT. Диаграммы на рис.16, лист 49.
На УКНЦ соответственно нулевой задержки AR нету, там задержка сделана на цепочке логических элементов и конденсаторов, потому время на разных экземплярах может разнится. Да и на контроллер ЦП поступает тактовая 6,25 МГц, а на сам ЦП 8 МГц, тоже надо учитывать.
На УКНЦ соответственно нулевой задержки AR нету, там задержка сделана на цепочке логических элементов и конденсаторов, потому время на разных экземплярах может разнится. Да и на контроллер ЦП поступает тактовая 6,25 МГц, а на сам ЦП 8 МГц, тоже надо учитывать.
Почему в вашем справочнике по ВМ2 указано:
В УКНЦ сигнал асинхронного обмена AR не используется, поэтому временные диаграммы будут показаны без использования этого сигнала.
Почему в вашем справочнике по ВМ2 указано:
В УКНЦ сигнал асинхронного обмена AR не используется, поэтому временные диаграммы будут показаны без использования этого сигнала.
Имеется ввиду, что он прямо не используется, SYNC идёт на AR через линию задержки и на внешние разъёмы он не поступает. Если бы он использовался, то любое подключаемое устройство должно было на него отвечать, в качестве примера 1515ХМ1-031. Потому и диаграммы показаны без него. Этот сигнал - особенность ВМ2, в МПИ/QBUS его нет.
Я смотрю по схеме Квант rev 5:
На ЦП SYNC заведен на AR через буферный элемент с открытым коллектором. Это означает, что низкий уровень будет передан без задержки, а высокий с чуть заметной задержкой, зависящей от номинала R3.
А вот на ПП SYNC заведен на цепь задержки на 2-х инверторах и конденсаторе, затем через буферный элемент. Затем уже этот задержанный SYNC поступает на все БМК. А так же через буфер ВП1-055 возвращается на AR.
Таким образом, AR всегда синхронен с SYNC.
А SYNC на ПП зачем-то задержан.
Внимание, вопрос. Зачем на ПП SYNC задержан, а на ЦП нет?
Этот сигнал - особенность ВМ2
Аналогичный сигнал есть и у ВМ3, но да - на МПИ/QBUS его нет
Аналогичный сигнал есть и у ВМ3
Это вроде SSYNC.
Надо проверить две вещи:
1. Попросить Ynicky или Vslav'а сделать диаграмму чтения и записи, когда AR выставляется сразу по SYNC.
2. Попросить владельцев живой УКНЦ ткнутся осциллографом на AR и SYNC для ПП, и для ЦП. И показать осциллограмму с задержкой между SYNC и AR.
Внимание, вопрос. Зачем на ПП SYNC задержан, а на ЦП нет?
На ПП часть устройств находится перед буфером 1801ВП1-055, а часть за ним. За буфером находятся программируемый таймер 1515ХМ1-031, каналы связи 1801ВП1-120, разъемы ВУ1 и ВУ2.
На ПП часть устройств находится перед буфером 1801ВП1-055, а часть за ним.
Т.е. чтобы устройства сперва получили адрес, а только потом выставился SYNC, а не наоборот.
Это вроде SSYNC
Да. Но я имел ввиду не название, а смысл :)
Т.е. чтобы устройства сперва получили адрес, а только потом выставился SYNC, а не наоборот.
Естественно. Сперва задерживается SYNC первыми двумя логическими элементами с конденсатором, для стабильности, чтобы адрес перелез спокойно через буфер. А второй партией элементов задерживается AR.
А второй партией элементов задерживается AR.
Эта задержка уже ничтожна, ее можно не считать.
- - - Добавлено - - -
По хорошему, они могли бы этот SYNC задержать на том же 055, чтобы было синхронно с адресом. А стали городить огород с конденсаторами.
Эта задержка уже ничтожна, ее можно не считать.
Ну-ну. Адрес снимается по приходу AR, после всё остальное и начинается.
По хорошему, они могли бы этот SYNC задержать на том же 055, чтобы было синхронно с адресом. А стали городить огород с конденсаторами.
В КВАНТовской схемотехнике почти так и делается, только от задержанного SYNC до AR.
В КВАНТовской схемотехнике почти так и делается, только от задержанного SYNC до AR.
Я про квантовскую схемотехнику и говорю, т.к. пользуюсь схемой Mick'а.
- - - Добавлено - - -
Ну-ну. Адрес снимается по приходу AR, после всё остальное и начинается.
Почему ну-ну? Задержка на 055 ничтожна. Ее практически нет. Между входом C1 и выходом A1.
Почему ну-ну? Задержка на 055 ничтожна. Ее практически нет. Между входом C1 и выходом A1.
А я про СЭМЗовскую. Там вместо -055 используются такие же элементы для задержки AR, как и те что задерживают SYNC.
А вот по схеме СЭМЗ интереснее.
Для ПП идет сперва задержка SYNC на двух инверторах и конденсаторе, затем такая же задержка идет для AR. Т.е. имеем двойную задержку, и, видимо, более медленное быстродействие.
- - - Добавлено - - -
Какая схема была первее, СЭМЗ или Квант?
Или, иными словами, что сначала сделали - двойную задержку, или же задержку на 055?
Какая схема была первее, СЭМЗ или Квант?
Или, иными словами, что сначала сделали - двойную задержку, или же задержку на 055?
Сперва был прототип, затем КВАНТ, ну и в завершении СЭМЗ.
Подытоживаю:
На ЦП задержки между SYNC и AR практически нет.
На ПП (Квант) SYNC задерживается, за ним сразу следует AR без задержки.
На ПП (СЭМЗ) SYNC задерживается, затем AR также задерживается.
- - - Добавлено - - -
Сперва был прототип, затем КВАНТ, ну и в завершении СЭМЗ.
Ну и зачем они в СЭМЗ'е тормознули эту линию, если на Кванте все работало? Или что-то не работало, раз отказались от трех буферных линий на 055?
На ЦП задержки между SYNC и AR практически нет.
Не согласуется с теорией относительности. Свет тоже имеет конечную скорость. Так что какая-то задержка всё же есть, небольшая, но есть. Но я думаю, если она значительно меньше такта CLCO, то ей можно пренебречь. Но это для ЦП через один логический элемент. А для ПП может получиться так, что эти небольшие наносекунды могут сыграть роковую роль и AR придет сразу же за прямым фронтом CLCO, тогда придётся ждать ещё один такт.
- - - Добавлено - - -
Ну и зачем они в СЭМЗ'е тормознули эту линию, если на Кванте все работало? Или что-то не работало, раз отказались от трех буферных линий на 055?
По слухам, на КВАНТЕ часто выходил из строя этот буфер, как раз в районе этих трёх линий. Видал даже фото, где паяли прямые перемычки.
А по тестам скорости вы не помните, СЭМЗы были более тормозными наверное, раз двойная задержка для ПП?
У меня СЭМЗ-ов нет. Надо смотреть тему про быстродействие, там может и выкладывали результаты. Но у меня по быстродействию и мои КВАНТы немного отличаются.
Но у меня по быстродействию и мои КВАНТы немного отличаются.
Они могут отличаться только из-за этой линии задержки, если схема у них одинаковая.
- - - Добавлено - - -
Нашел один тест на СЭМЗ от Keeper'а.
Если сравнивать медленную версию Квант'a и СЭМЗ, то на СЭМЗ почти везде добавляется 4 такта к операциям, которые длиннее 20 тактов. (20 тактов - это регистр-регистр). Что и следовало ожидать из-за двойной задержки.
Если сравнивать медленную версию Квант'a и СЭМЗ, то на СЭМЗ почти везде добавляется 4 такта к операциям, которые длиннее 20 тактов. (20 тактов - это регистр-регистр). Что и следовало ожидать из-за двойной задержки.
У меня на двух быстрых КВАНТАХ операции регистр-регистр - 16 тактов, а на медленном - 20 тактов. Но все КВАНТы.
У меня на двух быстрых КВАНТАХ операции регистр-регистр - 16 тактов, а на медленном - 20 тактов. Но все КВАНТы.
Именно.
На СЭМЗ 20 тактов типа регистр-регистр, как на Кванте. А вот более длинные операции уже медленнее.
А вот более длинные операции уже медленнее.
Какие? И число тактов.
Какие? И число тактов.
Все, кроме регистр-регистр.
Например, запись в регистр 177010 на медленном Кванте 32 такта, а на СЭМЗ 36 тактов.
Например, запись в регистр 177010 на медленном Кванте 32 такта, а на СЭМЗ 36 тактов.
А у меня на быстрых КВАНТах было 28 тактов.
А у меня на быстрых КВАНТах было 28 тактов.
Все сходится. На быстрых квантах 28, на медленных 32, а на СЭМЗ 36.
СЭМЗ в топку! Или переделывать под квант цепочку AR.
- - - Добавлено - - -
А в процентном соотношении у населения больше Квантов или СЭМЗов? Судя по тестам на форуме, Квантов больше.
- - - Добавлено - - -
Растактовка чтения и записи ОЗУ ЦП:
https://pic.maxiol.com/images2/1597441636.2152434844.01.png
Чтение из ОЗУ ЦП:
Описание:
Чтение из ОЗУ ЦП начинается по переднему фронту SYNC, а вовсе не по DIN, как в случае с ПП. После установки SYNC идет ожидание первого свободного слота памяти ЦП (все слоты памяти ЦП четные). В нашем примере первый свободный слот начинается в такте 8. Также необходимо, чтобы до начала свободного слота был установлен DIN. В связи с этим, более точные графики можно будет составить зная точную растактовку ВМ2.
Чтение из ОЗУ всегда словное:
Такт 8 - на шину A0..A7 выводится младшая часть адреса.
Такт 9 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса).
Такт 9.5 - на шину A0..A7 выводится старшая часть адреса.
Такт 10 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса). После чего ОЗУ выставляет на шину данных D0..D15 значение из памяти.
Такт 11.5 - снимается сигнал RAS.
Такт 12 - Шина A0..A7 освобождается, снимается сигнал CAS, устанавливается сигнал RPLY, по которому процессор считывает данные с шины AD, и снимает сигнал DIN. Посе чего сигнал RPLY снимается, и шина AD освобождается.
Замечания:
1. Чтение из ОЗУ инициируется фронтом сигнала SYNC, а не сигналом DIN. Однако, к моменту предоставления свободного слота памяти сигнал DIN тоже должен быть установлен. В противном случае, на шине AD будет высокоимпедансное состояние.
2. При чтении напрямую из ОЗУ, на адресную шину выставляется адрес сдвинутый вправо. При этом старший бит адреса A15 = 0.
3. При чтении через регистр планов 1 и 2, на адресную шину выставляется содержимое регистра адреса планов PLANE_ADR.
Запись в ОЗУ ЦП:
Описание:
Запись в ОЗУ ЦП начинается по DOUT. После установки DOUT идет ожидание первого свободного слота памяти ЦП (все слоты памяти ЦП четные). В нашем примере первый свободный слот начинается в такте 8.
Такт 8 - на шину A0..A7 выводится младшая часть адреса.
Такт 8.5 - на шину D0..D15 выводятся данные.
Такт 9 - видеоконтроллером устанавливается сигнал RAS, по которому в ОЗУ защелкивается адрес строки (младшая часть адреса).
Такт 9.5 - на шину A0..A7 выводится старшая часть адреса, устанавливается сигнал WE.
Такт 10 - устанавливается сигнал CAS, по которому в ОЗУ защелкивается адрес столбца (старшая часть адреса). После чего ОЗУ выставляет на шину данных D0..D15 значение из памяти.
Такт 11.5 - снимается сигнал RAS, по которому данные запоминаются в ОЗУ.
Такт 12 - Шины A0..A7 и D0..D15 освобождаются, снимается сигналы CAS и WE, устанавливается сигнал RPLY. В ответ на сигнал RPLY, процессор снимает сигнал DOUT.
Отличие записи байта от записи слова:
Если запись идет по четному адресу, то блокируется генерация CAS1.
Если запись идет по нечетному адресу, то блокируется генерация CAS0.
Если запись идет через регистровый механизм, то запись по адресу 176642, запишет младший байт в ОЗУ, а запись по адресу 176643 запишет старший байт в ОЗУ.
Замечания:
1. При записи напрямую в ОЗУ, на адресную шину выставляется адрес сдвинутый вправо. При этом старший бит адреса A15 = 0.
2. При записи через регистр планов 1 и 2, на адресную шину выставляется содержимое регистра адреса планов PLANE_ADR.
Чтение из ОЗУ ЦП начинается по переднему фронту SYNC, а вовсе не по DIN, как в случае с ПП.
А если будет запись?
Чтение из ОЗУ всегда словное:
А в МПИ/QBUS чтение всегда словное, байтовая только запись.
2. При чтении напрямую из ОЗУ, на адресную шину выставляется адрес сдвинутый влево. При этом старший бит адреса A15 = 0.
А может вправо?
Свои тесты пока не писал. А вот что нашел со штатной ПЗУ.
https://pic.maxiol.com/thumbs2/1597473197.1845267026.ppreadword177716.png (https://pic.maxiol.com/?v=1597473197.1845267026.ppreadword177716.png&dp=2)
https://pic.maxiol.com/thumbs2/1597473218.1845267026.ppwritebyte000446.png (https://pic.maxiol.com/?v=1597473218.1845267026.ppwritebyte000446.png&dp=2)
https://pic.maxiol.com/thumbs2/1597473233.1845267026.ppwritebyte177010.png (https://pic.maxiol.com/?v=1597473233.1845267026.ppwritebyte177010.png&dp=2)
https://pic.maxiol.com/thumbs2/1597473250.1845267026.ppwritebyte177014.png (https://pic.maxiol.com/?v=1597473250.1845267026.ppwritebyte177014.png&dp=2)
https://pic.maxiol.com/thumbs2/1597473266.1845267026.ppwritebyte177716.png (https://pic.maxiol.com/?v=1597473266.1845267026.ppwritebyte177716.png&dp=2)
https://pic.maxiol.com/thumbs2/1597473282.1845267026.ppwriteword177010.png (https://pic.maxiol.com/?v=1597473282.1845267026.ppwriteword177010.png&dp=2)
Свои тесты пока не писал. А вот что нашел со штатной ПЗУ.
Чем отличаются все эти скриншоты?
- - - Добавлено - - -
В общем, будем считать, что если AR выставляется без задержки, то DIN наступает на следующем же отрицательном фронте F1.
Чем отличаются все эти скриншоты?
1 - чтение слова по адресу о177716.
2 - запись байта по адресу о000446.
3 - запись байта по адресу о177010.
4 - запись байта по адресу о177014.
5 - запись байта по адресу о177716.
6 - чтение/запись слова по адресу о177010.
Добавил сюда (https://zx-pk.ru/threads/30964-revers-inzhiniring-bmk-1515khm1-2.html?p=1076730&viewfull=1#post1076730) описание записи слова в ОЗУ ЦП.
Замечу, что запись слова, и запись байта отличается. Чем - опишу позже.
- - - Добавлено - - -
Кроме того, отдельного рассмотрения требует запись и чтение в режиме ST.
Судя по всему, это потенциальный источник глюков, т.к. цикл доступа к памяти может оборваться на середине, из-за того, что RPLY выставляется сразу после DIN/DOUT.
- - - Добавлено - - -
Итак, о записи байта в ОЗУ ЦП.
Естественное отличие от записи слова:
Если запись идет по четному адресу, то блокируется генерация CAS1.
Если запись идет по нечетному адресу, то блокируется генерация CAS0.
Неестественное отличие от записи слова:
Запись начинается по сигналу DOUT, а не по SYNC. Что правильно и хорошо.
Чтение из ОЗУ ЦП начинается по переднему фронту SYNC, а вовсе не по DIN, как в случае с ПП.
Запись слова в ОЗУ ЦП начинается по переднему фронту SYNC, а вовсе не по DOUT, как в случае с ПП.
Так всё таки чтение или запись? В контроллере ЦП есть блок предсказаний?
Ну и, наконец, если запись идет через регистровый механизм, то запись по адресу 176642, запишет младший байт в ОЗУ, а запись по адресу 176643 запишет старший байт в ОЗУ.
- - - Добавлено - - -
Так всё таки чтение или запись? В контроллере ЦП есть блок предсказаний?
Чтение и запись слова начинаются по SYNC.
Запись байта начинается по DOUT.
Никаких предсказаний нет, просто такой вот 'кривой' контроллер)
- - - Добавлено - - -
Хотя, можно условно назвать это предсказанием. Я об этом не задумывался изначально. Но даже если так, оно все равно какое-то кривое.
2 - запись байта по адресу о000446.
3 - запись байта по адресу о177010.
4 - запись байта по адресу о177014.
5 - запись байта по адресу о177716.
Ynicky, в стандартном ПЗУ по данным адресам никакой записи байтов нет. К тому же почему-то сигнал WTBT выставляется перед неактивным SYNC. Может таким образом процессор сигнализирует, что будет операция записи?
- - - Добавлено - - -
Ну и, наконец, если запись идет через регистровый механизм, то запись по адресу 177640, запишет младший байт в ОЗУ, а запись по адресу 177641 запишет старший байт в ОЗУ.
Что-то я ничего не понял в этой фразе? Titus, а можете расшифровать поподробнее.
Что-то я ничего не понял в этой фразе? Titus, а можете расшифровать поподробнее.
Опечатался. Конечно там адреса 176642, и 176643.
Ynicky, в стандартном ПЗУ по данным адресам никакой записи байтов нет. К тому же почему-то сигнал WTBT выставляется перед неактивным SYNC. Может таким образом процессор сигнализирует, что будет операция записи?
Посмотрел команды по этим адресам. Байтовых нет.
Но в 5 случае:
160332$:MOV #40,@#177716 ; Останов ЦП (установка DCLO и ACLO)
актуальные данные в младшем байте.
А WTBT активен при выдаче адреса.
Так всё таки чтение или запись? В контроллере ЦП есть блок предсказаний?
Никаких предсказаний нет, просто такой вот 'кривой' контроллер)
Хотя, можно условно назвать это предсказанием. Я об этом не задумывался изначально. Но даже если так, оно все равно какое-то кривое.
Ynicky, в стандартном ПЗУ по данным адресам никакой записи байтов нет. К тому же почему-то сигнал WTBT выставляется перед неактивным SYNC. Может таким образом процессор сигнализирует, что будет операция записи?
А всё таки блок предсказаний есть. Действительно ТО надо не только смотреть, но и читать. На листе 16 прямо написано: "Вывод 19. WTBT. Выход информационного комбинированного сигнала "запись-байт". Во время выдачи адреса в цикле процедуры обмена по системной магистрали низкий уровень сигнала на этом выводе свидетельствует о том, что осуществляется процедура записи. Во время выдачи данных низкий уровень сигнала на этом выводе свидетельствует о том, что выдается не слово, а байт.". Лист 50: "В процедуре записи в фазе выдачи адреса сигнал WTBT выдается низким уровнем".
Во время выдачи адреса в цикле процедуры обмена по системной магистрали низкий уровень сигнала на этом выводе свидетельствует о том, что осуществляется процедура записи.
Вообще-то - это давно известно, на ВМ3 точно так же.
И подозреваю, что это будет справедливо (сигнал о том, что будет ЗАПИСЬ, во время выдачи адреса и SYNC) для QBUS в принципе.
Память упорно подсказывает, что такое упреждающее уведомление о предстоящей записи сделано с прицелом на типы памяти (вроде как на ферритах), у которых особая любовь к чтению (насколько я помню, в ферритовой памяти чтение разрушает данные и их надо восстановить) - то есть идёт уведомление, что даже если было только что чтение (цикл чтение-изменение-запись), то данные восстанавливать не надо - ибо будет запись в ту же ячейку. Но. Это мои предположения :)
А всё таки блок предсказаний есть. Действительно ТО надо не только смотреть, но и читать. На листе 16 прямо написано: "Вывод 19. WTBT. Выход информационного комбинированного сигнала "запись-байт". Во время выдачи адреса в цикле процедуры обмена по системной магистрали низкий уровень сигнала на этом выводе свидетельствует о том, что осуществляется процедура записи. Во время выдачи данных низкий уровень сигнала на этом выводе свидетельствует о том, что выдается не слово, а байт.". Лист 50: "В процедуре записи в фазе выдачи адреса сигнал WTBT выдается низким уровнем".
Ну вот. А я тут спрашивал, когда он выдается, говорили, что только при записи байта. Значит надо пересмотреть диаграммы.
А обычно на него и реагируют только при записи (DOUT) байта.
Хотя, конечно, мысль интересная - после приёма адреса быстрее шинные драйвера переключать, если будет НЕ ЗАПИСЬ.
Интересный тогда еще вопрос. Почему по диаграммам Ynicky сигнал DOUT выдается через 5 тактов после SYNC (или 4 такта после окончания WTBT). Тогда как при записи DIN выдается через такт после SYNC.
- - - Добавлено - - -
В общем, внесу коррекцию в описание.
Процедура записи чтения, как есть по SYNC, а процедура записи будет по DOUT. Что байтовая, что словная.
Видимо, это сделано именно потому, что в случае записи интервал между SYNC и DOUT слишком большой, и нельзя начинать писать настолько заранее, т.к. в этот промежуток может влезть целый слот памяти. А в случае с чтением можно начинать сразу по SYNC, т.к. DIN воспоследует уже через один такт. Это на такт ускоряет процесс чтения.
- - - Добавлено - - -
Обновил 1515ХМ2-003.
Оптимизированна схема для более легкого понимания
Исправлены неточности
p.s.: Особое внимание требуют RS-триггеры, которые при оптимизации могут превратиться в мину замедленного действия, связанную с тем, что прямой и инверсный выход RS-триггера неравнозначны. Если на прямом выходе 0, это еще не значит, что на инверсном будет 1. И наоборот. Это связано с тем, что вход R имеет приоритет на прямом выходе, а вход S на инверсном. Или говоря проще - если на R и S установлены единицы, то и прямой выход, и инверсный будут в 0.
Поэтому при оптимизации нельзя просто так перебрасывать сигнал с инверсного выход на прямой, или же убирать один из выходов, если в схеме используются два.
В данном реверсе я допустил подобную ошибку в схеме установки RPLY, но исправил ее. И проверил все остальные RS-триггеры в схеме.
Посмотрел схему ХМ2-001, и заметил, что при чтении данных, сами данные на шину AD выставляются одновременно с сигналом RPLY. Не опасно ли для ВМ2 это делать одновременно? Или же ВМ2 не сразу защелкивает данные с шины по сигналу RPLY, а чуть с задержкой, чтобы данные успели устаканиться?
Посмотрел схему ХМ2-001, и заметил, что при чтении данных, сами данные на шину AD выставляются одновременно с сигналом RPLY. Не опасно ли для ВМ2 это делать одновременно? Или же ВМ2 не сразу защелкивает данные с шины по сигналу RPLY, а чуть с задержкой, чтобы данные успели устаканиться?
Titus, читайте ТО, лист 46. Там сказано: "Для обеспечения надёжного приёма данные нужно выставлять на выводах AD(0-15) не позже, чем через 2/3 T после выставления сигнала RPLY и снимать их не ранее, чем снимется сигнал DIN." Диаграмма на листе 47.
Или же ВМ2 не сразу защелкивает данные с шины по сигналу RPLY, а чуть с задержкой, чтобы данные успели устаканиться?
nRPLY должен поступать после активации nDIN/nDOUT, если nRPLY поступит даже мгновенно после этих стробов, то минимум проходит целый такт пока процессор защелкивает nRPLY внутри (rply0) и вырабатывает внутренний строб записи данных (bus_wq) с шины nAD во внутренний латч. Поэтому данные легко могут быть выставленны не то что одновременно с RPLY, но и до такта задержаться (а то и до двух - как повезет с соотношением RPLY с фазой F1). Стандарт МПИ, кстати, допускает выставление RPLY до данных - 200нс, как раз примерно один внутренний такт ВМ2 при внешней частоте 10МГц.
http://www.1801bm1.com/files/images/dia_vm2_rply.png
Описал все 4 БМК в первом приближении.
Написал простую тестовую программу проверки начальной инициализации ЦП.
Промоделировал. ACLO и DCLO на ЦП устанавливается как надо и процессор стартует с адреса о160000.
Но сигнал /RPLY не завершается. Может что-то не так с REPLY LOGIC в ХМ2-003?
https://pic.maxiol.com/thumbs2/1597652071.1845267026.cpreadword160000.png (https://pic.maxiol.com/?v=1597652071.1845267026.cpreadword160000.png&dp=2)
Но сигнал /RPLY не завершается. Может что-то не так с REPLY LOGIC в ХМ2-003?
Логика очень проста. По отрицательному спаду на CAS0/CAS1 (A51) на выходе N40 устанавливается REPLY.
Нашел у себя ошибку.
https://pic.maxiol.com/thumbs2/1597655315.1845267026.cpreadword1600002.png (https://pic.maxiol.com/?v=1597655315.1845267026.cpreadword1600002.png&dp=2)
Описал все 4 БМК в первом приближении.
Видеовыход как будешь моделировать и получать картинку?
- - - Добавлено - - -
Я, кстати, все еще проверяю и оптимизирую реверсы, и порой нахожу неточности. Вернее, неточностей почти нет. Только изредка в RS-триггерах, т.к., как я уже писал выше, это мина замедленного действия после оптимизации, если их точно не проверить. Вот сейчас и проверяю.
Видеовыход как будешь моделировать и получать картинку?
Что бы промоделировать кадровый счетчик, нужно несколько часов. Как будет время побольше - сделаю. А для подключения к телевизору нужно что-то городить к плате FPGA, или делать (например) преобразование в VGA или HDMI. Больше склоняюсь ко второму варианту.
делать (например) преобразование в VGA или HDMI
Будешь сам придумывать схему преобразования? Или же есть где-то готовые наработки?
Мне тоже интересно, как формируют HDMI самоделкины в наше время.
А обычно на него и реагируют только при записи (DOUT) байта. Вторая (первая по времени в цикле Q-bus/МПИ) функция сигнала К БАЙТ Н (WTBT) - то, что низкий уровень на этой линии в адресной части цикла сообщает, что это будет цикл записи, ИМХО, это рудимент тех времен, когда память была чем-то, отличающимся от микроэлектронных схем. Например, ферритовой. Там, возможно, знание о том, чем будет этот цикл - записью или чтением - позволяло выиграть некоторое время и часть действий выполнить еще не получив адрес, или в процессе получения адреса.
Хотя, конечно, мысль интересная - после приёма адреса быстрее шинные драйвера переключать, если будет НЕ ЗАПИСЬ.Да не особенно оно ускорит - ведь RPLY выдают, обычно, сразу по приходу DIN, а данные можно выставить и заметно позже этого DIN'а...
Будешь сам придумывать схему преобразования? Или же есть где-то готовые наработки?
Мне тоже интересно, как формируют HDMI самоделкины в наше время.
JFYI, в проекте ReVerSE-U16 есть реализация HDMI:
https://github.com/mvvproject/ReVerSE-U16/tree/master/u16_hdmi_test
В одном проектов внутри видел зачатки передачи audio в hdml.
Память упорно подсказывает, что такое упреждающее уведомление о предстоящей записи сделано с прицелом на типы памяти (вроде как на ферритах), у которых особая любовь к чтению (насколько я помню, в ферритовой памяти чтение разрушает данные и их надо восстановить) - то есть идёт уведомление, что даже если было только что чтение (цикл чтение-изменение-запись), то данные восстанавливать не надо - ибо будет запись в ту же ячейку. Но. Это мои предположения
ИМХО, это рудимент тех времен, когда память была чем-то, отличающимся от микроэлектронных схем. Например, ферритовой. Там, возможно, знание о том, чем будет этот цикл - записью или чтением - позволяло выиграть некоторое время и часть действий выполнить еще не получив адрес, или в процессе получения адреса.
Найдите десять отличий
Будешь сам придумывать схему преобразования? Или же есть где-то готовые наработки?
Есть кое-какие собственные наработки по VGA контроллеру.
А преобразователь из VGA в HDMI взял из ссылки выше от @.yu.zxpk.
Но там 60 Гц кадровая развертка.
https://zx-pk.ru/threads/30578-bk001kh-na-fpga.html
https://zx-pk.ru/threads/31292-16-tsvetov-v-bk0010/page11.html
Также есть телевизоры с VGA и HDMI входами. На вход VGA подаю с реальной УКНЦ.
https://zx-pk.ru/threads/25871-adapter-uk-nts-k-sovremennym-tv-i-monitoram/page55.html?highlight=vga
Работает от 50 Гц. Будет ли работать от HDMI на 50 Гц - не знаю. Но у меня основная плата с FPGA - Марсоход3 с HDMI выходом. На других моих FPGA платах нет разъемов VGA и HDMI. Так что для них придется городить нашлепки с разъемами.
А преобразователь из VGA в HDMI взял из ссылки выше от @.yu.zxpk.
А есть ли в природе проекты, где HDMI генерится микроконтроллером, а не FPGA? Пусть даже очень быстрым микроконтроллером.
- - - Добавлено - - -
Да не особенно оно ускорит - ведь RPLY выдают, обычно, сразу по приходу DIN, а данные можно выставить и заметно позже этого DIN'а...
Ускоряет, т.к. DOUT выдается с задержкой относительно SYNC. А если ориентироваться по WTBT, то можно заметно ускорить процесс записи. Да и чтения тоже.
Ускоряет, т.к. DOUT выдается с задержкой относительно SYNC. А если ориентироваться по WTBT, то можно заметно ускорить процесс записи. Да и чтения тоже.
По поводу чтения согласен. Т.к. этот процесс идёт в фазе выдачи адреса, то адрес известен. Соответственно адрес используется и контроллер ОЗУ по сигналу арбитра формирует адрес для RAS/CAS и запоминает прочитанные данные в буферном регистре. А потом этот буферный регистр выставляется на шину по сигналу DIN. Здесь немного ускорить можно, тем более в магистрали ЦП память твёрдо стоит на двух ногах. А вот с записью сложнее. Сначала от того же процессора надо получить записываемые данные по DOUT, а уж потом выставлять для ОЗУ адрес по RAS/CAS.
Ускоряет, т.к. DOUT выдается с задержкой относительно SYNC. А если ориентироваться по WTBT, то можно заметно ускорить процесс записи.Записи? И что ты запишешь раньше DOUT'а? Кто, кроме DOUT'а даст гарантию, что на МПИ уже данные, а не адрес или "звон" после переключения? Для справки, с учетом разбега сигналов по корзине, из 200 нс между SYNC'ом и DOUT'ом, адрес гарантировано держится 25 нс после SYNC'а, а данные гарантировано появляются за 25 нс до DOUT'а. Остальные 150 нс - неопределенность, вполне вероятен звон и разное время добегания тех или иных битов по корзинке, где-то может быть еще бит адреса, а куда-то уже добежал бит данных
Да и чтения тоже.Где? DIN выдается через 200 нс после SYNC, RPLY надо выдавать в ответ на DIN, а данные можно выставить еще позже - до 125 нс Чем тут поможет знание в момент SYNC'а, что через 200 нс прилетит DIN ?
Да, это все относится к классической МПИ в корзинке - если делать свой процессор на FPGA "по мотивам" какого-то оригинального, то можно и МПИ похоронить, как это сделал коллега Vslav в своих последних синтезах, и все сделать по-своему, но к МПИ это не будет иметь никакого отношения.
В общем, коллеги, читайте документ 3.858.382 ТО "Центральный процессор М2", он рулез!
А вот с записью сложнее. Сначала от того же процессора надо получить записываемые данные по DOUT, а уж потом выставлять для ОЗУ адрес по RAS/CAS.
Не надо забывать, что чтобы что-то записать или прочитать, нам надо получить ближайший свободный слот памяти. Установился SYNC, и мы уже можем забронировать ближайший слот, который, может быть наступит в следующем такте. Тогда как если мы для бронирования слота будем ждать DIN или DOUT, этот слот убежит, и придется ждать следующий.
- - - Добавлено - - -
Записи? И что ты запишешь раньше DOUT'а?
Запись не происходит сразу по DOUT. Сначала контроллер памяти занимает свободный слот памяти, затем выдает на шину адреса строки и столбца, и уже затем записывает или читает данные.
Не надо забывать, что чтобы что-то записать или прочитать, нам надо получить ближайший свободный слот памяти. Установился SYNC, и мы уже можем забронировать ближайший слот, который, может быть наступит в следующем такте. Тогда как если мы для бронирования слота будем ждать DIN или DOUT, этот слот убежит, и придется ждать следующий.
По поводу бронирования я говорил про чтение по DIN, там нет никаких препятствий. Повторю ещё раз - получили адрес, узнали, что будет чтение, и при следующем разрешении арбитра PSC взяли, да считали слово с ОЗУ в буферный регистр, а потом, как придёт DIN, выставили этот буферный регистр на шину вместе с ответом RPLY.
Теперь по поводу записи. Ну получили мы по PSC разрешение работы с памятью, а у нас ни данных, ни DOUT. А ведь разрешение держится только 320 нс, за это время надо дать часть адреса по RAS в первые 160 нс, а за следующие 160 вторую часть адреса по CAS, да и выставить данные с сигналом WE. Т.к. адрес известен в фазе выдачи адреса, то его можно начать выдавать по RAS, а вот если данные с DOUT не успеют подбежать ко второй части, то что записывать будем, или холостое чтение сделаем?
Теперь по поводу записи. Ну получили мы по PSC разрешение работы с памятью, а у нас ни данных, ни DOUT.
Согласен. Да, бронирование хорошо только для DIN.
1515ХМ2-003-Optimized - rev 27
проверяя RS-триггеры, нашел один с инверсными входами, который при оптимизации потярял правильный приоритет выходов. Исправил. K39 в цепи контроллера прерываний.
Почему такое произошло - у стандартного RS-триггера, R имеет приоритет на прямом выходе, а S имеет приоритет на инверсном выходе. У RS-триггера с инверсными входами (которые также используются в наших БМК), R имеет приоритет на инверсном выходе, а S на прямом. Т.е. все наоборот. K39 был инверсновходовый, и при оптимизации потерял правильный приоритет выходов.
Запись не происходит сразу по DOUT. Сначала контроллер памяти занимает свободный слот памяти, затем выдает на шину адреса строки и столбца, и уже затем записывает или читает данные.Так никто не мешает начинать эти адресные дела по SYNC'у, т.е. получив адрес. А к тому времени прилетит DIN или DOUT и станет ясно, что надо делать - читать или писать. И предварительное знание того, кто именно из них прилетит, ничем особо не поможет.
И вообще, использовать динамическую память для клона УКНЦ, в котором все ХМ-ки и ВП-шки прошиты в FPGA имеет смысл только дл того, чтобы убедиться, что все распознано и перенесено на FPGA правильно. Рабочий проект, безусловно, надо будет делать из расчета на статическую. память - те ее объемы, которые нужны УКНЦ, легкодоступны и стоят копейки.
Так никто не мешает начинать эти адресные дела по SYNC'у, т.е. получив адрес. А к тому времени прилетит DIN или DOUT и станет ясно, что надо делать - читать или писать. И предварительное знание того, кто именно из них прилетит, ничем особо не поможет.
По этому поводу правильно написал Alex_K.
Время прихода DIN после SYNC короткое (1 такт). Предсказывается чтение, занимается слот, и тут же этот слот используется.
Время прихода DOUT после SYNC очень долгое (5 тактов на диаграммах выложенных выше). Если забронировать слот по SYNC, а слот длится всего 4 такта, то этот слот скорее всего будет упущен.
Поэтому в ХМ2-003 и используется предсказание по SYNC только для DIN.
- - - Добавлено - - -
И вообще, использовать динамическую память для клона УКНЦ, в котором все ХМ-ки и ВП-шки прошиты в FPGA имеет смысл только дл того, чтобы убедиться, что все распознано и перенесено на FPGA правильно. Рабочий проект, безусловно, надо будет делать из расчета на статическую. память - те ее объемы, которые нужны УКНЦ, легкодоступны и стоят копейки.
В принципе, можно использовать и статику. Но если хочется полной совместимости, чтобы работали глюки наложения чтения из ОЗУ на чтение из ПЗУ, глюки опережающего RPLY по ST, и т.д. - надо ставить динамику.
В принципе, можно использовать и статику. Но если хочется полной совместимости, чтобы работали глюки наложения чтения из ОЗУ на чтение из ПЗУ, глюки опережающего RPLY по ST, и т.д. - надо ставить динамику.
А вот по поводу так называемых глюков (я бы их так не назвал), то это не зависит от типа памяти, это особенность БМК и архитектуры. Собственно одно из основных отличий DRAM от SRAM - это необходимость регенерации, ну и в статике адрес передаётся за раз.
А вот по поводу так называемых глюков (я бы их так не назвал), то это не зависит от типа памяти, это особенность БМК и архитектуры.
Глюки, которые возникнут, если использовать динамику, и их не будет, если перейти на статику.
А если мы хотим получить абсолютно идентичный клон, то тогда нужно ставить динамику.
Глюки, которые возникнут, если использовать динамику, и их не будет, если перейти на статику.
А если мы хотим получить абсолютно идентичный клон, то тогда нужно ставить динамику.
А поконкретнее о каких глюках идёт речь. Ранее я писал, что это не глюки, а особенности архитектуры и БМК. По поводу наложения чтения в контроллере ПП в диапазоне адресов 0100000-0176777, то это особенность архитектуры. Единственно ОЗУ стоит на одной ноге и читается в два приёма, ПЗУ ответит быстрее. Также как и формированием ST и RPLY. В чём я соглашусь, это то что ОЗУ читается медленно, статика здесь прочтётся быстрее, но арбитр доступа всё равно останется, читать придётся в окне 320 нс. А абсолютно идентичный клон зачем? Ведь этих особенностей никто и ничто не использует.
А абсолютно идентичный клон зачем? Ведь этих особенностей никто и ничто не использует.
Я специально напишу тест, который будет это тестировать и крупными буквами писать - у вас несовместимый УКНЦ)
- - - Добавлено - - -
А поконкретнее о каких глюках идёт речь.
Я еще не проверял всех возможностей глюков опережающего RPLY по ST.
Я специально напишу тест, который будет это тестировать и крупными буквами писать - у вас несовместимый УКНЦ)
А вдруг результаты теста будут разные на разных УКНЦ?
А вдруг результаты теста будут разные на разных УКНЦ?
Это тоже надо предусмотреть. Для этого и изучается подробно структура чипов и схемотехника разных версий.
Titus, в ХМ1-32 не могу найти сигнал PCLC. Только на картинках.
Основательно переработал оптимизацию XM2-001.
Постарался привести ее к формату более поздних реверсов, без паутины длинных линий в контроллере клавиатуры.
Также сделана прочая логическая оптимизация и всевозможные подписи с уточнениями.
Ошибок вроде бы не было, но Ynicky лучше сравнить с предыдущей версией.
1515ХМ2-001-Optimized - rev 56.pdf (https://yadi.sk/i/6TWc2NCsdpo6dw)
- - - Добавлено - - -
@Titus, в ХМ1-32 не могу найти сигнал PCLC. Только на картинках.
А в схеме его и нет. Это Pixel Clock из ХМ1-136 для ориентира.
Моделирую запись в системную память ПП (8ми разрядная, DS5-DS12 по схеме Mick-а).
При зацикливании записи байта в память, запись предваряется чтением слова.
https://pic.maxiol.com/thumbs2/1597939534.1845267003.writebyteo0010043.jpg (https://pic.maxiol.com/?v=1597939534.1845267003.writebyteo0010043.jpg&dp=2)
При зацикливании записи слова в память, такого не наблюдается.
https://pic.maxiol.com/thumbs2/1597939572.1845267003.writewordo0010043.jpg (https://pic.maxiol.com/?v=1597939572.1845267003.writewordo0010043.jpg&dp=2)
Это у меня косяк или так и должно быть?
При зацикливании записи байта в память, запись предваряется чтением слова.
При зацикливании записи слова в память, такого не наблюдается.
Это у меня косяк или так и должно быть?
Это особенности процессора 1801/1806ВМ2. При записи байта перед этим читается слово. Команды MOVB, CLRB, MFPS.
Вроде бы такое было и у некоторых процессоров DEC.
Это особенности процессора 1801/1806ВМ2. При записи байта перед этим читается слово. Команды MOVB, CLRB, MFPS.
Вроде бы такое было и у некоторых процессоров DEC.
Мое предположение, что это могло быть сделано для того, чтобы поддержать запись в 16-разрядную память (которая не умеет писать байтами). Читается слово, изменяется байт, и пишется слово обратно.
Мое предположение, что это могло быть сделано для того, чтобы поддержать запись в 16-разрядную память (которая не умеет писать байтами). Читается слово, изменяется байт, и пишется слово обратно.
Увы! При байтовой записи в неиспользуемом байте выставляются нули. Это подтвердили тесты на реальной УКНЦ при записи в регистры внешних устройств, которые не отрабатывают сигнал WTBT.
Увы! При байтовой записи в неиспользуемом байте выставляются нули.
Ну и как бы это штатное (и описанное) поведение процов PDP-11.
Увы! При байтовой записи в неиспользуемом байте выставляются нули. Это подтвердили тесты на реальной УКНЦ при записи в регистры внешних устройств, которые не отрабатывают сигнал WTBT.
Тогда феномен байтовой записи непонятен. Не могли же, если это ошибка, допустить ее в нескольких процессорах сразу. Видимо, был умысел какой-то.
Тогда феномен байтовой записи непонятен. Не могли же, если это ошибка, допустить ее в нескольких процессорах сразу. Видимо, был умысел какой-то.
Микрокод проще с таким подходом:
memb = func(memb) для одноадресных типа inc/dec/сдвиги, поэтому memb всегда читается, включая clrb. Единственное исключение - подавление записи для tstb. Аналогично с двухадресным movb
Микрокод-то проще, но шина загружена лишним чтением, что на ВМ1 было ещё терпимо, а на ВМ2 уже изрядная печалька :(
Байтовая работа с памятью - тормоза ...
Titus, в ХМ1-032 при чтении системного ОЗУ данные в регистры REG_MEM_LOW и REG_MEM_HIGH не записываются по положительным фронтам сигналов WRITE_MEM_LOW и WRITE_MEM_HIGH, так как эти фронты приходят до рабочего фронта CAS с записью старшей части адреса. У тебя в схеме рабочий фронт записи в эти регистры не указан. Я сделал по отрицательному фронту, это правильно? А вообще, если рабочий фронт у триггеров и регистров не указан, я делаю по положительному.
А вообще, если рабочий фронт у триггеров и регистров не указан, я делаю по положительному.
Ну ты даешь) Если фронт не указан, значит запись идет по УРОВНЮ, а не по фронту.
Тебе придется переделать все реверсы, т.к. там половина регистров с записью по уровню, а не по фронтам, и менять это нельзя.
Переписал, а за одно перепроверил остальное. Кое что подправил. Проверяю дальше.
Переписал, а за одно перепроверил остальное. Кое что подправил. Проверяю дальше.
Того и гляди мы увидим первую реплику УКНЦ на ФПГА. А это сложнее, чем даже Союз-Неон, т.к. в последнем не было заказных чипов.
Промоделировал вертикальный счетчик в 136й. Работает правильно. Только кадровые синхроимпульсы VSYNN для четного и нечетного полей одинаковые, если, конечно, я все правильно описал. Нет сдвига на пол строки, как по ГОСТу.
Только кадровые синхроимпульсы VSYNN для четного и нечетного полей одинаковые, если, конечно, я все правильно описал. Нет сдвига на пол строки, как по ГОСТу.
Так на УКНЦ на двух полукадрах не 625 строк, а только 624. Из-за этого между двумя импульсами EVNT не 20000 мкс, а только 19968 мкс. Т.е. чуточку побыстрее 50 Гц. За час будет спешить около 6 сек, а за сутки 2 мин 18 сек.
Промоделировал вертикальный счетчик в 136й. Работает правильно. Только кадровые синхроимпульсы VSYNN для четного и нечетного полей одинаковые, если, конечно, я все правильно описал. Нет сдвига на пол строки, как по ГОСТу.
Оба поля одинаковые. Так же как и у 99% компьютеров 80-х годов. Единственная машинка, которую я знаю, с интерлейсом для некоторых режимов - это Amiga.
Посмотрел потранзисторную схему ВМ2, которую нарисовал многоуважаемый Vslav.
Хочется выразить ему огромную благодарность за столь кропотливый труд. Нарисовать более 10000 транзисторов - это надо иметь нереальную усидчивость) Возникло несколько вопросов:
1. Чем отличается Verilog-версия сделанная один в один по транзисторной схеме (асинхронная, как ты ее называешь) от модифицированной синхронной?
2. Как ты составлял Verilog-описание (я в этом чайник), описывал каждый транзистор, потом оптимизировал, либо же смотрел на целый блок и описывал его сразу?
3. И для меня непонятно, как можно было оставить транзисторную схему, и не сделать по ней логическую. Транзисторная - это, конечно, оригинал и эталон, но пользоваться ей невозможно не переведя в логический вид.
Еще вопрос к Vslav:
Не нравится мне схема сравнения PC1 и RA.
А именно транзистор T6636, и вокруг него.
1. Если сигнал ACMP_EN = 0, то T6636 открыт, и T6661 открыт. Все штатно.
2. Если сигнал ACMP_EN = 1, то T6636 закрыт, а линия ADR_EQ может притягиваться только к земле через одну или несколько линий сравнения. Таким образом, если ADR_RQ не притянута к земле (PC1 = RA), то вход T6661 окажется в воздухе, т.к. нечему притянуть его к плюсу. Может ты где-то ошибся?
1. Чем отличается Verilog-версия сделанная один в один по транзисторной схеме (асинхронная, как ты ее называешь) от модифицированной синхронной?
Отсутствием латчей - вся логика переделана на флип-флопы, а также уменьшено число внутренних фаз с четырех до двух (в моделях для ВМ2). Фазы были нужны для повышения быстродействия физического кристалла, в модели оно особой роли не играет, более того - вредно для синхронной платформы. Теоретически синхронную модель уже можно запихнуть в FPGA (например в проекте БК-0011М для Мистера взяли синхронную модель ВМ1 и, хотя она изначально не предназначалась для реального использования, нормально там работает), но оно выходит не очень оптимально по ресурсам и частоте.
2. Как ты составлял Verilog-описание (я в этом чайник), описывал каждый транзистор, потом оптимизировал, либо же смотрел на целый блок и описывал его сразу?
Смотрел на целый блок сразу. Схемотехника n-MOS несложная, после того как сгруппированы транзисторы и нарисован блок - функция понятна. Именно поэтому я не вижу смысла тратить время на перерисовывание в логических компонентах - нет added value, и пропадает автоматическая сверка с топологией - легко налажать и внести ошибки. В моих реверсах я могу мгновенно автоматически сравнить схему с топологией, поэтому у меня вообще не болит голова об ошибках, когда рисую схему - я знаю что при сверке их обязательно увижу и поправлю. Не все любят делать "закат солнца вручную" как ты в реверсах 1515 :)
Мои схемы всегда строго соответствуют топологии. Да, в топологии может быть ошибка - пропущен, скажем, транзистор на фотографии, но логика потом это выявляет (очень хороший пример был в LSI-11). Так что вероятность ошибки собственно реверса небольшая, чаще бывает лажа при переходе в синхрон и потом в оптимизации под FPGA, но именно для этого кейса сохраняется оригинальная модель, в ней обычно ошибок нет (хорошая иллюстрация с последними пофикшенными багами ВМ2) и можно использовать как эталон для отладки.
3. И для меня непонятно, как можно было оставить транзисторную схему, и не сделать по ней логическую. Транзисторная - это, конечно, оригинал и эталон, но пользоваться ей невозможно не переведя в логический вид.
Ну... Верилог же написан? И даже работает. Значит - пользоваться можно :)
- - - Добавлено - - -
Еще вопрос к Vslav:
Не нравится мне схема сравнения PC1 и RA.
А вот это как раз тот самый случай когда транзисторная схема демонстрирует схемотехническую особенность.
ADR_EQ - это здоровенный И-НЕ с кучей транзисторов и должен работать быстро. Поэтому в подтяжку поставили не просто depletion load, а специальный транзистор T6636 - он успевает быстро зарядить всю эту относительно большую емкость цепи ADR_EQ. Я думаю там в нем еще и некоторое легирование канала есть - T6636 вероятнее всего дополнительно обеспечивает слабенький pull-up для ADR_EQ. Легирование мы на фотографии не увидим, но логика работы всего этого блока понятна и так - компаратор адреса. ACMP_EN обычно сидит в нуле, ADR_EQ - высокий, T6636 открыт, емкость цепи заряжена. При сравнении адреса - ACMP_EN переходит в высокий, T6636 закрыт (возможен слабенький pull-up) и ADR_EQ уже может разрядится в ноль каким-либо разрядом компаратора. ACMP_EN еще и подфильтровывает эти разряды - чтобы срабатывало именно в определенный момент, когда все переходные процессы в XOR-aх завершились.
Отсутствием латчей - вся логика переделана на флип-флопы,
Под латчами ты поздразумеваешь RS-триггеры, а под флип-флопами D-триггеры?
- - - Добавлено - - -
а также уменьшено число внутренних фаз с четырех до двух (в моделях для ВМ2)
Уменьшение фаз - это отказ от инверсных версий фаз?
- - - Добавлено - - -
Ну... Верилог же написан? И даже работает. Значит - пользоваться можно
Можно пользоваться для создания FPGA-модели, но сложно, если хочется создать программную модель. Ибо, для этого надо видеть логическую схему.
- - - Добавлено - - -
При сравнении адреса - ACMP_EN переходит в высокий, T6636 закрыт (возможен слабенький pull-up) и ADR_EQ уже может разрядится в ноль каким-либо разрядом компаратора.
Т.е. ты хочешь сказать, что это у нас получается уже не статическая схема, а динамическая.
Т.к. если ACMP_EN продержится достаточно долго, то цепь разрядится, и мы получим глюк.
Под латчами ты поздразумеваешь RS-триггеры, а под флип-флопами D-триггеры?
Латч - триггер запоминающий значение D входа по уровню на С входе (типа ИР22).
Флип-флоп - триггер запоминающий значение D входа по фронту на C входе (типа ИР23)
Уменьшение фаз - это отказ от инверсных версий фаз?
Отказ от f2 и инверсии f2. f2 - это сдвинутая на 90 градусов f1.
Можно пользоваться для создания FPGA-модели, но сложно, если хочется создать программную модель. Ибо, для этого надо видеть логическую схему.
Мм.. Для создания верилог-модели тоже надо видеть логическую схему, и она в транзисторах вполне видна, надо просто попрактиковаться :)
Т.е. ты хочешь сказать, что это у нас получается уже не статическая схема, а динамическая.
Т.к. если ACMP_EN продержится достаточно долго, то цепь разрядится, и мы получим глюк.
ACMP_EN формируется импульсами, он максимум может длиться такт внешней частоты. Вот если ее остановить, то возможна проблема, да. К чему приведет ложный низкий уровень? Это значит адрес не совпадает, перечитывать предвыборку команды не надо. Останов тактирования на самомодифицирующемся коде - редкость, думаю никто не тестировал. И мы не знаем легирование T6636, если он со встроенным каналом и создает слабый pull-up, то никакого разряда не будет, все будет работать корректно.
Останов тактированя на самомодифицирующемся коде - редкость, думаю никто не тестировал.
Во всяком случае в УКНЦ останова тактирования не предусмотрена, а стало быть беспокоиться об этом не нужно.
- - - Добавлено - - -
Мм.. Для создания верилог-модели тоже надо видеть логическую схему, и она в транзисторах вполне видна, надо просто попрактиковаться
В транзисторах я ее вижу, но это гораздо менее удобно.
Это все равно, как видеть нитки под микроскопом, и понимать, что из них соткан ковер и конкретный узор на ковре (потранзисторная схема). И видеть ковер целиком с каждым обособленным узором (логическая схема).
- - - Добавлено - - -
Латч - триггер запоминающий значение D входа по уровню на С входе (типа ИР22).
Флип-флоп - триггер запоминающий значение D входа по фронту на C входе (типа ИР23)
Понял, латчем ты называешь триггер, записываемый по уровню, а флип-флопом по фронту.
По хорошему flip-flop - это любой триггер, элемент с двумя стабильными состояниями. И latch - это синоним flip-flop.
https://en.wikipedia.org/wiki/Flip-flop_(electronics)
Иными словами, ты переделал триггеры работающие по уровню, на триггеры работающие по фронту. Вообще, стрёмная затея, так можно что-то испортить)
- - - Добавлено - - -
Не забыл ли ты соединить базу и исток у T1562 и у всех нижестоящих по схеме триггеров?
https://pic.maxiol.com/images2/1598466292.2997898024.03.png
И еще вопрос по поводу PLM-ок внутри ВМ2.
Например в предекодере.
1. Что за земли с пометкой P и S?
2. Почему каждая линия адреса прямая и инверсная, и транзистор в ячейке PLM может стоять либо по прямой линии, либо по инверсной, либо вообще не стоять. Это что, троичная система получается? )
В транзисторах я ее вижу, но это гораздо менее удобно.
Вопрос привычки. Самый ценный ресурс - время, и под это был продуман и оптимизирован маршрут реверса. Выброшено все лишнее - типы транзисторов, информация о размерах, наработаны типовые расположения элементов, по обратной аннотации там целый ритуал, позволяющий манипулировать целыми группами транзисторов для однотипных ячеек (типа вот этого регистра микроадреса - схема для всех разрядов рисовалась одновременно), я там ролик выкладывал, но без подробных пояснений оно непонятно, и еще есть набор скриптов на перле, и даже изображение транзистора оптимизировано - чтобы пикад быстрее перерисовывал - все для сохранения времени. Если перевести время в деньги, то каждый отреверсенный процессор - это неплохой новый немецкий автомобиль. Привыкнуть понимать схему в транзисторах намного быстрее, чем заниматься не слишком интеллектуальным перерисовыванием с потерей автоматического контроля над ошибками (который в свою очередь позволяет не напрягаться и тоже экономит массу времени). Думаю, что если бы я таким перерисовыванием занялся, то у нас до сих пор и рабочего ВМ1 не было, о стоимости страшно даже подумать, не факт что я это себе позволил бы.
Понял, латчем ты называешь триггер, записываемый по уровню, а флип-флопом по фронту.
Это не я называю, это вполне устоявшаяся общераспространенная терминология.
По хорошему flip-flop - это любой триггер, элемент с двумя стабильными состояниями. И latch - это синоним flip-flop.
Нет, не синоним. В цифровой схемотехнике на сегодня latch подразумевает защелку по уровню, ff - защелку по фронту. По крайней мере, в тех книгах по HDL и цифровому дизайну что я читал используется такая терминология.
Иными словами, ты переделал триггеры работающие по уровню, на триггеры работающие по фронту. Вообще, стрёмная затея, так можно что-то испортить)
Это не затея, это необходимость - ты не сможешь надежно синтезировать латч в большинстве доступных семейств FPGA. Современные FPGA в большинстве своем - синхронные, содержат flip-flops, а с latch у них никак. Да, испортить можно легко, именно поэтому имеется оригинальная эталонная модель на латчах которая может быть только промоделирована, а когда пишется синхронная модель - то модификация происходит небольшими шагами и после каждого изменения прогоняется набор тестов и сравнивается время исполнения - что нигде не потерян или не добавлен такт.
Не забыл ли ты соединить базу и исток у T1562 и у всех нижестоящих по схеме триггеров?
Не забыл, если взять и подсветить - то будет видно что это одна цепь, просто пикад глюкнул и потерял точку junction на рисунке схемы, надо будет дорисовать.
И еще вопрос по поводу PLM-ок внутри ВМ2.
Например в предекодере.
1. Что за земли с пометкой P и S?
2. Почему каждая линия адреса прямая и инверсная, и транзистор в ячейке PLM может стоять либо по прямой линии, либо по инверсной, либо вообще не стоять. Это что, троичная система получается? )
ПЛМ использует каноническую конъюнктивную форму булевой функции нескольких переменных. Сначала вычисляются произведения входных переменных и их инверсий (P - products), а затем суммы произведений (SoP - sum of products), на выходе может быть опциональный инвертор результата. Соответственно, если в произведении нет транзистора - то переменная в данный продукт не входит ни в прямом ни в инверсном виде, если транзистор есть - то в умножении участвует или сама переменная или ее инверсия. Два транзистора не имеют практического смысла, так как x & ~x всегда ложно.
Земли P и S - это специальные цепи (ЕМНИП с именами GND-P и GND-S) подключаемые к "настоящей" земле через группы мощных транзисторов. Сделано для энергосбережения, n-MOS логика прожорливая, недостаточно просто остановить тактирование, а ПЛМ содержит заметную часть транзисторов процессора и нужна далеко не всегда - обычно ядро большую часть времени тупо ждет данные от медленной внешней шины. Поэтому землю ПЛМ можно отключить и оно не будет потреблять ток в простое.
ПЛМ использует каноническую конъюнктивную форму булевой функции нескольких переменных. Сначала вычисляются произведения входных переменных и их инверсий (P - products), а затем суммы произведений (SoP - sum of products), на выходе может быть опциональный инвертор результата.
В общем, фактически мы имеем некое ПЗУ, на адресную шину которого мы подаем входные данные, а на выходе ответ. Только в отличие от ПЗУ реализация гораздо более компактная.
- - - Добавлено - - -
Нашел описание в зарубежной литературе Sum Of Product (SOP) (https://www.electricaltechnology.org/2018/05/sum-of-product-sop-product-of-sum-pos.html)
Латч - триггер запоминающий значение D входа по уровню на С входе (типа ИР22).
Флип-флоп - триггер запоминающий значение D входа по фронту на C входе (типа ИР23)
сигналы на выходе регистров подобных ИР22 появляются раньше, чем у таких как ИР23 и за это время линии, которые стоят за регистрами могут успевать зарядиться, что, возможно, не будет успевать с регистрами как ИР23.
сигналы на выходе регистров подобных ИР22 появляются раньше, чем у таких как ИР23 и за это время линии, которые стоят за регистрами могут успевать зарядиться, что, возможно, не будет успевать с регистрами как ИР23.
Дело не только в этом. Латч прозрачен для сигналов в течении активного уровня тактируемого сигнала, флип - нет. Лично я не представляю, как заменить одно на другое просто так. Надо переписывать и перепроверять всю логику. А в случае с процессором, который весьма сложен - это чревато подводными камнями отхода от совместимости. Тесты выявляют ошибки очень условно. Ошибки тактирования, или всякие ошибки, на которые тесты не рассчитаны, они не выявят.
Кстати, еще вопрос Vslav'у, почему в FPGA сложно реализовать латчи? Ведь это простейшая пара 2И-НЕ, или 2ИЛИ-НЕ.
Или же в FPGA таких элементов нет, а есть только флипы?
почему в FPGA сложно реализовать латчи?
Видимо потому, что в FPGA нет И, ИЛИ, НЕ, латчей, фф, а есть логические элементы, которые управляющими сигналами программируются на выполнение набора некоторых функций. И именно из ЛЭ делают И, ИЛИ, НЕ, триггеры, мультиплексоры.. В простейшем случае - из одного ЛЭ, в более сложные - из нескольких. И структура самого ЛЭ достаточно стандартизована. Ну а дальше надо смотреть - как из ЛЭ делается латч или фф. Ну и учитывая, что из за синхронности проще предсказать, сколько сигнал идёт через фф, чем через латч (и просчитать синтез на предмет временных констрейнтов) - на латчи могли и подзабить - типа - вы хотите латч - вот вам, а дальше - ваши проблемы.
Видимо потому, что в FPGA нет И, ИЛИ, НЕ, латчей, фф, а есть логические элементы, которые управляющими сигналами программируются на выполнение набора некоторых функций. И именно из ЛЭ делают И, ИЛИ, НЕ, триггеры, мультиплексоры.. В простейшем случае - из одного ЛЭ, в более сложные - из нескольких. И структура самого ЛЭ достаточно стандартизована. Ну а дальше надо смотреть - как из ЛЭ делается латч или фф. Ну и учитывая, что из за синхронности проще предсказать, сколько сигнал идёт через фф, чем через латч (и просчитать синтез на предмет временных констрейнтов) - на латчи могли и подзабить - типа - вы хотите латч - вот вам, а дальше - ваши проблемы.
Вот как раз-таки flip-flop есть в FPGA, абсолютно во всех. Надо только глянуть на структурную схему LE/ALM в даташите...
Вот, к примеру, ALM в Altera/Intel:
https://www.researchgate.net/profile/Syed_Manzoor_Qasim/publication/258926868/figure/fig2/AS:296965104521217@1447813406315/Block-Diagram-of-Stratix-II-ALM-Courtesy-of-Altera-Inc.png
Вот как раз-таки flip-flop есть в FPGA, абсолютно во всех. Надо только глянуть на структурную схему LE/ALM в даташите...
Я имел ввиду, как самостоятельный элемент, а не как часть ЛЭ. Понятно, что в ЛЭ есть какое то количество привычных составляющих типа И, ИЛИ, НЕ (см структурную схему)
- - - Добавлено - - -
И понятно, что если есть что то готовое - то "синтезировать" такой объект проще.
Я имел ввиду, как самостоятельный элемент, а не как часть ЛЭ. Понятно, что в ЛЭ есть какое то количество привычных составляющих типа И, ИЛИ, НЕ (см структурную схему)
Во всех FPGA, с которыми я пока работал, flip-flop включён через мультиплексоры и может использоваться отдельно от LUT'а в ячейке. Так что использование FF не всегда означает использование ячейки как таковой - логика может быть подключена к одному участку, FF - к другому.
flip-flop включён через мультиплексоры и может использоваться отдельно от LUT'а в ячейке.
Он существует отдельно от ячейки или всё таки её составная часть?
- - - Добавлено - - -
Задам вопрос по другому - минуя мультиплексор, напрямую, добраться до ff можно?
Он существует отдельно от ячейки или всё таки её составная часть?
- - - Добавлено - - -
Задам вопрос по другому - минуя мультиплексор, напрямую, добраться до ff можно?
В Handbook'е на 4-ый циклон вот такие картинки:
https://image.prntscr.com/image/ZbWY7ewaSR2T5grRcD_zJg.png
https://image.prntscr.com/image/okQaXSWgQSeQRg6VZsnQRA.png
То есть прямого входа на вход D триггера нет, прямого выхода с выхода триггера Q нет. Что я и имел ввиду - триггер - составная часть ЛЭ.
Я думаю, понятно, что когда используется очень небольшая часть из функционала ЛЭ (типа - сделали мы элемент И), у нормального человека возникает досада, что остальной функционал просто пропал. И будь я на месте проектировщиков, я бы попробовал спроектировать ЛЭ там, что его можно было бы "раздробить" на части и использовать по частям. Но поскольку ЛЭ - это основа и должна выполнять ВСЕ функции - полностью разделить и сделать независимыми части - не получается. Ну или не очень старались
- - - Добавлено - - -
Вот что то подобное проектировщики ЛЭ и сделали...
То есть прямого входа на вход D триггера нет, прямого выхода с выхода триггера Q нет.
Все есть, Зайлинкс, Альтера, Личитанг и прочие построены примерно одинаково. ЛЭ содержит LookUp Table (LUT) для реализации комбинаторики и фф для схем с памятью. И обычно их можно использовать по-отдельности. Часто есть еще специальный режим LUT когда оно генерирует два выходных бита для построения сумматоров, плюс еще специальные отводы от соседних ячеек для ускорения переноса.
что его можно было бы "раздробить" на части и использовать по частям
Можно использовать по частям, и фиттеры очень часто это применяют. Квартус, например, в статистике показывает сколько число комбинаторных, чисто триггерных и смешанных ЛЭ получилось в проекте.
Все есть,
Судя по картинке, которая приведена - прямого подключения нет - через логические элементы, мультиплексоры (или демультиплексоры - я их значки не сильно помню - на результатах синтеза по функционалу смотрю)
И ещё раз - я имел ввиду, что на FPGA нет отдельных элементов, которые выполняли бы чистые функции с выходом routing линии. Есть только ЛЭ - более (память, в/в) или менее специализированные. Ведь не пишут же в характеристиках - 100 ЛЭ, 100 ячеек памяти, 100 элементов в/в, 200 ff триггерорв и 200 ЛА3 :)
- - - Добавлено - - -
Можно использовать по частям, и фиттеры очень часто это применяют.
Я и написал, что, допустим, если бы я был проектировщиком ЛЭ - я бы так сделал, что бы не пропадал уж совсем функционал, который в этом ЛЭ не использовался, ибо нужна было только комбинаторика или только триггер и что именно так проектировщики ЛЭ и сделали.
Но звёзды могу так сложиться (по времянке, допустим), что вот в данном ЛЭ использовали только комбинаторику, а триггер остался не у дел
Судя по картинке, которая приведена - прямого подключения нет - через логические элементы, мультиплексоры
Это мультиплексоры конфигурации. Они статически определяются залитым битстримом, именно так реализуется программируемая структура. А как ты иначе сделаешь подключение D-входа триггера или напрямую из роутинга или с выхода локальной LUT? Именно мультиплексоры. И я подозреваю что мультиплексоры там не логические, просто проходные транзисторы.
Мы, похоже, забыли про первоначальный вопрос. Почему нет латчей. И моё объяснение - потому что основа - ЛЭ, а на самостоятельно существующие И, ИЛИ, НЕ, триггеры. И только то, что просто синтезируется (не важно по какой причине) из ЛЭ - то и будет просто синтезируемым. Всё остальное (исходя из структуры ЛЭ) синтезироваться будет сложно. Я не прав в объяснении?
- - - Добавлено - - -
И - нет там самостоятельных триггеров. Они укрыты в инфраструктуре ЛЭ - в том числе той, которая нужная для подключения к линиям роутинга.
И - нет там самостоятельных триггеров. Они укрыты в инфраструктуре ЛЭ - в том числе той, которая нужная для подключения к линиям роутинга.
ЛЭ - это ящик, есть входы и выходы "подключаемые к роутингу". Ящик можно сконфигурировать так что получится независимая комбинаторная функция и независимый FF со своими отдельными входами-выходами, можно использовать по-отдельности.
Латч в FPGA на имитации логических элементов собрать на самом деле можно, иногда оно даже работать будет, но гарантиии повторяемости и переносимости - никакой, средств анализа нет никаких. Влететь запросто - проект пересобрал и работать перестало. Можно долго и нудно прибивать констрейнами, но опять таки - без гарантии.
Ящик можно сконфигурировать так что получится
Что я и говорил с самого начала. Есть только ЛЭ - и как ты их сконфигуришь - так и будут работать.
но гарантиии повторяемости и переносимости - никакой, средств анализа нет никаких.
Ну и учитывая, что из за синхронности проще предсказать, сколько сигнал идёт через фф, чем через латч (и просчитать синтез на предмет временных констрейнтов)
И? Типа я сказал что то другое?
Влететь запросто - проект пересобрал и работать перестало.
Это я хорошо выучил на PDP-2011 проекте от автора. Две строчки местами поменял (даже не связанные!! между собой) - и пушистый зверёк. Я хренову тучу времени убил на то, что бы всё это дело синхронизировать. Результат - у меня практически всегда запускается на 100 МГц, а когда первоначально трогал авторский - часто и на 25 не запускалось
Латч прозрачен для сигналов в течении активного уровня тактируемого сигнала
Именно поэтому сигналы на его выходах появляются - раньше (регистр еще не зафиксировал данные, а они уже появляются на выходе). В некоторых случаях это может ограничивать максимальную частоту работы микросхемы. Так же если заменять одно на другое (ИР22 на ИР23), то придется ставить инвертор тактового сигнала.
Интересно спросить Ynicky, что он думает про латчи, т.к. он делал 1515 для FPGA, а в 1515 полно латчей.
Интересно спросить Ynicky, что он думает про латчи, т.к. он делал 1515 для FPGA, а в 1515 полно латчей.
В своих разработках я стараюсь их избегать. И здесь я сначала пытался заменить их на флипфлопы, но потом решил описать как есть, промоделировать, убедиться что все работает правильно, а затем только попытаюсь их заменить, хотя бы где можно.
На сегодня подсоединил 8ми разрядную DRAM(DS5-DS12), сделанную из внутренней синхронной памяти ПЛИС. Остальную 16ти разрядную DRAM(DS13-DS28) подсоединил через SDRAM контроллер к внешней памяти. Преобразовал видеовыход на HDMI. Отдельно вроде все работает. Но при моделировании всего УКНЦ вылезают глюки. Пока с ними разбираюсь.
Преобразовал видеовыход на HDMI.
Как преобразовал? Про HDMI поподробнее, плиз.
Ведь для этого мало того, что нужен какой-нибудь внешний TDA19988, так еще и данные для HDMI подготовить. В каком разрешении HDMI?
- - - Добавлено - - -
затем только попытаюсь их заменить, хотя бы где можно.
Если будешь заменять, опубликуй, какой элемент и на какой ты заменяешь, чтобы можно было проверить, корректно это или нет.
- - - Добавлено - - -
На сегодня подсоединил 8ми разрядную DRAM(DS5-DS12), сделанную из внутренней синхронной памяти ПЛИС. Остальную 16ти разрядную DRAM(DS13-DS28) подсоединил через SDRAM контроллер к внешней памяти.
А нет ПЛИС, в которой уже на борту 192Кб?
- - - Добавлено - - -
Для Vslav:
Интересно, что у входного триггера /EVNT сигнал INIT имеет меньший приоритет, чем активный /EVNT в сочетании с /PLI_REQ.
Иными словами, если /EVNT = 0 (активен), и PLI_REQ = 0, то на выходе триггера все равно будет активный EVNT, даже, если INIT активен.
INIT сработает тогда, когда /EVNT станет равным 1 или PLI_REQ = 1.
А нет ПЛИС, в которой уже на борту 192Кб?
SRAM у FPGA в спецификациях дается в Kbit-ах, обычно блоки 9Kbit или 18Kbit (с возможностью адресации как 2 отдельных блока).
Если посмотреть на Xylinx Spartan или Artix, то нужно кол-во SRAM (2000 Kbit и выше) -- это старшие модели в серии, имеющие 50, 75, 100K Logic Cells.
Есть дешевые борды у китайцев, например вот это. Це вопроса под $100:
https://www.aliexpress.com/item/4000170042795.html?spm=2114.12010612.8148356.2.6fe 57fb2pEkpfm
Vslav щупал китайский Anlogic с 64MB 16bit SDRAM в корпусе FPGA, что так же интересно. Цена вопроса за борду - ~ $20.
но 16bit SDRAM, а для УКНЦ надо 24 bit SDRAM
а для УКНЦ надо 24 bit SDRAM
Для УКНЦ надо три банка по 64Kx8 бит.
LeoN65816
28.08.2020, 15:01
Именно поэтому сигналы на его выходах появляются - раньше (регистр еще не зафиксировал данные, а они уже появляются на выходе).
Предельно мягко и тактично: ты сам то понял, что сказал?... ;)
Интересно, что у входного триггера /EVNT сигнал INIT имеет меньший приоритет
Ты про T643? Он там вообще лишний, потому что дальше EVNT поступает на детектор фронта. И если бы INIT маскировал EVNT то по каждому INIT мы получали бы ложный фронт EVNT и лишнее прерывание.
Поскольку INIT формируется только самим ВМ2 и прерывания при этом не опрашиваются, то PLI_REQ все время низкий и ложного прерывания не получается.
- - - Добавлено - - -
Для УКНЦ надо три банка по 64Kx8 бит.
Не, надо использовать 16-битную SDRAM для ЦП и ПП, а для видеоконтроллера уже набирать пакетами строки в промежуточный буфер для формирования видеоданных 8x3. ПП ускорится (потому что 16-битный доступ) и видеоконтроллеру будет норм.
Не, надо использовать 16-битную SDRAM для ЦП и ПП, а для видеоконтроллера уже набирать пакетами строки в промежуточный буфер для формирования видеоданных 8x3. ПП ускорится (потому что 16-битный доступ) и видеоконтроллеру будет норм.
Мы про что говорим, про 100% УКНЦ на FPGA, или просто про совместимую с УКНЦ машинку?
Мы про что говорим, про 100% УКНЦ на FPGA, или просто про совместимую с УКНЦ машинку?
Что ты понимаешь под 100% УКНЦ?
Что ты понимаешь под 100% УКНЦ?
100% потактовый клон УКНЦ. На котором ни одна программа ни одним тестом не сможет отличить клон от оригинала.
Конечно, с оговоркой, что моделей УКНЦ было несколько, на разных версиях ХМ1/2.
Т.е. точный клон выбранной модели.
Все остальное - это лишь в той или иной степени совместимая с УКНЦ машинка.
Как преобразовал? Про HDMI поподробнее, плиз.
Ведь для этого мало того, что нужен какой-нибудь внешний TDA19988, так еще и данные для HDMI подготовить. В каком разрешении HDMI?
HDMI - это уменьшенный разъем стандарта DVI, применяемый для передачи цифровых мультимедийных данных. Он позволяет передавать широкий спектр форматов изображения. Главное - необходимо правильно закодировать тот формат, который нужно передать, ну и чтобы получатель данных мог этот формат раскодировать и отобразить. Никаких преобразований видеоформата УКНЦ я не делаю. Я просто подставляю RGB, синхросигналы и соответствующие частоты передачи на HDMI передатчик, который в свое время сделал MVV и выложил в открытый доступ. Воспримет ли телевизор видеоформат УКНЦ - пока не знаю. Но тот телевизор, который есть у меня с HDMI входом воспринимает сигнал с УКНЦ на VGA входе.
на HDMI передатчик, который в свое время сделал MVV и выложил в открытый доступ
Ссылка?
- - - Добавлено - - -
Но тот телевизор, который есть у меня с HDMI входом воспринимает сигнал с УКНЦ на VGA входе.
Какой именно сигнал? Прям RGB-сигнал подаешь на VGA-вход?
Если есть картинка на телевизоре, нужны скриншоты.
Ссылка?
- - - Добавлено - - -
Какой именно сигнал? Прям RGB-сигнал подаешь на VGA-вход?
Если есть картинка на телевизоре, нужны скриншоты.
Смотри сообщения 914 и 916(третья ссылка).
Смотри сообщения 914 и 916(третья ссылка).
По поводу HDMI - там мне мало что понятно, т.к. я не разбираюсь в Verilog-е, а описания на человеческом языке нет.
Посмотри эту ссылку:
https://marsohod.org/projects/proekty-dlya-platy-marsokhod3/307-max10-hdmi
Некоторые пояснения к моей реализации HDMI. Так как pixelclock в УКНЦ равен 12,5 МГц, а нижняя частота pixelclock HDMI интерфейса должна быть не менее 22 МГц, то я сделал следующее:
На HDMI передатчик я подаю pixelclock равный 25 МГц, т.е. каждый пиксель будет передаваться дважды подряд, соответственно количество пикселей в итоге будет равно 1600 (из них видимых 640х2=1280). Строк у нас 312. Таким образом на телевизор будет поступать следующий формат изображения: 1600х312. Период такого кадра соответственно равен: 40 нс (длительность 1го пикселя) х 1600 х 312 = 19,968 мс (чуть больше 50 Гц). Такой кадр могут отобразить только FullHD телевизоры (это надо иметь в виду)!
Таким образом на телевизор будет поступать следующий формат изображения: 1600х312.
Вообще-то есть стандарты, которые отобразят все телевизоры. А вот как раз такое нестандартное разрешение может случится что отобразит почти-то никто)
- - - Добавлено - - -
По хорошему, чтобы получить нормальную картинку, надо преобразовывать экран УКНЦ в один из стандартных режимов HDMI. Для этого нужен промежуточный буфер изображения.
Вообще-то есть стандарты, которые отобразят все телевизоры. А вот как раз такое нестандартное разрешение может случится что отобразит почти-то никто)
- - - Добавлено - - -
По хорошему, чтобы получить нормальную картинку, надо преобразовывать экран УКНЦ в один из стандартных режимов HDMI. Для этого нужен промежуточный буфер изображения.
Нужен стандартный режим телевидения, а не HDMI. Наиболее близкий - это 625 строк на 25 Гц. В нашем случае - 312 строк на 50 Гц почти совпадает со стандартным режимом телевидения (с учетом чересстрочной развертки). А вот разрешение по горизонтали могут не все телевизоры поддержать.
Нужен стандартный режим телевидения, а не HDMI. Наиболее близкий - это 625 строк на 25 Гц. В нашем случае - 312 строк на 50 Гц почти совпадает со стандартным режимом телевидения (с учетом чересстрочной развертки). А вот разрешение по горизонтали могут не все телевизоры поддержать.
Ну, попробуй на практике, посмотрим, что получится)
Еще для Vslav'а:
В ВМ2 заметил D-триггеры, у которых есть вход, D, C, и R. Причем, R сбрасывает только одно плечо триггера, что может привести к глюкам (потенциальным, я это еще не проверял).
Еще для Vslav'а:
В ВМ2 заметил D-триггеры, у которых есть вход, D, C, и R. Причем, R сбрасывает только одно плечо триггера, что может привести к глюкам (потенциальным, я это еще не проверял).
Это все учитывалось и это еще одна причина оставить схему в транзисторах.
Это все учитывалось и это еще одна причина оставить схему в транзисторах.
Перевод в логические элементы не мешает это учесть. Просто надо учесть, и всё)
Перевод в логические элементы не мешает это учесть. Просто надо учесть, и всё)
Ну-ну. Есть RS-триггер нарисованный в виде ЛЭ, что будет на прямом выходе если R и S активны? А на инверсном? Ответишь глядя на такую схему?
Ответ "это запрещенное состояние" - не канает, потому что в схеме такая комбинация входов случается. Абстракция всегда теряет в детализации.
Titus, посмотри, пожалуйста, сигнал OUT_A_LOW в ХМ-032. Как я понял, он низким уровнем должен переключать мультиплексор MUX_A на младшую часть адреса, а он у меня переключает на старшую (как в rev 43). Как должно быть?
Я уже не раз упоминал, что 1 на R и S - это 0 на обоих выходах. Это нормально и штатно, если оговорено в особенностях элемента.
- - - Добавлено - - -
@Titus, посмотри, пожалуйста, сигнал OUT_A_LOW в ХМ-032. Как я понял, он низким уровнем должен переключать мультиплексор MUX_A на младшую часть адреса, а он у меня переключает на старшую (как в rev 43). Как должно быть?
Высоким уровнем он переключает.
Видишь, на входе 17 написано /X или Y. Т.е. X выбирается нулем, а Y выбирается единицей.
В этом случае у меня он в 1 при активном RAS (ст. разряды) и в 0 при активном CAS (мл. разр.). Логику проверил, вроде как у тебя.
P.S. Понял, ст. и мл. наоборот.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot