МК-85, 1806 и другие звери

KPG wrote: Возможно на контроллере MSP-430 можно достаточно эффективно эмулировать данные калькуляторы (микрокомпьютеры)

Все таки он на половину совместим с PDP-11, посудите сами регистров вдвое больше (16 шт), это потребовало при той же ширине инструкции (16бит) добавить по биту на адрес регистра источника и приемника, откуда их взять? Взяли из режимов адресации, сильно редуцировав их, для источников оставили пост инкремент, для приемника выбросили. В общем свели два поля режимов адресации по 3 бита каждое, до общего трехбитного поля. Для примера

формат двух адресной команды msp430:

[opcode - 4bit][Sreg - 4bit][Ad][B/W][As - 2bit][Dreg - 4bit]

формат двух адресной команды lsi-11:

[B/W][opcode - 3bit][Smode - 3bit][Sreg - 3bit][Dmode - 3bit][Dreg - 3bit] 

Видно что прямого отображения в msp430 из LSI-11 нет, есть достаточно кривое на 40% закрывающее LSI-11. Из этого всего эффективной симуляции не получится, максимум удастся сделать 1МГц версию LSI-11 при условии что в msp430 будет прилично памяти для таблиц кроссировки - а это очень дорогие чипы. Ставить внешнее ЗУ - значит терять такты на обращение к нему через порт. Хотелось бы конечно понять будет ли востребован такой симулятор на частоте 0,5-1 МГц. Учитывая что версии msp430 дошли до тактовых 24МГц, расход по питанию будет приличным и вполне может покрыть таковой на H1806ВМ2. Другое дело что последнему надо чипсет для работы с периферией и она то уже будет жрать как не в себя.

на zx-pk занимаются похожей идей применить 1806ВМ2 в калькуляторе (сильно не МК-85!)

Есть еще версии PDP-11 у Hitachi (Сейчас это Renesas). Расширенная версия, но тем ни менее совместимая (не бинарно!) по системе команд (серия H8S,H8/300H). pdp-11 подобное Но это automative решение и потребляет он значительно!

KPG wrote: Карманный ПК “Электроника МК-85” Как его создавали
http://www.computer-museum.ru/histussr/mk_85_1.htm

Да приходилось читать эту статью, кроме того на сайте ixbt есть целая ветка бесед с Юрием Отроховым распросы про МК-85. Большое дело сделали наши зодчие, потребление 20 мВт при питании 6В это потребление по току - 3.3 мА на всю систему в целом. Мне кажется даже сейчас на такое потребление выйти проблематично. Даже если предположить что симулировать удастся на одной частоте.

P.S. Если есть желание давайте прикинем какие аппаратные/программные идеи могли бы хорошо продвинуть симуляцию 1806 на современной базе (msp430, stm32) не просто равно частотную копию, а превосходящую скажем на порядок при том же потреблении.

тоже интересно какие могут быть.
У меня был некоторый опыт по симуляции процессора PDP-11 на ПК (ассемблер + Форт) (немного незавершённый вроде команду SOB не выполнял и не считал тайминги, хотя таблица их была)
Форт - таблицы декодирования, ассемблер - команды.
Основная идея была использования родных флагов команд ПС процессора для симулированных команд,
с синхронизацией при необходимости с командами PDP-11.
Проект остался и симулировал PDP-11 команды со связью по RS-232 каналу с хост ПО.
С программными заглушками RS232 не всегда удавалось запустить эту связку (без аппаратного RS232)
был ещё канал TCP их общения, но по скорости особого прироста не давал в этой связке.
https://zx-pk.ru/attachment.php?attachmentid=31270&d=1322596893 Нашёл его "следы" в сети на zx.pk, хотя размещал совсем в другом месте с хост-Форт компилятором средой в архиве (может кому то оказался полезным, хотя на этом сайте не зарегистрирован - там, вроде, закрыта регистрация)

P.S. Сложно, конечно оценить сколько ресурсов потребуется на симулирование на STM32 или MSP430 (или их обоих)
но попробовать было бы интересно. (какую то подборку информации из сети уже себе сделал)
Хотелось бы и попробовать симулировать M68K TI-89|92

KPG wrote: P.S. Сложно, конечно оценить сколько ресурсов потребуется на симулирование на STM32 или MSP430 (или их обоих)
но попробовать было бы интересно. (какую то подборку информации из сети уже себе сделал)
Хотелось бы и попробовать симулировать M68K TI-89|92

