Цифровая археология: 1801 и все-все-все

Вид для печати

Показывать 40 сообщений этой темы на одной странице

02.07.2020, 22:15
forth32

Цитата:

Сообщение от Vslav

Надо ковырять 055 чтобы понять когда выводится сообщение о незапланированном прерывании и пытаться поймать это место.

Да место-то как раз более-менее понятно...
Если опираться только на результат дизассемблирования, то пока видна единственная ситуация, в которой это может произойти. Получается, что при выходе из прерывания по RTI не восстанавливается бит 8 PSW, управляющий режимом user/halt. В результате управление уходит не в монитор а хрен знает куда - по адресу 170004 в юзерском пространстве ничего нет, возникает таймаут шины и незапланированный вылет по вектору 4. Обработчик вектора 4 выводит сообщение о незапланированном прерывании и делает RTI, и далее все по кругу несколько раз, пока стек не затрет какие-то куски кода в памяти.
Как вариант, бит 8 может быть и восстанавливается, но при этом не поднимается бит wb_adr[16] (который бывший SEL) - тогда не переключается карта памяти с теми же самыми последствиями.
В выходные постараюсь написать тестовую программку, моделирующую эту ситуацию, тогда станет понятнее. Может быть, я и не прав. Тут надо тщательно разбираться.
02.07.2020, 23:42
Vslav

Цитата:

Сообщение от forth32

Да место-то как раз более-менее понятно...
Если опираться только на результат дизассемблирования, то пока видна единственная ситуация, в которой это может произойти. Получается, что при выходе из прерывания по RTI не восстанавливается

В тестовой SoC есть прерывания от таймера, я проверю восстановление PSW8 и адрес wb_adr_o[16].
03.07.2020, 07:38
forth32

Вложений: 1

Цитата:

Сообщение от Vslav

В тестовой SoC есть прерывания от таймера, я проверю восстановление PSW8 и адрес wb_adr_o[16].

Да тут аппаратные прерывания как таковые для проверки не нужны.
Тут такая ситуация. Монитор по команде Т переписывает весь тестовый код из ПЗУ в младший банк ОЗУ и передает туда управление командой START. Далее отрабатывается тест, и затем происходит возврат в монитор вот таким способом:

Код:

ROM:002306 loc_2306: ; CODE XREF: sub_1570+104↑J ROM:002306 ; default_int_handler+20↑J ... ROM:002306 012746 000740 mov #740, -(SP) ROM:002312 012746 170004 mov #loc_170004, -(SP) ROM:002316 000002 rti

По адресу 170004, а это теневой банк ОЗУ, лежит команда JMP на бесконечный цикл обработки пультовых команд. И вот в этот момент, после RTI, и происходит незапланированное прерывание. Понятно, что если сигнал SEL не поднимется, то так и будет - после RTI управление уйдет на несуществующие адреса.

Надо это дело проверить. Я написал простенькую тестовую программку:

Код:

.WORD START .WORD 0 .= 100 START: MOV #410,SP MOV #740,-(SP) MOV #RMON,-(SP) RTI RMON: MOV #MSG2,R3 CALL printstr MFPS R3 CALL PNUM STOP: BR STOP MSG2: .ASCIZ <15><12>"* PSW = "

Эта программка моделирует вышеописанный возврат в монитор - заталкивает в стек PSW с поднятым 8 битом. Запускаю. В терминале:

Код:

* PSW = 177744

Вроде все правильно, бит 8 PSW установился.
Дальше чисто программными способами, без изменения схемы, не проверить. У меня на моей плате есть 4 светодиода. Я подвесил на один из них бит 16 адреса:

Код:

reg [16:0] indaddr; always @ (posedge wb_stb) indaddr [16:0] <= wb_adr [16:0]; assign led0=indaddr[16];

Запускаю схему - светодиод не светится. То есть adr[16]==0. А поскольку программа в конце зацикливается и начинает топтаться по одним и тем же адресам, то все транзакции на шине должны быть с wb_adr[16]==1, и светодиод должен ярко светиться.
Вот она, проблема.
Остается промоделировать все это в моделсиме. Осциллограмму сюда я вставлять не буду, бесполезно это, прикладываю ее в архив. На ней хорошо видно:
1. Процессор читает слово 740 с адреса 000406. Это он из стека достал новый PSW.
2. По адресу 000116 читается 12703. Это уже выбирается первая команда после возврата по RTI. Адрес - именно 000116, ,бит 16==0, то есть перехода в режим пульта не было. Хотя в PSW бит 8 поднялся.

