Перенос эмулятора МК-61 на платформу msp430

От редактора. Текст Алексея Сугоняева (digitalinvitro) является итогом многих недель работы по переносу кода существующих эмуляторов МК-61 на аппаратную платформу msp430. Работе сопутствовали обсуждения на нашем форуме и активная переписка, отражавшая текущий ход событий. Много времени было потрачено на оптимизацию: первоначальные варианты эмулятора работали в разы медленнее оригинала 35-летней давности! Алексею пришлось не просто оптимизировать код, а менять некоторые принципы. К слову, на практике выяснилось, что генерируемый компилятором Си код, как правило, не хуже ассемблерного, а накладные расходы Си++ касаются памяти, а не быстродействия. О ходе этой увлекательной работы я попросил Алексея написать статью. Надеемся, она будет не только интересна любителям советских ПМК, но даст возможность развивать поднятую тему.

Текущее состояние макета на фото, предоставленное Алексеем. В качестве прототипа используется калькулятор МК-51.
МК-61 msp430

На правах вступительного слова

За эмуляцию комплекта К145ИК130x мне приходилось уже один раз браться, в прошлый раз меня на это сподвиг призыв Феликса Лазарева к сообществу любителей на сайте zx.pk.ru. Комплект оказался непростой. Мы привыкли вычитывать из радиоэлектронных справочников информацию гораздо более полную, омраченную, может быть, двумя-тремя опечатками и парой ошибок от разработчиков. В случае же с 145-м комплектом информации было просто “кот наплакал”. Наверное наиболее полным источником была книга Я.К.Трохименко “Программируемые микрокалькуляторы устройство и пользование”. Пока моя посылка с микросхемами для Феликса велением почты РФ путешествовала по ЮАР вместо Штатов, Феликс компилировал имеющиеся данные, пытаясь заставить мои скудные извилины работать. Но комплект был весьма необычным, а язык Трохименко в книге - слишком специфичным для меня. Где то на одной десятой блок схемы К145ИК130х я и “слился”. К тому времени посылка с закупленными на убой горячей концентрированной серной кислотой К145 - была подана Феликсом в розыск. Всплыла она в Йоханнесбурге по причине того, что в деревню с очень схожим с Бока-Рейтон названием почтовое отправление невозможно доставить - попросту нет дорог. Карты сложились, и посылку Феликс таки получил. К тому времени я уже окончательно разуверился в своих силах и только и мог наблюдать, что происходит у Феликса с реверсом кристаллов. В конце концов все получилось, Феликс порадовал нас кодом МК-61 для PC и iOS, а другие разработчики подхватили флаг и усилили наступление, добавив в эти ряды Андроид и JavaScript. По причине полного мной непонимания принципов работы К145 комплекта соваться в код и пытаться там что то окончательно для себя выяснить желания не было... Пока Сергей Тарасов не предложил перенести имеющийся у него исходный код эмулятора на msp430. Колеса истории МК-61 снова закрутились.

Исследование платформы МК-61 по исходному коду эмулятора

Чтобы знать, с чем мы имеем дело, стоит кратко описать комплект К145 присутствующий в МК-61:

К145ИК1302      -    1шт
К145ИК1303      -    1шт
К145ИК1306      -    1шт
К145ИР2         -    2шт

Сразу же скажу, что имеющийся эмулятор (причем не только Ф.Лазарева, но и С.Вакуленко) скрывает от нас особенности аппаратной реализации МК-61, а значит в каких то случаях он сильно не оптимален в угоду унификации кода. Поскольку начал с изучения эмулятора С.Тарасова, то в первую очередь пришлось столкнуться с объектным подходом. ООП также маскирует схемотехнику устройства за счет еще большей унификации кода. Необходимо было понять из каких же блоков состоит К145ИК130х, как они взаимосвязаны между собой, выяснить этапы и циклы работы комплекта, поскольку платформа, на которую предполагалось мигрировать, отличается производительностью от ПК раз так в 200-300.

Взяв за основу класс IK13, покопаемся в его "кишках":

class IK13
{
	const IK13_ROM *ROM;
	io_t R[IK13_MTICK_COUNT];
	io_t M[IK13_MTICK_COUNT];
	io_t ST[IK13_MTICK_COUNT];
	io_t S, S1, L, T, P;
	mtick_t mtick;
	microinstruction_t microinstruction;
	io_t AMK, ASP, AK, MOD;
	io_t input;
	io_t output;
	int8_t key_x, key_y, comma;
};

Оставляем только данные класса, поскольку только они отражают аппаратные особенности К145. Наблюдаем массивы R, M, ST. С них и начнем рассматривать комплект. Благодаря Трохименко и его книге, нам известно, что оперативная память комплекта преимущественно динамическая. Видимо, на тот момент разработчики нащупали очень удачное топологическое решение, состоящее в том, что динамическая память ― это последовательная цепочка коммутируемых транзисторами конденсаторов. Для того чтобы заряд конденсатора не успел “рассосаться” его передают в следующий за ним каскад с таким же точно конденсатором. Если в привычной нам DRAM имеется возможность при доступе к ячейке на чтение перезарядить ее, то в данной схемотехнике происходит постоянное чтение-перезаряд ячейки с передачей ее состояния следующей. Ячейки расположены друг за другом как в FIFO буфере. Буфер кольцевой, таким образом, информация в нем не теряется, достигнув конца.

Ключевая особенности К145 в том, что аппаратура имеет доступ только к одной ячейке, стоящей самой первой в буфере. Считав ее один раз, в следующий раз считать значение можно только через 42*4 такта. Почему на 4? Фактически ячеек 168, но удобней при рассмотрении серии К145 абстрагироваться до тетрады (4 бит). Конечно внутри К145 комплекта абсолютно все однобитное, но даже x86 не способен был бы работать с приемлемой скоростью, эмулируй он такую особенность комплекта. Опускаясь на уровень тетрад, мы не сильно грешим против истины, так как тактируется К145 - 4 фазами тактового сигнала, позволяющего аппаратуре привязаться в битовом потоке к началу и концу тетрад. В исходном коде эмулятора общее кол-во тактов на цикл 168, однако инкремент переменной счетчика тактов происходит на 4 за один такт. Массив М, R и ST имеют 42 тетрады, которые в коде представлены байтами, иначе пришлось бы тратить слишком много процессорного времени на доступ к ним.

Забегая вперед, скажу, что ошибочно считал переход к слову (msp430 ― 16-битный микроконтроллер) способом повышения быстродействия. Это не так из-за следующей особенности. Если необходимо получить доступ к тетраде номер X, то ее адрес, измеряемый в байтах, это X. Но при доступе к тетраде, как к слову, X требуется умножить на два, а это дополнительная операция при каждом доступе к регистровым кольцам в К145. Загрузка же, что слова, что байта, для msp430 идентична по таймингу.

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

Массив М в реальной жизни разомкнут, его вход и выход выведены на ноги микросхем (input, output) для каскадирования в большое кольцо-магистраль. Магистраль ― это оперативная память МК-61: любая ячейка магистрали посещает все каскадированные в магистраль микросхемы, то есть все шесть микросхем. Для МК-61 это происходит в следующем порядке: ИР2.1 -> ИР2.2 -> ИК1306 -> ИК1303 -> ИК1302. Магистраль ― это кольцо, и выход ИК1302 замыкается на вход ИР2.1.


Рис.1

Заметим, что память МК-61 ― это все что у него есть: память программ, регистровая память, стековая память ― совокупно это объем памяти магистралей всех регистров М. Для всех ИК130х объем магистрального регистра внутри 42 тетрады, для регистров ИР2 ― это 252 тетрады. Именно за счет регистров и расширяется память микрокалькуляторов ряда БЗ и МК. Вдобавок, последние модели были оснащены ИК1306, дающей еще 42 тетрады в магистральное кольцо.

Массив R и массив ST ― внутренние объемы ЗУ, и МК-61 они не доступны. В этих кольцевых регистрах происходят все промежуточные вычисления при исполнении микрокода. Будем считать их служебным хранилищем.

Изначально в эмуляторе для доступа к байтам-тетрадам кольцевых регистров используется переменная mtick, фактически это тактовый сигнал комплекса. Изменяется mtick от 0 до 167. При реализации основного цикла в котором mtick пробегает до 167, используется еще и внешний цикл for от 0 до 41. Выглядит расточительно два счетчика реализующих одну и ту же функциональность. В качестве оптимизации явно проситься убрать один цикл и развернуть его в последовательные 42 вызова процедуры эмулирующей аппаратуру IK13 (m_IK1302.Tick()). Если при этом mtick (в моем случае signal_I) будет адресовать байты, а не слова в кольце, то получим еще один небольшой бонус в производительности. Для этого переменная signal_I должна инкрементироваться на 1 каждый такт. В конце 41-го такта она должна обнулиться. Будем считать что 41 такт ― это один этап вычисления. 560 этапов вычисления составляют полный цикл устройства.

Процедура эмуляции такта К145 может быть условно разделена на модули по функциональности:
1) выборка текущей микрокоманды;
2) обработка возможного нажатия кнопки;
3) вычисление значение входа сумматора Alpha;
4) вычисление значение входа сумматора Beta;
5) обработка возможного нажатия кнопки и отображения на дисплей;
6) вычисление значение входа сумматора Gamma;
7) вычисление значения выхода сумматора;
8) запись в регистр R;
9) расчет значения регистра L;
10) расчет значения текущей ячейки магистрального кольца М;
11) расчет значения регистра S;
12) расчет значения регистра S1;
13) запись в регистр ST.