Кое что попробовал оценить на двух-адресных инструкциях PDP-11, которые можно кроссировать в машинный код msp340.

mov Rs, Rd - 37 тактов, на частоте 16МГц ~ 432 оп.сек.
mov @Rs, Rd - 38 тактов, на частоте 16МГц ~ 421 оп.сек.

Объемы кросс-таблиц
первый переход - 128 слов
второй переход - 512 слов
таблица кросс-инструкций для совместимых режимов адресации двухадресных инструкции - 512 слов
таблица тест-инструкций для приемника результата для совместимых режимов адресации двухадресных инструкции - 512 слов

Можно быстрей но объемы памяти требуемые на реализацию каждой из возможных вариантов этих инструкций ~ 512*12*7=43008 слова, т.е. ~ 86К. Учитывая что реализовались только двух-адресные инструкции :) это перебор. Поэтому выбрал метод подстановки кросс-инструкции в уже имеющееся окружение дополнительного кода в ОЗУ (некий вариант само модифицирующегося кода). Но расчет тактов не включает в себя реализацию модели памяти симулируемого устройства. Думаю что оценить расходы на сопутствующие нужды как "умножить на два" будет приемлемо. Получается что от 6МГц версии 1806ВМ2 msp430 будет отставать вдвое, а то и втрое. Выкладки с кодом в GoogleDocs, сюда мне их трудно прикрепить, если не против "помороковать" совместно над этим пишите в приват.

P.S. Есть вариант выбросить инструкцию pdp-11 через порт, объединить поля во внешней CPLD и забрать готовую инструкцию msp430. Но это все действие надо уложить в 20 тактов, иначе эффективность аппаратной поддержки будет ниже чем программной :) Учитывая что обращение к порту в msp430 будет стоить на запись - не меньше 4 тактов, на чтение - не меньше 2 тактов, а большинство msp430 имеют 8 р-р порты сделать это очень проблематично. Искать msp430 хотя бы с одним 16 р-р :)

P.P.S. Вчера вспомнил что есть кипарисовские PSoC5 умеющие цеплять к адресному пространству нечто похожее на CPLD блоки, вероятно они могли бы помочь с аппаратной поддержкой на частоте близкой к 30-50МГц но это уже чуждая PDP-11 архитектура команд и польза от ARM даже на частоте 80МГц будет сильно нивелироваться.

digitalinvitro wrote: Учитывая что реализовались только двух-адресные инструкции :) это перебор. Поэтому выбрал метод подстановки кросс-инструкции в уже имеющееся окружение дополнительного кода в ОЗУ (некий вариант само модифицирующегося кода).

Правильно ли я понимаю, что это своеобразный кэш уже декодированных инструкций (кусков кода) в родные инструкции MSP430 и возможность их выполнения при декодировании по соответствующим адресам оригинального кода?

KPG wrote: Правильно ли я понимаю, что это своеобразный кэш уже декодированных инструкций (кусков кода) в родные инструкции MSP430 и возможность их выполнения при декодировании по соответствующим адресам оригинального кода?

Нет - только одна инструкция. Дело в том что только одна инструкция превращается в кусок кода на 10-20 команд msp430. Размещать такой объем кода затратно по времени и окупится это только если это тело цикла, да и то при значительном числе итераций. По сути такой подход это что то вроде JIT и AOT и нужно обладать изрядным запасом памяти для таких подстановок. Так же как и Вашем случае я использую SR - регистр статуса msp430 как источник флагов и приличное кол-во инструкций и тактов приходится на формирование из него регистра статуса PDP-11. Конечно можно обдумать момент когда SR не транслируется в SR PDP-11, но в этом случае формировать дополнительные флаги статуса все равно придется. Кроме того придется и тщательно отнестись к инструкциям PDP-11 использующих регистр статуса как обычный регистр РОН. Об этом конечно можно подумать - но задача обширная. Да вообще задача симуляции обширна сама по себе, если решать ее в лоб - получится такой низкочастотный PDP-11, что вряд ли кому будет нужен.

P.S. Насчет ядра M68K мне казалось что Freescale поддерживает эту архитектуру в своих микроконтроллерах, разве нет?

digitalinvitro wrote:
P.S. Насчет ядра M68K мне казалось что Freescale поддерживает эту архитектуру в своих микроконтроллерах, разве нет?

Не углублялся в рассмотрение этого вопроса, если так то хорошо иметь бинарно совместимый по командам контроллер для M68K.