Вот и все мои на данный момент изыскания. Прикладываю архив с тестовой программкой. Конечно, запускать ее имеет больше смысла в симуляторе.
03.07.2020, 09:21
Vslav

Цитата:

Сообщение от forth32

По адресу 170004, а это теневой банк ОЗУ, лежит команда JMP на бесконечный цикл обработки пультовых команд. И вот в этот момент, после RTI, и происходит незапланированное прерывание. Понятно, что если сигнал SEL не поднимется, то так и будет - после RTI управление уйдет на несуществующие адреса.

Ни добавить, ни убавить - как всегда, блестящий и точный анализ от forth32, указывающий на проблему.
Чтение 170004 после rti на оригинальной асинхронной модели:

Скрытый текст

http://www.1801bm1.com/files/images/org_model_sel.png

[свернуть]

Чтение 170004 после rti на SoC модели (синхронная модель ведет себя тоже проблемно):

Скрытый текст

http://www.1801bm1.com/files/images/wbc_model_sel.png

[свернуть]

Вывод: реверс сделан правильно, чего-то поломалось при переносе на FPGA. Будет чем заняться на выходные.
03.07.2020, 11:23
Vslav

- при чтении 170004 не вырабатывается SEL
- а именно не вырабатывается sel2
- psw[8] не установлен
- при извлечении из стека нового слова состояния psw8_wa строба не было
- psw8_wa строба не было, так как был активен сигнал sf_byte, то есть - восстановили только младший байт из стека
- sf_byte активен из-за plm[1] указывающего на байтовую операцию
- выполнились микроинструкции по разным адресам 16₈(ошибка)/66₈(оригинал)
- неверный переход из-за разряда регистра ix[1]
- неправильно отработал сигнал dc_aux
- не появился сигнал bra
- потому что запоздал сигнал выхода матрицы ветвления plb
- потому что вход матрицы dc_b7 не успел поступить из-за замены латча на флип-флоп

dc_b7 - он как раз отвечает за проверку адреса возврата >= 160000 чтобы разрешить
возврат в пультовый режим, из-за запаздывания dc_b7 проверка была провалена.

В-общем, не уследил за одним латчем, сделал проброс:

Код:

