Спецификация формата .SNV (SNap for View)

[Dexus]

Почему бы вместо бинарных блобов не хранить хекс строки по например 64 символа (32 байта) и вообще все в текстовом виде? В принципе ширину любую можно, игнорируя при чтении перевод строк. Всего в 2 раза больше бинарника размером получится, красиво и наглядно, и редактируемо и просматриваемо в любом текстовом редакторе, в случае чего. Кроме того, само название формата “SNap for View” намекает на легкую просматриваемость, что больше соответствует текстовому виду.
А hex-view для просмотра это совсем не view.
Формат нужен текстовый. Interchangeable. Ну или не понятно зачем вообще эту тему затевать, выводя в общественность, если он все равно будет очередным 101м стандартом, который кроме своего эмулятора нигде не будет работать.

[Spectramine]

Почему бы вместо бинарных блобов не хранить хекс строки по например 64 символа (32 байта) и вообще все в текстовом виде? В принципе ширину любую можно, игнорируя при чтении перевод строк. Всего в 2 раза больше бинарника размером получится, красиво и наглядно, и редактируемо и просматриваемо в любом текстовом редакторе, в случае чего.

Чтобы было красиво и наглядно, надо не в два а в 3 раза больше места, потому что хекс-значения, не разделенные пробелом, малочитабельны. А точнее в 4 раза, потому что на каждый байт нужно ведь ещё вывести его представление в ASCII, дабы достичь той же функциональности просмотра. Плюс, чтобы находить адреса ячеек, надо в начале каждой строки выводить их, а это в целом ещё + 8 байт на строку.
Далее, такой файл конечно можно будет открыть любым текстовым редактором, но вот дизассемблировать его уже будет слегка проблематично, равно как и просматривать его графику и т.п. Равно как и редактировать - как вы собираетесь редактировать текстовый файл, в котором присутствует два значения для каждого байта (хекс и аски)?

Кроме того, само название формата “SNap for View” намекает на легкую просматриваемость, что больше соответствует текстовому виду.
А hex-view для просмотра это совсем не view.

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

Формат нужен текстовый. Interchangeable. Ну или не понятно зачем вообще эту тему затевать, выводя в общественность, если он все равно будет очередным 101м стандартом, который кроме своего эмулятора нигде не будет работать.

Текстовый формат будет настолько же интерчанжабл, насколько и бинарный, поскольку чтобы он был интерчанжабл, его всё равно надо поддерживать в других эмуляторах. Все его преимущества - что его можно будет смотреть в текстовом редакторе вместо хекс-вьювера. Но, как я уже сказал, человек, нуждающийся в просмотре файла в хекс-виде, скорее всего имеет под рукой хекс-вьювер.

[Dexus]

Ок. Делайте свой формат который кроме этого эмулятора нигде не будет использоваться.

Добавлю только одно, что в хекс редакторе переставить страницы местами, или просто дополнить какими-то чанками (блоками бинарников) вы не сможете. В отличие от текстового файла.

[Spectramine]

Ок. Делайте свой формат который кроме этого эмулятора нигде не будет использоваться.

Добавлю только одно, что в хекс редакторе переставить страницы местами, или просто дополнить какими-то чанками (блоками бинарников) вы не сможете. В отличие от текстового файла.

Ну как раз мой формат позволяет очень легко переставлять страницы местами, если бы вы вникли, вы бы знали. И почему нельзя в хекс-редакторе дополнить блоками бинарников? Это зависит от его функциональности, есть ли в нем работа с блоками или нет. А дополнять текстовый файл бинарным блоком может быть очень нетривиальной задачей - вам нужно сначала какой-то тулзой сконвертировать бинарный блок в текстовый хекс-вид, а потом вставить его в текстовый файл - это легко сделать, если блок выровнен по границам хекс-строк, а если нет? К тому же придется возиться с адресами в начале строк - тулза должна быть умной и подставлять правильные адреса при конверсии, иначе кто знает, что там распарсит эмулятор при чтении такого текстового файла.

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

