Как стать автором
Обновить

Комментарии 44

Может быть немного не в тему вопрос, можно ли всё это (программирование итд.) делать под линуксом, как-то я не всречал точного мнения. И это касается именно Xilinx.
Да можно, Xilinx Vivado распространяется в виде дистрибутивов под Windows и под Linux.
Некоторые предпочитают часть работы делать на Windows, часть на Linux. Так тоже можно.
А какая эффективная частота работы? (эффективная в данном случае эквивалентна частоты на которой работало бы БК)
На процессорный модуль подаётся ровно та же частота, что и в оригинальном БК — 3 MHz. Производительность при этом получается такая же с точностью до погрешности измерений, что говорит о том, что производительность на такт примерно одинакова.
Конечно используя современные технологии можно добиться гораздо лучшей производительности на такт, сделать конвейер и т.п., но мне было интересно вписаться примерно в тот же транзисторный бюджет. По модулю CPU у меня получилось — LUT — 2398, FF — 557. Это на мой взгляд сопоставимо с КР1801ВМ1 — около 18000 транзисторов.
Гмм. Там тот же монитор (биос по-современному), EMT, машинные коды PDP-11 и организация памяти с точки зрения программ, что и в оригинальной БК-0010?
Да, разумеется. Образы оригинальных ПЗУ монитора, блока тестов, языков Фокала и Бейсика доступны в Интернете. Организация памяти, система команд, контроллер клавиатуры, таймер и прочее полностью эмулируется.
Поскольку это не реализация «вентиль в вентиль» (были и такие попытки на FPGA), аппаратные баги 1801ВМ1 я эмулировать не стал.
Тот, что на Google code видел, тот, что на GitGub нет, спасибо за ссылку.
Пробежался по коду, во всяком случае видно, что некоторые неудобные особенности системы команд PDP-11 там обрабатываются корректно. Авторы молодцы.

Какие такие неудобные особенности системы команд :)? По сравнению с Intel, система команд PDP-11 была изящна как лань. Мне ассемблер БК до сих пор снится. Да мы, вообще, могли писать в машинных кодах, благодаря хорошей систематизации битовых полей в кодах инструкций. Это я вам как заядлый БКашник говорю.

О, для программиста система команд просто идеальна, я в своё время довольно много писал на ассемблере для разных архитектур. Но когда начинаешь реализовывать это в железе, натыкаешься на всякие неочевидности.
Например, команда ADD #1, R0 может вызвать переполнение (что отражается в бите C), команда INC R0, которая по сути тоже прибавляет 1 к R0, на содержимое бита C влияния не оказывает. Какова была логика у фирмы DEC сделать своё ALU в 70-х именно так, мне не известно, не исключаю, что у них просто так получилось.
Да, интересно, хотя V (Overflow) ставится. А можно еще вопрос: на сколько подробно вы собираетесь эмулировать все эти особенности архитектуры. Возьмем, для примера, тайминги:
например «очистка» памяти нулями CLR (R0)++, в силу какой-то экономии и реализации адресации в железе, делалась, фактически, в три операции — загрузка из памяти старого значения, обнуления, записи нового значения. Из-за этого быстрее было так: CLR R0, MOV R0,(R1)++. Такие вещи будут учитываться? Я просто, в свое время, написал эмулятор и там такие вещи работали не так как на реальной БК.
Это действительно очень тонкий момент. Если посмотреть на оригинальные тайминги PDP-11, то там видно, что например команда MOV R0, @#1000 выполняется за меньшее время и требует на одно обращение к памяти меньше, чем ADD R0, @#1000 именно за счёт того, что нам не нужно старое значение по адресу 1000. У меня сделано так же.
CLR в моей текущей реализации старое значение не читает. Тут дело не только в таймингах, а ещё и в том, что на этапе чтения из памяти может случиться ошибка шины.
Так же требуется специальная обработка для команд CLR, TST, CMP, BIT, JMP, JSR — где-то нам не нужно старое значение, где-то новое, где-то косвенность адресации уменьшается на один уровень.
Кстати у меня есть версия почему это реализовано именно так. Возможно в те времена экономили везде и на всем и делали только то, что требовалось от команды. У команды ADD была расширенная версия ADC в которой и использовался флаг C (Carry) в случае расширенной беззнаковой арифметики,. т.е. пара команд:
ADD R0, R2
ADC R1, R3
позволяла уже складывать 32-битные числа в регистрах (R0,R1)+(R2,R3). А для INC, DEC такой необходимости уже не было.
Где то попадалась в своё время таблица за сколько тактов выполняется на БК та или иная команда в зависимости от метода адресации.
Именно за БК не скажу, а по оригинальной PDP-11 эта информация есть в PDP-11 processor handbook, в самом конце.
Именно по БК, тайминги присутствуют в различных журналах в статьях Ю. Зальцмана
Нет нет нет, это было сделано специально, «так получилось» было не для DEC!
Простите за эмоцию, я просто очень любил PDP в их реинкарнации ДВК а первая любовь не ржавеет.

