ПК Лик: Формат записи на лету

[CityAceE]

Формат записи Лика на ленту следующий:

https://pic.maxiol.com/images2/1702454272.780858384.image20231213105734.png

Все цифровые значения в таблице приведены в шестнадцатеричном виде.

В файлах RKS опущен первый синхробайт E6, то есть RKS начинаются сразу с адресов начала и конца буфера имени 70 8F 82 8F.

Имя файла должно быть в кодировке КОИ-7 Н2 и иметь максимальную длину 15 символов. Всё, что меньше, дополняется нулями. Имя файла может быть и пустым, то есть 16 нулей.

Контрольная сумма на Python вычисляется следующим образом:



cs = 0
for i in range(start, length):
cs += data[i]
cs += (data[i] << 8)
cs &= 0xffff




Контрольная сумма от игр для Лика, зачастую не бьёт с расчётной. Думаю, что там либо другой диапазон считается (но я проверял с разными диапазонами и подогнать под сумму у меня не получилось), либо используется немного другой алгоритм расчёта. Точнее может подсказать анализ ПЗУ от Лика. А может быть кто-то уже и так знает в чём там дело?
Добрался до анализа расчёта контрольной суммы на Лике. Суть та же, что и в стандартном Мониторе, кроме завершения процедуры. И для закрепления полученных знаний написал скрипт перевода файлов из формата Лик в стандартный формат, хотя по сути расчёт контрольной суммы для Лика там и не требуется. А вот точно потребуется он для обратного перевода. Такой скрипт тоже в планах, так как хочу на своём Лике с его родным ПЗУ позапускать некоторые вещи. А пока к первому сообщению, чтобы не потерялся, прикладываю скрипт lik2spec.py.


А какие на специалисте использовались обычно клавиши чтобы начать игру?
Да всё стандартно там. Чаще всего это клавиши курсора и пробел.

[CityAceE]

Сделал я обратный конвертор, то есть из формата стандратного монитора Специалиста в Ликовский. Для проверки загрузки начал переставлять родные ПЗУ-шки в Лик, и понял, что не помню где какая стояла. Но методом тыка подобрал верную последовательность. И тут выяснилось, что у меня микросхемы на трёх местах не читаются. По диапазону D800-DFFF читаются 0xFF, а по E000-E7FF и E800-EFFF - 0x82 (то есть пустота). То есть оправдались мои худшие ожидания: когда я выкорчёвывал переделки под SP-580, я перепиленные дороги не соединил, так как, видимо, решил, что раз первые две микросхемы работали как надо, то и ладно. В итоге нашёл всё, что я там нарезал и восстановил. Теперь все 6 микросхем ПЗУ определяются и работают. И вот я, наконец, начал загружать первую программу. Из Загрузчика (то есть по Сбросу) ничего так и не получилось. Получилось по директиве I. И вот тут я столкнулся с тем, что моя версия ПЗУ считает контрольные суммы ровно так же, как их считает стандартный Монитор. И загруженная программа с "другой" КС ругается на ошибку:

https://pic.maxiol.com/thumbs2/1701871955.780858384.photo20231206171155.jpg (https://pic.maxiol.com/?v=1701871955.780858384.photo20231206171155.jpg&dp=2)

Я, конечно, записал в WAV все 12 Кб моего ПЗУ. Но теперь не знаю, чем его распознать и преобразовать в BIN. Такая утилита мне также понадобится, когда дойдёт дело до оцифровки моих кассет, когда я их найду. Я ведь даже уже и магнитофон себе купил под это дело Panasonic RQ-2102:
https://images-cdn.ubuy.co.in/647862549a49f46c374f3386-rq2102.jpg

[CityAceE]

И загруженная программа с "другой" КС ругается на ошибку:
Хм... Загадка природы. Нашёл свои пометки в руководстве пользователя:
https://pic.maxiol.com/thumbs2/1701873722.780858384.photo20231206174013.jpg (https://pic.maxiol.com/?v=1701873722.780858384.photo20231206174013.jpg&dp=2)
Я своей же рукой записывал контрольную сумму для этих Шахмат, как F850, на которую теперь этот же компьютер ругается. Что за ерунда?

[svofski]