P.S. Интересно, что на 8052 получился проект запуска x86 компьютера с графикой 640х350 https://fleasystems.com/flea86.html
(из-за тактовой наверное 144МГц и сколько при этом потребление получилось)
Следующий вариант этого проекта, правда, уже на FPGA.

Впечатляющий проект. Масштабность в миниатюрности. Жаль, с коробочкой не получилось. На чём-то подобном и хочется разрабатывать Каллисто.

Насколько я понимаю, во FleaFPGA Ohm можно уже залить 80186 и гонять родной код без программной эмуляции.

Честно говоря по данному вопросу пока совсем мало сделано, самое простое из возможного просто загнать его вверх выставкой R15 (PC) симулируемой машины выше 64К, но это возможно только для msp430 с ядром CPUX где возможна 20-битная адресация. Но вопрос с адресацией ОЗУ в этом пространстве выше 64К под вопросом. Вариант с 128Кб FRAM контроллеров msp430 - совсем уж не проходной :)

Рассматривая адресное пространство МК85 видно что простым сдвигом и не отбиться, нужно симулить порты.

PORTS
80-DF	O	;60 bytes, LCD RAM, only bits 4-0 are significant
E0	O	;1 byte, bits 3-0 - cursor position, bit 4 - cursor form
E8	O	;1 byte, related to LCD controller
100	I	;1 word, bits 8-2 - keyboard matrix columns
102	O	;1 word, bits 3-1 - keyboard matrix rows
104	I/O	;1 word, the CPU control register,
		;bit 3 - selects fast CPU clock when set
		;bit 10 - stops the CPU clock when cleared
106		;1 word, apparently not used

ROM  0000:	.dw	0B40,00E0	;reset vector
RAM  8000-87FF	

Ещё, наверное, понадобится на отслеживание попадание исполнительного адреса по данным адресам портов иначе адреса ПЗУ, ОЗУ
Какую то память или контроллер (типа PIC) придётся задействовать для МSP430 с малым внутренним Флэш.

KPG wrote: Ещё, наверное, понадобится на отслеживание попадание исполнительного адреса по данным адресам портов иначе адреса ПЗУ, ОЗУ
Какую то память или контроллер (типа PIC) придётся задействовать для МSP430 с малым внутренним Флэш.

Таблицу страниц для трансляции адреса придется вводить так и так - взяли старший байт адреса, получили чтением по нему из таблиц страниц адрес в адресном msp430. На таблицу потребуется 256х2=512 байт если я ничего не попутал. Если бы не порты можно было бы дальше на этот адрес перенаправлять инструкцию. Но порты так не сделать там каждое обращение нужно брать и симулить отдельно иначе одни и те же данные идущие в порт без различий между собой не смогут быть пойманы периодическим прерыванием симулирующим периферию. А значит придется делать на адрес трансляции переход и если порты в эту страничку попадают - отдельно заглубляться цепочкой сравнений, если нет то из вызванной по адресу трансляции процедуры дополнительно модифицировать код кросс-инструкции смещая источник или приемник или оба вместе в адресном пространстве. Я пока даже не знаю на что наткнемся в этом случае.

Скажем сместить источники и приемники можно при индексной адресации, при косвенной по регистру уже ничего не получится, неужели все косвенные придется свести к индексным?

Либо как Вы и предлагаете расшить пространство снаружи через другой контроллер или CPLD. Но тут есть нюанс у маленьких msp430 порты 8 разрядные, выбросить "за борт" 16 разрядный адрес можно только в два приема и то при условии что принимающий слово контроллер синхронизирован с msp430 по колву тактов на захват с порта 8 р-р данного. Что бы они как в конвейере отработали две посылки из msp430 по 2 байта и потом тут же прием 2 байт через другой порт в сторону ms430. Тогда на забортный контроллер ляжет задача отработать за переферию и возможно за ОЗУ, которого в малых msp430 - кот наплакал. Надо это проработать. Насчет PIC не знаю, а вот stm8 можно заставить потрудится. Что скажите?

все доступные варианты, а далее выбмрать из наиболее эффективных-приемлемых
может даже сменив контроллер для симуляции например на STM32

P.S. Если "повторить" Электронику-85/90 то может быть имеет смысл отреверсить Бейсик-ПЗУ данных калькуляторов,
но это оставит за боротом возможности по эмулированию других архитектур на PDP-11 процессоре.
Отладочная плата с STM8L у меня тоже есть. :)
В какой момент вводить адресное смещение в дешифрации целевых команд, тоже есть повод задуматься.