br[7] <= ~(wr2 ? (ax[15:13] == 3'b111) : dc_b7);

forth32, спасибо за помощь в отладке, на github выложено обновление с куммулятивным фиксом - поправлены все найденные ошибки.
03.07.2020, 12:10
forth32

Ну, что ж, вот и все заработало наконец. Спасибо огромное, VLSAV! Тесты теперь практически идут как надо:

Код:

@T0 *** test sistemnoj pamqti *** prowerka okon~ena *** test ozu *** pamqtx 020000 -157776 pamqtx 000600 -017776 prowerka okon~ena *** test prc *** prowerka okon~ena *** test terminala *** wwedite sledu`}ie simwoly: 1 2 3 4 J C U K prowerka okon~ena *** test acpu *** defekt 16 *** test ngmd *** defekt nezaplanirowannoe prerywanie @

Последний тест НГМД все же выдает уже порядком надоевшее незапланированное прерывание, но это, скорее всего, из-за того, что портов контроллера НГМД в моей системе физически нет - при попытке работы с ними будет как раз такое прерывание. Но я, на всякий случай, это еще проверю, мало ли что еще могло всплыть.
Теперь осталось сочинить схему контроллера ИРПР для подключения принтера, и какой-нибудь эмулятор дисковода на SD-карте, как это сделано, например, в проекте PDP2011. Скорее всего это будет RK05 как самый емкий из поддерживаемых монитором.

Надеюсь, что ошибок в системе больше нет. Хотя вполне допускаю, что они могут встречаться в других процессорах. На них ведь до сих пор ничего серьезнее тестов не запускали. Возможно, когда-нибудь кто-то соберет практическую схему, например, МС1201.01 на ВМ1, погоняет тесты и тоже на что-нибудь нарвется.

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

Добавил в схему пару регистров на место портов НГМД - тест стал завершаться с дефектом 27. Никаких больше незапланированных прерываний. Полная победа!
03.07.2020, 12:12
Vslav

Цитата:

Сообщение от forth32

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

Да, покрытие заводскими тестами оказалось так себе, поэтому буду запускать проект mc507 - ДВК на FPGA. Блочный накопитель на SD-карте тоже в планах. Ну и надо бы переработать ПЗУ, там много мусора, его выкинуть, переместить на 160000, умерить аппетиты на теневое ОЗУ.
03.07.2020, 12:47
Hunta

Цитата:

Сообщение от forth32

как это сделано, например, в проекте PDP2011.

Фигово там, на самом деле, сделано. Точнее, будут две проблемы, если использовать RK11 или RL11 и одна с половиной проблема, если RH11.

- В RK11 и RL11 после того, как стартует операция, делается запрос на ПДП и он снимается после того, как ВЕСЬ запрос закончится.
- Все контроллеры рассчитаны на внутренний вариант шины, а он не совсем совпадает с QBUS - ни по сигналам, ни по логике отработки, по крайне мере, ПДП.
- Первый пункт в RH11 автор вроде поправил, но налетел на эпизодическую ошибку в каком то варианте Unix-а, причем виноват именно новый вариант RH11

Ну и как "вишенка" на торт - RK11 и RL11 (со старой схемой работы) работают только с SD картами, но не с более новыми. Хотя это и не сильно парит - SD
ещё есть в продаже. RH11 он переделал и на поддержку новых карт, но... см пункт 3

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

Вдогонку. RK11 я переделал, что бы он не был такой жадный к ПДП (остальные пока нет), но он рассчитан на мой вариант внутренней шины (который как бы ещё в процесс развития и доработки, хотя на DE10 вроде как всё работает но проблема), плюс на виртуальную "корзинку", плюс, для выхода на QBUS - на конвертер QBUS <-> внутренняя шина. И до какой то степени "корзина" и особенно конвертер - в процессе отладки и доработки. То есть пока отдавать, собственно, нечего...

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

Э.. Забыл написать про половинку проблемы с RH11. Отсутствие загрузчика (вроде как) в 055 прошивке. Но тут наверняка не скажу - 055 не потрошил - и какие там загрузчики - не скажу. Просто сильно подозреваю, что для RH11 нету..
03.07.2020, 13:10
forth32

Цитата:

Фигово там, на самом деле, сделано. Точнее, будут две проблемы, если использовать RK11 или RL11 и одна с половиной проблема, если RH11.

Да, это я знаю. Я лет 5 назад поигрался с этим проектом. Думал из него сделать МС1201.02, но не получилось - тут нужен именно ВМ2.
Тогда я перегнал большинство исходников с мерзкого VHDL на кошерный Verilog, сделал полноценный терминал VT52 вместо того убожества, что там было, и сильно переделал дисковую подсистему. В моем варианте все три контроллера уже работают с SDHC-картами, более того, они все разделяют между собой одну и ту же карту, каждый хранит образы дисков в своей области адресов.

В данном случае контроллер RK05 мне придется переделать с недо-QBUS шины на стандартный wishbone, тогда его можно будет легко подключить к уже сделанной МС1201.02. Вот и займусь в выходные. Может быть, потом и еще кому пригодится.

Цитата:

Сообщение от Vslav

Ну и надо бы переработать ПЗУ, там много мусора, его выкинуть, переместить на 160000, умерить аппетиты на теневое ОЗУ.

Если из него выкинуть тесты, лишние загрузчики (типа перфоленточного) и еще кое-какой хлам, то можно, наверное, килобайта в 3-4 уложиться, а то и меньше. Там самое жирное - эмулятор FIS-инструкций, ну и обработчик пультовых команд тоже немало занимает. Можно вполне его упихать в щель 160000-167776, там все равно никаких портов нет. Тогда в юзерском режиме будет доступно 000000-157776. А теневое ОЗУ -оно же все равно пропадает, в данном случае область 160000-177776. Пусть себе монитор ее использует как хочет.
Я бы мог заняться такой переделкой ПЗУ 055, поскольку уже его дизассемблировал, но в данном случае нужны, как я понимаю, ДВКшные пзу.
03.07.2020, 13:17
Hunta

Цитата:

Сообщение от forth32

они все разделяют между собой одну и ту же карту

Даже не буду на это заморачивать, плюс как раз в том, что могут параллельно работать. Так что у меня к DE10 подключена платка, на которой разведено три SD разъёма и в планах ethernet адаптер припаять

Цитата:

Сообщение от forth32

с мерзкого VHDL

Вы просто не умеете его готовить. И в нём есть некоторое количество полезностей, которых нет в verilog

Показывать 40 сообщений этой темы на одной странице

Цифровая археология: 1801 и все-все-все

Скрытый текст

Скрытый текст