[iff2 0]

...

 

на ПЛИС реализации процессора трудно добиться 100% соответствия,

то есть какие-то программы пойдут, а какие-то нет

и иногда доделать для работы следующей программы будет также трудно, как и запустить первую (ну например если потребуется изменить такты исполнения)

в том примере, на который ссылаетесь bk0010-fpga в DE1 я так понял, что некотрые программы не пошли и работа стала

скорее наоборот :). Результат во многом зависит от возможностей железа и знаний разработчика...

Изменено 23 декабря, 2011 пользователем iff2

[VVoland 0]

в том примере, на который ссылаетесь bk0010-fpga в DE1 я так понял, что некотрые программы не пошли и работа стала

 

http://zx.pk.ru/showthread.php?t=13034 - я общался с ТС, он сказал что это делалось в качестве хобби, и все что было интересно сделать уже сделано. Т.е. изначально никаких задач 100% совместимости с БК там не ставилось, только сэмулировать в общих чертах ВМ1.

А допилить до 100% совместимости, ну или хотя бы до 99.9% (как у эмулятора Алексея Савельева) при желании можно.

[iff2 0]

Уже есть хоть с чего начинать :)

Изменено 24 декабря, 2011 пользователем iff2

[Leka 0]

Документация на ВМ2(~300Мбайт): http://zx.pk.ru/showthread.php?p=434162

 

 

 

 

[Stepanov 8]

Коллеги! :santa2:

А что Вы скажете об обходном пути решения этот задачи, не делать машину прямо выполняющую древние машинные коды, а использовать рекомпилятор.

Т.е. софтина (для ПК?) которая не торопясь замещает команды PDP на функционально аналогичные комбинации команд скажем ARM. Достоинств у этого пути много, а из недостатков наверное основной - невозможность в реальном времени обработать _новую_ программу, т.е. нельзя будет загрузить со старого флопа исполняемый код и передать на него управления, придется сначала его загрузить в промежуточное хранилище, там рекомпилировать, и новый образ загрузить в память реального арма.

Насчет проблемы самомодифицирующегося кода и прочих трюков, например проверка контрольных сумм кода при выполнении, то для того чтобы перекомпилированная программа ничего не заподозрела достаточно не забыть в памяти держать оригинальные образы программ до рекомпиляции. Скорость выполнения рекомпилированной программы будет (IMHO) 10-70% от скорости реального арма её выполняющую, зависит от качества реализации рекомпилятора.

 

[tAmega 0]

Документация на процессор просто песня.

Искреннее восхищение и благодарность Вам Leka за то, что нарыли ее, ну и конечно разработчикам которые выложили.

 

Отличия между процессорами 1801ВМ1 и 1801ВМ2

http://code.google.com/p/bkbtl/wiki/VM1vsVM2

 

Теперь осталось раздобыть такую же доку на контроллер дисплея.

Клаву можно самому додумать, дисковод можно заменить каналом ввода

с магнитофона, и закачивать софт по двум проводам, звук можно не слушать,

а вот без видео никуда.

 

Так что без контроллера дисплея действительно никуда и нужно на него

полное описание.

 

Но с 1801ВМ2 это конечно прорыв. Спасибо.

[Leka 0]

Документация на процессор просто песня.

 

Ссылку там увидел: http://forum.ixbt.com/topic.cgi?id=64:2829

 

Решил так.

1) Разобраться с RT-11 - достаточно ли будет переписать только парочку драйверов, чтобы ОС, системные программы и компиляторы (на игрушки наплевать) могли работать с совершенно другой периферией и организацией памяти. Если да, то:

2) Эмулировать в FPGA только процессор, все остальное делать, как удобнее.

 

 

 

На RT-11 v5.3 в инете есть исходные коды на ассемблере (без комментов), поэтому смотрю именно эту ОС, а не клоны.

Изменено 25 декабря, 2011 пользователем Leka

[GetSmart 0]

А что Вы скажете об обходном пути решения этот задачи, не делать машину прямо выполняющую древние машинные коды, а использовать рекомпилятор.

 

...т.е. нельзя будет загрузить со старого флопа исполняемый код и передать на него управления, придется сначала его загрузить в промежуточное хранилище, там рекомпилировать, и новый образ загрузить в память реального арма.

 

Идея очень хорошая. Я бы даже сначала подумал, что можно заменять одну команду PDP-11 на несколько АРМовых, то есть чтобы все вообще команды PDP-11 масштабировались в константное число раз. И тогда адресация внутри кода будет элементарно масштабироваться. Если же команда соответствует 1-в-1, то в конце АРМ-версии команды будут простые NOP-ы. Без константного масштабирования по-моему будет полный геморой. Но потом другая идея родилась. Можно рекомпилировать одну команду PDP-11 в одну ARM, а там, где потребуется больше - ставить CALL на эту функцию, которые уже будут общими для одной конкретной команды PDP-11.

 