Перед тем как перейти к оптимизации выборки микрокоманды, обратим внимание, что ИК1302, ИК1303, ИК1306 по своей сути ― конечные автоматы, переход между состояниями которых реализуется посредством программозадатчика. Программозадатчик, используя встроенное масочное ПЗУ микросхем, оперирует такими абстракциями, как “инструкция”, “микропрограмма”, “микрокоманда”. Инструкция ― это совокупность микропрограмм, микропрограмма совокупность микрокоманд. Основная единица программозадатчика ― микрокоманда. Каждый такт конечный автомат отрабатывает по выбираемой микрокоманде. Наиболее общая единица, с которой работает программозадатчик ― инструкция, она отрабатывается один раз за этап (этап, как уже оговаривалось ― 42 такта). Инструкция выбирается в начале этапа в нулевом такте. То, какая инструкция будет считана из ПЗУ, определяет байт, состоящий из тетрад кольцевого регистра R: R[39]..R[36]. При самом первом пуске все регистры комплекта обнуляются, таким образом, самая первая инструкция, выполняемая комплексом, выбирается по адресу 00. ПЗУ представлена нижеприведенной структурой ROM для ИК1302, ИК1303, ИК1306.

typedef struct
{
	 microinstruction_t microinstructions[68]; // микрокоманды
	 instruction_t instructions[256]; 	   // команды
	 uint8_t microprograms[1152];              // микропрограммы 
} IK13_ROM;

Всего инструкций 256, их адрес восьмиразрядный, поэтому достаточно двух тетрад, чтобы позиционироваться в нем. Инструкция занимает 32 бита или 4 байта в ширину. Три младших байта задают адрес в ПЗУ микропрограмм, сменяясь поочередно. Таким образом, инструкция содержит три смещения в ПЗУ микропрограмм. При внимательном изучении кода эмулятора выясняем, что адрес микропрограммы меняется только три раза за этап. В эмуляторе это привязано к значению k=mtick/36. Вычисления смещения в ПЗУ микропрограмм происходят при k<3 mtick=0...107, k==3 mtick=108...143, k==4 mtick=144...167. Как мы помним, mtick меняется в диапазоне 0..167. Для k<3 смещение внутри ПЗУ определяется по нулевому байту инструкции, для k==3 по первому байту инструкции и при k=4 по третьему байту инструкции.


Рис.2

Несмотря на то, что код эмулятора каждый такт вычисляет смещение ASP, оно неизменно в заданных интервалах mtick. Для тактового сигнала signal_I, равного mtcik/4, расчет смещения ASP достаточно проводить в начале нулевого такта, в начале 27 такта и в начале 36 такта. Поскольку все 42 такта уже развернуты вместо цикла, то это еще один путь для оптимизации производительности эмулятора. В 36-м такте происходит вычисление адреса новой инструкции, в тетрады 38 и 39 кольцевого регистра R заносится ее адрес. После того, как смещение ASP известно, происходит выборка микрокоманды. Так как происходит это в каждом такте, то смещение необходимой к исполнению микрокоманды зависит от mtick. Смещение микрокоманды ― это ASP, умноженное на 9, к которому суммируется значение из таблицы, сопоставленное такту. В эмуляторе индексом является mtick/4, в моем же случае ― просто signal_I. Вот эта таблица.

static mtick_t J[] =
{
	0, 1, 2, 3, 4, 5,
	3, 4, 5, 3, 4, 5,
	3, 4, 5, 3, 4, 5,
	3, 4, 5, 3, 4, 5,
	6, 7, 8, 0, 1, 2,
	3, 4, 5, 6, 7, 8,
	0, 1, 2, 3, 4, 5
};

Не теряя такты на чтение из массива по индексу, попросту передаем внутрь процедуры на каждом такте соответствующую ему константу. Я рассуждал следующим образом: чтение из массива занимает не меньше трех, а то и четырех тактов в то время, как загрузка константы ― это два такта. Однако некоторые константы для msp430 загружаются с приятным бонусом: за один такт грузятся константы из ряда 0, 1, 2, 4, 8, -1. Если оптимизатор компилятора достаточно умный, он не будет по традиции ANSI C (если быть совсем точным то ABI) передавать параметры через стек (stdcall), а будет отправлять их в регистрах (fastcall). В этом дополнительном слагаемом мне не удалось увидеть никакой системы с простой зависимостью от signal_I или mtick.

Микрокоманда ― это 32-разрядная величина, каждый бит которой управляет мультиплексором или дешифратором записи внутри К145. Условно можно разделить микрокоманду на 16 старших и 16 младших разрядов. Но поле одного из дешифраторов записи находится очень неудобно для такого деления: начинается с 15-го и завершается 17-м битом. Но так удобнее для понимания, что младшая часть микрокоманды управляет сумматором, организуя для него слагаемые Alpha, Beta и Gamma. Ниже на рисунке я попытался представить механизм суммирования в виде управляемых битовыми полями мультиплексоров. Надо понимать, что комбинации битов приводят к подключению через механизм OR любой совокупности входов мультиплексора. И, конечно, схемотехнически ― это не мультиплексор, а селектор, выходы которого объединены огромным шинным OR. Это очень удобный и широко используемый прием, такой мультиплексор проще схемотехнически чем строгий, запрещающий комбинацию входов. Однако забегу вперед и скажу: анализ полей всех микрокоманд показал, что хоть комбинации битов и используются для выбора входных линий, но далеко не все, количество комбинаций ограничено. Этот факт тоже можно использовать для увеличения производительности, перейдя от последовательного списка условий к конструкции с выбором (switch). Сумматор вычисляет байт, младшая тетрада которого это значение Sigma, а старшая ― регистр P. От значения регистра P зависит только значение регистра L, а вот Sigma ― это результат который может попасть в S, S1, R[], ST[], M[]. Управляет записью Sigma, старшая часть микрокоманды ― дешифратор записи результата.


Рис.3


Рис.4


Рис.5


Рис.6

Запись в кольцевой регистр ST в зависимости от битов 26 и 27 может происходить следующим образом:

  • биты 26,27 = 0,0 - нет записи результатов;
  • биты 26,27 = 0,1 - прямой порядок записи результатов;
  • биты 26,27 = 1,0 - обратный порядок записи результатов;
  • биты 26,27 = 1,1 - запись результатов через логическое ИЛИ.


Рис.7

Однако при анализе не удалось найти микрокоманды ни для одной из микросхем ИК1302, ИК1303, ИК1306 с установленными в “1” битами 27 и 26. Вероятно использование таких микрокоманд было отложено “на потом”, либо применено в других приборах, кто знает из чего в СССР делали баллистические вычислители для артиллеристов. В эмуляторе С.Вакуленко код для реализации записи результата через ИЛИ оказался вырезан, что косвенно подтверждает отсутствие необходимости в данной аппаратуре у МК-61. Вырезал этот код из эмулятора для MSP430 и я.

В поисках возможностей увеличить производительность наткнулся на то, что все три эмулятора от Ф.Лазарева, С.Тарасова и С.Вакуленко использовали необычную модель кольцевого регистра, а именно массивы в памяти IK1302.M, IK1303.M, IK1306.M, IR21.M, IR22.M проводили закольцовку через запись в ячейку с индексом mtick/4 (signal_I). Последнее значение, взятое из IR22.M, писалось в IK1302.M и mtick/4, завершив кольцо. Это было не оптимально, так как на каждый объект класса IK13 следовало три присвоения: входной переменной input из предыдущего объекта класса, потом выходной переменной output из массива M[42], затем массиву M[42] из входной переменной input. Увеличить производительность можно было представив кольцевой регистр М как массив в памяти равный суммарной емкости всех магистральных регистров комплекса, 42*3+252*2=630. При этом, просто двигая три указателя внутри него, можно было отказаться от присвоений, да и от объектов IR22, IR21. Регистровые файлы ИР2 ничего кроме магистрали не инкапсулировали, их функциональность сводилась к трем присваиваниям. В конце 42-го такта необходимо было ввести проверку выхода указателя за рамки массива с переносом его на нулевой элемент если выход произошел. При этом инкременты указателей были не нужны: signal_I и так это делал, оставалось его использовать в качестве индекса дополнительно к указателям.


Рис.8

В итоге эмулятор стал слишком не похож на своих собратьев, и пришлось выискивать в кольце адреса памяти ПМК для всех необходимых типов: регистров, стека и шагов программы. Поскольку расположение регистров М различных микросхем может быть разным, например:
a) IR2.1 -> 1306 -> 1303 -> 1302 -> IR2.2;
b) IR2.2 -> IR2.1 -> 1306 -> 1303 -> 1302;
то приведу смещения в массиве для своего распределения в кольце М.


Рис.9

uint16_t pack7[15] = {
 &ring_M[461],&ring_M[461+42],&ring_M[461+84],&ring_M[461+126],&ring_M[461+168],
 &ring_M[41] ,&ring_M[41+42] ,&ring_M[41+84] ,&ring_M[41+126] ,&ring_M[41+168],
 &ring_M[251],&ring_M[251+42],&ring_M[251+84],&ring_M[251+126],&ring_M[251+168]
}

Шаги программной памяти разбиты пакетами по 42 байта (так как байт представляет собой тетраду, то 42 тетрады). Пакеты смещены по массиву кольца указанным выше способом с шагом в 42 тетрады. Внутри пакета распределены 7 шагов программной памяти. Распределены они нелинейно, в конце пакета идет ШАГ-0, в начале ШАГ-1, далее по нарастающей ШАГ-3, 4, 5, 6. Логически это объясняется только тем, что Шаг-0 по малому кольцу переходит в Шаг-1, но физически на этом уровне кольца нет. Так как шагов 7 а байт-тетрад 42, то период равен 42/7 = 6. Таким образом старшая тетрада (смещение +6) кода ШАГ-а, находится впереди младшей (смещением +3). Код ШАГ-а ― это байт.


Рис.10

Так как в ШАГ входит 6 тетрад, а заняты из них только 2, то, очевидно, остальные тетрады используются под размещение регистров от 0 до Е и стека X, Y, Z, X1. Регистры залегают в пакетах, младший разряд мантиссы идет со смещения 0 в пакете с шагом +3 для каждого следующего разряда. Младший разряд порядка сдвинут на +26 от начала пакета, старший разряд смещен на +3 относительно младшего разряда порядка. Регистр 0 (П0) располагается в пакете с ШАГ-0..ШАГ-6 памяти программ. Следующий регистр ― в следующем пакете и так далее до регистра Е (ПЕ). Становится понятным, почему в такой структуре памяти не получался регистр F: не вписывался в систему. Регистры стека X1, X, Y, Z, T залегают рядом с разрядами регистров памяти, начиная с пакета для ШАГ-64..ШАГ-70.

Клавиатура


Рис.11

Нажатия кнопок передаются в эмулятор через свойства IK1302 (она отвечает за клавиатуру и отображение в МК-61). Для этого IK1302 использует переменные key_x, key_y, означающие активность столбца и колонки для замкнутой клавиши. Например:

0 - {2,1}, 1 - {3,1}, 2 - {4,1}, F - {11,3}, K - {10, 9}, С/П - {2,9}

Максимальное количество функций, повешенных на кнопку, равно трем, поэтому задействование дополнительных функций происходит в следующих циклах сканирования матрицы клавиатуры Y=1..3, 4..6, 7..9 при неизменном X. Например для кнопки С/П обработка производится в 9-м цикле сканирования.

Эмулятор проверяет каждый столбец три такта подряд (по количеству сканирования Y), от 3 до 5 ― это столбец с координатой 2, от 6 до 8 ― столбец 3, последний столбец 11 проверяется в тактах 33..35. Приведу код:

switch (microinstruction >> 24 & 3)
{
  case 2:
  case 3:
    if ((mtick / 12 | 0) != key_x - 1)
    if (key_y > 0)
      S1 |= key_y;
    break;
}

Я его несколько “подрихтовал” для достижения меньшего времени исполнения проверок на вход. Заодно при передаче значения key_x во избежание потерь на вычисления, решил рассчитать заранее и IK1302_key_xm = key_x - 1. Думаю, что имеет смысл проверку key_y на ноль исключить, так как в эмуляторе мы формируем нажатие только при его наличии.

if((mi_hi | ~0x0300) == 0xFFFF)
        if (div3_table[signal_I] != IK1302_key_xm)
            	if (IK1302_key_y > 0)
                    	IK1302_S1 |= IK1302_key_y;

Столбца 0 не существует, так же как и столбцов 12, 13, 14, поэтому в этих тактах проверка бессмысленна. Возможно это повод подумать об оптимизации, заменив в этих тактах вызов Tick() на вызов схожей по коду процедуры, без проверки нажатия. Исходный эмулятор для передачи нажатия в комплект использует процедуру KeyPress, так как при нажатии кнопки на реакцию калькулятора требуется дополнительный цикл работы. После любого цикла значение key_x, key_y обнуляется. Вполне вероятно, что эффективней будет использовать специальную процедуру DoStep (отработка цикла комплекта) осуществляющую проверку клавиатурной матрицы. А для циклов, в которых нажатие кнопки не передается, использовать упрощенный код.

Эмулятор МК-61 на платформе MSP430

На данном этапе работы, получившийся переработанный код эмулятора, в 2,3 раза быстрее реального МК-61. Но необходимо учесть, что для этого пришлось изрядно перекроить программу под находящийся в ПЗУ МК-61 микрокод и схему МК-61. Таким образом пришлось пожертвовать универсальностью кода для всего комплекта К145ИК130х. И даже в этом случае на частоте 25-27 МГц эмулятор способен лишь вдвое обогнать своего собрата, работающего на частоте 100 КГц! Расчет производительности осуществлял по программе из теста “Счастливые билеты”.

   00    01    02    03    04    05    06    07    08    09 
00 ИП8   П0    ИП0   ИП1   +     ИП2   +     ИП3   -     ИП4   
10 -     ИП5   -     Fx=0  19    ИП7   1     +     П7    FL0   
20 03    С/П

Для МК-61 время счета составило 40 секунд, для MK61msp ― 17 секунд.

О затратах памяти

Для портирования МК-61 на другие платформы разберем затраты оперативной памяти:
1) основное магистральное кольцо М - 630 байт;
2) кольцевые регистры (ST,R) ИК130х - 84*3 байта;
3) логические регистры (L,T) ИК130x - 2*3 байта;
4) временные регистры (S,S1,P) ИК130х - 3*3 байта;
5) регистры клавиатуры (key_x, key_y) - 2*2 байта;
6) флаг MOD - 1*3 байта.

Итого на комплект К145 для МК-61 требуется 904 байта. Однако в самом эмуляторе присутствуют дополнительные структуры данных для обслуживания эмулятора (клавиатуры, ЖК, терминала, стек микроконтроллера). В моем случае потребность в ОЗУ достигла 1215 байт. Потребность в ПЗУ (флеш) намного выше: только ПЗУ микрокода занимает 7344 байта. Объем ПЗУ в моем случае достиг 24-25 Кб.

Метки публикаций: 
Русский

Комментарии

Тема серьёзно проработана! Снимаю шляпу. Неплохое ускорение получилось. У меня на pic32 48МГц калькулятор работал в 2.4 раза быстрее оригинала. Здесь примерно та же скорость на частоте процессора 25МГц.

Сергей Викторович благодарен Вам за оценку. Не могли бы Вы осветить кое какие вопросы? Мы заметили намедни одну интересную штуку с эмулятором, об этом Сергей Тарасов хотел бы создать отдельное дополнение к статье. Так вот мы решили подключить в кольцо дополнительную память... И Вы знаете, получилось. Хотя и не совсем то, что мы ожидали, поскольку воткнули в магистраль ИР2, а получили только 7 шагов памяти (к 105 имеющимся) и еще один регистр F дополнительно. ИР2 содержит гораздо больший объем памяти, которого бы хватило на 42 шага. Мы стараемся сейчас подтвердить или опровергнуть, но думаю что факт все-таки свершившийся. Не могли бы Вы прокомментировать такую возможность? Пробовали Вы на своем эмуляторе нечто подобное?

Великолепнейшая статья! Автору почёт! Всё расписано до мелочей, от души благодарю, шедевр просто!

.

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Оптимизация МК-61 и публикация материалов по его устройству — достойный труд.

Сама же платформа msp430 не уверен, что интересна. Неплохо бы перенести получившийся эмулятор на что-нибудь, имеющееся у людей. Лучше всего на айфон. Но можно также на десктоп. Идеальна, конечно, прошивка W77LE516P в МК-161. Она натыкается ровно на те препятствия, которые мешают переводу Каллисто на низкий уровень.

Эмулятор на основе кода Феликса уже давно написан для более распространённой, чем айфон, платформы - Андроид.

А запускать эмулятор МК61 на МК161 - это, как мне кажется, для особых ценителей. Будет такой медленный вариант оригинального МК61 :)

А вот msp430, оставленный в корпус типа МК51, заинтересует многих

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Частота процессора МК-161 почти совпадает с msp430. Запас по быстродействию у новой версии эмулятора есть. Возможно, получится сделать и быструю версию МК-61. Плюс сервисные возможности, если останется место в памяти камня — поддержка библиотеки программ, компилятор/декомпилятор, связь с ПК, управление внешними устройствами и другие возможные расширения.

Разницу с единичным «msp430, оставленным в корпус типа МК51» объяснить просто. Это как в музей сходить и повосхищаться, могут же некоторые люди! Или иметь дома своего верного друга-вычислителя.

Увы, Арви, нет запаса по быстродействию. Для того что бы он появился, нужно сейчас приложить усилия по стандартизации микрокода МК-61. За счет унификации микропрограмм (синхропрограмм) можно будет создать задел по быстродействию раз так в 10. Но надо начать вскрывать микрокод.

Вот это уже другой разговор!

Открыл сейчас Трохименко. Итак, команды К (это обычные КОП, например 54 это КНОП — или сложнее?) запрограммированы, как несколько синхропрограмм АСП. Каждая из АСП запрограммирована, как последовательность из девяти микрокоманд МК — среди которых даже бывают лишние. То есть в реальности их может быть и меньше девяти.

Сейчас эмуляторы переводят каждую из 68 (40) микрокоманд в 32-битную последовательность битовых полей, которую и исполняют, эмулируя оборудование. Это работает только потому, что скорость современных зарубежных ЭВМ позволяет подобные накладные расходы.

Вместе с тем если перевести все синхропрограммы на язык Си (приблизительно этим занимался Трохименко, описав множество синхропрограмм на русском языке и псевдокоде) — быстродействия W77LE516P внутри МК-161 должно хватить на подобный эмулятор.

Интересно, можно ли сделать промежуточный гибридный вариант? То есть эмулятор, который бы исполнял команду К, вызывая закодированные на Си АСП — а если какая-нибудь из АСП ещё не закодирована, включал тикалку, временную адресацию и скатывался на буквальное исполнение микрокоманд из прошивки, как в эмуляторах Феликса и Арбинады.

Мы с Сергеем Тарасовым, Виталием Самуровым обсуждали в личной переписке возможность мобилизации трудящихся на вскрытие фрагментов микрокода. Смысл такой, я фактически цитирую Феликса Лазарева, опять же из личной переписки - "ключ к пониманию лежит в декодировании по ASP".

42 такта микрокоманд всегда формируются тремя синхропрограммами ASP0,ASP1,ASP2 которые содержутся в одной 32-битной инструкции. Само собой таких синхропрограмм не может быть много - хотя бы потому что ASP - 8 битное поле. Но не забываем о том что одна и та же синхропрограмма может использоваться для первых 27 тактов (0..26 такт), и для последующих 9 тактов (27..35 такт). И это будут в чем то похожие, но в чем то разные синхропрограммы (часть микрокода из серединки будет изъята). Предположим что их не 256 а 512, хотя конечно меньше 512.

Приведу фрагмент синхропрограммы АСП = 4Е, выполняющийся в момент сброса первой.

(00800120) : S+ ~S -> S                     F -> S                     
(00040020) : S -> R[ 0]                     S -> R[0]        F -> R[0] 
(00000000)                                                             
(01000001) : R[ 3] -> S1                    R[3] -> S1                 
(00080820) : S+1 -> R[ 2]                   S + 1 -> R[2]    0 -> R[2] 
(00080020) : S -> R[ 3]                     S -> R[3]        F -> R[3] 
(01000001) : R[ 6] -> S1                    R[6] -> S1                 
(00080820) : S+1 -> R[ 5]                   S + 1 -> R[5]    0 -> R[5] 
(00080020) : S -> R[ 6]                     S -> R[6]        F -> R[6] 
(01000001) : R[ 9] -> S1                    R[9] -> S1                 
(00080820) : S+1 -> R[ 8]                   S + 1 -> R[8]    0 -> R[8] 
(00080020) : S -> R[ 9]                     S -> R[9]        F -> R[9] 
(01000001) : R[12] -> S1                    R[12] -> S1                
(00080820) : S+1 -> R[11]                   S + 1 -> R[11]   0 -> R[11]
(00080020) : S -> R[12]                     S -> R[12]       F -> R[12]
(01000001) : R[15] -> S1                    R[15] -> S1                
(00080820) : S+1 -> R[14]                   S + 1 -> R[14]   0 -> R[14]
(00080020) : S -> R[15]                     S -> R[15]       F -> R[15]
(01000001) : R[18] -> S1                    R[18] -> S1                
(00080820) : S+1 -> R[17]                   S + 1 -> R[17]   0 -> R[17]
(00080020) : S -> R[18]                     S -> R[18]       F -> R[18]
(01000001) : R[21] -> S1                    R[21] -> S1                
(00080820) : S+1 -> R[20]                   S + 1 -> R[20]   0 -> R[20]
(00080020) : S -> R[21]                     S -> R[21]       F -> R[21]
(00040000)  -> R[23]                        ? -> R[23]       ?? -> R[23]
(00040020) : S -> R[24]                     S -> R[24]       F -> R[24]          
(00A03120) : S+ ~S+ ~L+L-> S: P -> L :      F + 1 -> S       0 -> S    

Первый столбец это то что выдает специализированный на расшифровку микрокода эмулятор под PC, следующие два столбца это собственно приближение к какому то здравому смыслу. Или как называет это Феликс Лазарев - эвристика.

Это все нужно осмыслить систематизировать и только потом переходить к кодированию синхропрограмм в законченные процедуры.

Однако собранный после этого эмулятор надо покрыть тестами, да не простыми а в сравнении с тем что выдает микрокомандная версия. Скажем вычислением CRC всей памяти комплекта после каждого этапа вычисления и сравнения.

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

Вы описали вполне рабочий план. Не вижу ничего сверхъестественного, чего бы требовалось от программиста. К предложению запустить два эмулятора параллельно (эталонный и разрабатываемый) — и сравнивать области памяти комплекта (не обязательно даже CRC, прямые сравнения норм) могу добавить ещё одно.

Заменять синхропрограммы на кодированную «эвристику» шаг за шагом. Каждый раз сверяя поведение новой, более совершенной модели, с эталоном. С учётом высказанного вами вырисовывается такой план:

1. Объединить два независимых эмулятора в одной программе под десктоп. Со своими областями памяти, индикаторами и т.д. Оба эмулятора исполняют одинаковый код из одного и того же входного файла — куда можно записать, для начала, «8 ферзей».

2. Написать «мостик», их объединяющий. Просто функцию Compare(), которая сравнивает области памяти обоих комплектов.

3. Второй эмулятор «заморозить» — вынести в отдельный файл, к которому не прикасаться больше никогда.

4. Первый эмулятор усовершенствовать, позволив синхропрограммам выполняться «по эвристике», если такая уже закодирована. И выполняя синхропрограммы с помощью эмуляции, если пока эвристика для неё не разработана.

5. Постепенно заменять синхропрограммы на эвристику, одна за другой, от самых простых к сложным — каждый раз прогоняя «8 ферзей» (или более сложный тест) и проверяя, совпадает ли результат с эталонным. Таких шагов может быть и 500. Главное здесь — сохранять бэкапы после каждого шага, чтобы при выявлении расхождений можно было прогнать по новым тестам все предыдущие шаги и точно выяснить, в какой синхропрограмме ошибка.

EDIT

Может потребоваться обновление всей цепочки бэкапов. То есть у версии №123 могут быть обновления 123.1, 123.2 и т.п. На каждом из шагов эмулятор должен поддерживаться в полностью работоспособном состоянии — давать одинаковые результаты с эталоном при любых входных файлах (тестах).

Предположим, что на этапе №256 был найден новый тест, дающий расхождение. Прогон этого теста на бэкапах показал, что эмуляторы №1…99 дают верный результат, а сбой начинается в эмуляторе №100. Это локализовало ошибку в реализации синхропрограммы ASP33, которая была введена в эмуляторе №100 и ещё не была реализована в шагах №1…99.

В результате появилась версия 100.1, в которой эвристика ASP33 исправлена. Эту эвристику ASP33 надо распространить по последующим шагам, в результате чего появятся версии 101.1, 102.1… 255.1 — именно на них потребуется проводить последующие тесты, при выявлении новых расхождений. Такие цепочки обновлений вряд ли потребуются часто, но возможность их совершать повышает уверенность в правильности кодирования синхропрограмм. Также, по мере приобретения опыта, на одном шаге можно пробовать кодировать сразу несколько синхропрограмм.

Понимаете, Арви, каков это объем работы? Вы упустили еще один ряд тестов - это тесты с нажатием кнопок и выполнением функций, они протекают не так как исполнения оп-кода МК61 по программе, таким образом нужно будет заложить симуляцию всех функций с клавиатуры.

Вот Вы нарисовали план работы, можете реализовать в одиночку? Кроме того если посмотрите на распечатку АСП выше то там есть код который я не понимаю что делает, то есть сейчас я не понимаю что он делает. Я бы начал с того что перебрал бы все имеющиеся синхропрограммы и попытался бы их как то обозвать - выдать мнемонику ей. Почему, потому что синхропрограммы три на этап (42 такта), а этапов 560. В выше описанном фргаменте есть код который мне не понятен и я его не как не отэвристил, мало того я даже не знаю как его закодировать, потому что он например не имеет источника, а имеет только приемник. Что это НОП или может какой то хитрый хак который разработчики МК61 сделали потому что не хватало ресурсов. Ведь синхропрограммы могут нести двойной смысл для разных фрагментов вычисления. Думаю начать надо с минимального понимания что делаешь.

Понимаю, конечно. Такой объём работ я выполнил, перенося Форт на входной язык МК. Многие сотни слов, написанных на допотопном ассемблере ЕС ЭВМ и более знакомом ассемблере 8086. Шаг за шагом, начав 26 августа 2014 года, я уже довёл работу до release candidate 2 и сейчас неторопливо шлифую напильником, готовя уже римейк с повышенным быстродействием.

Наградой мне вместо миллиардов Билл Гейтса и Стива Джобса — мат из Новосибирска, нападение на жж-сообщество, отражение мощной многомесячной атаки вандалов и спамеров на вики, многолетний разрыв отношений с родителями-путинистами, полунищенское существование в Москве между мыслями о самоубийстве и о стояниях на улицах с протянутой рукой. С невероятным трудом, в кроссовках с отваливающейся подошвой, заплатил вчера последние 50 рублей мелочью, закрыв кредит в банке, взятый просто на еду. Особенности национального возрождения в России почему-то отличны от того же процесса в Калифорнии. :-)

Но дело сделано. Исходный код Каллисто в свободном доступе — загружай кто хочет, было бы желание. И вы справитесь. Думаете товарищу Степанищеву налаживать производство «Электроники МК-161» было легче, чем нам? Возможно, он даже больше грязи в свой адрес выслушал, чем я. А нервы у нас всех не железные.

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

Начинать кодировать АСП лучше с самых простых — тех, о которых написал Трохименко. Если не понимаете ASP4E, попробуйте начать с ASP04 (стр. 155, таблица 4.5). Она кажется достаточно простой.

Насколько я понимаю, а я разбираюсь в этом куда меньше вашего, в эвристике будет много откровенного мусора, вызванного низким уровнем технологий 1970/80 годов. Без этого мусора эмулятор работать будет прекрасно. Но до реализации всех синхропрограмм я бы не удалял его из кода, а реализовывал синхропрограммы в точности такими, какие они есть.

Ещё вопрос к вам. Я написал примерный план, исходя из своего ограниченного понимания работы эмулятора. Насколько я понимаю, в кольцо ПМК включено несколько микроЭВМ, в каждой из которых свой набор АСП. Если в разных микроЭВМ будут одновременно выполняться разные синхропрограммы — их взаимодействие усложнит эвристику, или они относительно независимы?

Не проверял совпадают ли синхропрограммы разных микросхем по микрокоду, вероятно нет. Усложнит ли эвристику - то же трудно сказать, не думаю что микросхемы в комплекте обмениваются какими либо внутренними переменными, скорее всего каждый делает свою работу над общими данными в кольце М, вероятно захватив оттуда порцию данных только для себя. Скажем ИК1306 сильно не догружен по работе над данными.

Не думаю что я осилю что то в одиночку, так что пока это интересно вероятно буду копаться. Но уже сейчас мне кажется более полезным перейти в Verilog что бы стартануть на ПЛИС.

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

Предположим, что в промежуток времени Т микроЭВМ М1 выполняет АСП1. В тоже самое время микроЭВМ М2 выполняет АСП2. За этот промежуток времени Т общее кольцо сдвинется. Может ли (даже не в общем случае, а в конкретном микрокоде МК-61) произойти такое, что АСП2 потребует на входе часть информации, которую генерирует АСП1 в течении того же самого времени Т?

Если вдруг ответ утвердительный, мы не сможем расщепить эвристику АСП1 и АСП2 в две независимые функции на языке Си, выполняющиеся последовательно. Очевидно, что микрокоманды можно заменять подпрограммами, но в данном случае такой же трюк с АСП потребует ручного распутывания паутины их одновременных взаимодействий. Вот это действительно может стать практически за пределами возможностей человека. :-)

Дело в том что у каждой микросхемы свой комплект регистров R[42],ST[42],S,S1,L,T,P. Я думаю что первоначально каждая микросхема из комплекта заглатывает из кольца данные к себе в регистры (вероятно регистр R для этого более всего подходит), сомневаюсь что все таки может быть такая ситуация когда две и более микросхемы работают над своими данными, но кто знает - допустим. Как только данные из общего кольца М оказались внутри микросхем комплекта, они не пересекаются, вероятно в это время кольцом М вообще никто не пользуется. Каждый работает над своей порцией данных, потом они так же сливают каждый свою порцию данных в кольцо М. Я не могу сказать сейчас что то более точное, это всего лишь предположения.

