Где найти информацию по форматам хранения образов для эмуляторов?

[Pyk]

*.rk и *.rkp - это просто последовательность байт, записываемых на ленту. Двоичные файлы rkr, rkp, rka имеют вид:
2 байта - начальный адрес (сначала старший (!) байт)
2 байта - конечный адрес (сначала старший байт)
блок данных
00 - 2 байт (в rkp - 1 байт)
E6 - 1 байт
контрольная сумма - 2 байта (сначала старший байт)

[Advertiser]

[jerri]

Pyk, да да как то нетипично для 80х процов

[barsik]

А почему выбрали такой нелогичный и не соответствующий реалу формат?

Второй синхробайт E6 перед контрольной суммой оставили, а первый убрали. Вместо двух нулей перед вторым E6, оставили только один. Если уж убирать нули, то оба. И если оставлять или убирать E6, то тоже оба. И как быть с форматом ОРИОНА. Там аж три синхробайта E6, - перед именем, перед блоком и перед КС. Сколько же из них выкидывать при конверсии в формат аналогичный RK? Впрочем, для ОРИОНА это не требуется, т.к там для хранения укоренился формат ORD, который в расширенном варианте содержит КС и дату файла.

А первый байт E6 в файле нужен, он даёт хоть какую-то защиту для распознования файла и для защиты эмулятора от ввода совершенно случайного файла. Из-за этого, при попытке ввести в эмулятор случайный файл у которого старший байт адреса большой, иногда происходит ввод в верхние адреса, в область ПЗУ и за ней, отчего затирается сам код эмулятора и происходит завис.

Именно так и сделал А.Дёмин в своём формате GAM, который полностью соответствует реалу, так что если сделать программу для PC выводящую содержимое GAM-файла на ленту в двухфазной кодировке, то этот файл можно считать в реальный РК86 или клон, МИКРО-80, СПЕЦИАЛИСТ, ОРИОН и ЮТ-88.

А формат RK не годится для этого.

[b2m]

иногда происходит ввод в верхние адреса, в область ПЗУ и за ней, отчего затирается сам код эмулятора и происходит завис.

У меня никогда не затирается код эмулятора. При вводе в верхние адреса, ВГ75 и ВТ57 могут получить неправильные данные, отчего на экране ничего не будет видно.

[Pyk]

А почему выбрали такой нелогичный и не соответствующий реалу формат?

Почему это он не соответствует реалу?
Перед контрольной суммой и был один синхробайт, я ничего не убирал. Ноль тоже был один. Я ничего не выкидываю и не добавляю ни в случае РК, ни в случае Ориона - на диск пишутся ровно те байты, которые передаются процедуре вывода байта на магнитофон.
Что же касается первого E6 - тут случай спорный. Не пишем же мы ракорд из нулевых байтов перед синхробайтом? Ну так можно этот ведущий синхробайт считать либо частью ракорда, предваряющего полезные данные, либо частью собственно данных. Мне тогда, в 97-м (ух-ты, уже почти 20 лет прошло!), показалось более логичным отнести его к концу ракорда, а не к началу данных, и, соответственно, игнорировать. А может быть, просто подумал, что раз он не несет полезной нагрузки, то и не нужно его писать. Или не захотелось писать отдельный код для обработки этого первого синхробайта - не помню уже. Может быть, и не совсем удачный выбор, но что сделано, то сделано, и проблем особых оно не вызывает. Ну разве что, невозможно файлы вместе с ракордами писать, но оно и не нужно в общем-то...

- - - Добавлено - - -

Небольшое уточнение: один нулевой байт перед контрольной суммой - это в Партнере. В остальных ПК действительно два. Но в любом случае: в файле именно то, что выдает Монитор. Сообщение про формат поправил.

[jerri]

Pyk, почему сначала старший потом младший байт? это же противоречит логике i8080

[DDp]

почему сначала старший потом младший байт? это же противоречит логике i8080

Ответ, возможно, где-то в истории.
По ссылке пример формата на ленте от "Эл.-K1-10" на ВМ80 - двухбайтовые значения также старшим вперёд.

[NEO SPECTRUMAN]

почему сначала старший потом младший байт? это же противоречит логике i8080

а какая в принципе разница?
может не по логике 8080
но зато линейно и по человеческой логике (слева на право)

контрольная сумма - 2 байта

как именно она находится
и в какой последовательности байты?

[jerri]

а какая в принципе разница?
может не по логике 8080
но зато линейно и по человеческой логике (слева на право)

потому что ld hl,(nnnn) берет сначала младший потом старший байт
потому что тип процессора должен на это указывать

а то как хранится слово указывает что для автора ближе серия M68000

как именно она находится
и в какой последовательности байты?

во во тут же возникают странные вопросы
а так такого вопроса даже бы не возникло

[NEO SPECTRUMAN]

потому что ld hl,(nnnn) берет сначала младший потом старший байт
потому что тип процессора должен на это указывать

да какая разница если вводятся\выводятся то они по одному байту

я тоже обычно стараюсь придерживаться правильной последовательности
но если по ошибке выходит обратная я ее никогда не исправляю(про всякие 16 битные таблицы)...

во во тут же возникают странные вопросы
а так такого вопроса даже бы не возникло

да нет
этот вопрос должен возникать постоянно
чтоб неначто с деревянным черенком не наступить стоя по колено в воде