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

[forth32]

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

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

[Vslav]

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

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

[forth32]

В тестовой 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 поднялся.

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

[Vslav]

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

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

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

[свернуть]

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

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

[свернуть]

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

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

[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. Никаких больше незапланированных прерываний. Полная победа!

[Advertiser]

[Vslav]

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

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

[Hunta]

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

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

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

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

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

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

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

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

[forth32]

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

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

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

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

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

[Hunta]

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

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

с мерзкого VHDL

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