KPG wrote: все доступные варианты, а далее выбмрать из наиболее эффективных-приемлемых
может даже сменив контроллер для симуляции например на STM32

Да все больше склоняюсь в эту сторону и сам.

KPG wrote: P.S. Если "повторить" Электронику-85/90 то может быть имеет смысл отреверсить Бейсик-ПЗУ данных калькуляторов,

Петр Пиетек уже сделал это за нас. Если подкладывать удобные адреса в код МК-85 и МК-90 то получится такой странный кентавр, вроде бы pdp-11 но только под Бейсик :)

KPG wrote: но это оставит за боротом возможности по эмулированию других архитектур на PDP-11 процессоре.

Вы все правильно понимаете, это оставит за бортом даже возможность на МК-85 писать в кодах pdp-11, а уж о симуляции любой отечественной PDP-11 платформы можно забыть. А ведь там столько всего интересного :). Например интересный советский компьютер Союз-Неон ПК-11.

KPG wrote:
Отладочная плата с STM8L у меня тоже есть. :)
В какой момент вводить адресное смещение в дешифрации целевых команд, тоже есть повод задуматься.

Пораскинем мозгой. Имеем кросированную в msp430 инструкцию, а может быть даже не одну а несколько как например в случае с MOV в котором PDP-11 ставит флаги, а msp430 нет. Допустим мы все режимы адресации сведем к индексной вида

operate X(Rs), Y(Rd)

. Тогда нам остается оперировать смещениями X,Y согласно таблицы трансляции тем самым добиваясь попадания в нужный адрес. В случае когда мы опираемся только на регистр для команд PDP-11 вида

operate (Rs), (Rd)

нужно выдернуть Rs и Rd сидящие в РОН и прогнав их через таблицу трансляции адреса вычислить смещения. То есть не просто получить адрес с таблицы, а привести его к регистру по которому адресуемся X = Rs - TableAddress[Rs]. Что то мне подсказывает что это оверхед, если X просто поместить в регистр по которому потом косвенно адресоваться инструкцией

operate @Rs, Rt

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

operate @Rs, Rt
operate Rt,  0(Rd)

А это мне очень напоминает механизм load/store современных RISC таки как Cortex-ы. И что же мы выигрываем применяя msp430? Мы теряем его РОН потому что 5 регистров снизу может не хватить (вероятно). Мы теряем его родственность PDP-11. Из всего приобретая только его Ultra LowPower. Но работая на 16МГц непрерывно симулируя целевую архитектуру PDP-11 мы теряем даже это. Или я все таки не прав и что то упускаю?

P.S. Кроме того размеры ОЗУ msp430 стесняют даже платформы уровня МК-85, не говоря о других PDP-11 совместимых.

digitalinvitro wrote:
А это мне очень напоминает механизм load/store современных RISC таки как Cortex-ы. И что же мы выигрываем применяя msp430? Мы теряем его РОН потому что 5 регистров снизу может не хватить (вероятно). Мы теряем его родственность PDP-11. Из всего приобретая только его Ultra LowPower. Но работая на 16МГц непрерывно симулируя целевую архитектуру PDP-11 мы теряем даже это. Или я все таки не прав и что то упускаю?

P.S. Кроме того размеры ОЗУ msp430 стесняют даже платформы уровня МК-85, не говоря о других PDP-11 совместимых.

Правильнее, конечно, брать MSP430 с FRAM чтобы нивелировать часть оверхэда кода.
Можно рассмотреть кристалл, например, STM32F103ZET6 на нём и флэш и ОЗУ памяти достаточно много + большое количество I/O
Какое то обсуждение в теме работы двух контроллеров "друг на друга"
http://forum.6502.org/viewtopic.php?f=9&t=4461

KPG wrote: Правильнее, конечно, брать MSP430 с FRAM чтобы нивелировать часть оверхэда кода.
Можно рассмотреть кристалл, например, STM32F103ZET6 на нём и флэш и ОЗУ памяти достаточно много + большое количество I/O
Какое то обсуждение в теме работы двух контроллеров "друг на друга"
http://forum.6502.org/viewtopic.php?f=9&t=4461