Внутри одной микросхемы АСП работают по порядку с одной и той же порцией данных, там тоже свои кольца из регистров R и ST, и само собой что в одной микросхеме АСП1 готовит данные для АСП2, а АСП2 для АСП3. И происходит именно так что АСП1 = АСП2, но такты на которые они наложены разные для АСП1 их гораздо больше. Таким образом АСП2 = АСП1 выполняет только часть работы АСП1. Она частично равна АСП2, при полном совпадении по коду. Как в случае АСП = 4E для первого этапа вычислений инструкция содержит три ASP {4E,4E,20}. Как видите первое и второе совпадают по коду, но различны по эвристике.

Заглянул ещё раз в Трохименко.

В каждой микроЭВМ есть сдвиговый регистр M — они и объединены в системную магистраль, где ещё и отдельные внешние сдвиговые регистры присутствуют. За каждый такт (В1, В2, В3 и В4) регистр M сдвигается на 1 бит. Сейчас не могу сказать точно, на сколько бит сдвинется М за время выполнения АСП, например X (по количеству тактов) — но столько же новых бит войдёт в каждую микроЭВМ.

Каждая микроЭВМ выполняет свои синхропрограммы (АСП) параллельно с другими.

Если за это время выполнения синхропрограммы X бит, результат работы АСП-А одной микроЭВМ-А, не успевают дойти до другой микроЭВМ-Б. Или же входят в неё, но игнорируются выполняющейся там АСП-Б, тогда мы сможем реализовать АСП-А и АСП-Б функциями на языке Си и выполнить их последовательно, одна за другой.

Если же АСП-Б успевает прочитать результат работы АСП-А (которая выполняется одновременно с ней) и отреагировать на этот результат, задача по замене синхропрограмм функциями на языке Си сильно усложняется.

Можно, конечно, не разбирать этот момент заранее и проигнорировать данное соображение. Если АСП-А и АСП-Б не передают данные друг другу, всё получится и так. А если связаны, просто возникнут ошибки. Тогда и разбираться.

Вы написали про разные АСП1 и АСП2 внутри одной микроЭВМ. С этим как раз проблем не возникнет. Они выполняются строго последовательно, как вызов функций на языке Си. Речь о взаимодействии разных микроЭВМ, проводящих вычисления параллельно над различными в любой момент времени (но предположительно пересекающимися за время выполнения синхропрограмм) участками системной магистрали М.

Арви, кольцевые регистры R,ST внутренние не внешние. Даже если микросхема пользуется данными сброшенными в кольцо другой микросхемой комплекта, она синхронизируется по метке старт/стоп кольца и вероятно никогда не станет читать общее кольцо М без четкого понимания адреса чтения (а для этого ей придется прочитать метку синхронизации и пропустить приличное кол-во этапов). Если помните мое последнее исследование, то в нем выяснилось что кольцо М может проходить дробное кол-во раз по кругу, в разных конфигурациях с доп памятью и без. Кроме того даже порядок следования микросхем может быть нарушен и это не ломает работы комплекта. Поэтому думаю мои размышления про синхронизацию в кольце верны. А поскольку синхронизация очень дорогостоящая вещь на нее уходит приличное кол-во этапов - смысл это не имеет, думаю что совместная работа над данными не ведется. Но даже если микросхемы синхронизируются как то иначе это ничего не меняет я не вижу проблем с эвристикой ASP у каждой микросхемы свое ПЗУ и коды ASP могут совпадать, а вот микрокод для них - вряд ли. Короче говоря не вижу проблем в этом, просто получается очень много процедурного кода описывающего ASP. О кол-ве ASP мы тоже пока ничего не знаем - может их десятки, а не сотни.

Я уже "собрал" вчера отладочный комплекс с возможностью проверки работы комплектов между собой - микрокомандный и синхропрограммный с шитым кодом. Пока проверяю работы ИК1302. Разобрал конечно мало 4 разных синхропрограммы. Опять же разобрал не значит осознал, а значит просто перевел в код на Си который на данном этапе генерирует внутреннее состояние ИК1302 совпадающее с микропрограммной ИК1302.
Вижу что процедурный код между одинаковыми по коду ASP разный, так что кол-во вариантов нужно умножать на 3. Если вариантов ASP скажем 100, то процедур может быть 300.

Пока проверяю работы ИК1302. Разобрал конечно мало 4 разных синхропрограммы.

Ого! Не думал, что получится так быстро добиться первого успеха. Мои поздравления. Работа предстоит огромная, но главное начать.

Это часть истории, начавшейся с исследования «электронного океана». Я уже рассказываю про подвиг Феликса Лазарева своим ученикам. Многих вдохновляет.

Опять же разобрал не значит осознал, а значит просто перевел в код на Си который на данном этапе генерирует внутреннее состояние ИК1302 совпадающее с микропрограммной ИК1302.

Осознать это и невозможно. По крайней мере на данном этапе. Когда переведём все АСП и проверим работоспособность. Устраним мусор, проверим работоспособность. Дадим говорящие имена переменным магистрали… вот тогда, возможно, начнёт что-то прорисовываться.

Что «сверхоперативная память» R (42 бит) и ST (42 бит) внутренняя, я знаю. Но кроме них в ИК13 есть ещё отдельный сдвиговый регистр M — «оперативная память» ёмкостью 42×4=168 бит. Он и включён в системную магистраль так, как на вашем рисунке — по крайней мере в ИК13. В подключении к системной магистрали ИК18 (МК-52, возможно МК-61) есть какие-то особенности, в которых я пока не разобрался. Текущий бит сдвигового регистра М может, например, подаваться на вход α сумматора — посмотрите, там есть M среди R, M, ST….

Да, ПЗУ в каждой микроЭВМ свои. В ИК13 их три — память команд (ПК) 256×23 бит, память синхропрограмм (ПСП) 128×3×3×6 бит и микрокоманд (ПМК) 68×28 бит. Набор синхропрограмм действительно придётся алгоритмизировать для каждой микроЭВМ по отдельности. Главное — сохраняйте промежуточные этапы, чтобы всегда можно было локализовать возможные ошибки-опечатки.

Впрочем, если ваш эмулятор позволяет «выключать» процедурный код любой АСП и переводить её на микрокод — промежуточные варианты не обязательны.

Нет Арви, кроссы между двумя комплектами микросхем невозможны, т.е. пока нет возможности переключить АСП-комплект проходящий отладку на исполнение микрокода, он всегда исполненяет синхропрограмму как процедуру. Достаточно сложно перекинуть контекст процедурного АСП-эмулятора в контекст микропрограммного. Микропрограмный контекст расширяется дополнительными переменными. Что бы поменьше возиться с кодом - работаю с версией уже готового микрокодового комплекта msp430 только компилирую ее под ПК. А комплект под msp430 сильно оптимизирован на предвычислениях, поэтому в контексте много несовпадений.

Вы пошли другим путём, но вам видней. Я-то предполагал, что возможно «выключить» микроЭВМ на несколько тактов — подменив эмуляцию микрокода вашей процедурой АСП. И потом в течении всего времени, соответствующего аппаратному исполнению АСП, «вытягивать» в системную магистраль уже просчитанную процедурой часть массива М.

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

Это большой труд, мы все желаем вам успеха.

digitalinvitro wrote: Это все нужно осмыслить систематизировать и только потом переходить к кодированию синхропрограмм в законченные процедуры.

Однако собранный после этого эмулятор надо покрыть тестами, да не простыми а в сравнении с тем что выдает микрокомандная версия. Скажем вычислением CRC всей памяти комплекта после каждого этапа вычисления и сравнения.

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

В самой технологии автоматизированного тестирования нет ничего сложного. Сложность в другом:

  • объем кода тестов будет превышать основной в разы
  • для написания действительно хороших тестов, вскрывающих глубокие изъяны, нужен человек, разбирающийся в предмете не хуже программиста основного кода
  • проблема встраиваемых систем: даже параноидальное тестирование на платформе разработки не дает гарантии при переносе на платформу эксплуатации

Нужен разумный компромис по объему тестов, тут есть небольшая лазейка 560*3 раз за одну команду тестирование будет совершать разные комбинации и вероятность появления ошибки станет гораздо выше. То есть даже очень скромный тест, а вероятно такой возможен в виде одна команда МК61 - один результат для ее проверки, даст огромную статистику по тестированию.

Большинство ошибок в алгоритмизации микрокода будет отлавливаться уже на первом тесте — даже «8 ферзей» избыточен.

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

Как тесты, можно прогнать широко распространённые программы. Главное, чтобы использовались все коды операций, нажимались все клавиши. Если они ошибок не выявят, это будет утка по принципу «выглядит как утка, плавает как утка, крякает как утка». Остальное доберём багрепортами.

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

iPhone? Серьезно?

что тогда это такое http://appcrawlr.com/ios/mk61-lite-programmable-rpn-calc?

Десктоп?

Так ведь я именно десктопную версию Сергея Тарасова взял в разработку!

Арви я понимаю Вашу приверженность МК-161 поскольку Вы его купили, приличные средства я полагаю вложены. Но в старой как мамонт архитектуре 8051 не нахожу ничего привлекательного. Одни пороки - а) восьмибитка, б) бешеное потребление, в) 4 тактовый цикл (система команд явно рожденный CISC) г) ни какой возможности гибко управлять тактированием

msp430 против того что стоит в МК-161 это все равно, что Энергия против Saturn-V. Поверьте просто нет шансов у 8051 против msp430. Все что удалось вытянуть по производительности на msp430 оттолкнувшись от десктопной версии, будет загублено переносом на любую 8-разрядную платформу. Устроит цикл размером в 2 секунды?
Потребление наноамперы в режиме сна (не глубокого!) микроамперы в режиме работы в тупом цикле без отдыха. Устроит потребление в 150-250мА на платформе 8051 находящегося в МК-161, вместо 20-50мА на платформе msp430? Это потребление во время работы на максимальной частоте msp430 равной 25-27МГц.