Интересно, почему вы думаете, что текстовый формат внезапно стал бы использоваться в других эмуляторах?) На текущий момент распространенных текстовых форматов снапшотов нет, и наверно не потому, что эта идея никому не приходила в голову.

[Dexus]

Наверное потому что такова традиция эмуляторописателей - делать свои форматы (самое простое - бинарный, тк не надо кодировать/декодировать строки), и забивать на всех остальных болт.

Редактируя бинарник хекседитом нужно понимать всю внутреннюю структуру, где заголовки чанков где длины (которые нужно сообразно править), а если там ещё и таблицы смещений до чанков (каталог типа) то вообще гаси свет.

В текстовом же просто нашёл нужную секцию по ctrl+f, и скопипастил там что надо или подредактировал значения.

У вас видимо какая-то профдеформация на почве хекс едиторов, которые стоЯт отнюдь не у всех, и вообще на самом деле мало у кого, и стОят они денег (если не ломанное что-то).

[Lethargeek]

Зачем?

чтобы разница понятнее и нагляднее

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

хекс едиторов, которые стоЯт отнюдь не у всех, и вообще на самом деле мало у кого, и стОят они денег (если не ломанное что-то)

ВНЕЗАПНО: https://hexed.it

[Spectramine]

Наверное потому что такова традиция эмуляторописателей - делать свои форматы (самое простое - бинарный, тк не надо кодировать/декодировать строки), и забивать на всех остальных болт.

Для всех остальных есть такая вещь, как дизассемблирование в текстовый файл с разметкой кода. Это намного удобнее, информативнее и модифицируемее, чем любые текстовые снапшоты с хекс-инфой.

Редактируя бинарник хекседитом нужно понимать всю внутреннюю структуру, где заголовки чанков где длины (которые нужно сообразно править), а если там ещё и таблицы смещений до чанков (каталог типа) то вообще гаси свет.

Вот именно поэтому и был разработан этот формат, в котором нет ни чанков, ни заголовков, ни длин, ни таблиц смещений. Есть сплошной массив содержимого памяти, строка номеров страниц памяти, и несколько строк остальной информации с фиксированными смещениями от конца файла.

В текстовом же просто нашёл нужную секцию по ctrl+f, и скопипастил там что надо или подредактировал значения.

А не получится просто скопипастить - надо ещё потом ручками править адреса будет, в отличие от хекс-редактора. И значения редактировать получится, только если инфа в текстовом файле хранится либо в хекс, либо в ascii виде - иначе парсер не будет знать, какое из значений читать в память.

У вас видимо какая-то профдеформация на почве хекс едиторов, которые стоЯт отнюдь не у всех, и вообще на самом деле мало у кого, и стОят они денег (если не ломанное что-то).

Так отнюдь не все и занимаются просмотром и редактированием снапшотов) а те, кто занимается, в состоянии найти себе бесплатный хекс-редактор.


Вот интересно, много ли вы занимались просмотром/исследованием/редактированием снапшотов, что вам не хватало возможности сохранить их в текстовый файл и наслаждаться потом? Насколько умозрительны ваши соображения?

Вот @Lethargeek перелопатил кучу игр для их раскраски под ULAX. Но почему-то при этом у него не возникла простая и понятная идея - написать сохранение состояния в текстовый файл, в котором так удобно потом всё смотреть и редактировать. Правда, надо ещё написать загрузку таких файлов, но это тоже не слишком сложная задача.

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

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

чтобы разница понятнее и нагляднее

Те, кто ранее открывал снапшоты в хекс-вьювере, и так представляют себе разницу, а остальные разницы не оценят.

[Dexus]

> Вот @Lethargeek перелопатил кучу игр для их раскраски под ULAX.
Ну вот примерно про такое я и говорю (профдеформацию), когда вместо кучи иероглифов и закорючек (хексов) уже начинаешь видеть блондинку, брюнетку...

