Просмотр полной версии : PDP-11 на FPGA
Перепилил ещё два модуля. Один - массив данных - так что его быстро сделал. А второй - некоторая кучка регистров для некоторой кучки сигналов. Механическая мутораня работа - времени много. Но вроде работает - проверил доступность регистров и чтение-запись. Вроде ещё один модуль и можно будет посмотреть - что из этого вышло...
Словный ускорит процесс в 2 раза точно... Возможно даже чуть более...
PDP-11 машина ориентирована всё же больше на слова.
Словный ускорит процесс в 2 раза точно
Нет. В силу того, как идёт обмен контроллера с терминалом. И уж
Возможно даже чуть более
точно нет.
Небольшой ускорение будет на обработке прерывания (войти-сохранится ... выйти), а то что внутри (обработка буфера плюс возможная перекидировка) - как был, так и останется. И если посмотреть драйвер операционок - будет заметно, что на передачу - основные затраты будут именно там.
Ну а приём - вообще выигрыш от словного обмена (с терминалом) будет околонулевой.
Единственно, где будет заметно ускорение - это когда терминал будет использоваться для (интенсивного) межкомпьютерного общения. Но и там - мультиплексоры выиграют сильнее.
И есть ещё один подводный камень - само устройство как должно сообщать, а терминал это определять - принято/передается два байта или один - и на это тоже нужны будут команды, так что выигрыш от того, что для передачи (условно) нужна одна команда (слово), а не две (два байта) - нивелируется ещё и этой (этими) доп командами для решения вопроса - байт или слово. Ну и драйвера придётся допиливать.
Подводя итоги - выигрыш будет только на то, что будет одно, а не два вхождения и выхода в/из прерывания.
Перепилил последний модуль, связал все, теперь тестирование. Пока не работает :)
Когда-то это уже было - https://zx-pk.ru/threads/28952-pdp-11-na-fpga.html?p=958774&viewfull=1#post958774
Только тогда авторский вариант видеотерминала был ниочем - так.. игрушка-заготовка.
То есть я с ним поигрался, пробовал допилить, но.. знания vhdl и fpga были не того уровня.
И вот, не прошло и пяти лет, как вдруг вслыла в голову мысль - а не взятся ли нам за нашего Вильяма Шекспи.. тьфу - за модуль VT от автора PDP-2011 :) К этому времени и знания-умения подросли и перепелил я много чего в PDP-2011, так что решил даже название сменить и автор сделал ОЧЕНЬ приличный видеотерминал, а вот у меня руки-желания не доходили :)
Но подумал я (как всплыло в голову) и всё таки сел за переделку модуля VT под PDP-11X. И вот, не прошло и четырёх дней (где то 3.5 дня понадобилось минус сон и домашние дела), как...
Та-да-да-дам! (http://www.KpXX.Ru/PDP-11X(93/VT)
- - - Добавлено - - -
Качество телефонное, но демонстрируется не всё про модуль VT, как сделаю какую-никакую демонстрашку (заодно и проверю функционал) - попробую сделать фото и видео фотоаппаратом жены :)
Приведение в порядок и объединения исходников
Теперь есть ещё одна реализация - аппаратная - терминала класса VT52 :) Ну, на самом деле там не совсем VT52 плюс нет меню для возможности настройки параметров, но поскольку это определяется прошивкой - вопросы решаемы :) Плюс ещё хочу добавить поддержку русского набора символов плюс псевдографику :)
Процесс объединения кода с упором на параметризацию продолжается. Ещё продолжил прочёсывать программный код модуля VT - мне некоторые места в коде не нравятся, да и допилить до русских букв хочется, но для начала - причёска кода под меня с проверкой правильности результата.
Так что пока чего-то нового некоторое время не будет.
Дальше в планах (помимо русских букв) - попробовать переключить режим VT с 640х480 на 1280х1024 (в идеале - с параметризацией) - это нативный для монитора.
- - - Добавлено - - -
Подумалось - благодаря сильной параметризации процессора (если быть точнее - то можно ещё добавить) - можно собирать вариант процессора только с теми командами, которые использует модуль, собираемый на основе процессора PDP-11 - типа (на текущий момент) VT и XU :) Ну и никто не мешает добавить свои - нужные - команды :) Надо только запараметризовать и требуемые для HaltMode команды - что бы он (внезапно) не перестал работать :)
Различные варианты конфигураций "PDP-11" и процессорных "плат" объединил в исходники с параметризаицей. Теперь синтезы, проверки и фиксы ошибок, которые найду. Ну и после этого переделка старых вариантов конфигураций "PDP-11" под новые реалии :)
В процессе разборки с графикой VT105 нашёл ошибку при перепиле (классический copy-paste) и занимательную ошибку (до сих пор никаких не проявлялась) в контроллере последовательного порта KL11 - мой код был написан так, что при чтении регистра буфера вывода (177566 для консольного) автоматом отправлялся байт 0 :) Не начал бы отлаживать код VT105 - так бы и болталась. Ну и много времени убил на то, что бы понять - кто дурит - код HaltMode или всё таки KL11. Пришёл к выводу, что всё таки KL11 - щас синтезируется для проверки.
По графике VT105. Увы, несколько разочаровала - она всё таки ориентирована на бизнес применение, а не на просто графики. Из обнаруженных "проблем" - для каждой координаты X может присутствовать (за исключением спец-применений) только одна точка по оси Y. Так что даже простые математические графики вызовут проблему - как только понадобиться (по любой причине) поместить для одного X-а несколько Y-ов или, скажем, нарисовать вертикальную линию. Хотя, конечно - может я просто не до конца разобрался - особенно в тех самых - спец-вариантах.
- - - Добавлено - - -
Да, ошибка исправлена. Ну и задно начал переделку KL11 под стандартный вариант работы шины.
Потом попробую нарисовать демо-программу, показывающую работу VT105 и заснять видео.
Basic с поддержкой графики на VT105 нашёл, но беда в том, что оно хочет MINC модули и без них работать не хочет... Думаю :)
Попытка хакнуть Basic с налету не прокатила. Ни в варианте - найти адреса в файле и подменить, ни в варианте - сделать заглушку на адреса MINC, ни в варианте - после сделанной заглушке обнаружить место (какой-то) проверки и попробовать хакнуть Basic в ОЗУ. Технически можно попробовать сделать более полноценную заглушку под обнаруженный код проверки - времени вроде много не потребуется, но.. подумаю :) А пока - любимое занятие - причёска кода :)
Так что - точки выводить могу, горизонтальные линии - могу, координатную сетку - могу - и на этом пока всё :)
Можно сделать так, при генерации включить в тело программы объектные модули графической библиотеки и обращаться к ним из Basic оператором CALL ...
Это, конечно, при условии, что такая библиотека есть ....
И нет готовых программ для Basic.
Это для RT11.
Можно сделать так, при генерации включить в тело программы объектные модули графической библиотеки
Учитывая, что я программист с почти 40-летним стажем (осталось немножно до 40), как думаешь - я мог додуматься до этого варианта? ;)
И для Basic-а есть программы-примеры, вот только, при попытке их запустить - "?MINC-F-Lab module routines are using the screen at line XXX". С чем я и пытался разобраться
Прическа кода продолжается. Вроде ничего ещё не сломал :)
В процессе обнаружил неточность в реализации одного регистра - оказывается, на тех моделях, где он есть - имеет две совсем разные реализации :) Поправил, проверяю.
Если я правильно понял, то нашёл ошибку в реализации красно-желтого стека для FIS на PDP-11/35-40. Попытка пофиксить, но там такая каша в тесте начинается в случае неправильной обработки, что даже пока не знаю...
В общем, не прошло и года, как Штрилиц догадался, что в halt mode работа на пониженной тактовой как правило - нафик не нать (не так уж часто я его отлаживаю), а вот в обычном..
Была мысль сделать регистр перехода на пониженную частоту - по принципу регистра прерывания, но когда я уже собрался с духом его сделать - пришло озарение - вообще нафик выключить понижение частоты для halt mode. То есть если сильно нужно будет - или отключить этот механизм (вернуться к старому) или сделать доп рычажок - для включение пониженной и в halt
mode... Но пока это не нужно - не буду заморачиваться.
Короче, пошёл дальше смотреть - чего не так с красно-жёлтом в FIS..
Грёбаная отложенная реакция на запрос прерывания и код, написанный так, что может по разному выполняться в зависимости от того - есть она или нет...
Короче - красно-желтые лимиты здесь не при чем (но ошибка для FIS всё таки была) - это своебразное поведение проца из-за кривости реализации отложенной реакции. К сожалению, процессор - это ещё тот бардак, но пока думаю причесать код наружных модулей, а потом всё таки покопаться в проце. Попробую сделать ещё одну попытку пофиксить отложенную реакцию, но если не получится - пока забью.
Вроде как вычислил причину - надо БЫСТРЕЕ снимать сигнал готовности от терминала, что бы на следующем такте проца он уже не видел запрос на прерывание :) Собственно то, что это место в тесте то работало правильно, то нет - как раз и намекал, что кто-то или запаздывает или слишком быстрый :)
Теперь опять надо тестировать разные модели процессора..
В целом, вроде бы проблему решил - изменив низкоуровней модуль uart. Ценой переделки подмодуля tx :) Надо бы ещё и rx переделать - дабы ускорить его работу - возможно, это решит и проблему автоопределения моего VT220 в режиме - ответ посылаем на полной скорости :)
Поставил синтезироваться разные модели PDP-11 и пошёл спаааааать...
Поскольку появились варианты 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 :) Нуу... Сильно быстро он отрабатывает :D
Весь в тестировании и фиксах... Вроде разобрался с модулем ПДП, но, похоже, реализация обмена внутренней шины и модуля SDRAM страдает... некоторой неправильностью. Плюс там ещё и разные тактовые домены. Судя по тому, что я видел в сигналтап - реализация протокола обмена с SDRAM более-менее правильная, а вот взаимодействие с ним со стороны модулей PDP-11.. Закончу прогон формального теста для сгенерированных конфигураций PDP-11 и займусь этим
Иногда в голову приходят неожиданные идеи :)
Очередная.
В некоторых процессорах имеется в наличии регистр PIRQ - с помощью него можно организовать программный запрос на прерывание - выставляешь в нём определённый бит (биты) и оп-па (если приоритет процессоры позволяет) - прилетает запрос по вектору 240. У автора PDP-2011 этот регистр тесно интегрирован с процессором (то есть в коде cpu.vhd идёт прямая работа с регистром). Поскольку в основе PDP-11X лежит PDP-2011 - так же до сегодняшнего дня было и у меня :) Но теперь запросы на прерывание от PIRQ построены по общей схеме - то есть он для процессора - как некое внешнее устройство :) Это позволило облегчить модуль процессора :) Для некоторых моделей, понятно :)
Из занятного.
В реальных PDP-11, насколько мне известно на текущий момент, только (максимум) четыре уровня приоритета запросов на прерывания - с 4 по 7. PIRQ - единствененый способ запросить прерывания на уровнях приортета с 1 по 3 :) Ну и запроса на уровне приоритета 0 не существует даже теоретически :)
Интересно, а как на машинах серии Pro-3XX?
Там же контроллер прерываний ...
И он подключен как? К одному уровню прерываний или что-то более хитрое?
Даже не скажу, это надо схемы смотреть, как там разведено соединение этого чипа с процом. Насколько мне не изменяет память, у самого F11 так же четыре входных линии запросов на прервание - с приоритетами с 7 по 4. И как я понимаю, внешний контроллер они добавили, что бы упростить реализацию подтвеждения прерывания - вместо того, что бы клепать на каждой плате расширения - они вынесли всё это дело на материнку. С соотвествующей необходимостью программировать этот чип. Как и примерно сделали с дешифровкой адресов этих плат.
В планах попробовать собрать на основе PDP-11X и Pro серию, но там из-за особенностей архитектуры возни и доп модулей будет больше. Так что пока только более традицонные варианты - типа KDF11, KDJ11. Ещё непаханное поле - с T11 - опять же - из-за его особенностей, хотя с ним вроде проще будет
Как бы это сказать помягче... В общем, шаловливые ручки в очередной раз завели меня в модуль (раньше он входил в состав процессора, но потом я его оттуда выделил - с прицелом на использования и для ПДП устройств) ввода-вывода. Исходно, как он работал (ввод-вывод) у автора - мне не нравилось, в первую очередь - в случае устройств - да, да, SDRAM! - для которых надо было ждать заверешениие цикла чтения или записи, а с учётом того, что код (тогда ещё) из PDP-2011 планировалось использовать и для внешних (по отношению к FPGA) устройств - был добавлен сигнал (аналог) RPLY. Но в первом варианте мне не нравилось то, что цикл в/в заканчивался ожданием снятия сигнала - тратились такты. А их можно было бы и потратить впараллель с продолжившим работу процессором. Но есть ситуации, когда за первой операцией в/в сразу следует вторая. И их надо разделять на шине - то есть тут всё таки подождать окончания предыдущей перед началом следующей. Но с ходу придумать - как это сделать - тогда (уровень знаний FPGA) не получилось :) Потом в какой-то момент я придумал некий вариант, который вроде бы позволял достичь этого, но.. получалось много тактов ожидания.
И вот в очередной раз сунулся в этот вопрос :) Где-то так на пятый день войны (в том числе - и со своими ошибками) вроде бы начало вырисовываться решение :) Ещё не окончательный вариант - но из тупика сдвинулся :)
Фуф.. Всё таки записал видео про VT105 и его тест :) Жена слегка обработает - и выложу :)
Сильное подозрение, что скорость прохождения теста на моём экземпляре VT105... э... "несколько" выше, чем на оригинале от DEC :D
- - - Добавлено - - -
Тест VT105 (http://www.KpXX.Ru/Pics/VT105Test.mp4)
В живую чуть по другому воспринимается, в видео всё таки есть эффект от частоты видео и частоты обновления монитора. Но более менее похоже :) Если с ходу видео не запуститься - Ctrl-F5 :)
Добавляю в VT поддержку русских букв и псевдографики :)
Прикольную ошибку посадил - чуть чуть ошибся :) (http://www.KpXX.Ru/Pics/MirroredChars.jpg)
Рисую символы в верхней половине ASCII. Некоторые готовые можно перенести, некоторые с доделкой, некоторые с нуля...
Дошёл до буквы "И" в слове "Передовую" :)
Ошибки - наше всё :) Посадил ещё одну - и долго пытался понять - кто виноват. Оказалось - ошибка усечения :)
Поправил. Продолжаю клепать шрифты. Доделаю нижнюю половину верхней половины (ну, может похожие по начертания буквы перенесу) и спаааать..
- - - Добавлено - - -
Остались русские буквы.. (http://www.KpXX.Ru/Pics/VT105-KOI8.jpg)
Из занимательного.
Автор PDP-2011 для VT использовал шрифт 8x20, что в принципе логично (640x480)
КЦГД использует шрифт 8x10 (что тоже логично) - то есть в принципе можно навыдирать из КЦГД :)
Но у VT многие вертикальные линии сдвоены - шрифт получается пожирней. Плюс, у VT есть аттрибут bold. В общем, развлечение будет ещё то..
Осталось 23 символа - перенёс все, которые имеют аналоги плюс некоторое количество похожих - перенёс и подправил
В первом приближении - е. Конечно, не факт, что все отрисованные символы (даже мне) понравятся, но будет уже проще и меньше :)
Собираются RT-11, патченные мной, что бы не сбрасывали 8 бит. Ну и надо ещё PIP хакнуть. Думаю, минут через 10-15 если всё будет норм - выложу очередную фотку :)
- - - Добавлено - - -
Кстати, в своё время я (для 5.0) делал более полный патч поддержки русского языка - включая русские сообщения в мониторе :) И он даже (по идее) должен остаться. Попробую похожее сделать для 5.7
- - - Добавлено - - -
Не, с ходу не шмагла.. Надо глыбжу копать..
- - - Добавлено - - -
Ещё один фИкус нашёл. Поправил. Собирается..
- - - Добавлено - - -
Система да, PIP пока нет... Смотрю...
- - - Добавлено - - -
Набор символов (http://www.KpXX.Ru/Pics/CharTables.jpg) (не хватает двух - с кодом 200 и 233)
Текст на русском (http://www.KpXX.Ru/Pics/RussianText.jpg)
- - - Добавлено - - -
Следующее, чем думаю заняться (но пока не 100 процентов) - перейти на разрешение 1280х1024 :)
- - - Добавлено - - -
А, нет, не так. Дальше - поддержка переключения по кодам RUS LAT :) И ввод русских букв :)
С обработкой RUS LAT при выводе всё оказалось достаточно просто - нужный базовый функционал уже заложен автором PDP-2011. Теперь и тексты в КОИ8 отображаются как надо и тексты и программы, использующие RUS LAT - аналогично :)
Осталось добавить функционал переключения с клавиатуры. И это будет явно не RUS LAT, учитывая особенность LAT :)
В редакторе EDIK переключение RUS/LAT происходит по приходу CTRL/N , первый раз пришло - клавиатура в RUS, второй раз - в LAT. И минимум проблем с оригинальной RT-11 и прочая :)
Главное - не трогать кнопку RUS/LAT на клавиатуре ...
Вот в ФОДОС CTRL/O нв CTRL/D заменили, но кнопки некоторые на терминалах работать корректно перестали...
У периферии с обработкой RUS/LAT проблем нет.
ереключение RUS/LAT происходит по приходу CTRL/N
Я добавил переключение вывода по RUS/LAT только из-за того, что (и очень часто) в текстах встречается, ну плюс это как бы штатные символы переключения вывода, но, учитывая, что основная кодировка (ну по крайне мере пока) внутри VT - КОИ-8, плюс - сам VT должен знать - что у него с клавиатуры вводится, для клавиатуры это явно будут комбинации клавиш, которые в комп передаваться НЕ БУДУТ, а значит это точно будут не Ctrl/N и уж тем более не Ctrl/O.
Ну и поскольку на PC уже есть комбинации, которые используются для переключения клавиатуры, которые все знают (а кто не знает - их проблемы), то, как обычно, уже засыпая, я решил - это будет Ctrl/Shift и Windows/Пробел.
Осталось только добавить функционал в фирмварю.
- - - Добавлено - - -
но кнопки некоторые на терминалах
Это на каких таких терминалах?? Терминал у меня один - VT.
У периферии с обработкой RUS/LAT проблем нет
Тот же комментарий.
Кстати, с учётом наследования, теперь официальное его название - VT-11X.
Поскольку описание работы PS/2 клавиатуры отличается... разнообразием - добавил возможность отладки в VT-11X и сразу этим воспользовался.
Наглядно о scan-кодах :)
PDP-11/105 (0KW) FullODT
>>>G
Hello, world: [PDP-11X vt105]
3C F0 3C 3C 3C 3C F0 3C 3C F0 3C 3C F0 3C 3C F0 3C 3C 3C 3C 3C 3C 3C F0 3C D6 F0
D6 D6 F0 D6 D6 F0 D6 D6 F0 D6 D6 F0 D6 D6 F0 D6 D6 F0 D6 D6 F0 D6 D6 F0 D6 D6 F
0 D6 D6 F0 D6 D6 F0 D6 D6 F0 D6 D6 D6 D6 D6 D6 D6 F0 D6 D6 F0 D6 D0 3G D0 F0 3G
D0 3G D0 3G D0 3G D0 F0 3G D0 3G D0 F0 3G D0 3G D0 F0 3G D0 3G D0 F0 3G 24 F0 24
24 F0 24 24 24 24 24 24 F0 24 21 F0 21 21 F0 21 22 F0 22 C8 F0 C8
- - - Добавлено - - -
Однако - ошибся в выводе байта в 16-ти ричном виде.. Щас поправленный вариант выложу..
- - - Добавлено - - -
Правильные scan-коды:
PDP-11/105 (0KW) FullODT
>>>G
Hello, world: [PDP-11X vt105]
25 E0 25 24 E0 24 C0 3F C0 E0 3F C0 22 C0 FC C0 E0 FC C0 E0 22 FE E0 FE C1 24 E7
C1 E0 24 E0 E7
Полез в описание scan-кодов, посмотрел на вышенаписанное, задумался и... опять неправильный вывод :) Исправил, собирается...
- - - Добавлено - - -
Ну теперь вроде совпадает с таблицей :)
>>>G
Hello, world: [PDP-11X vt105]
14 F0 14 16 F0 16
Засада пришла откуда не ждали :) Вроде справился, но - отладка...
- - - Добавлено - - -
Извиняюсь за качество - телефон :)
Ввели и (http://www.KpXX.Ru/Pics/KOI8Input.jpg)
вывели :) (http://www.KpXX.Ru/Pics/KOI8Output.jpg)
Видно допущенный косяк - " вместо Э
- - - Добавлено - - -
В общем - теперь надо проверять перекодировку. Ни хотелось бы код по причёсывать ибо он там.. Не очень :)
- - - Добавлено - - -
Однако не всё учёл, был ещё один хитрожопый сценарий. Придумал, поправил, тестирование-отладка...
- - - Добавлено - - -
В первом приближении - вроде всё работает :) Ну, кроме, Windows+Space :)
Пока поразвлекаюсь причёсыванием кода
Как-то даже не задумывался и вдруг...
Из занимательного - эмулятор VT52 вполне себе обрабатывает КОИ8 (на другой стороне com порта - VT-11X):
PDP-11/03 (28KW) FullODT
qwertyu
QWERTYU
йцукенг
ЙЦУКЕНГ
- - - Добавлено - - -
Налетел на страннное поведение не знаю кого..
Суть - запустил на DE10 вариант с только VT-11X c выходом его наружу через com порт. Связал этот порт с simh. Запустил под simh RSX+. И наблюдаю такое - если какое-то (достаточно небольшое) время клавиатуру не трогать, то после этого первая реакция на попытку вывода (нажатого на клавиатуре или из программ) символа происходит с ОЩУТИМОЙ задержкой. Пока не знаю на что или на кого грешить, но в VT-11X есть моменты, которые мне на нравятся - как написаны. В первую очередь - передача В комп - вся сделана на опросе готовности, а не по прерываниям. В общем - попричёсываю код и попробую в процессе этого посмотреть - что будет меняться...
- - - Добавлено - - -
Всё ближе к тому, что бы иметь коробку, которая будет играть роль (с подключенным монитором и клавиатурой) терминала. Платы c FPGA есть, платы (не помню как правильно называются, но они преобразуют цифровые сигналы в сигналы для VGA) есть, платы <цифровой сигнал <-> RS232> есть, осталось только подобрать подходящий коробок, всё спаять и запихать туда :) Ну и - ВРЕМЯ выбрать :)
Переделал и отправку в комп на прерывания.
Но не понятную задержку это не убрала. У меня впечатление, что она как-то связано с морганием курсора, но - курсор вроде как полностью аппаратный и такой задержки вроде как не должно быть.. В общем - в процессе разборок. Уже думаю эмулятор PDP-11 Патрона посадить на com порт - сравнить с simh. Хотя комбинация vt-52 Патрона плюс simh не вызывала проблем - но я использовал связь через telnet протокол, а не com порты...
Переключение по RUS/LAT при выводе текста - это, конечно, хорошо, но его должен учитывать (а не учитывал) процесс перекодировки скан-кодов в коды символов. Вроде как реализовал, но надо оптимизировать..
Не прямое отношение к FPGA, но прямое отношение к прошивке VT-11X :)
В общем как-то так получилось, что в DSMAC оператор ELSIF добавил давно, но когда (после перерыва возни с PDP-11) попробовал его использовать, оказалось, что он не фига не работает :) А вчера чего-то КАААААК пришла в голову мысль - КАКОГО???
Вобщем, сделал до какой-то степени рабочий вариант. До какой-то - потому что пока проверено только в сценарии - после IF - одно условие - без всяких AND и OR :)
11 000000 ;IF R0 EQ #0 THEN
000000 005700 TST R0
000002 001006 BNE 1003$
12
13 000004 ;IF R1 EQ #10 THEN
000004 020127 000010 CMP R1, #10
000010 001001 BNE 1013$
14 000012 000240 NOP
15 000014 ;END
000014 1013$:
16
17 000014 000240 NOP
18
19 000016 ;ELSIF R0 EQ #1 THEN
000016 000425 BR 1007$
000020 1003$:
000020 020027 000001 CMP R0, #1
000024 001002 BNE 1023$
20
21 000026 000240 NOP
22
23 000030 ;ELSIF R0 EQ #2 THEN
000030 000420 BR 1007$
000032 1023$:
000032 020027 000002 CMP R0, #2
000036 001002 BNE 1033$
24
25 000040 000240 NOP
26
27 000042 ;ELSIF R0 EQ #3 THEN
000042 000413 BR 1007$
000044 1033$:
000044 020027 000003 CMP R0, #3
000050 001002 BNE 1043$
28
29 000052 000240 NOP
30
31 000054 ;ELSIF R0 EQ #4 THEN
000054 000406 BR 1007$
000056 1043$:
000056 020027 000004 CMP R0, #4
000062 001002 BNE 1053$
32
33 000064 000240 NOP
34
35 000066 ;ELSE
000066 000401 BR 1007$
000070 1053$:
36
37 000070 000240 NOP
38
39 000072 ;END
000072 1007$:
Уже проверил на VT-11X - после замены кода на использование IF-ELSIF-ELSE - результат идентичный :) Но меньше меток и BR :)
Глубоко копаюсь в DSMAC. Обнаружил интересное - вместо
LET R0 := #0
LET R0 :B= R0 SET.BY (R2)+ ; load char
можно писать сокращённо
LET R0 := #0 ! R0 :B= R0 SET.BY (R2)+ ; load char
Учитывая, что после LET часто идёт комментарий именно на этот LET, практическая ценность.. не велика
Вариант типа ELSIF R0 EQ #1 AND R1 EQ #2 добил.
Вроде как осталось проверить (и практически наверняка добить) OR в ELSIF - то есть вариант типа ELSIF R0 EQ #1 OR R0 EQ #2
- - - Добавлено - - -
C OR как и ожидалось - требует допиливания :) Пилим....
- - - Добавлено - - -
Заменил ! на | - смотрится вроде читабельней
Информация к размышлению для читающих эту тему (продублировано в первом сообщении).
Модуль процессора построен так, что я могу как генерировать реально существующие процессора (которы проходят или почти проходят тесты, созданные под эту модель) с учётом всех (или почти всех) их особенностей, так и собирать процессора с определёнными характеристиками.
То есть - есть некий набор характеристик. Были созданы описания реально существоваших моделей процессоров, в которых уже заданы эти характеристики. И когда генерируется прошивка - как параметр - идёт ссылка на какое-то описание процессора. Но никто не мешает насоздавать такие описания с любым уникальным набором характеристик. Типа - PDP-11/03 с FPP.
- - - Добавлено - - -
И этим я воспользовался при создании модуля VT11-X - то есть в описаниях процессоров есть описание процессора именно под этот модуль - он представляет собой вполне законченную PDP-11, но - с нестандартным адресом запуска (20000(8)), со специализированной прошивкой (ПЗУ в области ОЗУ), специализированными модулями (СпецVGA и PS/2) и отсутствием устройст типа дисков. И в отладочном варианте присутствует FullODT, так что прошивку я спокойно могу отлаживать даже когда она не работоспособна :)
По прежнему война с ELSIF. Не всё так просто, как казалось - когда вперемешку AND и OR в IF
Поскольку тема не про DSMAC (возможно создам), то вкратце:
- в какой то момент понял, что попытка добавить ELSIF всё больше напоминает заплатки на заплтках
- был достаточно долгий (времени свободного мало) период разборок - как же оно всё работает
- постепенно в воспалённом мозгу родилась идея - как оно ДОЛЖНО работать, что бы
- началась переделка кода (пока классика - IF ... THEN ... ELSE ... END) под новую концепцию
- параллельно рисовался файл для тестирования DSMAC
- на текущий момент вроде как IF ... THEN ... ELSE ... END работает
Параллельно сделал
- более правильный вариант однострочного IF (типа IF R1 EQ #1 THEN LEAVE LOOP)
- обработку не только вариантов типа R0 EQ #0 OR R1 EQ #1 OR R2 EQ #2 OR R3 EQ #3 OR R4 EQ #4, но и вариантов типа R0 EQ #0 AND R1 EQ #1 OR R2 EQ #2 AND R3 EQ #3 OR R4 EQ #4 (в терминах старого DSMAC - AND после OR - где он выдавал ошибку. В моей интерпретации - AND в приоритете, OR на втором месте - то есть в блок IF попадём, если выполнится один из вариантов R0 EQ #0 AND R1 EQ #1 , R2 EQ #2 AND R3 EQ #3 или R4 EQ #4 Вроде как такой вариант будет полезней
Теперь опять ELSIF, но если я не ошибся в предположениях, то его добавление пройдёт быстро.. Чуть позже станет ясно - ошибся или нет.
Ну и потом - восстановление функционала циклов - ибо они использовали внутри себя IF, но с ним всё теперь по другому.
ELSIF (после, конечно, доработки под новую концепцию IF) встал как влитой :) Без всяких танцев с бубном :) Буду, конечно, дальше проверять на восстановлении или переделки исходников, но пока всё ОК!
Дальше - циклы (восстановление функционала)
- - - Добавлено - - -
И циклы удалось быстро пофиксить!
Так что на этом эпопея с DSMAC до какой-то степени закончена и я возвращаюсь к прошивке VT-11X :)
До каких то экзотческих вариантов использования DSMAC в прошивке VT-11X не добрался, но пока всё компилируется без ошибок и собирается в идентичный с эталонным вариантом (сделано со старым вариантом DSMAC) файл. Но всё равно - будет потихоньку добавлять с тестовый .MAC - может что и вылезет неправильного
В процессе переделки прошивки VT-11X выловил первую ошибку :) Если в ELSIF после логического условия не написать THEN (первоначальный автор DSMAC сделал это слово не обязательным) - происходит странное :) Обойти проблему просто (написать THEN и всё щастливы), так что бросать все силы на исправление - не буду. Как получится - поправлю
В обед закончил переделку прошивки под DSMAC. В принципе, это уже был не исходный вариант от автора - я его слегка переделал и допилил для поддержки русского языка, но оставалось много не переделанного кода. Теперь всё допилил.
Достаточно много мест (оставил себе пометку), где добавлен код для возможных будущих расширений, но с IF-ELSIF-ELSE-END он не требуется. В выходные почищу такие места.
Ну и есть места, которые можно оптимизировать - тут уже придётся проверять в живую. Тоже в выходные.
Ну и есть места с вопросами. Тоже посмотрю внимательно в выходные.
Жжжж... Тестов XXDP именно VT100 вроде как нету.. Придётся самому писать...
Некоторая оптимизация прошивки - процесса передачи всякого в ЭВМ. У автора сильно не оптимально по коду и способу.
Дальше хочу повозиться с обменом с PS/2 - не только приём, но и передачу сделать - светодиоды зажигать, пикать и с прицелом на мышь
"Человек предполагает, а пальчики располагают"
В общем, сунулся я чего-то в модуль VGA и... понеслася.. Короче, текущий план-занятие - попробовать переделать 640x480 в 1280x1024 :)
Давняя война с в/в процессора. Попробовал вариант для ускорения процесса, но... не взлетел. Вернул как было (одна из причин, по который исходники PDP-11X недоступны - много экспериментирую - и могу много изменений откатить), буду дальше думать.
Вспомнил, с чего начался квест с ELSIF, сунулся в исходник FullODT, поправил вложенные IF на ELSIF (где возможно, есссвенно) и.. налетел на ошибки при трансляции. Оказывается - WHILE не доделал под последние постановления ВЦСПС :) Надо было в тестирование тоже добавить :) Пофиксил ошибку WHILE (в тесты добавлю позже), теперь будем потестировать FullODT (хотя на первый взгляд оттранслировалось как надо).
Из того, что никогда пока не использовал - оператор FOR (выглядит реализованным) и оператор CASE - а вот тут только предположительно, что не дорисован - надо будет ещё первоначальный исходник глянуть - чего там и как, потому как, если судить по коду - чего-то такое я пробовал делать, но...
Основной план - по прежнему VGA на 1280х1024
- - - Добавлено - - -
Ну как же без косяков то :) Точнее говоря - не всё доделал для WHILE...
Вывод - НАДО БОЛЬШЕ ТЕСТОВ :)
Воюю в VHDL...
Просто, что бы осталось :)
HH 2.2 RT-11 Cold boot..
HH DSK/TTY multiplexer v3.3 2016
FPP- эмулятор FP.SYS (c) А.Г.Григорьев
RT-11SB (S) V05.07
.р MSCPCK
?KMON-F-Invalid command
.RUN SPEED0
Тест быстродействия V3.4.1 (кэш, если он есть выключен)
NOP empty 24 984 348 оп./сек
NOP 12 492 173 оп./сек -> 24 984 344 оп./сек
BR .+2 empty 24 984 348 оп./сек
BR .+2 12 492 173 оп./сек -> 24 984 344 оп./сек
R1(23456.)+R0(12345.) empty 5 552 435 оп./сек
R1(23456.)+R0(12345.) 3 998 365 оп./сек -> 14 285 496 оп./сек
.
Модуль в/в в процессоре всё-таки удалось переделать, но пока он в "экспериментальном" состоянии.
Также причёсываю другие модули под единый подход общения с шиной плюс оптимизация.
Ну и периодически пробую дорабатывать VT-11X под 1280х1024, но там ещё самое начало..
Причёска кода, сейчас на раздаче RK11 и RL11 - распил их монолита. Потом сравню картинки до и после.
В процессе первого подхода к снаряду в RK11 выпилил из монолита чтение регистров и вроде всё ок. Потом выпилил запись бита GO в CSR - и получил феерическое поведение. Скажем - перестали писАться регистры адреса памяти, счётчик слов и регистра адреса диска. Ну а при попытке запись в CSR кода 5 (чтения) на выходе имел в CSR - 44 (не помню на вскидку эти биты, но они как бы при чтении вообще не должны возникать). В процессе поиска проблемы обнаружил классику - CopyPaste :) Забыл в определение записи в младший байт (всех регистров) добавить - при выборке соотвествующего регистра. И пока оставался старый вариант (запись в регистры - внутри монолита) - всё был ок. А как только выделил хоть что-то оттуда, так начался феерверк. Причем эта же ошибка по CopyPaste ушла и в RL11. Как только поправил - есссвенно всё заработало :)
Причёска кода и оптимизация (разные модули).
Плюс - с поддержкой КОИ-8 в RT нарисовалась проблема. Как выяснилось, восьмой бит используют (по информации от Form-а) не только KED и KEX, но и - сама RT-11 :) Один из сценариев использования вычислил, пробую пофиксить.
Ну и.. Не знаю, на кого бочку катить (под подозрением Mentec), но по крайне мере 5.7 страдает от использования разных констант в числовом, а не символьнов виде. Поэтому - возможно проблема - тронешь в одном месте - вылезет незнамо где...
Всякие платы, разъёмы - собрались вместе. Сегодня руки дошли - распаял разъёмы на плату.
И - теперь у меня ещё один стенд с FPGA - дочерняя плата RP2040 и плата с Cyclone V 5CEFA7F23 от QMTech.
Так что в планах - расписать распиновку разъёмов и собрать ещё один топ модуль PDP-11X - но уже под этот стенд. Поскольку какое-то время назад специально, в расчёте на другие платы FPGA веделил этот плата-зависимый модуль - перенос технически будет достаточно простым. А вот что вылезет у QMTech - посмотрим :)
В планах сделать ещё два стенда - есть ещё две платы с двумя разными Cyclone IV.
Но - когда дойдут руки - пока не знаю...
прикольно бы было запустить на минимальной какой-нибудь плате типа как вот та китайская плата с cyclone3 или есть сейчас на али аналогичные по цене платы на cyclone4 но зато уже с памятью, сделать типа как http://searle.x10host.com/Multicomp/index.html
на минимальной какой-нибудь плате
Они сейчас, увы, стали относительно дорогими - то есть выгодней покупать что-то побольше по ресурсам. Ну и от той же QMTech есть более интересное практически по той же цене - https://aliexpress.ru/item/32949281189.html
Это, кстати, одна из двух моих плат на Cyclone IV
В модуле RK11 закончил вытаскивать работу с регистрами из монолита. Есть некоторое количество вопросов по поводу того, а что будет, если во время выполнения команды контроллером взять и какой-нибудь регистр поменять, но это надо смотреть или тестами (но не всё реализовано) или по схеме-описанию, так что выверять точно не сейчас буду :)
Решил погонять тесты на RK11 и... с ходе обнаружил ошикбу - команда 0 (сброс контроллера) вызывает его зависание :) Поправил, тест (ZRKJ, первый в серии) стал сыпать меньше ошибок :) Смотрю дальше...
- - - Добавлено - - -
Исправил ещё 4 ошибки и...
.R ZRKJE0
ZRKJE0.BIC
RK11 LOGIC TEST I
MAINDEC-11-DZRKJ-E
END PASS # 1##
END PASS # 2##
END PASS # 3##
END PASS # 4##
Первый тест проходит :)
Запустил второй - ZRKK. Ожидаемо - куча ошибок. Второй процесс разбора и исправлений пошёл..
C ZRKK основная проблема на текущий момент - чтение-запись в флагом Format. То есть работа с заголовком сектора. Дабы упростить себе жизнь в стародавние времена - я на этот функционал тогда положил. Теперь вот восстанавливаю. Что-то уже начало шевелиЦЦа.
Интересно то, что чтение и запись с этим флагом ведут себя весьма по разному - чтение читает и передает в память одно слово из заголовка, а запись перестаёт проверять - а на том ли мы цилиндре - но сама запись аналогично варианту без флага - то есть заголовок пишется по любому. Обычно простая запись заголовок не пишет - только находит его :)
Работа с битом форматирования более-менее. Двигаюсь дальше по ошибка ZRKK
На ZRKK осталось шесть ошибок (раньше сыпалось штук под 20-30) :)
Тестируя RK11 - наткнулся на ошибку в прошивке FullODT. Но не сразу понял, что ошибка в FullODT - сначала грешил на RK11, потом на процессор, потом на "PLM" процессора :) Ошибка из класса - начал писать код, потом что-то отвлекло и код был недописан. И поскольку его недописанность мало на что влияла...
По поводу ZRKK и шесть ошибок - это я погорячился :) Периодически вспоминал и забыл, что для ПДП устройств не был дописан код отсутствия сигнала обращения по несуществующему адресу. Ну и нормальным драйверам и операционкам это как бы не мешало, а до тестов, которые проверяют ВСЁ - руки всё не доходили. Вот - дошли - и оно вылезло :) Так что в ZRKK шесть+ ошибок :)
Отработка общего механизма - NonExistingMemory (на самом деле, конечно - не существующий адрес, но у DEC это традиционное название и акроним - NXM :) ). Пока автор сажает ошибки, так что - отладка, но что-то уже шевелиЦЦа
NXM для процессора уже работает, а вот RK11 сопротиваляется. Отладка-доработка.
Нуу... Последняя ошибка - прямо таки из разряда - Это не ошибка! Это - фича!! :D И RK11 честно говорил - дааа, я всё прочитал! Да, по адресу 160000 (машина без ДП :) )! Да, все 256 слов :D
В общем - у меня так память генерировалась, что её было 64 кб :) Вот в последние 8 кб RK11 и писал :) Всё по чесноку :) Как только выставил адрес 200000 - всё, NXM прилетел и был обработан :)
Но - для теста нужно всё таки 56 кб :) Пришлось немного хакнуть модуль памяти :)
Ну вот - по крайне мере теперь ZRKK не сваливается, а идёт (пусть и с ошибками - разберусь) по всем восьми дискам :)
Устал от RK11 (там уже надо выполнение команд причёсывать плюс более точно синхронизировать внутренние изменения и видимость снаружи - некоторые процессы опаздывают - и тесты валятся).
Сцепился с MMU - процесс тот же - распиливание монолита. Есть задумки по ускорению его работы, но посмотрим.
В "отладке", если это можно так назвать про FPGA :) В очередной раз проверяю работу проца на низкой (1 Гц) тактовой. После переделки модуля в/в процессора - теперь каждый микротакт (даже связанный с в/в) процессора - ровно один такт тактовой :)
То есть, если бы это дело так же взлетело бы на 100 МГц тактовой - то скорострельность была бы до 100 мипсов :)
Развлекаюсь разным - из разряда - на что глаз упадёт. Появились мысль по расширению "PLM", но на текущий момент с файлом-описанием "PLM" было уже не удобно работать - 27 полей плюс комментарий - слишком широкий текст, плюс ещё некоторые специфические тормоза в Far-е. В голову пришла мысль распилить его на части - вертикально - то есть разные поля в разных файлах. Плюс скрипт, который бы всё объединял. Но с учётом того, что файл-описание уже есть, первым пришлось набросать скрипт, который его монолит распилил на составляющие. А потом уже скрипт, которые бы части объединил.
Первый вариант (каждое поле в своём файле, скрипт для объединения) (за обеденный перерыв) - готов.
Но есть логически связанные поля, которые хотелось бы иметь в одном файле. Так что следующая доработка - возможность брать из файла описания для нескольких полей. Это уже вечером, после работы.
Ну и всё это началось с мыслей о добавлении ещё полей в "PLM". Что будет сделано уже после написания скрипта версии 2 - ибо будет две добавки по 9 (или 10-11-12 - пока нет понимания - сколько) полей.
Всё это мне напомнило мне мой любимый подход - управление логикой работы программы через описатель с данными :) Получается - горизонтальное микропрограммирование я уже давно освоил - в несколько другой области. Но с существенным отличием - в электронике все микрооперации при горизонтальном микропрограммировании выполняюся одновременно :)
Ну и попутно добавил в свою программу поиска (и удаления) дублей файлов добавил так же расчёт и сохранение SHA256. Плюс наконец-то (не прошло и 30 лет с момента первой версии) добавился подсчёт простейшего варианта КС (простое суммирование) и CRC32 :) Так что теперь вероятность совпадения всей информации о файле (длина плюс 5 КС) - крайне мала
На доработку скрипта с возможностью размещения нескольких полей в одном файле ушло меньше получаса. Продолжаю развлекаться с процесором :)
Продолжаю ковыряться внутри процессора и для упрощения исследования (исходно не я писал и с ходу переходы между "микрокомандами" не скажу) всё таки допили заготовку "Ручной тактовый генератор" (осталась ещё от ранних времён возни с PDP-11 в FPGA) до рабочего состояния :) Теперь у меня есть генератор тактовой для сверхнизких частот :)
Ещё небольшая доработка скрипта слияния частей "PLM" - пропуск пустых строк и строк с только комментарием - для более удобного чтения файла человеком.
Добавил новые поля и попробовал их использовать в командах RTI и RTT. Вполне работает, но пока это эксперименты с удобством и работоспособностью новых полей.
Продолжаются эксперименты, уточнения, исправления, расширение набора полей (в том числе для специфически обрабатываемых ситуаций и команд). На текущий момент правильно отрабатываются всё (но не всё пока оптимально), переделанное на новый механизм - отработка прерываний, RTI и RTS. Очень помогает ручной тактовый режим :)
Один из ключевых моментов - у автора PDP-2011 чтение регистров было асинхронным. Я уже не раз налетал на то, что не всегда работает (на повышенной тактовой) правильно. И поскольку заманался бороться с этим - одна из целей переделки внутрянки - сделать чтение регистров синхронным. Ну а что бы несколько ускорить процесс (так как часто нужно читать не один регистр в процессе выполнения команды или отработки прерывания) - реализовал подсмотренную в PDP-11/70 технику :)
Следующей под раздачу попадёт, скорее всего, JMP.
Но, возможно, какая-то из однооперандных команд. Типа SWAB (если она есть на PDP-11/03) или COM (если SWAB нет на PDP-11/03)
Насчёт отсутствия SWAB на PDP-11/03 - это я погорячился.. Есть она там, есть :) Видимо, память царапнула про другое (сброс или не сброс V), но до сознания царапка не успела дойти :)
Так что следующие команды под раздачу - JMP, CLR и COM, поскольку они одноадресные, ближе к началу таблицы операций по кодам и две из них с особенностями (JMP только читает, а CLR только пишет).
Разобрался с тем, как инициализировать массив (aka ОЗУ-ПЗУ) через константные индексы. До этого инициализация сама по себе проблем не вызывала, но просто тупым перечислением значений одно за другим.
Это позволит не просто смоделировать ПЗУ(ОЗУ) с адресным полем (в котором указан адрес ячейки из него же), но и не пересчитывать руками (числовые) индексы, если поменялся порядок ячеек или ячейки были добавлены (удалены).
А так же позволит нарисовать "реальные" процессора - отталкиваясь от их схемотехники и ПЗУ (в том числе ПЗУ микрокода).
Ну а пока это нужно мне - с моими переделками PDP-2011 :)
Шаблон-концепт получил, попробую наполнить содержимым (JMP, SWAB, CLR, COM) и посмотреть, что получается.
SWAB - поскольку и с ней начал возиться.
JMP, SWAB, CLR, COM - это я как-то погорячился. Там перепиливать много надо будет. Поэтому начал с чего попроще - RTI. RTI - потому как оно почти в FullODT не используется и есть вероятность добраться до отладки (в пошаговом режиме) в нем.
Первый вариант допилил - посмотрим, скоко будет ошибок и как оно взлетит.
- - - Добавлено - - -
Ну, всё было ожидаемо - и наличие ошибок и поведение. Вот только забыл на пульт выдавать новую инфу - о микроадресе :)
После фикса всех тупых и не тупых ошибок новая модель показал свою работоспособность :)
RTI/RTT переведены на новый подход :) По крайне мере всё работоспобно до успешной загруки RT-11
Теперь XXDP :)
- - - Добавлено - - -
Одна (по крайне мере) ошибка нашлась - прерывание по установленному T-биту не отработало так, как положено.
Ок, в принципе - ожидаемо.
T-бит пока не поддаётся, но он не критичен для просто работы процессора, в том числе операционок, поэтому пока забил.
Вместо этого взялся за обработку прерываний (кстати, косвенно связанную и с T-битом). По сравнению в RTI/RTT несколько сложней и больше по объёму переделок плюс обработка прерыаний - это не выполнение команд процессора, но и упрощение внутрянки должно быть больше.
Пока описываю работу в microROM. После завершения - начнётся внесение изменений в логику процессора.
Обработка преываний, фаза TRAP (это когда вектор, предопределённый или от устройства, получен и собственно начался процесс перехода по вектору со всем сопутствующим) переделана, теперь отладка.
До одной ошибки уже допер - поправил - синтезируется.
Потратив некоторое количество нервов - я всё таки вычислил (вроде) все зависимости внутренних процессов от обработки TRAP. Последнее, что трепало нервы - yellow stack :) Yf
Так что на текущий момент переделана сладкая парочка - прерывания-RTI/RTT и при этом грузятся XXDP и RT-11 на PDP-11/03. Дальше, как обычно - тесты :)
А потом посмотрю :)
Погонял. Проблема с T флагом ушла. Не удивлён (почему я сунулся в TRAP) :)
Но нарисовалась другая проблема, причём ловит её только один тест (надо попробовать закрыть этот подтест и посмотреть - не вылезит ли ещё где), причём только в одной редакции и только в одном подтесте :)
Пример кода:
MOV #136,R4
MOV #376, (R4)
MOV #17256, R0 ; адрес п/п проверки флагов
INCB (R4)+ ; тестируемая инструкция
; и вот где-то в промежутке между последним микродействием
; по засылке адреса п/п в R0 и началом выполнения (R4)+
; в R0 записывается 0 (по тому как сигнал записи в регистр
; не сбрасывается
CALL (R0) ; что приводит к очевидным последствиям при попытке выполнить вызов
Причём сама INCB выполняется без проблем и с правильными флагами на выходе..
Пока, как и с флагом T - отложил поиск и устранения причины, так как подозреваю наведённую ошибку - из-за начала переделки на полнстью синхронную работу с регистрами. Ну и поскольку запуску и работе операционок и тестов - не мешает.
Теперь, наверное, займусь RTS
Update. Что-то я про флаг T погорячился - проблема то ушла :)
На новый механизм переведена RTS. RT-11 и XXDP грузятся, тесты от PDP-11/03 и тест памяти - ок, за исключением той же проблемы из https://zx-pk.ru/threads/28952-pdp-11-na-fpga.html?p=1185969&viewfull=1#post1185969 . Ну, она пока не сильно мешает, так что - пока разборки с ней отложены :)
Была сделана некоторая оптимизация выполнения (с учётом полученного опыта) RTI/RTT/RTS. Попробую тоже сделать с цепочкой TRAP.
Вроде как ок, но надо тесты погонять. Чуть позже :)
Тесты - ок, начинаю двигаться по прерванному - JMP, SWAB, CLR. Возможно, с определённой оглядкой на операции с двумя операндами. Как подопытного кролика - возьму BIC (наоболее универсальный вариант по алгоритму).
Подход такой же, как и с RTI/RTT/RTS - расписываются микрооперации, учитывается порядок и возможность параллельного выполнения. Учитывая, что могу читать в паралель source и destinations регистры :)
Вот при написании предыдущего предложения заметил интересное - после написания "source и" и начала написания de браузер подсказал мне - destination? с предложением нажать таб :) Похоже, MS и в Edge начала добавлять intellisense :)
- - - Добавлено - - -
Как пример - как выглядит описание для RTS:
-- -------------------------------------------------------------------------
--
-- RTS reg
-- SrcReg - reg, DestReg - SP
--
-- -------------------------------------------------------------------------
-- чтение (DestReg) будет выполнено до микрошага addrRTSa
-- PC <- SrcReg | чтение Destreg | SrcReg <- Destreg
mrom(addrRTSa) := MRomEntry( -- 016
NextAddr => addrRTSz
, isGet => Yes -- читаем
, isGetAtDestReg => Yes -- читаем (DestReg)
, isPC_SrcReg => Yes -- PC <- SrcReg
, isSrcReg_AtDestReg => Yes -- SrcReg <- (DestReg)
, isDataSpaceUsing => Yes -- адрес возврата в стеке - в D пространстве (для процессоров с поддержкой I-D)
);
-- post operation (в том числе DestReg <- DestReg+2)
mrom(addrRTSz) := MRomEntry( -- 017
NextAddr => addrNextOp
, isPostRTS => Yes -- пост операции для RTS
, isCommonPrefetch => Yes -- пост операции - общий набор
);
Небольшая расшифровка, скажем, для isPC_SrcReg => Yes -- PC <- (SrcReg)
На этапе выполнения по тактовому импульсу сработает сохранение считанного содержимого SrcReg в PC (если, конечно, выполняется не оператор RTS PC - тогда данное действие будет заблокировано, хотя ничего страшного не будет, если не блокировать).
Всё, ушёл спать, дальше уже с утра буду развлекаться :)
Умею я, блин, ошибки сажать..
Предыстория :) Начал пилить JMP-SWAB-CLR под новую схему. Расписал микрооперации. Посмотрел. Понял, что пока ничего в голову на предмет повтороного использования расписанного не приходит, поэтому для начала решил в лоб реализовать, а там посмотрим. Ок. Нарисовал код под SWAB reg. Не работает. То есть в принципе код отрабатывает, но неправильно. Почесал почесуемое. Слегка подправил. И...
Вообще перестало работать!
Ну, я же знаю, то сначала надо свои ошибки искать. Вот с примерно вчерашних часов четырёх (дня) искал :) Ошибка тупая :) Поправил, посмотрим, что будет на выходе :)
- - - Добавлено - - -
Да, после фикса ошибки стало лучше - RT-11 грузится и даже работает.
На очереди, как обычно, XXDP с тестами.
И, технически, теперь я могу подцепить другие одноадресные команды в варианте работы с регистрами.
Но для начала сделаю остальные режимы адресации - и для JMP-CLR. И, возможно, так же что-то подпилю с учётом возможного опыта :)
Оптимизация работы с регистрами (теперь и запись и чтение идут быстрее), что позволит удалить некоторые шаги, связанные с ожиданием записи в регистры (ну, по мере переделки) - с новым мехазмом выполнение данная проблема прям в глаза полезла.
И вроде как нашёл причину ошибки https://zx-pk.ru/threads/28952-pdp-11-na-fpga.html?p=1185969&viewfull=1#post1185969, по крайне мере мой тестовый код на ней не спотыкается. Но как обычно - надо проверить тестами XXDP.
Так что - сейчас синтезируется и посмотрим на тесты. Некоторые сомнения вызывает RTS (после оптимизации), так что вполне возможно, что после тестов будет поиска ошибки :)
- - - Добавлено - - -
В целом - ситуация лучше, но есть ещё ошибки. Ищу...
Ошибка обнуления регистра найдена и пофиксина - результат невнимательной доработки кода под новый подход :)
Дальше вылезла ошибка XOR. Сначала подумал, что из-за более быстрой работы регистров (и не сохранение результата ALU), но оказалось - изменение из разряда - "а вот так лучше". Не в этот раз. Вернул - XOR заработал :)
Дальше вылезла ошибка yellow stack trap - сложно было понять, что именно она. Думаю над исправлением...
- - - Добавлено - - -
Сбой в тестах прерывани (VKAD). Бум разбираться и фиксить
- - - Добавлено - - -
Аха, для начала накосячил в JMP reg - прерывание не отработывается
Все тупости и корявости были найдены и пофиксины, теперь снова все тесты PDP-11/03 проходят.
Попробую слегка оптимизировать (см ускорение работы с регистрами), если получится - хорошо, если нет - верну как было и в любом случае - двинусь дальше :)
Из хороших новостей - в новом "микрокоде" убраны последние задержки (для завершения чтения и записи регистров), доставшиеся в наследство от PDP-2011 - тесты PDP-11/03 проходят без проблем.
Из плохий - решил собрать для проверки PDP-11/04 и.. зависание на ровном месте - RTI не отрабатывает. Причём - отличий в работе RTI между /03 и /04 я (пока) не вижу, а внешне - после завершения микрокода RTI /03 читает следующую инструкцию, а /04 не читает, видит, естественно, ещё RTI, начинает её выполнять, но вот по завершению что делать дальше - не знает - нет у неё перехода (естественно) дальше.. Начал воевать вчера вечером, пока ясности нет...
Я тут уже третий день хожу под вирусом, которые мелкие притащили плюс вчера был "жаркий" день на работе - голова протестует против вдумчивого думанья, так что слегка попричёсывал код (убрал последние следы задержек - были в описании констант, не использовались - так что, как-то неаккуратненько, доктор) а потом для проверки концепии перевёл на микрокод не только SWAB reg, но и CLR, COM, INC, DEC, NET. ADC, SBC, ROR, ROL, ASR, ASL - пока все тоже для варианта - Op reg, так как данное изменение - тупое редактирование описаний этих команд и никакого нового микрокода. Ну и сказалось то, что управление ALU идёт давно уже из "PLM". Синтезирую, посмотрю - как заработаю, пофиксю ошибки, потом погоняю тесты.
Потом, скорее всего, допилю микрокод для TST. Его ещё не допили из-за следующих факторв:
- все одноадресные команды можно разбить на три группы (только читают (пример - TST), только пишут (CLR), читают-что-то делают-пишут)
- внутрянка сейчас работает так, что нужные регистры для выполнения команды читаются ещё на этапе пред-декодинга
- поэтому, несмотря на то, что для, скажем, CLR - формально регистр читать не требуется - вся дальнейшая работа идёт как у читай-пиши команд. И поэтому в варианте - работа с регистрами - микрокод один и тот же.
- а вот для TST надо блокировать запись, что, в принципе, делается элементарно, но (по крайне мере пока) - отдельной веткой микрокода. Которую ещё надо написать. А у нас - ВИРУС :D
- - - Добавлено - - -
RT-11 загрузилась без проблем, формальный тест прошёл, на очереди XXDP
- - - Добавлено - - -
Занимательно :) Падает тест на такой последовательности:
JMP ODD+1
..
ODD: DEC PC
...
Последовательность, конечно, специфическая (и по докам PDP-11/03 игнорит нечётное обращение), но, получается, что преддекодинг берёт не то значение PC :)
Будем посмотреть :)
Ну а тесты инструкций (включая EIS) проходят беЗпроблем :)
- - - Добавлено - - -
Нашёлся ещё один тест (это был VKAD, а нашёлся VKAL), где проверяется такая же последовательность. Остальные проходят.
- - - Добавлено - - -
Хороший, кстати, пример того, что, в принципе, все регистры у PDP-11 равны, но некоторые "равнее" других.
Особенно "ровный" - R7 aka PC.
Чуть менее "ровный" - R6 aka SP :)
- - - Добавлено - - -
И ещё одна мысль.
Судя по этой последовательности - посл JMP ODD+1 нечётность PC СОХРАНЯЕТСЯ :) Хоть команды и будут выбираться по чётному (сброшен бит 0) адресу :) Но когда PC будет использоваться как источник или приёмник в команде - бит 0 участвует :) По крайне мере - на PDP-11/03 :)
- - - Добавлено - - -
Чёт мне надоело для запуска тестов грузить XXDP, а потом ещё ждать, пока она найдёт файл.. Уже начинаю больше задумываться на добавку в FullODT прямой работы с ФС, хотя бы с ФС RT-11 - благо она - не бином RSX :)
- - - Добавлено - - -
Поведение PC поправил. VKAD и VKAL проходят. Начинаю гонять тесты сначала :)
- - - Добавлено - - -
Все тесты PDP-11/03 проходят.
Нуууу... почти все - одна из редакций VKAC - VKACB0 - некоторое время назад начала выпендриваться. Но! Её более новая редакция - VKACC1 - как часы. Если учесть, что не проходит тест прерываемости FIS (а эти инструкии пока никаким боком в новом механизме) - пока забил. Когда совсем будет нечего делать :D (скажем - очередной ступор) - может и подумая над его поведением :)
- - - Добавлено - - -
Жжжж.. Про байтовые варианты забыл. Так что на очереди они.
- - - Добавлено - - -
Ещё и накосячил с реализацией байтовых вариантов :) Поправил, синтезируется...
- - - Добавлено - - -
Поправил. И второй раз попал в ситуацию, когда XXDP грузится, тесты проходят, а RT-11 падает. Ну, в прошлый раз она не падала, а говорила (через драйвер VM), что у вас ДП неправильно работает :) Так что - ишууууу, иде ошибка порылась..
Попробовал разные варианты изменения кода - фсё равно фигВам.. Придётся всё таки лезть в код и смотреть - чего там. Проблема в том, что RT уже успевает переключиться на работу через драйвер - соотвественно - поиск проблемного места будет не тривиальный.
И да, вчера забыл написать - падает она с сообщением "?BOOT-U-I/O error" - ещё работает загрузчик. Падает при попытке загрузки с RK11, RL11 и HX..
- - - Добавлено - - -
Всё, вычислил ошибку :) Значит - тесты её не проверяют :) Проблемы была (ну может что ещё есть) в CRLB reg - сбрасывала весь регистр (расширение знака?), а не только младший байт. Ок, будем пофиксить.
- - - Добавлено - - -
Смотрю на код - и в упор не вижу проблем. Решил для очистки совести проверить работоспобность всего остального, заблокировав новый вариант для CLRB, и, скорее всего - в этой ветки вообще старый код удалю, добавив в микрокод флаг - расширять знаковый бит младшего байта в старший байт. Так оно будет проще и меньше веток.
- - - Добавлено - - -
Да, проблема в CRLB
- - - Добавлено - - -
Переделал код на использование нового флага - а вот фиг.. Какая-то более тонкая ошибка..
- - - Добавлено - - -
Уф... Всё, дошло. CLRB reg - этот вариант команды ДОЛЖЕН прочитать регистр - ибо с регистрами нет работы на уровне байт.
- - - Добавлено - - -
Теперь RT всё устраивает. Щас формальный тест закончится и прогоню XXDP-шные тесты :)
Были мысли по очередной оптимизации по результатам игр, возможно, займусь ими.
- - - Добавлено - - -
Тесты XXDP идут, RT-11 грузится - очередной milestone :)
Плюс TST и TSTB. Смотрю на мысли про оптимизацию. Пока чего-то не так делаю - даже не стартует..
- - - Добавлено - - -
Начинает потихоньку оживать, но местами сопротивляется.. :)
Там не местами :) Там вообще феерические ошибки сыпались, но как только пытался копать предполагаемое место ошибки, как она разззззз - и тютю :) В общем, немного больше суток доходило, какую глупость сотворил :)
Итак, на текущий момент:
- новый механизм используют - обработка прерываний, RTI/RTT. RTS и (SWAB CLR(B) COM(B) INC(B) DEC(B) NEG(B) ADC(B) SBC(B) TST(B) ROR(B) ROL(B) ASR(B) ASL(B)) reg.
- все (на текущий момент) мысли по ускорению процесса выполнения передедланных инструкций реализованы
- RT-11 грузится и проходит формальный тест (копирование диск-в-диск с проверкой)
- XXDP грузится и тесты для PDP-11/03 (кроме FIS VKABC0) проходят.
Что буду переделывать дальше - пока не знаю, но уже примерно с неделю ломаю голову над (общими) обработчиками получения исходного операнда, получения операнда-получателя (где это нужно) и сохранения результата. Есссвенно, в рамках нового подхода на основе "табличной" обработки. Некоторые мысли (как сделать) есть, так что.. возможно, что и этим займусь. А может попробую реализовать какой-то частный случай и посмотреть - как пойдёт.
Мысли по поводу того, как сделать общие обработчики, сформировались, начиню пробовать. Для начала - источник (reg), по результатам буду смотреть - куда дальше
Следующей под раздачу (для проверки концепции обработки разных режимов адресации общим кодом) попала BIS в вариантах BIS (reg), reg.
В целом - концепция работоспособна, но, с учётом того, что для остальной части команд нужен и старый код... Мешанина дикая.. Как говорится в анекдоте - "и теперь с этой хнёй попробуем взлететь!". Так что - иногда синтезированное не работает и хрен пойми - где оно колом встало.
На текущий момент - RT-11 загрузилось, формальный тест прошло. Начинаю XXDP..
- - - Добавлено - - -
Тесты XXDP тоже прошли.
Дальше добавлю и проверю BISB, а потом другие двуадресные команды в том же варианте.
Потом, скорее всего, пройдусь по списку команд и посмотрю, какие ещё в принципе могут использовать новый подход - и попробую и их туда же.
Ни у где-то в этой цепочке попробую сделать код не только для reg, но и (reg) как приёмник
Занимательно смотреть, как при некоторых неправильно работающих командах (копи-паст кривой, соотвественно тесты на них валятся) RT-11 - загружается и даже что-то там делает :)
Подредактировал "PLM" для переключения BIC(b)|BIS(b) (reg1), reg2 на новый подход, но (см выше), так что сейчас собирается исправленный вариант и опять пойдёт в тесты :)
Выловил мелкую ошибку (выставлял, что ячейка - указатель, не смотря на то, что сей факт с ячейки должен был быть сброшен) и среднюю.. даже не знаю, чем её считать :) Сценарий:
1000 27700
1002 5
...
1010 ...
1012 ...
Формально, такой вариант не допустим - ибо в этом режиме адресации операнд (5+1004-> 1011) процом воспринимается как указатель на указатель. То есть 1011 - это адрес ячейки (словный!), где лежит указатель на операнд. Но 1011 - нечётный адрес и на большинстве компов получим прерывание по вектору 4. На самом деле, ячейки 1000 и 1002 содержат не команду, а данные, так что с точки зрения корректности программы всё ок. Но вот в силу расположения этих ячеек - DisAsm воспринимает их как ячейки с командами. И получалось что-то типа (MOV @1011, R0) при чем он понимает, что 1011 - это ячейка указатель, поэтому а) на неё надо поставить метку и б) надо взять из неё указатель и поставить метку на ячейку, куда он указывает :) С пунктом б правда всё ОК - раз нечётный, а должен быть четным - ничего не делаем. Пункт а сам по себе не страшен. Хотя, как оказалось, установленная на нём метка не сбрасывается - ибо в коде сброса проверяется - а не нечтный ли адреса - а вот это уже неприятно - так как в DisAsm-е я пытаюсь соблюдать правило - метка только если есть реальный указатель на слово или байт :) Так что, по размышлению, генерировать КРИВУЮ команду он будет (в конце концов - на некоторых процах команда пройдёт), но вот метки в таких случаях надо будет подчищать :)
Устал от программирования :)
И попутных разборок файлопомойки - так как нужно было найти нужные файлы для DOS-11.
Вернулся к основам - так как PDP-11 на FPGA - это то, с чего опять воскрес интерес к PDP-11 (хотя полностью он и не угасал никогда :) )
Для начало надо было вспомнить - чего я там ваял :) И где остановился в наваянном :)
- - - Добавлено - - -
И сдвинулся с того места, где застрял :) Ок, потестируем наваянное..
В общем.. устал воевать с разным. Плюнул - и начал ваять процессор с нуля :) Ну не совсем с нуля - что-то я успел наваять с подходом а-ля-PLM - так что некая БАЗА есть. Но процессор по сути - с нуля. Из работающего на текущий момент - все команды коротокого перехода (BR/BEQ/BNE...), а так же частично (не все режимы адресации реализованы) некоторые команды.
Скажем
- из команд работают MFPS reg, CMP reg, #xxx :)
- из режимов адресации reg, (reg), (reg)+, -(reg)
Ну и если есть отличия в использовании режимов адресации на разных процессорах - это тоже пока - КАК ДОЛЖНО БЫТЬ, а не КАК РЕАЛИЗОВАНО :)
Сейчас занялся режимом @#XXX, будет проверяться на MFPS :)
Ну, на самом деле, это был не @#XXX а более общий вариант - @(reg)+ :)
На текущий момент работают (в какой-то мере) reg, (reg), (reg)+, @(reg)+, дальше (параллельно) -(reg) и @-(reg) и посколько их плюсовые аналоги описаны - с минусовыми будет несколько проще :)
Периодически (время!) возвращался к проекту, на текущий момент вроде остались только X и @X режимы. Ну и тестирование - ошибки и в описании команд и микрокоманд нахожу..
- - - Добавлено - - -
А, нет, ошибся, @-(reg) ещё не сделал :)
Давно хотимое и никак руки недоходимое - организация для проекта репозитория. Поэтому начал с этого.
Шаг первый - создание первоначального коммита. Основное требование - это должен быть рабочий коммит. Поэтому всё началось с проверок.
К сожалению, вся история ДО будет в виде хаотичного набора файлов.. Может быть когда-нибудь и восстановлю, не знаю.
Жаль, что в момент первого знакомства я ещё был далёк от git-а, хотя система управления проектами использовалась, но увы, нацеленная на VS
sharklodon
18.04.2025, 00:58
Привет,
Надеюсь, что скоро мы сможем разместить ваш проект на GitHub.
Спасибо,
Shark
Надеюсь, что скоро мы сможем разместить ваш проект на GitHub
Есть некоторое количество проблем:
- Я не уверен в доступности GitHub в будущем. Тревожные звоночки уже были
- Этот проект пока всё ещё в стадии изучаем-исследуем-пробуем VHDL и FPGA, так что его часто шатает из стороны в сторону с ОЧЕНЬ большой переделкой исходников, что делает бесполезными коммиты и публикацию
- В силу второго пункта - его нельзя назвать продуктом, который кто-то может взять и получить что-то работоспособное - даже на DE-10 Standard, на которой я тренируюсь
На текущий момент - вялотекущие попытка организации репозитория и обдумывание другого подхода к реализации PDP-11 на FPGA. Вялотекущие - ибо времени свободного КРАЙНЕ мало...
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot