PDP-11 на FPGA

[Hunta]

Поскольку появились варианты PDP-11 с VT105, встал вопрос с HX: У которого по умолчанию CSR 177560 После некоторых раздумий, появились два варианта HX - с CSR 177560 и 177060 (CSR для "консольника" halt режима)

И вот тут я малость ступил (ну а чё - два часа ночи, голова спать хочет) - после сборки образа с XXDP под новый вариант CSR, когда XXDP решила не загружаться - подумал, что опять что-то не доделал в модуле uart.

Но с утра голова была посвежее - и обнаружил, что драйвер HX для XXDP от Патрона я слегка подпилил - увеличил макс размер устройства до 32 Мб. А когда собирал ночью драйвер - использовал не тот исходник В общем, поправил, слегка - ещё раз - исходник, генерацию драйвера и сделал два варианта образа XXDP. Главное, теперь не забывать и грузить с правильного устройства для VT варианта PDP-11 Ну а для без VT-шного варианта - пока без разницы - оба эмулятор VT52 Патрона настроены одинаково.

Теперь можно тесты для VT погонять

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

Нашёл Acceptance test для VT105 Нуу... Сильно быстро он отрабатывает

[Hunta]

Весь в тестировании и фиксах... Вроде разобрался с модулем ПДП, но, похоже, реализация обмена внутренней шины и модуля SDRAM страдает... некоторой неправильностью. Плюс там ещё и разные тактовые домены. Судя по тому, что я видел в сигналтап - реализация протокола обмена с SDRAM более-менее правильная, а вот взаимодействие с ним со стороны модулей PDP-11.. Закончу прогон формального теста для сгенерированных конфигураций PDP-11 и займусь этим

[Hunta]

Иногда в голову приходят неожиданные идеи

Очередная.

В некоторых процессорах имеется в наличии регистр PIRQ - с помощью него можно организовать программный запрос на прерывание - выставляешь в нём определённый бит (биты) и оп-па (если приоритет процессоры позволяет) - прилетает запрос по вектору 240. У автора PDP-2011 этот регистр тесно интегрирован с процессором (то есть в коде cpu.vhd идёт прямая работа с регистром). Поскольку в основе PDP-11X лежит PDP-2011 - так же до сегодняшнего дня было и у меня Но теперь запросы на прерывание от PIRQ построены по общей схеме - то есть он для процессора - как некое внешнее устройство Это позволило облегчить модуль процессора Для некоторых моделей, понятно

Из занятного.

В реальных PDP-11, насколько мне известно на текущий момент, только (максимум) четыре уровня приоритета запросов на прерывания - с 4 по 7. PIRQ - единствененый способ запросить прерывания на уровнях приортета с 1 по 3 Ну и запроса на уровне приоритета 0 не существует даже теоретически

[Alex]

Интересно, а как на машинах серии Pro-3XX?
Там же контроллер прерываний ...
И он подключен как? К одному уровню прерываний или что-то более хитрое?

[Hunta]

Даже не скажу, это надо схемы смотреть, как там разведено соединение этого чипа с процом. Насколько мне не изменяет память, у самого F11 так же четыре входных линии запросов на прервание - с приоритетами с 7 по 4. И как я понимаю, внешний контроллер они добавили, что бы упростить реализацию подтвеждения прерывания - вместо того, что бы клепать на каждой плате расширения - они вынесли всё это дело на материнку. С соотвествующей необходимостью программировать этот чип. Как и примерно сделали с дешифровкой адресов этих плат.

В планах попробовать собрать на основе PDP-11X и Pro серию, но там из-за особенностей архитектуры возни и доп модулей будет больше. Так что пока только более традицонные варианты - типа KDF11, KDJ11. Ещё непаханное поле - с T11 - опять же - из-за его особенностей, хотя с ним вроде проще будет

[Hunta]

Как бы это сказать помягче... В общем, шаловливые ручки в очередной раз завели меня в модуль (раньше он входил в состав процессора, но потом я его оттуда выделил - с прицелом на использования и для ПДП устройств) ввода-вывода. Исходно, как он работал (ввод-вывод) у автора - мне не нравилось, в первую очередь - в случае устройств - да, да, SDRAM! - для которых надо было ждать заверешениие цикла чтения или записи, а с учётом того, что код (тогда ещё) из PDP-2011 планировалось использовать и для внешних (по отношению к FPGA) устройств - был добавлен сигнал (аналог) RPLY. Но в первом варианте мне не нравилось то, что цикл в/в заканчивался ожданием снятия сигнала - тратились такты. А их можно было бы и потратить впараллель с продолжившим работу процессором. Но есть ситуации, когда за первой операцией в/в сразу следует вторая. И их надо разделять на шине - то есть тут всё таки подождать окончания предыдущей перед началом следующей. Но с ходу придумать - как это сделать - тогда (уровень знаний FPGA) не получилось Потом в какой-то момент я придумал некий вариант, который вроде бы позволял достичь этого, но.. получалось много тактов ожидания.

И вот в очередной раз сунулся в этот вопрос Где-то так на пятый день войны (в том числе - и со своими ошибками) вроде бы начало вырисовываться решение Ещё не окончательный вариант - но из тупика сдвинулся

[Hunta]

Фуф.. Всё таки записал видео про VT105 и его тест Жена слегка обработает - и выложу
Сильное подозрение, что скорость прохождения теста на моём экземпляре VT105... э... "несколько" выше, чем на оригинале от DEC

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

Тест VT105
В живую чуть по другому воспринимается, в видео всё таки есть эффект от частоты видео и частоты обновления монитора. Но более менее похоже Если с ходу видео не запуститься - Ctrl-F5

[Hunta]

Добавляю в VT поддержку русских букв и псевдографики
Прикольную ошибку посадил - чуть чуть ошибся

[Hunta]

Рисую символы в верхней половине ASCII. Некоторые готовые можно перенести, некоторые с доделкой, некоторые с нуля...

Дошёл до буквы "И" в слове "Передовую"

[Hunta]

Ошибки - наше всё Посадил ещё одну - и долго пытался понять - кто виноват. Оказалось - ошибка усечения
Поправил. Продолжаю клепать шрифты. Доделаю нижнюю половину верхней половины (ну, может похожие по начертания буквы перенесу) и спаааать..

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

Остались русские буквы..