Но теперь не знаю, чем его распознать и преобразовать в BIN.
Что будет если вав затащить в Тапира (https://caglrc.cc/tapir/) ?

[CityAceE]

Что будет если вав затащить в Тапира ?
Затаскивал, конечно. Лишь какой-то небольшой кусок из центра распознаёт.

[CityAceE]

https://pic.maxiol.com/thumbs2/1701871955.780858384.photo20231206171155.jpg (https://pic.maxiol.com/?v=1701871955.780858384.photo20231206171155.jpg&dp=2)

0000 - это начальный адрес
60FF - это конечный адрес
2D50 - это считанная КС
F850 - это вычисленная КС

Но вся суть в том, что в RKS как раз и прописана F850, а не 2D50. Я проверил на ещё нескольких файлах. Он считывает с ленты КС, делает над числом ещё какое-то действие и уже потом сравнивает с вычисленной суммой. Что ж буду копать дальше.

[svofski]

Затаскивал, конечно. Лишь какой-то небольшой кусок из центра распознаёт.

Понятно. Я со Специалистовскими вавами вообще его не испытывал. Спасибо!

[HardWareMan]

Я своей же рукой записывал контрольную сумму для этих Шахмат, как F850, на которую теперь этот же компьютер ругается. Что за ерунда?
Т.е., битое ОЗУ тут не берётся во внимание?

[CityAceE]

Т.е., битое ОЗУ тут не берётся во внимание?
Скорее всего нет, потому что если потом подать команду подсчитать КС, то она будет в точности совпадать с прописанной в файле. Но при этом то, что считывается из файла не соответствует тому, что в нём прописано.

Но я всё-таки прогнал все тесты Рюмика. Тесты ошибок не выявили.

[CityAceE]

Понятно. Я со Специалистовскими вавами вообще его не испытывал. Спасибо!
Перезаписал WAV ещё раз, понизив уровень записи, а заодно и сделав его моно. И в Тапире в режиме RAW всё отлично распозналось! В других форматах он ошибочно первые байты заголовка файла Лика воспринимает, как адреса загрузки и поэтому остаток файла не распознаёт. Но в RAW я вижу все данные, которые мне нужны 100%. Спасибо!

И вот похоже, что HardWareMan всё таки прав насчёт памяти. В отгрузке пишется именно та сумма, которую и я рассчитываю. Emu80 в режиме Лика тоже и WAV, и RKS загружает без ошибок КС. И ПЗУ я сравнил, они отличаются только фильтром цифровых клавиш с нажатым НР. Хотя кроме памяти ещё могу грешить на RKM Player, с помощью которого я скармливаю моему Лику RKS-файлы. Возможно, это он неправильную сумму подкидывает вместо записанной. Уже завтра оцифрую сигнал с этого проигрывателя и посмотрю что он там передаёт в качестве КС.

[CityAceE]

В общем, найден источник проблем. Это RKM Player. Он распознаёт формат Лика, как "Spec-mon". При этом ему не нравятся контрольные суммы, которые рассчитывает Лик.

https://pic.maxiol.com/thumbs2/1701931868.780858384.screenshot202312070.png (https://pic.maxiol.com/?v=1701931868.780858384.screenshot202312070.png&dp=2)

Ну и при воспроизведении он подставляет сумму, которую он считает корректной. В итоге Лик при загрузке ругается:

https://pic.maxiol.com/thumbs2/1701932258.780858384.photo20231207095546.jpg (https://pic.maxiol.com/?v=1701932258.780858384.photo20231207095546.jpg&dp=2)

Исходный воспроизводимый файл выглядит так:

https://pic.maxiol.com/thumbs2/1701932456.780858384.20231207100001.png (https://pic.maxiol.com/?v=1701932456.780858384.20231207100001.png&dp=2)

Далее я оцифровываю то, что воспроизводит RMK Player, подкидываю в Tapir и вижу следующее:

https://pic.maxiol.com/thumbs2/1701932675.780858384.20231207100237.png (https://pic.maxiol.com/?v=1701932675.780858384.20231207100237.png&dp=2)

Помимо того, что RKM Player добавил имя, взяв его из имени файла, он ещё и контрольную сумму поменял.

В первом сообщении расписал формат Лика записи на ленту.

[b2m]

Байты 70 8F 82 8F это вроде бы не сигнатура, а начало и конец блока, куда считывается имя и КС. Итого 13h байт. А BC это не синхробайт, а на мой взгляд тип данных, в данном случае Byte Code. Надо бы проанализировать другие типы файлов...

[CityAceE]

b2m, спасибо за уточнение!

[CityAceE]

Поэкспериментировал и выяснил следующее:


Байты 70 8F 82 8F это вроде бы не сигнатура, а начало и конец блока, куда считывается имя и КС. Итого 13h байт.
По адресам 8F70-8F7F действительно хранится имя, которое задаётся с клавиатуры вместе с директивой I. Формат имени 15 символов + 0. При попытке указать в директиве I имя 16 и более символов получаем ошибку. Я пробовал изменять эти адреса в файле и даже вручную забивал по новым адресам имя для поиска в процессе загрузки, но это ни на что не повлияло.
Адреса 8F80-8F82 вообще никак не затрагиваются.
По адресам 8F83-8F99 с ленты загружаются первые 23 байта, начиная с 70 7F 82 7F и заканчивая контрольной суммой.


А BC это не синхробайт, а на мой взгляд тип данных, в данном случае Byte Code.
Пока озаглавил в таблице, как "Тип данных", но на самом деле на Лике кодовый блок можно отгрузить только одним способом. И по этому адресу всегда находится байт BC. Я пробовал отгрузить программу на BASIC, но там формат вообще другой на выходе.

Очевидно, что этот байт, что незадействованные 3 ячейки 8F80-8F82 - это рудимент при адаптации монитора с другой платформы.


Надо бы проанализировать другие типы файлов...
Я других типов для Лика не нашёл. Отгрузить как-то иначе с самого Лика тоже не получилось.

[CityAceE]

Занимаясь проверкой программ со Специалиста на своём Лике я испытал неудобство из-за отличия форматов. Собственно, эта тема и является результатом таких проверок. И вот если один-два файла по-быстрому руками ещё можно откорректировать, но далее это уже превращается в настоящий геморрой. А каких-то инструментов для автоматизации этого процесса нет. Наверное, каждый сам для себя пишет подобные утилиты. Вот и я в итоге решил упростить себе жизнь и написал программу на Python.

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

Подробнее про имена файлов. RKS для Лика содержат внутри себя имя файла, которое при загрузке в компьютер по директиве I обязательно нужно указывать. По умолчанию имя берётся из недр входного RKS, если это RKS с заголовком, то есть который загружается в Специалист с помощью директивы I Монитора. Если это безымянный файл, то имя формируется из имени входного файла. Так как у Специалиста и, соответственно, у Лика используется кодировка КОИ7Н2, где отсутствуют строчные буквы, то все строчные русские буквы преобразуются в заглавные. Но и с латинскими не всё так просто. Так как русские буквы в КОИ7Н2 хранятся на месте строчный латинских, то иногда при перегоне русское имя теряется и остаётся на латинице. Например, файл udaw.rks - это почти со 100%-но вероятностью УДАВ.rks. В общем, исходя из этого, мой скрипт при преобразовании имени оставляет латинские буквы только, если они заглавные. Все остальные буквы преобразуются по тем или иным правилам в заглавные русские. Но и это ещё не всё! На оригинальной прошивке Лика в Мониторе невозможно набрать некоторые символы: Пробел, !, ", #, $, %, &, ', (, ), <, _. А так как при загрузке файла нужно в обязательном порядке в директиве I указать имя загружаемого файла, то если в имени будет любой из этих символов, то загрузить этот файл не получится, так как не получится набрать его имя. Сюда же попадает и запятая (,), так как она является сепаратором для команд Монитора. Все эти символы заменяются в имени на звёздочку (*).

Ну а теперь про сам скрипт. Вызывается он просто:


python file2lik.py filename


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

Дополнительно обрабатываются следующий ключи:

-n NAME или --name NAME: Если вам хочется принудительно задать какое-то своё имя, то этот параметр для вас. А если в качестве NAME указать NoName (в любом регистре), то в RKS запишется пустое имя и тогда этот RKS будет загружаться в компьютер не зависимо от того, какое имя было указано в директиве I.

-s START или --start START: По умолчанию адрес загрузки берётся из файла RKS, или в случае преобразования бинарного файла подставляется нулевой адрес. С помощью этого ключа вы можете задать свой адрес. Указывать стартовый адрес можно в десятеричном виде, либо в шестнадцатеричном формате с префикосом 0x, например 0x100.

-w или --wave: Если указать этот ключ, то помимо RKS дополнительно будет сформирован и сохранён WAV для загрузки в реальный компьютер. WAV имеет следующие характеристика: 8-бит, моно, 22 кГц. Этого достаточно для загрузки в настоящий компьютер. Я проверял, у меня всё загружается.

-v VOLUME или --volume VOLUME: Можно увеличить или наоборот уменьшить громкость в получаемом WAV. По умолчанию задана громкость 96. Но она может варьировать от 0 (полная тишина) до 127 (полная громкость).

-c CONSTANT или --constant CONSTANT: Это константа скорости записи. По умолчанию эта константа равна 8. Но её можно уменьшить, и тогда скорость будет выше, либо увеличить для замедления. Эмулятор Emu80 загружает файлы, созданные с константами от 8 до 11. На реальном компьютере я тестов не проводил. Но со значением по умолчанию мой Лик файлы загружает без проблем.

- h: вывод краткой справки по использованию скрипта и его ключам

Скрипт писался под себя, и я не заморачивался, чтобы сделать полную отказоустойчивость. Не подсовывайте ему всякую ерунду и не вводите левые значения в качестве параметров, и всё будет хорошо. Я вроде проверил все возможные сценарии, но не исключаю, что где-то что-то не учёл и возможен вылет с ошибкой. Если вдруг вы столкнётесь с какой-то ошибкой (Хотя кого я обманываю? Никто даже не будет пытаться запускать этот скрипт! :) ), то пишите - я поправлю.