> Есть сплошной массив содержимого памяти, строка номеров страниц памяти, и несколько строк остальной информации с фиксированными смещениями от конца файла.

Очень мило. А если мне надо переместить кусок данных на 300 байт вперед? Границ-то нету, добавил даже один байт вначале и привет, нужно смотреть что куда сместилось. Чанки в этом смысле лучше. Но хуже в другом - нужно "длины" корректировать, чтобы они все не поехали. И для таких ситуаций, когда нужна куча разнородных и необязательных данных, которые можно просмотреть глазками и поискать "проблему", и придумали текстовые форматы (xml/json-derived), как например тот же docx (который очевидно прогрессивнее бинарного .doc). Для эмулятора с 1050 вариантов конфигураций подобный подход к сохранению файла состояния (снапшота) очевидно более универсален и удобен, чем бинарник, да еще и без чанков.

К тому же, есть прекрасная встроенная возможность для всяких обратных-прямых совместимостей между версиями, и вариантами наполнения.

[Spectramine]

> Вот @Lethargeek перелопатил кучу игр для их раскраски под ULAX.
Ну вот примерно про такое я и говорю (профдеформацию), когда вместо кучи иероглифов и закорючек (хексов) уже начинаешь видеть блондинку, брюнетку...

Ну так а вы же предлагаете те же хексы, но в текстовом формате))

> Есть сплошной массив содержимого памяти, строка номеров страниц памяти, и несколько строк остальной информации с фиксированными смещениями от конца файла.

Очень мило. А если мне надо переместить кусок данных на 300 байт вперед? Границ-то нету, добавил даже один байт вначале и привет, нужно смотреть что куда сместилось. Чанки в этом смысле лучше. Но хуже в другом - нужно "длины" корректировать, чтобы они все не поехали. И для таких ситуаций, когда нужна куча разнородных и необязательных данных, которые можно просмотреть глазками и поискать "проблему", и придумали текстовые форматы (xml/json-derived), как например тот же docx (который очевидно прогрессивнее бинарного .doc). Для эмулятора с 1050 вариантов конфигураций подобный подход к сохранению файла состояния (снапшота) очевидно более универсален и удобен, чем бинарник, да еще и без чанков.

К тому же, есть прекрасная встроенная возможность для всяких обратных-прямых совместимостей между версиями, и вариантами наполнения.

Видимо вы умозрительно переносите свой профессиональный опыт на узкую хобби задачу . Переместить любой кусок данных на любое количество байт в хекс-редакторе, имеющем функции работы с блоками, не проблема. То, что там может что-то там сместиться - так оно точно также сместится, если вы сделаете это же, но внутри текстового файла.

Здесь нет кучи разнородных и необязательных данных - здесть есть однородное байтовое содержимое памяти, незачем огород городить с текстовым форматом. Плюс некоторое число полей, описывающих состояние Z80 и системы, с которыми иметь дело вне эмулятора приходится намного реже. Вот они в текстовом формате выглядят приличнее и понятнее - но ради редкой необходимости их посмотреть-отредактировать нерационально завязываться с текстовым форматом. Достаточно привязать их к удобным смещениям в бинарнике.

Чтобы появилась куча разнородных данных, которые можно посмотреть глазками и поискать проблему - есть разметка кода и текстовый дизассемблер, вот в нем можно делать что хочешь, и удобно редактировать, и адреса автоматически корректируются при ассемблировании.

А текстовый формат снапшота ничего не даст, кроме того, что поля состояния системы будут выглядеть читаемее и модифицироваться легче - но не ради них это всё затевалось в основном, а ради содержимого памяти, которое в текстовом формате и редактировать сложнее (потому что адреса строк надо править), и занимает в 5 раз больше памяти, и плюс легко накосячить с синтаксисом, когда после нескольких правок файл внезапно станет непринимаемым эмулятором из-за потери скобки или запятой.