На фото в заголовке присутствует всем знакомый МК-51, вот в его корпус я и попытаюсь затолкать то что получится, однако элемент питания у МК-51 это CR2032 - емкость 200-240 mA*Ч. Хотелось бы рассчитывать на автономность порядка суток в режиме работы, и недели в режиме средней нагрузки. Даже на msp430, рекордсмене в области потребления среди микроконтроллеров и то сильно сомневаюсь что это удастся (как бы другой элемент ставить не пришлось). А МК-161 высосет эту батарею даже не работая за полчаса-час. Какой в этом смысл?

Приложение MK61+ это калькулятор, совместимый с МК-61 и попытка его расширить. Он не является полным эмулятором со 100% совместимостью, которая есть в вашей разработке — там нет «электронного океана» и всего остального, что нас увлекло. Есть нововведения, которые мало кто принял для себя.

Попробуем решить проблемы в коммуникации, явно существующие. Например, ссылки на МК61+ и другие интересные приложения для iOS я приводил на данном сайте неоднократно. Далее.

1. Я читал вашу статью. Напишу подробней, раз не возникло понимания. Сергей Тарасов написал эмулятор на C++. Вы, из-за ограничений платформы msp430, существенно оптимизировали эмулятор по сравнению с версией на C++. Верно?

Именно про перенос вашей (оптимизированной) версии на десктопы/iOS/МК-161 я и написал. На мой взгляд, версия Арбинады избыточна, требует больших ресурсов. Ваша представляет собой важное развитие темы эмулятора МК-61 и новый state of art.

2. Позвольте мне говорить за себя, как я уважаю вас и позволяю вам отвечать за свои поступки и побуждения.

МК-161 это отечественный калькулятор. Разработанный в России людьми, которые говорят на русском языке, на русском языке пишут к нему документацию. Доведённый здесь до уровня продукта, с учётом возможного выпуска комплектующих в России и Белоруссии — и продающийся здесь, одно время даже на прилавках. Из этого идёт мой приоритет и показатель полноценного развития архитектуры МК-61, а не «приличные средства вложены». Средства можно вкладывать и в другие проекты.

Будет ли налажен в России выпуск msp430, калькуляторов на этой основе — уверенности нет. Моддинг МК-161 кажется хорошим решением. Особенно если для этого будет достаточно просто скачать и залить вашу прошивку. Замечу, что в вашей способности создать 1 экземпляр на msp430 для себя лично я никогда не сомневался.

Ваше сравнение с Энергией и Сатурном-V поддерживаю. К сожалению, обе ракеты сомнительны (есть люди, в них сомневающиеся) и давно не выпускаются (возможно даже утеряны), предлагаю во избежание флейма эти аналогии не развивать. Также согласен, что здесь много технических вызовов. С другой стороны, в МК-161 есть заточенная под МК-61 клавиатура и подходящий индикатор.

Чтобы избежать дальнейшего непонимания — речь идёт о перепрошивке W77LE516P внутри существующих и выпускающихся МК-161, а не попытках установить 8051 в корпус МК-51, которые нынче не выпускается. Не вижу особых преимуществ по потреблению, какую программу исполнять — вашу прошивку с полноценным эмулятором или родную из Новосибирска. Впрочем, я не измерял, насколько отличаются потребление МК-161 в режиме ожидания нажатия клавиши и режиме счёта по программе. Не исследовал, чем это вызвано.

Арви давайте глядеть правде в глазе? Ну вот посмотрите на что похож 8-битник в МК-161. Еще раз повторю что это очень древнее ядро i8051. Но не устраивает оно не по этому, а потому что оно очень-очень медленное. Цитирую

In the W77LE516 each machine cycle is four clock periods long. Each clock period is designated a state. Thus each machine cycle is made up of four states, C1, C2 C3 and C4, in that order.

Как видите вводится понятие машинного цикла. Вы, Арви, наверняка помните наш К580ВМ80, так вот там примерно тоже самое - есть машинный цикл. Это неделимая единица, он не может закончиться раньше. То есть самая быстрая машинная инструкция займет цикл, а самая длинная может и больше, на страницах Даташит на W77LE516P посвященных таймингу инструкций нарисованы осциллограммы на 2-х, 3-х, 4-х и даже 5-и цикловые инструкции для инструкций с операндами. Представим, что все наши команды занимаю два цикла и нам очень повезло. Но цикл - это 4 такта. А значит 8 тактов занимает команда. Команда которая оперирует с 8 битным операндом. Уверяю Вас, Арви, нам не повезет, потому что 256 байт памяти данных нам не хватит, а значит нам нужны будут команды с операндом из двух байт, скорее всего это 3-4 цикловые команды. А это уже от 12 до 16 тактов. На частоте 25МГц.
Максимальное количество тактов msp430 - 6 редко 7, для данных лежащих далеко (за 64К пространством). Однако функционально данная команда выполняет перемещение одного 16 битного слова из памяти в память к примеру mov @R7+, 200(R8)!!!! В случае 8051 понадобится две 2 цикловые команды сначала заглотнуть потом выплюнуть для одного байта, потом для второго.
Минимальное 1 такт. Для доступа к данному, косвенной адресацией - 2 такта. Таким образом W77 в 6-8 раз медленнее msp430.

Что это значит? Для реакции на клавиатуру МК-61 использует два цикла, каждый цикл на msp430 проходит за 0,63 секунды (Арви я старался как мог уменьшить это время и практически исчерпал себя). Таким образом задержка на нажатие кнопки МК61 на msp430 достигает 1,2с! Это очень заметно, я даже как то приводил слова Виталия Самурова, что такая задержка делает калькулятор сильно на любителя. В случае с МК-161 это приведет к задержке в 6 раз большей - 6 секунд. И это очень оптимистичный прогноз!!!

Я понимаю, что Вы хотели с минимальными усилиями использовать элементную базу МК-161. Но база выбрана крайне не удачно. Винбондовский аналог 8051 производить ни в Белоруссии ни в России не станут. Тут уже производят аналоги 8051 на базе Atmel. Мало того любой AVR убивает 8051 и его тоже производят у нас (я говорю про официальные аналоги). Кроме того в России производят чип гораздо более подходящий на роль ядра микрокалькулятора или микроэвм, это ARM Cortex M3 - 1986ВЕ91Т (аналог STM32F103х). Если Вы беспокоитесь за импортозамещение - то тогда предложили бы как базу хотя бы STM32.

МК-161 разработан в России людьми говорящими на русском, уж сколь Вас такая национальная идея влечет. Но Винбонд его "сердце", разработан не в России. Так что тут у техасцев паритет с винбондавцами, для нас они одинаково инородны.
Да программа МК-161 приближающаяся по совместимости к МК-61 безусловно доброе и бодрое изделие, и это на форуме не отрицает никто. Мы уже сорок раз похвалили СЕМИКО и лично Михаил Борисовича. Который в последствии отвернулся от сообщества любителей, увы..такова капиталистическая жизнь, то что не приносит прибыли должно уйти. Придется смириться с тем что прошивку на МК-161 в исходном коде не увидеть. Мало того со слов СЕМИКО она вся на ассемблере, что сузит круг причастных к ее доработке лиц. В основе МК-161 очень хорошая библиотека BCD арифметики, может быть даже замечательная, но что толку если ее исходники нам никогда не будут доступны????

Теперь об оптимизации - не совсем так как Вы пишите. Да взял С++ версию Сергея Тарасова. Вырезал излишества интерфейса, для любого микроконтроллера бесполезные. Потом все это запустил на тесте из 6 действий (6 нажатий кнопок) получил просто дикое время исполнения на частоте 1МГц, а именно в районе двух минут! Понял что надо двигаться, приемами оптимизирующими размещение ресурсов для конкретной аппаратной платформы (msp430) добился порядка 1,2 минут. Разогнал аппаратуру до 25МГц, штатно разогнал конечно, получил - 30 секунд. Теперь в ход пошли алгоритмические ухищрения, шаг за шагом сужал количество кода за один такт ИК130х. До тех пор пока не вышел на показатель 6 с копейками секунд за тест. Если говорить о PC то моя оптимизация для нее бесполезна, я мог сделать даже еще и хуже для конвейрезированного многопоточного суперскаляра. Мало того для STM32 а это ARM я бы оптимизировал совсем по другому, то есть для iOS от моей оптимизации может быть совсем не большой прибыток. Это кстати подтверждается словами Сергея Вакуленко, его 32-разрядный MIPS на частоте 48МГц, работает так же как 16 разрядный msp430 на частоте 25МГц. То есть разрыв по частоте вдвое, плюс по ширине шины еще вдвое, и того в 4 раза. То есть для АРМ мой симулятор будет примерно в 4 раза быстрее. Так для ARM на iOS частота синхронизации чуть ГГц, это же в 40 раз больше 25Мгц.

Мало того вот Вы предлагаете что то писать под винбонд W77. Назовите средства проектирования и отладки под W77, они в свободном доступе? Чем шить? Чем дебажить по JTAG? Куда без этого двигаться?

Если бы не оптимизирующие ресурсы компилятора, если бы не платформа на которой все отлаживалось (а это программные средства - причем совершенно бесплатные для желающих разрабатывать под msp430), то ни о какой скорости говорить бы не пришлось. Можно даже на opensource GCC скомпилировать, будет правда чуть хуже по производительности.

Недостатки W77 есть, согласен. Осуждать их, увы, неконструктивно. То, что сердцем МК-161 выбрана умершая W77 это факт. Который приходится учитывать — получаешь от него удовольствие или нет.

Производить W77 в России не будут, соглашусь. Но код, написанный для W77 можно будет относительно легко адаптировать под отечественные МК51, если вдруг будет решено переводить всё на отечественную элементную базу.