Причём всю эту рекомпиляцию, а она при этом будет не сложная, легко сможет делать ARM прямо в рилтайме, сразу после загрузки с дискеты и создания выполняемого образа.

 

Но при этом растактовка не будет соответствовать 1801ВМ1. Игры вероятно будут неправильно работать.

Изменено 25 декабря, 2011 пользователем GetSmart

[Stepanov 8]

Фиксированная длина замещающего кода это конечно красивое решение, но думаю толку от него маловато, поскольку в любом случае рекомпилированная программа физическую память видеть не должна, все её обращения и манипуляции должны происходить в отведенном блоке с виртуальными номерами, страничной организацией и пр. особенностями. Дело именно в этом, нет никакого значения сколько реальных команд занимает замещение, достаточно помимо блока с виртуальной памятью завести таблицу ссылок (таблица отображения) которая будет указывать адреса команд в реальной памяти. Например. Оригинальная программа (с которой так поступили, что она оказалась в процессоре из будущего) считывает значение ячейки в которой хранится указатель на подпрограмму потом копирует этот указатель в другую ячейку, возможно как-то его меняет (условно ADD m[], 0х100), и потом делает переход по этому адресу. В этом случае на самом деле будет вот что: реальная программа лезет во вычисленному адресу в одномерный массив виртуальной памяти, там храниться образ оригинальной программы, от туда копирует в регистр (виртуальный) некое число, о его смысле АРМ догадываться не может, потом копирует значение этого регистра в другую ячейку виртуальной памяти, а вот потом хочет перейти по этому (вычисленному по сути) адресу и для этого в момент перехода из таблицы отображения берется реальный физический адрес и делается по нему переход. Если функции замены прописаны правильно то в случае когда оригинальная программа например висла в мертвом цикле и реальная рекомпилированная программа будет реально виснуть в мертвом цикле виснуть, что есть благо и доказательство точности воспроизведения. И конечно у оригинальной программы не окажется шанса заглянуть за кулисы.

 

С видеоадаптером - тоже. Одно дело если требуется подключить этот аппарат к доисторическому "колокольчику", но я полагаю что средства отображения будут современные, да и в выбранном ARM вероятно будет встроенный видеоадаптер который грех не использовать. И для этого достаточно написать простую функцию которая будет копировать кусок масива виртуальной памяти в реальный видеобуфер, с необходимыми трансформациями конечно. Со звуком кстати сложнее, поскольку там midi процессор был насколько я помню.

 

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

 

А если реально рассмотреть качество работы современных компиляторов, то возникнет мысль что с ассемблером можно и не связываться, возможно немного пожертвовав (для отдельных семейств) быстродействием. И написать всю эту машину на СИ (и отладить на ПК, или с комфортом на ARM).

 

ЗЫ

... и Нью-васюки становятся столицей мира!

[VVoland 0]

Итак, окончательное пожелание, которое будет направлено в разработку: http://forum.bk-fpga.ru/viewtopic.php?f=2&t=13

 

Жду критики, замечаний, дополнений.

[GetSmart 0]

ИМХО Саакашвилли второй раз съест свой галстук, чем кто-то сделает весь список работ не позднее следующего года и меньше чем за 300 тыров :)

Там работы на небольшое КБ. Но КБ меньше ляма не попросит.

 

А уж постоплата добавляет специфических эмоций :)

[vetal 0]

Жду критики, замечаний, дополнений.

1. Разнесите разработку ПО и КД - это абсолютно разные задачи, которые выполняются независимо.

2. Учтите, что 95% работы - это разработка ПО.

3. К ТЗ необходимо приложить всю документацию, в которой описано чему должна быть обеспечена совместимость как в плане конструирования так и в плане временных диаграмм.

[poinr5217 0]

http://code.google.com/p/bk0010/

[tAmega 0]

У меня только один вопрос, даташиты на 1801ВП37, 1801ВП14 и остальные уже нашли или нет?

Если нет, как будут разрабатываться прототипы контроллеров на FPGA?.

Хорошо бы список даташитов и документации на БК пристегнуть к ТЗ, либо в виде доков, либо в виде ссылок.

Иначе это все останутся только пожелания.

[Flood 13]

Там работы на небольшое КБ. Но КБ меньше ляма не попросит.

 

КБ попросит миллион разве что за разработку эскизного проекта первого этапа на бумаге. А с постоплатой будет работать только с окологосударственным или крупным коммерческим заказчиком.

Так что я бы расчитывал только на энтузиастов, для которых оплата работы не является принципиальным условием.