Submitted by Ajaja on пн, 19/10/2020 - 17:55 Permalink
Хороший вопрос. Но не уверен, что что-то готовое есть.
С этим и в существующих софтовых эмуляторах явная проблема. У эмулятора для андроида свой формат состояния ПМК, у JS-эмулятора свой. Оба нечитабельные и несовместимые друг с другом. Программы еще как-то можно в них в текстовом виде загружать, но не регистры памяти.
Неплохо было бы какой-то универсальный, читабельный (с комментариями и пр.) формат для этого иметь.
Submitted by st on пн, 19/10/2020 - 18:29 Permalink
Для обмена привычнее мнемокод команд МК61, т.е. обычный текст с возможностью добавления комментариев, инициализации регистров и перехода на начало программы (это не всегда В/0, немало программ начинаются с БП хх). Единственная заковыка с кодировками, т.к. русские символы потребуют либо юникод, либо кодовую страницу, но эту информацию легко добавить в заголовок файла.
// Заголовок
ENCODING=Win1251
// Программа: начальный адрес в десятичной системе + команда или список команд через пробелы или табуляции
PROGRAM
00. ИП8
01. П0 ИП0 ИП1 + ИП2 + ИП3 - ИП4
10. - ИП5 - Fx=0 19 ИП7 1 + П7 FL0 03 С/П
22. БП 00
// Инициализация регистров: константа + регистр или список регистров
// Допустимы как русские П0..ПЕ так и латинские R0..RE
REGISTERS
1 П1 П2 П3 П4 П5
0 П7
10 П8
// Стартовый адрес
START=00
Submitted by AtH on пн, 19/10/2020 - 18:35 Permalink
У каждой клавиши есть название. Даже несколько, написанных над ней, под ней или справа. Можно эти названия и использовать, памяти же хватит на все синонимы:
В/О F ПРГ ИП Д F x<0 0 9 В↑ ИП 8 …
Пустое место (пробелы, табуляции, переводы строки, возвраты каретки) отделяют одну клавишу от другой. Как комментарий можно использовать \ и ; — они пропускают текст до конца строки. В конце можно передать «спецклавишу» END , другие «спецклавиши» могут использоваться для возвращения статуса.
Кодировка для отечественных ПМК уже разработана. Вряд ли есть смысл плодить вавилонское нагромождение, лучше использовать имеющуюся. Если есть ненависть к русским буквам, можно использовать латинскую мнемонику, там ASCII и меньше синонимов.
На компьютере программы лучше хранить в стандартном формате MKP, преобразовывая их при передаче в нажатия клавиш. Существуют компиляторы из MKL в MKP. Вроде, даже с открытым исходным текстом.
Submitted by Vitasam on пн, 19/10/2020 - 20:04 Permalink
Использовать надо привычный мнемокод, это однозначно.
Но плодить форматы (MKP, MKT) нет особого желания, формат файлов должен быть один - читабельный человеком и MK61S, то есть текстовый. Можно написать "компилятор" на Питоне, который будет осуществлять конвертации кодировок или пересчет адресов, но формат файлов должен быть один.
Мне пока ближе что-то, похожее на формат HP42S:
00 { 36-Byte Prgm }
01 LBL "PSN" ;
02 MVAR "mu" ; mu = ALPHA down MATH mu
03 MVAR "N" ;
04 VARMENU "PSN" ;
05 STOP ;
06 EXITALL ;
07 RCL "mu" ;
08 ENTER ;
09 +/- ;
10 E^X ;
11 X<>Y ; x=mu y=exp(-mu)
12 RCL "N" ;
13 Y^X ; mu^n
14 LASTX ; n
15 N! ;
16 / ;
17 x ;
18 .END. ;
Добавить только тип кодировки, стартовый адрес, контрольную сумму и содержимое регистров памяти.
МК61S сможет "поглощать" такой формат "нативно" (через терминал или утилиту на Питоне), равно как и выкидывать программу в тот же терминал. В последнем случае пропадут комментарии
Submitted by Vitasam on пн, 19/10/2020 - 20:58 Permalink
А, да, я забыл уже, что MKL это программа в текстовом виде.
Но все-таки я сторонник одного файла - программа, регистры и служебная информация. Все в текстовом виде. Мощи Cortex-M4 микроконтроллера, на котором будет MK61S хватит для обработки "на лету".
Submitted by AtH on чт, 22/10/2020 - 18:40 Permalink
Никто не мешает добавить в MKL псевдокоманды для генерации MKD.
Собственно, отсутствие такой возможности и заставило меня перейти с MK.EXE на SP-Forth в черновиках Каллисто-2 и бета-версии 161eForth. IMHO надо развивать культуру, а не начинать каждый раз с нуля.
Submitted by Vitasam on пт, 23/10/2020 - 09:54 Permalink
MKL выглядит почти так как мы тут обсуждаем (HP42S-подобно), за исключением того, что там метки в тексте, а не адреса. Предполагает создание утилиты-компилятора. Отладка в виде "гляжу в текст программы и на экран МК61S" не очень удобно - в тексте нет адресов.
Метки и компилятор необходимы для 10000 шагов ассемблерных портянок МК161, но надо ли это для ретрокалькулятора в 105 шагов памяти?
.CHARSET 1251
; Файл uskorenie
.ORG 0
A0: ; с адреса 24
K MS->D
M A
0
PP M 9045 ; Размерность аргумента тригонометрических функций (Дополнительные функции)
RM A
F SIN
F X^2
RM 2
*
RM A
2
*
F SIN
F X^2
RM 3
*
-
1
+
RM 1
*
R/S
GOTO A0
.END
Submitted by AtH on пт, 23/10/2020 - 15:16 Permalink
Есть две разные вещи — файл, как программа хранится на диске десктопа, и протокол, по которому эта программа передаётся в ПМК. Файл и протокол могут быть близки друг другу, могут сильно отличаться, но это разные сущности.
Опять же, компилятор из исходного текста (MKL) в код программы (MKP) может быть только на десктопе — так сделано в МК-161. Но можно компилятор прошить и в ПМК. Если в ПМК есть свой компилятор, там же может быть и текстовый редактор.
В минимальном решении исходный код (MKL) хранится только на десктопе, в ПМК же встроен отладчик и усовершенствованный редактор кода программы (MKP) с декомпилятором из кода в мнемонику.
Возможности MKL, конечно, избыточны для МК-61S. Те же макрокоманды графического интерфейса на МК-61S не нужны. Но неплохо, если у простых программ будет единая запись, чтобы их можно было загружать как в МК-61S, так и в МК-161.
Программы, написанные по правилам (например, из справочника Дьяконова), будут работать и там, и там одинаково. Неплохо, когда у них единое представление. Тогда владелец может скачать их исходный код (MKL) и загрузить в свой ПМК, не заботясь о его версии. И небольшие программы тогда тоже можно будет писать и выкладывать для обоих ПМК.
Submitted by A.L. on вт, 17/11/2020 - 20:32 Permalink
В своей реализации скриптового интерпретатора кода МК я организовал работу с метками так:
1. Выделил код 0xFF под идентификатор "метка", за ним один байт - сама метка, итого 256 меток.
2. Если эта пара ("Метка" + идентификатор) встречается в программе автономно без предстоящей команды
перехода - она считается объявлением метки, исполняется как НОП.
3. Если после команды перехода есть пара "Метка- идентификатор" - то ищем метку в коде и переходим на нее. Иначе - переходим по адресу. Например, БП FF MM, где ММ - метка. При такой логике ничего не рушится в области совместимости снизу вверх и метки реализуются безболезненно. Переход на метку может быть выполнен из любой команды перехода, кроме косвенного.
При исполнении программы организована очередь на 16 меток (пара метка - адрес), если метка есть в очереди - то ничего не ищем, сразу переходим, если метки нет - то тогда нужно искать по коду программы с последующим запихиванием ее в очередь.
В принципе, упрощает наброску программы на коленке.
Но без соответствующего расширения для VSCode его не очень удобно было бы использовать. Плюс, для инициализации регистров памяти приходится использовать такие вот подпрограммки как YINI в примере, благо тут память под код программ почти неограничена. Для МК-61S для регистров придется придумывать что-то другое.
Поскольку большинство программ используются в единственном числе в ПМК, то LBL, LEN, CHECKSUM, NOTE можно хранить в отдельной "metadata":
Загрузка из PC через терминал/утилиту обновляет метаданные автоматически. Контрольная сумма вычисляется заново и сравнивается с полученной из метаданных суммой.
Отображение и редактирование на экране ПМК в отдельном режиме (доп.кнопки)
Вывод программы в терминал PC автоматически подставляет метаданные в указанном формате.
"Вертикальный" способ отображения текста программ очень хорошо подходит будущему формату режима PRG в MK61S:
а также удобен для печати на узких ленточных принтерах типа HP82240B, почему бы и не замахнуться на такое? :)
Submitted by Ajaja on вт, 20/10/2020 - 09:33 Permalink
Добавить еще XYZTL, текущий указатель на комманду, положение Р/ГРД/Г,.. что там еще? Все последние блоки сделать необязательными, кроме программы.
Неплохо получилось бы.
Submitted by Vitasam on вт, 20/10/2020 - 10:01 Permalink
XYZTL и Р-ГРД-Г однозначно надо добавить. Текущий указатель (SP) - это для сохранения полного состояния калькулятора?
Да, все блоки, кроме программы, опциональны. При загрузке только программы из PC поля LEN, CHECKSUM обновятся автоматически. При выгрузке в PC все поля создадутся и заполнятся соответственно (в том числе через специальный интерфейс MK61S)
Submitted by AtH on вт, 20/10/2020 - 11:42 Permalink
Почему счётчик адресов это SP?
Для сохранения полного состояния нужно ещё записывать стек возвратов, глубиной 5 вложений. Если у вас тут всё внезапно английское, например так:
RS: 000 000 000 000 000
Submitted by Vitasam on вт, 20/10/2020 - 13:22 Permalink
это все в отдаленное будущее, для начала бы доделать базовый функционал.
Английское потому что в коммуникационных программах обычно все плохо с кириллицей и кодировками (и не только в коммуникационных, а во вполне официальных ПМК-шных утилитах).
Submitted by AtH on ср, 21/10/2020 - 08:15 Permalink
Не разделяю убеждений, что сложности с русским алфавитом осознанно закладывают русофобы из ЦРУ и Пентагона.
Моя основная мысль — ПМК это та область, где мы можем сознательно прокладывать путь для восстановления отечественной индустрии. Без западофобии :-), но с уважением к нашей культуре, нашим предкам. Потом эти наработки могут быть восприняты и в других областях.
Для ПМК уже предложена в Новосибирске хорошая кодовая таблица, где собраны все нужные нам символы. У русских букв есть однозначный 8-битный код, что позволяет проверять правильность их приёма и передачи по 8-битному каналу. Этот код основан на 866 странице, то есть имеется некоторая совместимость и вне мира ПМК.
Куда приятнее посылать MK61S "ИПД", а не "RMD". Это не такая уж сложная техническая задача, но народ оценит. Часть любителей советских ПМК любит и русскую, советскую культуру вообще. Это не только те, кто живут в России и имеют сложности с английским. Я встречал любителей русской культуры и русского языка в Польше и США.
Если есть сомнения по безопасности повторного использования новосибирских разработок, никто не мешает использовать Юникод, 16-битный или UTF-8.
Submitted by Vitasam on ср, 21/10/2020 - 09:06 Permalink
Сложности с русским алфавитом заложились исторически, а не осознанно - кто первый выдал массовую вычислительную технику человечеству, того и кодовая таблица. Я вчера попробовал новосибирскую утилиту для связи с ЭКВМ - как были косяки с русским интерфейсом, так и остались. А уже пятая часть 21го века на дворе
Я тоже за использование русской мнемоники в МК61С (можно ее так называть, от слова СТМ32 :)
Можно, наверное, использовать уникод для хранения текстов программ в файле. А внутри МК61С хранить в 866 таблице, конвертировать самой ПМК на лету. Мощности хватит.
Submitted by AtH on ср, 21/10/2020 - 13:10 Permalink
На новосибирские утилиты у нас сейчас влияния мало. Пусть останутся на их совести. Исправляют баги, уже хорошо.
Поддерживаю идею хранения символов внутри МК61S в cp866, с ПМКшным расширением из ЭКВМ. Также вполне разумно, что на международных устройствах используется Юникод.
Вопрос лишь в том, где граница. Предлагаю рассматривать протокол обмена, как часть MK61S. Тогда внутри самого ПМК всё будет последовательно, а общение с ним предсказуемо. Легче будет соединять этот ПМК с ЭКВМ и другой отечественной техникой, по мере её возникновения. Преобразования из / в Юникод можно осуществлять в коммуникационных программах, возможности десктопа позволяют.
Так сделано в MK.EXE, где псевдокоманда .CHARSET позволяет выбрать, из какой кодировки десктоп будет преобразовывать символьные константы в 866.
Edit. Название MK-61S мне больше нравится. Оно отражает гибридность устройства — советский ПМК поверх STM32. Надеюсь, однажды сможем сделать отечественный ПМК на отечественной комплектухе. Но пока так.
Submitted by Vitasam on ср, 21/10/2020 - 14:01 Permalink
Ага, разумно все перекодировки переложить на сторону PC-шной утилиты. Которая, скорее всего, будет написана на Питоне, как кроссплатформенная и скриптовая.
Submitted by st on вт, 20/10/2020 - 13:27 Permalink
Покомандная запись неудобна для ручной набивки, при этом разбор текста весьма примитивный для обоих случаев. Длину указывать тоже не надо, это источник труднообъяснимых ошибок, просто разбивать на секции
PRG
01. .....
10. ....
При этом построчный формат позволяет записывать и покомандно тоже, 1 команда на строку, а не несколько.
Submitted by Vitasam on вт, 20/10/2020 - 13:30 Permalink
покомандную запись сложно парсить средствами самой MK61S. Если, конечно, найдутся желающие реализовать это в прошивке, я за :) В "черной таблетке" ресурсов хватит
Submitted by Vitasam on вт, 20/10/2020 - 13:45 Permalink
И со стороны человека не все так однозначно (с). Предполагая, что никаких сторонних утилит и компиляторов мы не используем, мне лично проще ввести программу и потом отлаживать ее в самой ПМК (глядя в экран ПМК и в текст), когда она записана в исходном тексте вот так:
Теоретически мы можем выделить еще килобайт, а то и несколько, ОЗУ для хранения комментариев к каждой строке в исходном тексте, и потом, при экспорте программы обратно в PC вписывать их обратно в нужные строки.
Но Гитлаб открыт всем, поэтому все дополнения с радостью принимаются :)
Submitted by st on вт, 20/10/2020 - 18:35 Permalink
Поточному разбору текста все равно что обрабатывать:
00. хх
01. уу
...
или
00. хх уу ...
или даже
00. хх 01. уу ...
в грамматике, где адрес отделены от команды точкой или еще чем-то. Между пробелом, табуляцией и переводом строки в качестве разделителей разницы нет.
Прямо сейчас у меня, к сожалению, нет времени написать такой код, но работы там на один день максимум вместе с тестами. Возможно на выходных попробую хотя бы начать.
Submitted by Vitasam on чт, 22/10/2020 - 16:33 Permalink
Сейчас все в Си, проще было с libopencm3 работать.
Проект под Stm32CubIDE тоже начали в Си, но если удобнее будет, могу переделать проект под плюсы. Мысль была попробовать, вот, причина появилась.
UPDATE: попробовал создать новый проект из старого .ioc файла и создать новый проект с нуля.
Несмотря на выбор C++ как Target Language:
в обоих случаях проект создается в C:
В общем, пока предлагаю ориентироваться на Си, как язык разработки фирмвари MK61S.
UPDATE 2: при помощи лома и ноутбука (с) таки можно заставить проект CubeIDE поддерживать Плюсы - там предлагают не трогать main.c (чтобы кодогенератор не создавала main.c из main.cpp каждый раз), а добавить в main() лишь один вызов - cpp_link(), где весь функционал написан на Плюсах.
Все хидер файлы уже с
#ifdef __cplusplus
extern "C" {
#endif
Так что если на Плюсах удобнее писать, пиши на Плюсах, потом затащим в проект.
Submitted by Vitasam on сб, 24/10/2020 - 23:45 Permalink
Перетащил оболочку MK61S и драйвер дисплея в Плюсы.
Результаты эксперимента (Release билд, оптимизация -Ofast):
1. Скорость "коротких" билетов не изменилась
2. Потребление памяти в Плюсах чуток больше
Думаю, можно все в Плюсы перетаскивать, удобство налицо
Submitted by st on пн, 26/10/2020 - 00:32 Permalink
Хорошая новость, хоть и ожидаемая. На моей памяти Алексей уже пробовал подобное на MSP430, накладные расходы на "плюсы" были на уровне единиц процентов.
Submitted by Vitasam on пн, 26/10/2020 - 09:47 Permalink
Да, вполне ожидаемо.
Единственное - Mk61Emu оставлен в C и вынесен в отдельный каталог Firmware/Mk61sApp/Mk61EmuCore. Предлагаю его оставить Сишным, а в Плюсах делать всю инфраструктуру вокруг.
Я перенес версию с Плюсми в /master, как основную ветку.
Разница в секундах между RUN... и PRG finished: (38094 - 31640) = 6.45
Что дает на "синей таблетке" 6.2x от скорости предка ( Stm32Cube IDE, Release build, Optimization level: "For speed -Ofast" )
Хороший вопрос. Но не уверен,
Permalink
Хороший вопрос. Но не уверен, что что-то готовое есть.
С этим и в существующих софтовых эмуляторах явная проблема. У эмулятора для андроида свой формат состояния ПМК, у JS-эмулятора свой. Оба нечитабельные и несовместимые друг с другом. Программы еще как-то можно в них в текстовом виде загружать, но не регистры памяти.
Неплохо было бы какой-то универсальный, читабельный (с комментариями и пр.) формат для этого иметь.
Мнемокод
Permalink
Для обмена привычнее мнемокод команд МК61, т.е. обычный текст с возможностью добавления комментариев, инициализации регистров и перехода на начало программы (это не всегда В/0, немало программ начинаются с БП хх). Единственная заковыка с кодировками, т.к. русские символы потребуют либо юникод, либо кодовую страницу, но эту информацию легко добавить в заголовок файла.
Пример для "Билетов"
Текстовый протокол
Permalink
У каждой клавиши есть название. Даже несколько, написанных над ней, под ней или справа. Можно эти названия и использовать, памяти же хватит на все синонимы:
Пустое место (пробелы, табуляции, переводы строки, возвраты каретки) отделяют одну клавишу от другой. Как комментарий можно использовать \ и ; — они пропускают текст до конца строки. В конце можно передать «спецклавишу» END , другие «спецклавиши» могут использоваться для возвращения статуса.
Кодировка для отечественных ПМК уже разработана. Вряд ли есть смысл плодить вавилонское нагромождение, лучше использовать имеющуюся. Если есть ненависть к русским буквам, можно использовать латинскую мнемонику, там ASCII и меньше синонимов.
На компьютере программы лучше хранить в стандартном формате MKP, преобразовывая их при передаче в нажатия клавиш. Существуют компиляторы из MKL в MKP. Вроде, даже с открытым исходным текстом.
Один формат файлов
Permalink
Использовать надо привычный мнемокод, это однозначно.
Но плодить форматы (MKP, MKT) нет особого желания, формат файлов должен быть один - читабельный человеком и MK61S, то есть текстовый. Можно написать "компилятор" на Питоне, который будет осуществлять конвертации кодировок или пересчет адресов, но формат файлов должен быть один.
Мне пока ближе что-то, похожее на формат HP42S:
00 { 36-Byte Prgm } 01 LBL "PSN" ; 02 MVAR "mu" ; mu = ALPHA down MATH mu 03 MVAR "N" ; 04 VARMENU "PSN" ; 05 STOP ; 06 EXITALL ; 07 RCL "mu" ; 08 ENTER ; 09 +/- ; 10 E^X ; 11 X<>Y ; x=mu y=exp(-mu) 12 RCL "N" ; 13 Y^X ; mu^n 14 LASTX ; n 15 N! ; 16 / ; 17 x ; 18 .END. ;Добавить только тип кодировки, стартовый адрес, контрольную сумму и содержимое регистров памяти.
МК61S сможет "поглощать" такой формат "нативно" (через терминал или утилиту на Питоне), равно как и выкидывать программу в тот же терминал. В последнем случае пропадут комментарии
Плодить форматы
Permalink
Никаких MKT в МК61S не потребуется, так как в нём нет области текста.
Есть стандарт MKP для откомпилированной программы и MKL для исходного текста. Максимум, если потребуется, можно добавить MKD для сохранения регистров.
А, да, я забыл уже
Permalink
А, да, я забыл уже, что MKL это программа в текстовом виде.
Но все-таки я сторонник одного файла - программа, регистры и служебная информация. Все в текстовом виде. Мощи Cortex-M4 микроконтроллера, на котором будет MK61S хватит для обработки "на лету".
Расширим MKL?
Permalink
Никто не мешает добавить в MKL псевдокоманды для генерации MKD.
Собственно, отсутствие такой возможности и заставило меня перейти с MK.EXE на SP-Forth в черновиках Каллисто-2 и бета-версии 161eForth. IMHO надо развивать культуру, а не начинать каждый раз с нуля.
MKL
Permalink
MKL выглядит почти так как мы тут обсуждаем (HP42S-подобно), за исключением того, что там метки в тексте, а не адреса. Предполагает создание утилиты-компилятора. Отладка в виде "гляжу в текст программы и на экран МК61S" не очень удобно - в тексте нет адресов.
Метки и компилятор необходимы для 10000 шагов ассемблерных портянок МК161, но надо ли это для ретрокалькулятора в 105 шагов памяти?
Файл и протокол
Permalink
Есть две разные вещи — файл, как программа хранится на диске десктопа, и протокол, по которому эта программа передаётся в ПМК. Файл и протокол могут быть близки друг другу, могут сильно отличаться, но это разные сущности.
Опять же, компилятор из исходного текста (MKL) в код программы (MKP) может быть только на десктопе — так сделано в МК-161. Но можно компилятор прошить и в ПМК. Если в ПМК есть свой компилятор, там же может быть и текстовый редактор.
В минимальном решении исходный код (MKL) хранится только на десктопе, в ПМК же встроен отладчик и усовершенствованный редактор кода программы (MKP) с декомпилятором из кода в мнемонику.
Возможности MKL, конечно, избыточны для МК-61S. Те же макрокоманды графического интерфейса на МК-61S не нужны. Но неплохо, если у простых программ будет единая запись, чтобы их можно было загружать как в МК-61S, так и в МК-161.
Программы, написанные по правилам (например, из справочника Дьяконова), будут работать и там, и там одинаково. Неплохо, когда у них единое представление. Тогда владелец может скачать их исходный код (MKL) и загрузить в свой ПМК, не заботясь о его версии. И небольшие программы тогда тоже можно будет писать и выкладывать для обоих ПМК.
По поводу меток.
Permalink
В своей реализации скриптового интерпретатора кода МК я организовал работу с метками так:
1. Выделил код 0xFF под идентификатор "метка", за ним один байт - сама метка, итого 256 меток.
2. Если эта пара ("Метка" + идентификатор) встречается в программе автономно без предстоящей команды
перехода - она считается объявлением метки, исполняется как НОП.
3. Если после команды перехода есть пара "Метка- идентификатор" - то ищем метку в коде и переходим на нее. Иначе - переходим по адресу. Например, БП FF MM, где ММ - метка. При такой логике ничего не рушится в области совместимости снизу вверх и метки реализуются безболезненно. Переход на метку может быть выполнен из любой команды перехода, кроме косвенного.
При исполнении программы организована очередь на 16 меток (пара метка - адрес), если метка есть в очереди - то ничего не ищем, сразу переходим, если метки нет - то тогда нужно искать по коду программы с последующим запихиванием ее в очередь.
В принципе, упрощает наброску программы на коленке.
www.avl.by
Мне тоже такой формат
Permalink
Мне тоже такой формат программ для HP-42S нравится. Я в нем программы для free42 и храню, примерно в таком виде:
00 { 90-Byte Prgm } // Папа, мама, я и микрокалькулятор. Финк Л.М. Парусная регата 01 LBL "YAHT" 02 STO 04 // 00.П4 03 0 // 01.0 04 STO 12 // 02.ПC 05 STO 13 // 03.ПD 06 LBL 04 07 RCL 05 // 04.ИП5 08 STOP // 05.С/П 09 STO 05 // 06.П5 10 COS // 07.Fcos 11 RCL ST X // 08.В^ 12 SQRT // 09.FКвКор 13 STO 06 // 10.П6 14 × // 11.x 15 1 // 12.1 16 + // 13.+ 17 STO 07 // 14.П7 18 RCL 04 // 15.ИП4 19 RCL 05 // 16.ИП5 20 + // 17.+ 21 COS // 18.Fcos 22 RCL 06 // 19.ИП6 23 × // 20.x 24 RCL 00 // 21.ИП0 25 × // 22.x 26 RCL 07 // 23.ИП7 27 ÷ // 24.: 28 5 // 25.5 29 × // 26.x 30 STO 08 // 27.П8 31 RCL 04 // 28.ИП4 32 SIN // 29.Fsin 33 × // 30.x 34 STO 10 // 31.ПA 35 RCL 12 // 32.ИПC 36 + // 33.+ 37 RCL 02 // 34.ИП2 38 + // 35.+ 39 STO 02 // 36.П2 40 STOP // 37.С/П 41 RCL 10 // 38.ИПA 42 STO 12 // 39.ПC 43 RCL 08 // 40.ИП8 44 RCL 04 // 41.ИП4 45 COS // 42.Fcos 46 × // 43.x 47 STO 11 // 44.ПB 48 RCL 13 // 45.ИПD 49 + // 46.+ 50 RCL 03 // 47.ИП3 51 + // 48.+ 52 STO 03 // 49.П3 53 STOP // 50.С/П 54 RCL 11 // 51.ИПB 55 STO 13 // 52.ПD 56 RCL 04 // 53.ИП4 57 STOP // 54.С/П 58 STO 04 // 55.П4 59 GTO 04 // 56.БП 57.04 60 END 61 LBL "YINI" 62 0 63 STO 02 // x 64 STO 03 // y 65 10 66 STO 00 // v 67 ENDНо без соответствующего расширения для VSCode его не очень удобно было бы использовать. Плюс, для инициализации регистров памяти приходится использовать такие вот подпрограммки как YINI в примере, благо тут память под код программ почти неограничена. Для МК-61S для регистров придется придумывать что-то другое.
Как-нибудь так?
Permalink
Поскольку большинство программ используются в единственном числе в ПМК, то LBL, LEN, CHECKSUM, NOTE можно хранить в отдельной "metadata":
"Вертикальный" способ отображения текста программ очень хорошо подходит будущему формату режима PRG в MK61S:
а также удобен для печати на узких ленточных принтерах типа HP82240B, почему бы и не замахнуться на такое? :)
Добавить еще XYZTL, текущий
Permalink
Добавить еще XYZTL, текущий указатель на комманду, положение Р/ГРД/Г,.. что там еще? Все последние блоки сделать необязательными, кроме программы.
Неплохо получилось бы.
XYZTL и Р-ГРД-Г
Permalink
XYZTL и Р-ГРД-Г однозначно надо добавить. Текущий указатель (SP) - это для сохранения полного состояния калькулятора?
Да, все блоки, кроме программы, опциональны. При загрузке только программы из PC поля LEN, CHECKSUM обновятся автоматически. При выгрузке в PC все поля создадутся и заполнятся соответственно (в том числе через специальный интерфейс MK61S)
Полное состояние
Permalink
Почему счётчик адресов это SP?
Для сохранения полного состояния нужно ещё записывать стек возвратов, глубиной 5 вложений. Если у вас тут всё внезапно английское, например так:
RS: 000 000 000 000 000
Отдаленное будущее
Permalink
это все в отдаленное будущее, для начала бы доделать базовый функционал.
Английское потому что в коммуникационных программах обычно все плохо с кириллицей и кодировками (и не только в коммуникационных, а во вполне официальных ПМК-шных утилитах).
Русский алфавит
Permalink
Не разделяю убеждений, что сложности с русским алфавитом осознанно закладывают русофобы из ЦРУ и Пентагона.
Моя основная мысль — ПМК это та область, где мы можем сознательно прокладывать путь для восстановления отечественной индустрии. Без западофобии :-), но с уважением к нашей культуре, нашим предкам. Потом эти наработки могут быть восприняты и в других областях.
Для ПМК уже предложена в Новосибирске хорошая кодовая таблица, где собраны все нужные нам символы. У русских букв есть однозначный 8-битный код, что позволяет проверять правильность их приёма и передачи по 8-битному каналу. Этот код основан на 866 странице, то есть имеется некоторая совместимость и вне мира ПМК.
Куда приятнее посылать MK61S "ИПД", а не "RMD". Это не такая уж сложная техническая задача, но народ оценит. Часть любителей советских ПМК любит и русскую, советскую культуру вообще. Это не только те, кто живут в России и имеют сложности с английским. Я встречал любителей русской культуры и русского языка в Польше и США.
Если есть сомнения по безопасности повторного использования новосибирских разработок, никто не мешает использовать Юникод, 16-битный или UTF-8.
Сложности с русским алфавитом
Permalink
Сложности с русским алфавитом заложились исторически, а не осознанно - кто первый выдал массовую вычислительную технику человечеству, того и кодовая таблица. Я вчера попробовал новосибирскую утилиту для связи с ЭКВМ - как были косяки с русским интерфейсом, так и остались. А уже пятая часть 21го века на дворе
Я тоже за использование русской мнемоники в МК61С (можно ее так называть, от слова СТМ32 :)
Можно, наверное, использовать уникод для хранения текстов программ в файле. А внутри МК61С хранить в 866 таблице, конвертировать самой ПМК на лету. Мощности хватит.
Кодировка
Permalink
На новосибирские утилиты у нас сейчас влияния мало. Пусть останутся на их совести. Исправляют баги, уже хорошо.
Поддерживаю идею хранения символов внутри МК61S в cp866, с ПМКшным расширением из ЭКВМ. Также вполне разумно, что на международных устройствах используется Юникод.
Вопрос лишь в том, где граница. Предлагаю рассматривать протокол обмена, как часть MK61S. Тогда внутри самого ПМК всё будет последовательно, а общение с ним предсказуемо. Легче будет соединять этот ПМК с ЭКВМ и другой отечественной техникой, по мере её возникновения. Преобразования из / в Юникод можно осуществлять в коммуникационных программах, возможности десктопа позволяют.
Так сделано в MK.EXE, где псевдокоманда .CHARSET позволяет выбрать, из какой кодировки десктоп будет преобразовывать символьные константы в 866.
Edit. Название MK-61S мне больше нравится. Оно отражает гибридность устройства — советский ПМК поверх STM32. Надеюсь, однажды сможем сделать отечественный ПМК на отечественной комплектухе. Но пока так.
Кодировка + протокол
Permalink
Ага, разумно все перекодировки переложить на сторону PC-шной утилиты. Которая, скорее всего, будет написана на Питоне, как кроссплатформенная и скриптовая.
Если у уважаемого st получился написать протокол парсера, можно будет сразу попробовать добавить такую перекодировку в будущую утилиту.
А я пока начинаю писать драйвер МК52й "железной" клавиатуры с дополнительными кнопками.
Покомандная запись
Permalink
Покомандная запись неудобна для ручной набивки, при этом разбор текста весьма примитивный для обоих случаев. Длину указывать тоже не надо, это источник труднообъяснимых ошибок, просто разбивать на секции
При этом построчный формат позволяет записывать и покомандно тоже, 1 команда на строку, а не несколько.
это да, но (+)
Permalink
покомандную запись сложно парсить средствами самой MK61S. Если, конечно, найдутся желающие реализовать это в прошивке, я за :) В "черной таблетке" ресурсов хватит
Там регулярная
Permalink
Там регулярная грамматика, все делается за один проход посимвольно без возвратов и вроде даже без lookahead-ов.
Со стороны человека
Permalink
И со стороны человека не все так однозначно (с). Предполагая, что никаких сторонних утилит и компиляторов мы не используем, мне лично проще ввести программу и потом отлаживать ее в самой ПМК (глядя в экран ПМК и в текст), когда она записана в исходном тексте вот так:
чем когда вот так:
Теоретически мы можем выделить еще килобайт, а то и несколько, ОЗУ для хранения комментариев к каждой строке в исходном тексте, и потом, при экспорте программы обратно в PC вписывать их обратно в нужные строки.
Но Гитлаб открыт всем, поэтому все дополнения с радостью принимаются :)
Поточный разбор
Permalink
Поточному разбору текста все равно что обрабатывать:
или
или даже
в грамматике, где адрес отделены от команды точкой или еще чем-то. Между пробелом, табуляцией и переводом строки в качестве разделителей разницы нет.
Прямо сейчас у меня, к сожалению, нет времени написать такой код, но работы там на один день максимум вместе с тестами. Возможно на выходных попробую хотя бы начать.
Было бы здорово
Permalink
Если получится, можно сразу интегрировать в MK61S, UART уже работает полностью
У тебя Си
Permalink
У тебя чистый Си или можно с плюсами?
Сейчас все в Си
Permalink
Сейчас все в Си, проще было с libopencm3 работать.
Проект под Stm32CubIDE тоже начали в Си, но если удобнее будет, могу переделать проект под плюсы. Мысль была попробовать, вот, причина появилась.
UPDATE: попробовал создать новый проект из старого .ioc файла и создать новый проект с нуля.
Несмотря на выбор C++ как Target Language:
в обоих случаях проект создается в C:
В общем, пока предлагаю ориентироваться на Си, как язык разработки фирмвари MK61S.
UPDATE 2: при помощи лома и ноутбука (с) таки можно заставить проект CubeIDE поддерживать Плюсы - там предлагают не трогать main.c (чтобы кодогенератор не создавала main.c из main.cpp каждый раз), а добавить в main() лишь один вызов - cpp_link(), где весь функционал написан на Плюсах.
Все хидер файлы уже с
#ifdef __cplusplus extern "C" { #endifТак что если на Плюсах удобнее писать, пиши на Плюсах, потом затащим в проект.
Оболочка MK61S и ЖКИ драйвер в C++
Permalink
Перетащил оболочку MK61S и драйвер дисплея в Плюсы.
Результаты эксперимента (Release билд, оптимизация -Ofast):
1. Скорость "коротких" билетов не изменилась
2. Потребление памяти в Плюсах чуток больше
Думаю, можно все в Плюсы перетаскивать, удобство налицо
Хорошая новость
Permalink
Хорошая новость, хоть и ожидаемая. На моей памяти Алексей уже пробовал подобное на MSP430, накладные расходы на "плюсы" были на уровне единиц процентов.
Плюсы
Permalink
Да, вполне ожидаемо.
Единственное - Mk61Emu оставлен в C и вынесен в отдельный каталог Firmware/Mk61sApp/Mk61EmuCore. Предлагаю его оставить Сишным, а в Плюсах делать всю инфраструктуру вокруг.
Я перенес версию с Плюсми в /master, как основную ветку.
Последний код: 6.2х от скорости предка
Permalink
Последний код в /master Гитлаба.
Сеанс программирования MK61S "короткими билетами" через UART:
Разница в секундах между RUN... и PRG finished: (38094 - 31640) = 6.45
Что дает на "синей таблетке" 6.2x от скорости предка ( Stm32Cube IDE, Release build, Optimization level: "For speed -Ofast" )
Лог программирования "коротких билетов"
Permalink
Лог программирования "коротких билетов", FW v.0.6.6 (Debug build):