На чём делать альтернативные отечественные ПМК, можно было бы обсудить. Мне нравится вариант с форт-процессором Dophin. Но пока нет ни спонсора, согласного вкладываться в такой проект, ни исполнителя, согласного посвятить годы жизни налаживанию производства в не самой простой стране — это всё забавные, но опять же бессмысленные умственные упражнения. Имеем дело с тем, что есть и выпускается.

Да, для W77 лучше всего писать на ассемблере. Более того, библиотеку BCD-арифметики и многое другое придётся писать практически с нуля. Хотя ссылки на некоторые заготовки в свободном доступе здесь публиковались. К счастью, для проекта МК61 нужны только библиотеки ввода-вывода. Которые создать, разумеется, тоже подвиг.

Инструменты разработчика. Их надо подбирать, конечно. Для МК51 довольно просто нагуглить компиляторы и эмуляторы. Мне для Каллисто на первых порах будет достаточно самодельного форт-ассемблера, написанного на SP-Forth, с постепенным переносом форт-ассемблера МК-51 под Каллисто. К отладке есть разные подходы. Можно использовать JTAG, можно пользоваться эмуляторами. Есть сторонники использования тестовой печати — конечно, это для этапа, когда мы научимся выводить на индикатор МК-161 хотя бы точку.

Обсуждать недостатки аппаратной базы необходимо! Мало того для любителей, а мы любители, нужно аппаратную базу знать от корки до корки и выбирать исходя из нескольких основных позиций:

а) доступность на рынке, на большинстве удобных по доставке до места жительства ресурсах
(он-лайн магазины, aliexpress, e-bay)
б) стоимость, для любителей желающих повторить конструкцию - это непременное условие
в) наличие бесплатных, а желательно открытых для проектирования "софтверных" инструментов (компилятор, отладчик, программатор)
г) наличие дешевых средств для программирования и JTAG отладки

Отечественный производитель выставляет за свои контроллеры такие баснословные деньги, что любителям этого не потянуть, какие бы они патриоты своей страны и своего производителя не были бы. Это странно потому что быть патриотом в области автомобилестроения в нашей стране даже выгодно. Мало того отечественные производители в силу того что откровенно покупают лицензии на топологию и HDL, не выдумывают ничего сами и ПО для разработки в том числе. Они предлагают его брать у тех же IAR, Keil, очень редко Phiton (наш Фитон). Как, Вам, такая ситуация Арви? Возьмете кошерный 8051 от отечественного производителя и накатите на десктоп ПО для разработки от Keil? Или опять таки лицензионный отечественный ARM от Миландра, и опять пойдете за средой к IAR.

Отечественный электронщик любитель (радиолюбитель) с молоком матери всосал не 8051 а Atmel AVR или уж на крайний случай Microchip PIC12/PIC16. Вы будете в одиночестве с желанием что то делать на 8051, ну возможно найдете еще одного мамонта, с форуме Chaos-а, например, там есть люди которые любят 8051. Для Atmel AVR к тому же существуют очень доступные и совершенно дешевые аппаратные средства программирования и даже отладки, и абсолютно бесплатное разностороннее ПО для написания программ.

вот списочек по релевантности

1. AVR
2. STM8
3. MSP430
4. STM32

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

Главное что Вы все время упускаете, время работы в автономном режиме - и тут альтернативы msp430 к сожалению нет и не будет.

Писать на ассемблере. Я ничего не имею против ассемблера, мало того сам очень часто этим балуюсь. Но помните о том, Арви, что кроме Вас это еще кому то нужно и исходные тексты написанные на ассемблере уже никуда кроме как на W77 не смогут быть перенесены. Пока похоже это нужно Вам одному, кроме Вас в пользу варианта перешивки МК-161 никто не высказывался, даже те люди которые его купили.

Другие платформы, я тоже люблю Форт, Арви. Но... К1894 ВГ1Т так называемый Dophin TF16 (технофортовский форт процессор) ни что иное как залитая в ПЛИС прошивка. ПЛИС естественно не наша, как говорят на Wiki атмеловская. Нам никто не мешает разрабатывать свои архитектуры в том числе и Форт-ядра как софтпроцессоры в ПЛИС. Более того это очень интересно, как мне кажется интересней чем писать под существующие платформы. Но только в СССР была собственная специфичная "программируемая" логика - так называемые БМК. А вот Россия только и может что копировать чужие достижения в области CPLD и FPGA и опять таки стоят они баснословно, мало того отстают лет на 10 от того что сейчас называют ширпотребом в ПЛИС. Так что я бы например ушел бы в FPGA и сделал все там, даже микрокомандная версия будет раз в 100 быстрей эмулятора на любой микроконтроллерной платформе. Скорее всего так и будет, потенциал тут не ограничивается ни чем - это может быть некое форт-ядро с ускорителем BCD арифметики.

Арви,если уж говорить о том что компоненты МК-161 могут быть полностью замещены на отечественные то придется признать что такое можно построить только на 1806ВМ2 или Т36ВМ1-2 или на 580ВМ1. Но потреблять это все будет мама не горюй, даже W77 окажется рачительным экономом.

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

И Вашу приверженность к W77 я понимаю, конечно.... но не одобряю. Сколько экземпляров выпустила СЕМИКО? Наверное не больше 100?

Обсуждайте на здоровье. Критикуйте Россию, если нравится. За это в ГУЛАГ, вроде, не сажают. Даже из уст Михаила Борисовича было много критики здесь высказано.

Речь о том, что такой подход неконструктивен. Он может помочь психологически — выпустить пар из котелка. Самобичевание лучше для здоровья, чем например, использовать алкоголь для успокоения разума. Так как действительно позволяет «аппаратную базу изучить от корки до корки».

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

Проблема здесь в другом. Мы привыкли к советскому способу производства, когда конечный продукт продаётся по цене чуть выше стоимости комплектующих. А в буржуазном мире у людей должен быть интерес, чтобы заниматься производством. В США купить айфон по цене $900 и стоимостью комплектухи $300 это нормальное дело. Они рады, что их соотечественник на таких продажах зарабатывает — т.к. верят, что однажды и им самим улыбнётся удача. Что они тоже смогут разбогатеть, продавая собственные изделия по цене в три раза выше себестоимости.

Если осуждать Новосибирск за задранные цены, то у других потенциальных отечественных предпринимателей не возникнет интереса сделать ПМК №2 — на более мощной элементной базе. Так как продавая продукт по советским ценам, а не втридорога, квартиру и автомобиль не купишь, семью содержать не сможешь.

Конструктивный подход к разработке отечественных технологий такой. Если есть желание и возможность начинать собственное производство — да, выбрать лучшее из отечественного, реализовать ПМК на нём, начать его производить и зарабатывать на жизнь таким путём. Как и сделали в Новосибирске, молодцы ребята!

Если производством заниматься желания нет, придётся умерить аппетит. Взять лучшее из того списка с единственным пунктом, который есть. И попытаться выжать максимум из МК-161 на W77, как в своё время мы выжимали максимум из Б3-34. Чем я, собственно, и занимаюсь, уже добившись некоторых успехов.

Теперь об ассемблере. В случае Форта система делится на две части — низкоуровневую и высокоуровневую. Слова низкого уровня (примитивы) действительно пишутся на ассемблере. Но они стандартизированы. Чем дальше от них, тем более переносимыми становятся определения слов. Каллисто 1.0 была вполне успешно написана — хотя за основу брались Форт ИТЭФ и Форт ЕС, которые были написаны на ассемблерах, весьма отличных от входного языка МК-161. Примитивы пришлось писать заново, а высокоуровневая часть во многом совпадает с советскими предшественниками.

Если вернуться к задаче написания эмулятора МК61, то структуры данных эмулятора, основанные на прошивке «Электроники МК-61», могут быть переносимыми. Реализация движка, который их интерпретирует, действительно будет зависеть от камня. Как Феликс опубликовал микрокод, движки появились под разные архитектуры — даже под Андроид! При переходе на следующий уровень и реализации АСП подпрограммами большую роль будет играть псевдокод синхропрограмм и сама архитектура эмулятора, которые также можно будет переносить между камнями.

Если выбираете из того что есть то на e-bay, ali куча программируемых кальков, прекрасной наружности и прекрасных же кишок, стоящих от силы 190 рублей. Вскрываем смотрим что там за база и если там не тараканы залитые черной смолой, то ищем что же за платформа чем ее шить и разрабатывать.

Из чего выбираете из того что есть на отечественном рынке? Арви я пытаюсь Вас понять уже какой пост и какой год и не могу, не могу понять ни вашей мотивации ни ваших убеждений. Потому что они идут в разрез друг с другом.

Все намного проще как я понимаю - у Вас имеется МК-161, ее дизайн далек не то что от iPhone про кторый Вы все время говорите, а даже от тех самых китайских кальков с e-bay и ali. Но он Вас устраивает, потому что в отечестве больше не фига нет. Кишки устраивают по той же причине. Получается так Вы купили грубо говоря платформу для разработки и поскольку она у Вас есть то Вы и будете разрабатывать на ней. Остальные слова - информационный шум. Так ведь есть еще люди купившие МК-161, почему они то не пытаются сделать из нее iPhone?

Вот нас предположим 100 любителей калькуляторов, из них у десятка есть интерес что то делать на столе из комплектухи. Остальные ни в жисть таким заниматься не будут! Если их что то не устраивает они возьмут в руки HP-39g/50g который у них есть. Так вот не про них ведь мы говорим, верно? Мы говорим про тех любителей калькуляторов которые помнят МК-61, МК-52, МК-85, МК-90, МК-95, МК-72 но в силу определенных процессов в нашей стране 25-30 лет назад уже не смогут прикоснуться ни к их рестайлингу, ни к ним самим. Что им остается? А остается им буквально следующие - выискивать удобные корпуса и вкорячивать туда современную начинку. Для чего? Для того что бы на досуге посидеть по вспоминать былые времена, потренировать засохшие мозги, а может быть подключить этот самый калькулятор к своей домашней лаборатории и задействовать его в сугубо практических целях, управления процессами и регистрации данных. Некоторые для этого используют ПЛК, некоторые RPi, а некоторым вот хотелось бы такой экзотики. Речь не идет о производстве, так как конкурировать с МК-61 на рынке современных калькуляторов невозможно и не нужно. Речь идет о каком то любительском сообществе как например zx.pk.ru в котором распространяются неплохие но любительские поделки ну максимум десятками экземпляров (всяческие клоны и реплики ZX-spectrum, Специалиста, 86РК, БК-0010 и т.п.). Если в этих экземплярах применять какие то заранее ущербные технологии - то что показать своим товарищам, бледную немочь?