Да рассматривал эту возможность, цены на msp430 с обычнмы Flash 128К и 32К ОЗУ удивляют - от 400 рублей. Думаю что FRAM при таких объемах будет дороже. В то же время stm32 при такой цене это уже шилд. Надо пощупать stm32 на предмет в какую канитель выльется симуляция адресного пространства, РОН в stm32 уже однозначно переезжает в ОЗУ :) смысл генерировать самомодифицирующийся код уже не вижу.

P.S. Прочитал по ссылке ветку. Надо же кто то еще использует "пропеллер". Причем пропеллер в связке с WDC816 (6502). Пропеллер как мне кажется насколько интересный на столько же и очень неудачный чип. Вам приходилось иметь с ним дело?

digitalinvitro wrote:
P.S. Прочитал по ссылке ветку. Надо же кто то еще использует "пропеллер". Причем пропеллер в связке с WDC816 (6502). Пропеллер как мне кажется насколько интересный на столько же и очень неудачный чип. Вам приходилось иметь с ним дело?

Сейчас глянул в "Чип и Дип" есть платы совместимые с Ардуино с Propeller тоже, но цена как то "отпугивает".
https://www.chipdip.ru/product/32214-propeller-asc-arduino-s

P.S. Но, Форт похоже неплохо на них зашёл (и не один). https://forums.parallax.com/discussion/141704/comparison-of-propeller-fo...
Раньше это разработчик (Peter Jakacki) делал проект(ы) на LPC2148 c Forth и даже вошел в призёры конкурса от производителя данных контроллеров со своим проектом в году примерно 2008.

У человека отошёл ЖКИ на МК-85 и он собрал свой контроллер с четырёхстрочным ЖК http://electrosch.blogspot.com/p/85-atmega8.html

попробовал на нескольких режимах посмотреть как это будет. Адресное пространство виртуализировано через таблицу страниц (256 страниц, страница 256 байт).

pdp-11          stm32  т.оп/s 70Mhz
mov.w Rs, Rd     37T    1891
mov.w Rs, (Rd)   43T    1627
mov.w Rs, (Rd)+  46T    1521

Довольно не плохо складывается, писать только очень много придется.

использован PIC24EP512GP202
https://github.com/andrew-jacobs/em-retro

P.S. Здесь проект эмуляции БК на STM32F407 https://github.com/abelykh0/stm32f407-bkEmu
и у этого же автора Z80, и некоторые другие проекты.

digitalinvitro wrote: Нет - только одна инструкция.

Возможно, имеет смысл сохранять пул декодированных линейных инструкции в стэк-данных (растущий к верхним адресам) и при циклическом-условии возврата в диапазоне декодированных инструкций в стеке передавать на них управление (предварительно дополнив кодом возврата). Но, возможно, это не такая удачная в реализации идея.

KPG wrote:

digitalinvitro wrote: Нет - только одна инструкция.

Возможно, имеет смысл сохранять пул декодированных линейных инструкции в стэк-данных (растущий к верхним адресам) и при циклическом-условии возврата в диапазоне декодированных инструкций в стеке передавать на них управление (предварительно дополнив кодом возврата). Но, возможно, это не такая удачная в реализации идея.

Мысль хорошая! Надо будет подумать над этим. Если баланс будет в пользу такого JIT :) то надо будет это применить. Порядка 15 тактов идет префетч, и вот в результате этого префетча получаем адрес куска кода - симулятора. Сбросить в стек этот адрес затрата не большая, но вот понять что мы вернулись и стек содержит уже ранее префетченный адрес - это вопрос, видите как это сделать быстро? Закладывать в стек 2 слова - первое слово адрес инструкции симулируемой инструкции pdp-11, второе слово - адрес куска кода выполняющего симуляцию? Перед префетчем сравнивать что там на вершине стека и осуществлять переход. В этом случае конечно стеком уже по прямому назначению не воспользоваться, кроме того его нужно будет закольцевать маской. Но может игра и стоит свеч.

fetch:
         cmp R15, 2(SP)          ; 4T
         jnz next                ; 2T
         mov @R15,  PC           ; 2T
next:
         push R15                ; 3T
         bic.w #loop_bit,  SP    ; 2T
decode:
         .....                   ; 15T
         push T2(R7)             ; 5T

Если так очень приблизительно прикинуть то теряем в случае кеш-промаха 16Т плюсом к 15Т декодирования, но в случае кеш-попадания 10T вместо скажем 15 без кеширования, и вместо 31 с кешированием. То есть все таки выигрываем 5 таков по отношению к тому если бы классически без кеширования симулировать.