Особенно интересует сейчас .rk .rkp
Особенно интересует сейчас .rk .rkp
С уважением,
Jerri / Red Triangle.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
http://demin.ws/projects/radio86/emu...os/dox.html#io
и несколько позамороченней формат, но в нем тоже кое что есть
http://www.emu80.org/rss.html
Последний раз редактировалось zebest; 06.03.2017 в 19:46.
Profi v3.2 -=- Speccy2010,r2
*.rk и *.rkp - это просто последовательность байт, записываемых на ленту. Двоичные файлы rkr, rkp, rka имеют вид:
2 байта - начальный адрес (сначала старший (!) байт)
2 байта - конечный адрес (сначала старший байт)
блок данных
00 - 2 байт (в rkp - 1 байт)
E6 - 1 байт
контрольная сумма - 2 байта (сначала старший байт)
Последний раз редактировалось Pyk; 09.03.2017 в 22:29.
Pyk, да да как то нетипично для 80х процов
С уважением,
Jerri / Red Triangle.
А почему выбрали такой нелогичный и не соответствующий реалу формат?
Второй синхробайт E6 перед контрольной суммой оставили, а первый убрали. Вместо двух нулей перед вторым E6, оставили только один. Если уж убирать нули, то оба. И если оставлять или убирать E6, то тоже оба. И как быть с форматом ОРИОНА. Там аж три синхробайта E6, - перед именем, перед блоком и перед КС. Сколько же из них выкидывать при конверсии в формат аналогичный RK? Впрочем, для ОРИОНА это не требуется, т.к там для хранения укоренился формат ORD, который в расширенном варианте содержит КС и дату файла.
А первый байт E6 в файле нужен, он даёт хоть какую-то защиту для распознования файла и для защиты эмулятора от ввода совершенно случайного файла. Из-за этого, при попытке ввести в эмулятор случайный файл у которого старший байт адреса большой, иногда происходит ввод в верхние адреса, в область ПЗУ и за ней, отчего затирается сам код эмулятора и происходит завис.
Именно так и сделал А.Дёмин в своём формате GAM, который полностью соответствует реалу, так что если сделать программу для PC выводящую содержимое GAM-файла на ленту в двухфазной кодировке, то этот файл можно считать в реальный РК86 или клон, МИКРО-80, СПЕЦИАЛИСТ, ОРИОН и ЮТ-88.
А формат RK не годится для этого.
Последний раз редактировалось barsik; 06.03.2017 в 21:49.
Почему это он не соответствует реалу?
Перед контрольной суммой и был один синхробайт, я ничего не убирал. Ноль тоже был один. Я ничего не выкидываю и не добавляю ни в случае РК, ни в случае Ориона - на диск пишутся ровно те байты, которые передаются процедуре вывода байта на магнитофон.
Что же касается первого E6 - тут случай спорный. Не пишем же мы ракорд из нулевых байтов перед синхробайтом? Ну так можно этот ведущий синхробайт считать либо частью ракорда, предваряющего полезные данные, либо частью собственно данных. Мне тогда, в 97-м (ух-ты, уже почти 20 лет прошло!), показалось более логичным отнести его к концу ракорда, а не к началу данных, и, соответственно, игнорировать. А может быть, просто подумал, что раз он не несет полезной нагрузки, то и не нужно его писать. Или не захотелось писать отдельный код для обработки этого первого синхробайта - не помню уже. Может быть, и не совсем удачный выбор, но что сделано, то сделано, и проблем особых оно не вызывает. Ну разве что, невозможно файлы вместе с ракордами писать, но оно и не нужно в общем-то...
- - - Добавлено - - -
Небольшое уточнение: один нулевой байт перед контрольной суммой - это в Партнере. В остальных ПК действительно два. Но в любом случае: в файле именно то, что выдает Монитор. Сообщение про формат поправил.
Pyk, почему сначала старший потом младший байт? это же противоречит логике i8080
С уважением,
Jerri / Red Triangle.
Ответ, возможно, где-то в истории.
По ссылке пример формата на ленте от "Эл.-K1-10" на ВМ80 - двухбайтовые значения также старшим вперёд.
D356 47C0 35F8 F55E 8A52 A88F F3F8 B003 03EB 3D7F
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)