Если производством заниматься не получается, а ведь не получается, потому как ради 100 потенциальных пользователей нет смысла, то нужно заниматься любительским конструированием РЭА, чем все и занимаются. Если это делать на более менее унифицированной базе, то конструкция пойдет в дело. Для слабо рукастых товарищей, годятся конструкторы от тех кто процесс макетирования завершил и обозначил это готовым устройством на печатной плате с заявленными ИНТЕРЕСНЫМИ характеристиками. Вот как то так.

По поводу ассемблера и Форта. Да существует элементарынй набор слов который организует само форт ядро, и да он выполнен на ассемблере. Но мы говорили не про Форт, а про написании библиотеки для МК-161 для BCD арифметики, а это уже библиотека, а не десяток примитивов Форта и количество кода в библиотеке BCD арифметики на ассемблере превысит 1000. Это будет абсолютно не портируемый код, не то что код комплекта К145 от Феликса Лазарева. Он сначала "взломал" комплект, а потом на С++/С описал его функциональность. И конечно такой эмулятор портировать можно, причем в очень малое время - порядка 2-3 часов. Потому что приходится переписывать с С++ на С++ или с Си на Си. Я бы например даже не понял бы математической идеи заложенной в умножение или деление - если бы читал код на ассемблере 8051. Даже если бы там был комментарий к каждой строке.

В движке МК-61 если говорить о том виде в каком он перенесен в msp430 интерпретации процентов 20%, остальное зашито в код насмерть. При переходе к раскрытию смысла АСП, интерпретации останется 5%, синхропрограммы станут "шитым кодом". Основную часть кода программы будет составлять компилируемый код, если его написать на ассемблере то получите производительности +5% , но переносимость будет 0%. Оно надо?!

у Вас имеется МК-161, ее дизайн далек не то что от iPhone про кторый Вы все время говорите, а даже от тех самых китайских кальков с e-bay и ali. Но он Вас устраивает, потому что в отечестве больше не фига нет.

Всё верно.

Арви я пытаюсь Вас понять уже какой пост и какой год и не могу, не могу понять ни вашей мотивации ни ваших убеждений.

Проблема не в вас.

Главная проблема в том, что своим проектом «IBM PC» фирма «International» Business Machines промыла мозги значительному проценту программистов. В том числе мне пришлось тратить время на выход из этого гипноза — а товарища Степанищева, видимо, спасли его тараканы. В СССР пасть под гипноз IBM было особенно просто, мы привыкли к идеологии об «одном единственно верном пути» и восприняли «международный» путь IBM как единственно возможный. Потом сама же IBM и отказалась от своего проекта, но некоторые фирмы всё ещё лавируют в иллюзии «международности» и не привязанности к государству — кто-то выигрывая, кто-то разоряясь.

Когда туман «IBM PC» рассеялся, оказалось, что МК-161 это лучшее, что есть в России.

iPhone/Mac это лучшее, что есть в Калифорнии, США. Конечно, я воздаю им должное и использую их шедевры для развития отечественных технологий. Всё время, что мы разрушали собственные технологии в пользу «международности» — США руками Apple и под прикрытием шумихи «IBM PC» планомерно строила свои национальные.

Мне хотелось бы, чтобы в России производилась техника лучше МК-161. Но просто так волшебная «рука рынка» её нам с таможни не принесёт, сколько не шуми. Над этим надо работать, организовывать отечественное производство. Возможно, вступать в конкуренцию. Пока кто первым очухался от наркоза, а это произошло в Новосибирске, того и тапки.

Теперь про двоично-десятичную арифметику. Понимаю, что для вас это больная тема. И станет столь же больной для меня, когда кто-нибудь, официально или нет, опубликует ввод-вывод для W77.

Здесь волшебным переносимым «кодом Лазарева» является сама математика. Именно она задаёт интерфейс к вашей библиотеке BCD — которую да, всё время придётся затачивать под камень.

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

Теперь про новый подход к АСП. Здесь переносимой частью будет «эвристика». Возможно, в ассемблерном коде эвристика будет оформлена псевдокодом и размещена в комментариях. Но от этого она не становится менее ценной — именно она позволит переносить новый код эмулятора с платформы на платформу.

Арви к сожалению, Вы не хотите заметить что даже в такой ущербной России как у на с Вами процессы приборостроения таки идут. И Ваше утверждение что в России ничего лучше МК-161 не производится ложно.

Ну например содержимое по вот такой ссылке Российские процессоры для Вас является новостью?

Возьмем Мультиклет (спорная архитектура - да) но нет ни каких препятствий - покупайте разрабатывайте МК-161 на нем https://ldm-systems.ru/catalog/multiclet.

С Эльбрусом как я понимаю при наличии денег тоже особых проблем не будет.

Элвис опять же, доступно.

МК-161 против приведенного выше - это кустарная поделка. Неужели Вы думаете, что МК-161 не возможно повторить самому именно в таком виде в каком она продается? Никто не хотел бы повторять это путь МК-161, все понимают - что это бессмысленно. У СЕМИКО своя ниша http://mk.semico.ru/kpa/kpa.htm, вот это она делает хорошо.

Процессы идут, конечно. И МК-161 тому свидетельство.

За ссылку спасибо. По ней мне интересней всего раздел «Российская архитектура, российская микроархитектура». Из такой комплектухи можно было бы сделать ПМК — но на 22 марта 2017 года сделали только МК-161. Где процессор зарубежный по всем параметрам, кроме «возможно, мы сможем когда-нибудь выпускать что-нибудь вроде этого».

Покупать предложенные процессоры и разрабатывать без возможности производить ПМК это действительно бессмысленно, пустой расход сил. «При наличии денег», как вы правильно написали, можно создать программируемые калькуляторы лучше МК-161. С этим тезисом согласен. Но пока не совпало так, чтобы деньги были у тех, кто способен на такой подвиг.

МК-161 остаётся лучшим (единственным) отечественным ПМК. Чтобы его производить — да, требуется много ухищрений. Не только технических, но и в бизнесе.

Да, других нет. Ценник, правда, далеко за пределами добра и зла. Я свой 161й брал за 4700 рублей, трижды подумав. Но за 14800 рублей...

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Мне был нужен программируемый калькулятор для несложных расчётов и моделирования простеньких схем, а на МК1хх я вышел случайно в поиске индикатора для МК-72. Я свой МК-161 в 2011 также за 4700 покупал при зарплате порядка 12000. Это где-то порядка 40%, мне смартфон дешевле вышел, но аналог от НР на тот момент стоил даже чуть больше денег. Узнай я о МК-161 в 2009, я бы не пощадил и половины моей тогдашней зарплаты. Даже в 2008, я бы затянул ремень, но купил даже МК-152, если бы узнал о нём! Меня подкупила простота программирования несложных задач, графику я даже и не собирался использовать, разве только строка комментариев для подсказок. Осенью 2012 я себе ламповый усилитель собрал, рассчитаный по двум с нуля написанным программам по своим методикам на МК-161, так что он послужил мне по назначению :) Не, у меня было пару откомпилированных программок на QBasic, и даже одна программка на бейсике под форточки, но с появлением калькулятора они потерялись за полной ненадобностью. Сейчас зарплата на заводе порядка 25000 и 14800 это уже почти 75℅, я могу сказать только что мне здорово повезло приобрести его до повышения цен :)
З.Ы. Вообще-то МК-1хх это платформа десятилетней давности, МК-161 это всего лишь немного переработанный МК-152.

Очень хорошо, кстати, переработанный — с учётом отзывов и пожеланий, в том числе участников «Кон-Тики». Меньший корпус, автономное питание и возможность перепрошивки, которую мы так поздно оценили.

10 лет назад просто выпустить калькулятор уже было чудом. Сейчас требования выросли. Аппетит приходит во время еды.

Периодически я проверяю сайт «НПП СЕМИКО» на предмет новых ПМК. Но последняя новость там больше года назад — о том, что из публичного доступа убраны ровно те схемы, которые как раз понадобились для написания любительской прошивки. Вот это они сделали своевременно. :-)

Новая цена запредельная, конечно. Особенно на фоне понижения курса доллара.

Надеюсь, в эту цену включены не только дачи Медведева с уточками и зарплаты «Росгвардии» для борьбы с народом, но и профессиональная разработка ПМК нового поколения. В котором будет то, что я уже реализовал в Каллисто — имена переменных и подпрограмм, «бесконечный» стек данных, структуры управления и т.п.

Советская фирма «Электроника», кстати, анонсировала свои новые модели заранее в журнале «Наука и жизнь». Хотя брала деньги не от покупателей, а из бюджета. И объяснять, почему такие цены, ей требовалось только государственным структурам.

В конце концов все получилось, Феликс порадовал нас кодом МК-61 для PC и iOS,

Для iOS? А где можно скачать эмулятор МК-61 с кодом Феликса?

Магистраль ― это оперативная память МК-61: любая ячейка магистрали посещает все каскадированные в магистраль микросхемы, то есть все шесть микросхем.

Шесть? В статье описывается пять микросхем: три микроЭВМ ИК13 и два регистра ИР2.

Я их уже три нашел :)

Насчет iOS я думаю, Вам, надо самому Феликсу написать поинтересоваться.

У меня предложение - добавлять в конце статьи ссылку на следующую по теме статью. Например, в начале статьи Эмулятор МК-61. Охота в потемках есть ссылка на эту статью. Навигация по сайту будет легче.

---------------------------
Истина где-то рядом
www.litres.ru/vitaliy-samurov/dozvonitsya-do-devy/

Да согласен, навигация по циклу статей - вещь крайне удобная.

Навигация по тэгу "Парк периода ЕГГОГологии" :)