DEC специально так сделала для облегчения работы с длинными данными, чтобы команды смещения индексного регистра либо изменения счетчика не трогали бита переполнения для следующих разрядов, и в библиотеках это красиво использовалось.
Кстати, круто!!! Тоже вполне логично. Но это только подтверждает, что все не случайно, что все команды были продуманы, да еще и спроектированы для каскадной работы в связках. Обожаю PDP-11! Не перестаю восхищаться.
Логика в этом есть. Ну что же, респект тем, кто об этом подумал.
Инженерная мысль DEC и программная реализация многих модулей RT-11 с кучей гениальных хинтов в реализации на ассемблере, многому меня научившие в своё время, до сих пор впечатляет.
Ну тут надо понимать, что уродливость системы команд Intel в сравнении с DEC была обусловлена архитектурой: когда у Intel использовалась раздельные шины данных и адреса, у DEC она была общей. Отсюда и растут эти приятности в виде адресации ячейки памяти как регистра или косвенные адресации.
Честно говоря, не вижу связи между косвенной адресацией и раздельностью шин адреса и данных. DEC использовал архитектуру с равноправными регистрами общего назначения, Intel со специализированными (аккумулятор, индексные, счётчик и так далее). Вот отсюда и разница.
А вы не могли бы более развернуто объяснить какая связь между шинами и адресацией, тем более, что, насколько мне известно, шина у них стала раздельная начиная с 286-го процессора, а архитектура закладывалась гораздо раньше. А z80, по вашему, по той же причине имеет схожую архитектуру?
Всегда считал, что планировалось, что отдельные команды для доступа к портам, будут экономить адресное пространство, так как имеют, по сути, своё отдельное. Но время все расставило на свои места, и сейчас, масса устройств проецируют себя в адресное пространство ядра напрямую, причем большими диапазонами. Т.е. подход DEC победил.
У Intel начиная с 8086 раздельные шины данных и адреса. Другое дело что до, как раз, если я точно помню, 286 использовались общие контакты на корпусе для передачи и данных и адресов.
Я пришёл к этому выводу лет 25 назад когда активно программировал ДВК и БК-0010 на Ассемблере и в машинных кодах. Там неплохо видна эта идея, если машинный код представить в двоичном виде, а затем сэмулировать его обработку на АЛУ и шине. Даже писал что-то вроде реферата для себя на сей счёт. Но вот сходу так тезисно сейчас не изложу.
Не совсем так. У DEC была и шина с раздельными данными и адресом при той же системе команд и даже чуть расширенной.
Дело в другом — ортогональная система команд — то есть все регистры равноправны и к ним применимы все способы адресации, то есть получается полная таблица — отсюда название — требует бОльшего количества железа, нежели специализированные регистры и имеет меньшее быстродействие при прочих равных условиях — вот почему 8080 встала на этот скользкий путь.
«За все в этом мире надо платить».
НЛО прилетело и опубликовало эту надпись здесь
Есть промежуточный продукт между Vivado и ISE: PlanAhead. Поддерживает и старые камни (3, 6) и седьмое поколение (но не самые последние).
Меня как любителя это никак не задело, всё же 7-е поколение FPGA появилось аж в 2010 году, Artix-7 в 2011, Zynq-7000 если не ошибаюсь в 2012. Предполагаю, что это важно для тех, кто занимается коммерческой разработкой под FPGA и поддерживает старые проекты на Spartan.
И ещё жаль CPLD. Новых нет, а старые поддерживаются только в ISE.
Спасибо за статью!
Сделать с нуля собственный процессор с контроллером шины и обработкой прерываний
К сожалению, этот пункт почти никак не отображен в статье.
Под собственным Вы подразумеваете использовать soft-процессор, реализованный на HDL? Если да, то это и вправду интереснее чем Microblaze, но в этой области есть интересная возможность работать с MIPS'ом на FPGA, что подробно рассказано и в Харрисах и в статьях Юрия Панчула.
Да, естественно, для того чтобы сделать БК-0010, нам надо сделать soft-процессор на HDL с системой команд PDP-11. Microblaze нам тут не подойдёт, MIPS тоже, к тому же я не думаю, что про MIPS кто-то расскажет лучше, чем YuriPanchul
За одну статью обо всём проекте БК-0010 рассказать просто невозможно, про процессор будет отдельная статья, я думаю четвёртая по счёту. Постараюсь всё написать быстро!
А нам говорили, что язык БК-0010Ш определяется воткнутой микросхемой. У нас был ФОКАЛ и не было Бейсика. Но в том возрасте я, во-1, не знал какие языки могут быть, во-2, не осознал зачем нужен компьютер вообще. Зачем писать «Привет, человек!», зачем расставлять астериски в виде ёлочки… Я только на первом курсе прозрел, что философское место компьютера быть инфо-хабом для широких масс населения, но это меня зажгло на очень много лет — до сих пор тлеет ;-)
Так и было. Язык был прошит в ПЗУ по адресам — первые 8KБ занимал «монитор», а дальше 24KБ сам язык. Не помню как в БК-0010Ш (вариант для школ), а в БК-0010-01 там лежал обалденный Вильнюс-86 Бейсик (по моему клон GW-Basic). При подключении блока МСТД со своим ПЗУ, оригинальные ПЗУ отключалось, а по этим адресам проецировался Фокал. Но он занимал 8KБ и был намного примитивней по возможностям. Также он был намного медленнее бейсика, т.к. полностью интерпретировался, в отличие от первого, который сначала компилировал программу в промежуточный код (это была интересная смесь машинных команд и данных), а потом уже быстро выполнялся.
Да, так и было. В 8 килобайт сумели засунуть полноценный интерпретатор с поддержкой арифметики с плавающей точкой (пусть числа были пятибайтовые, но всё же). Ассемблерный код интерпретатора просто чудовищный — использовались все возможности процессора и самые тяжелые режимы адресации.
Вильнюс-Бейсик — это не клон, это с нуля написанный язык, сразу для нескольких советских pdp11-like машин: ДВК, БК, УКНЦ. Исходный код можно найти, много где лежит.
Но авторы были под сильным впечатлением от Yamaha MSX, поэтому по ряду вещей этот язык похож на Basic MSX.
https://ru.wikipedia.org/wiki/%D0%91%D0%B5%D0%B9%D1%81%D0%B8%D0%BA_%D0%92%D0%B8%D0%BB%D1%8C%D0%BD%D1%8E%D1%81
Я не точно выразился, и имел ввиду не клон — в плане исходного кода. Это клон — в плане синтаксиса самого Бейсика, так как их было много вариантов на тот момент. А то, что создатели молодцы и проделали огромную работу и все сами написали с нуля — я в курсе.
Из обсуждений у меня сложилось впечатление что вы реализуете процессор с нуля, используя описание системы команд.
Между тем, уже существует Verilog реализация реального 1801ВМ1 — полученная в результате реинжиниринга реального процессора. Все подробности вот в этой теме:
http://zx-pk.ru/threads/23978-tsifrovaya-arkheologiya-1801-i-vse-vse-vse.html
У Вас сложилось совершенно верное впечатление.
Проект, на который Вы ссылаетесь очень интересен прежде всего тем, что люди проделали огромную работу и нашли много плохо документированных особенностей 1801ВМ1 в том числе аппаратные баги (действительно баги, например там в каком-то месте просто не хватает транзистора). Целью того проекта было именно сделать аналог 1801ВМ1 на современной элементной базе, то есть сделать некое изделие, которое можно впаять вместо ВМ1 в БК-0010. Этой цели, насколько я понимаю, добились.
Взять тот проект и переделать его в soft core не получится. Во-первых, в 1801ВМ1 использовались двунаправленные и мультиплексированные шины, в качестве внутренних шин в FPGA такие использовать нельзя. Во-вторых, если посмотреть на Verilog-исходники того проекта, то там практически gate-level дизайн. То есть описано, что сигнал на выводе таком-то представляет собой функцию в нормально дизъюнктивной форме от сигналов таких-то. Понятно, что это следствие обратного инжиниринга, но сюда невозможно ни добавить новую команду, ни сделать процессор с таким же набором команд, но с отдельными шинами для адреса и данных.
Наконец основная задача у меня — показать, что можно сделать с помощью Vivado. Проект БК-0010 — лишь средство сделать это интересным.
Кстати, обратите внимание на Электронику 100/25 в которой была совместимая система команд, но чуть расширенная и другая внешняя шина.
Просто в ней процессор был сделан на чистой логике и она была микропрограммная, причем тексты всех микропрограмм были приведены в руководстве и я своими руками чинил процессор при помощи блока микропрограммной отладки.
И схемы всех плат были и даже с таблицами прошивок ПЗУ.
Это я к тому, что можно поискать чистый микрокод, а не реверсить его из описания команд.
Спасибо.
Да я собственно процессор и всё остальное уже сделал, у меня есть работающий вариант эмулятора. Мне осталось сделать описание наиболее интересных моментов и выложить здесь (и оставшуюся часть исходников на GitHub).
На БК-0010 (1801ВМ1) были базовые команды PDP-11 плюс некоторые из расширенного набора (XOR, SOB).
Вот кстати, если что, эмулятор который вырос из моего: Эмулятор БК-шек с исходниками. Я его года 2 делал, поддержку дисков, ленты, нескольких аппаратных конфигураций. Дальше навалилась работа, семья и я не смог продолжать. Но бросать дело, совсем, было очень жалко, поэтому я выложил исходники в сеть на сайте своего эмулятора. Потом, вот, человек, взял их и за основу и продолжил дело. Он очень сильно развил эмулятор, исправил ошибки, поддержал современное железо. В общем, я очень благодарен ему и слежу за сайтом. Свое имя он почему-то скромно умалчивает на сайте. Я с ним связывался, но дано, и забыл как его зовут. Может быть он и появится тут и присоединится.
Никогда бы не подумал что был БК с механической клавиатурой.
В моём детстве он был таким:
image
Строго говоря, БК-0010 был с плёночной клавиатурой, как на вашем фото. С механической был БК-0010-01. Дребезжала она очень сильно.
В 90-е выпускалась хорошая клавиатура МС-7008.01, совместимая с БК, значительно более качественная.

Принимайте в клуб написавших эмулятор БК0010-01.) Кстати, тут есть авторы известных игр? Напишите названия своих игр и как подписывали игры.)

Под БК-0010 я писал кое-какие системные программы, не игры. А вот под Орион-128 написал немало. Это было позже, в 90-х.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории