Особенно интересует сейчас .rk .rkp
Особенно интересует сейчас .rk .rkp
http://demin.ws/projects/radio86/emu...os/dox.html#io
и несколько позамороченней формат, но в нем тоже кое что есть
http://www.emu80.org/rss.html
*.rk и *.rkp - это просто последовательность байт, записываемых на ленту. Двоичные файлы rkr, rkp, rka имеют вид:
2 байта - начальный адрес (сначала старший (!) байт)
2 байта - конечный адрес (сначала старший байт)
блок данных
00 - 2 байт (в rkp - 1 байт)
E6 - 1 байт
контрольная сумма - 2 байта (сначала старший байт)
Pyk, да да как то нетипично для 80х процов
А почему выбрали такой нелогичный и не соответствующий реалу формат?
Второй синхробайт E6 перед контрольной суммой оставили, а первый убрали. Вместо двух нулей перед вторым E6, оставили только один. Если уж убирать нули, то оба. И если оставлять или убирать E6, то тоже оба. И как быть с форматом ОРИОНА. Там аж три синхробайта E6, - перед именем, перед блоком и перед КС. Сколько же из них выкидывать при конверсии в формат аналогичный RK? Впрочем, для ОРИОНА это не требуется, т.к там для хранения укоренился формат ORD, который в расширенном варианте содержит КС и дату файла.
А первый байт E6 в файле нужен, он даёт хоть какую-то защиту для распознования файла и для защиты эмулятора от ввода совершенно случайного файла. Из-за этого, при попытке ввести в эмулятор случайный файл у которого старший байт адреса большой, иногда происходит ввод в верхние адреса, в область ПЗУ и за ней, отчего затирается сам код эмулятора и происходит завис.
Именно так и сделал А.Дёмин в своём формате GAM, который полностью соответствует реалу, так что если сделать программу для PC выводящую содержимое GAM-файла на ленту в двухфазной кодировке, то этот файл можно считать в реальный РК86 или клон, МИКРО-80, СПЕЦИАЛИСТ, ОРИОН и ЮТ-88.
А формат RK не годится для этого.
У меня никогда не затирается код эмулятора. При вводе в верхние адреса, ВГ75 и ВТ57 могут получить неправильные данные, отчего на экране ничего не будет видно.Цитата:
Сообщение от barsik
Почему это он не соответствует реалу?Цитата:
Сообщение от barsik
Перед контрольной суммой и был один синхробайт, я ничего не убирал. Ноль тоже был один. Я ничего не выкидываю и не добавляю ни в случае РК, ни в случае Ориона - на диск пишутся ровно те байты, которые передаются процедуре вывода байта на магнитофон.
Что же касается первого E6 - тут случай спорный. Не пишем же мы ракорд из нулевых байтов перед синхробайтом? Ну так можно этот ведущий синхробайт считать либо частью ракорда, предваряющего полезные данные, либо частью собственно данных. Мне тогда, в 97-м (ух-ты, уже почти 20 лет прошло!), показалось более логичным отнести его к концу ракорда, а не к началу данных, и, соответственно, игнорировать. А может быть, просто подумал, что раз он не несет полезной нагрузки, то и не нужно его писать. Или не захотелось писать отдельный код для обработки этого первого синхробайта - не помню уже. Может быть, и не совсем удачный выбор, но что сделано, то сделано, и проблем особых оно не вызывает. Ну разве что, невозможно файлы вместе с ракордами писать, но оно и не нужно в общем-то...
- - - Добавлено - - -
Небольшое уточнение: один нулевой байт перед контрольной суммой - это в Партнере. В остальных ПК действительно два. Но в любом случае: в файле именно то, что выдает Монитор. Сообщение про формат поправил.
Pyk, почему сначала старший потом младший байт? это же противоречит логике i8080
Ответ, возможно, где-то в истории.Цитата:
Сообщение от jerri
По ссылке пример формата на ленте от "Эл.-K1-10" на ВМ80 - двухбайтовые значения также старшим вперёд.
а какая в принципе разница?Цитата:
Сообщение от jerri
может не по логике 8080
но зато линейно и по человеческой логике (слева на право)
как именно она находитсяЦитата:
Сообщение от Pyk
и в какой последовательности байты?
потому что ld hl,(nnnn) берет сначала младший потом старший байтЦитата:
Сообщение от NEO SPECTRUMAN
потому что тип процессора должен на это указывать
а то как хранится слово указывает что для автора ближе серия M68000
во во :) тут же возникают странные вопросыЦитата:
как именно она находится
и в какой последовательности байты?
а так такого вопроса даже бы не возникло
Там странный немного алгоритм подсчета КС. Приведу просто кусок кода, рассчитывающий КС по этому методу:
Ну или смотрите оригинал в Мониторе хотя бы того же РК-86 - точка входа 0F82AH.Код:uint16_t cs = 0;
for (uint16_t i = 0; i < fileSize - 1; i++) {
cs += buf[i];
cs += (buf[i] << 8);
}
cs = (cs & 0xff00) | ((cs + buf[fileSize - 1]) & 0xff);
Последовательность - опять-таки, сначала старший байт.
да какая разница если вводятся\выводятся то они по одному байтуЦитата:
Сообщение от jerri
я тоже обычно стараюсь придерживаться правильной последовательности
но если по ошибке выходит обратная я ее никогда не исправляю(про всякие 16 битные таблицы)...
да нетЦитата:
Сообщение от jerri
этот вопрос должен возникать постоянно
чтоб неначто с деревянным черенком не наступить стоя по колено в воде
В Микроше по-другому считается, и у ЮТ-88 по-своему.
- - - Добавлено - - -
А в Специалисте, если я правильно помню, обратный порядок байт.
так что он не может из коробки загрузить РК-шную прогу???Цитата:
Сообщение от uart
оно ж должно вроде было делаться совместимым
ладно ют88...
NEO SPECTRUMAN, у неё и скорость записи различается, и контрольная сумма без сикхробайта идёт. Ну и сама не совместима, частично в лучшую сторону, частично нет.
Казалось бы, что за прошедшие 20 лет (когда доступны эмуляторы отечественных БК) форматы МГ-файлов для эмуляторов всех типов бытовых ЭВМ давно устоялись. Похоже, что так это есть для ОРИОНА, РК86 и клонов.
Но когда недавно мне понадобилось воспользоваться эмулятором СПЕЦИАЛИСТА, я с удилением обнаружил, что в форматах эмуляторов для СПЕЦИАЛИСТА царит неразбериха и путаница. Увы, могу судить только по двум эмуляторам, EMU от b2m и EMU80 от Pyk.
Как всем известно, на СПЕЦИАЛИСТЕ в первое время использовался МГ-формат волковского монитора, достоинство которого в том, что он грузится не только директивой монитора, но и по сбросу с автостартом. Что очень важно для многоблочных МГ-программ, т.к это заменяет отсутствующий в МГ-формате флаг автостарта (хотя мне известны способы вышибать управление при вводе в любом формате).
Однако формат А.Волкова был неудобен для ориентации в записях на кассетах, т.к не содержит никакой информации об имени файла (отчего это имя приходилось говорить в микрофон). Потому, как только был опубликован орловский монитор, то его формат с именем (по директивам I и O) стал основным форматом применяемым на кассетах СПЕЦИАЛИСТА.
Какие-же форматы имеются для виртуализации МГ-записей СПЕЦИАЛИСТА ?
Оказывается есть только формат RKS, причём это расширение ничего не говорит о МГ-формате файла. Потому что есть файлы в формате волковского монитора (это в дистрибутивах EMU80) и есть файлы в формате орловского монитора (т.е с именем), имеющие то же самое расширение RKS.
Эмулятор EMU от b2m не ориентируется на расширение файла, он работает в реальном времени прогоняя саму программу 8-ми разрядки, вводящую файл. Поэтому ему всё-равно каким расширением пользователь назовёт свои файлы.
Работа в реальном времени это очень большое достоинство эмулятора EMU, потому что это позволяет грузить программы защищённые от копирования МГ-форматом или просто многоблочные программы в обычной двухфазной кодировке. Для правильного ввода важно лишь, чтобы сам пользователь знал в каком формате его файлы и не пытался вводить по директиве I файлы выгруженные по директиве W в формате волковского монитора и наоборот. Причём этот эмулятор также великолепно читает и пишет в формате WAV, хотя и надо знать некоторые нюансы по пользованию эмулятором для ввода программ по сбросу.
Итак, из-за отсутствия двух разных расширений для двух разных форматов, встречаются МГ-файлы с расширением RKS в формате волковского монитора и встречаются МГ-файлы с расширением RKS в формате орловского монитора. Естественно взглянув на первые байты в дампе эти форматы легко различить. Файлы в формате волковского монитора имеют в начале блок адресов, а файлы для орловского монитора имеют в начале 3 байта D9 и затем имя файла длиной до 17-ти байт, после чего идет второй пилотон и далее остальная дребедень.
Т.к эмулятор EMU от b2m не зависит от расширения файла, предлагаю для МГ-формата орловского монитора использовать расширение SPT (ну или любое другое, желательно характерное). От слов Specialist Tape, можно и TSP. Тогда сразу будет ясно, что для ввода такого файла надо использовать директиву I.
В эмуляторе EMU от b2m работа с магнитофоном сделана просто великолепно, сто-процентное качество эмуляции, всё как в реале. Ввод по сбросу делается запуском магнитофона и, как только пошёл пилотон, запуском или директивы 'B', или, если монитор не имеет такой директивы, то запуском по GC000<ВК>. А красная кнопка сброса не срабатывает, т.к по ней ошибочно останавливается магнитофон. Это позволяет программе автоматически запуститься по окончании ввода. А для ввода по сбросу файла в формате WAV надо сначала выбрать отмену, а во-второй раз выбрать файл WAV.
Новое расширение не навредит и эмулятору EMU80, т.к оказывается он вообще не грузит файлы в формате орловского монитора. Он использует файлы в формате волковского монитора и требует расширения RKS (хотя возможно можно загрузить файл в формате орловского монитора в формате WAV, но и это у меня не получилось).
В случае волковского формата расширение RKS абсолютно оправдано, т.к соответствует логике форматов RKR, RKP, RKA, RKV, RKL и других RK?-форматов. К сожалению почему-то оказалось, что в этом эмуляторе не работает процедура ввода по сбросу или я просто не понял как это делается. Похоже, причина в неудачном алгоритме МГ-эмуляции (но зато EMU80 идеально эмулирует дисководы). Об этом напишу в теме EMU80.
Итак, суть поста в том, чтобы уговорить пользователей и авторов эмуляторов использовать два типа файлов для эмулятора - в формате волковского монитора (RKS) и в формате орловского монитора. Как указано выше, для EMU ничего делать не надо, достаточно просто переименовать имеющиеся МГ-файлы, чтобы не было путаницы.
Можно ещё уговорить хранить файлы в разных каталогах. А можно и не уговаривать.Цитата:
Сообщение от barsik
Да, действительно неудобно. Я почему-то раньше не догадался сделать так, чтобы при выборе WAV автоматически отключался перехват.Цитата:
Сообщение от barsik
Теперь, когда выскакивает окно открытия файла, вызванное перехватом процедур чтения/записи байта, можно выбрать wav-файл, и тогда перехват отключится. Кому надо - качайте новую версию.
Есть, правда, пара недостатков:
- при записи wav-файла нужно как и раньше тыкать в кнопку на тулбаре после окончания записи, чтобы остановить запись файла
- некоторые компьютеры имеют отдельные процедуры чтения/записи пилот-тона, обычно они просто пропускаются, если активен перехват, и к сожалению, если отключить перехват в момент открытия файла, то будет уже поздно, так что в этих случаях придётся действовать по старинке: сначала запускать проигрывание wav-файла, а потом давать команду чтения/записи