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

[Shiny]

Назвать такой снэпшот ANS (реверсное SNA)

Неудачный выбор: .ans относится к ansii-art и к направлению textmode scene.

[Advertiser]

[ZXMAK]

ну SNV тоже относится к Data files containing Single Nucleotide Variations (SNV).
Так можно на любое сочетание трех букв найти уже используемый формат

[Spectramine]

можно просто оставить sna формат как есть, просто записывать вначале банки памяти, а потом блок регистров, который искать относительно конца файла. Назвать такой снэпшот ANS (реверсное SNA), чтобы подчеркнуть что данные в нем сохранены наоборот. Тогда смещение банок памяти в снэпшоте будет начинаться с нуля

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

[Lethargeek]

ну SNV тоже относится к Data files containing Single Nucleotide Variations (SNV).
Так можно на любое сочетание трех букв найти уже используемый формат

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

[ZXMAK]

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

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

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

чтото типа такого:

<xml>
    <state_z80>
        <regs af="#0044" bc="#2000" de="#4000" hl="#0000" />
        <regs ix="#4000" iy="#0000" ir="#1234" pc="#0038" sp="#2000" wz="#0000" />
        <regs af_="#0044" bc_="#2000" de_="#4000" hl_="#0000" />
        <regs im="2" lastei="0" fx="0" ex="0" />
    </state_z80>        

    <state_ay>
        <config frequency="1773800" mix="abc" volume="80" />
        <regs r0="#00" r1="#00" r2="#00" r3="#00" r4="#00" r5="#00" r6="#00" r7="#00" />
        <regs r8="#00" r9="#00" ra="#00" rb="#00" rc="#00" rd="#00" re="#00" rf="#00" />
    </state_ay>
    
    <ram_page id="0">
        <row offset="#0000" value="000102030405060708090a0b0c0d0e0f" />
        <row offset="#0010" value="000102030405060708090a0b0c0d0e0f" />
        <row offset="#0020" value="000102030405060708090a0b0c0d0e0f" />
        <!--...-->
    </ram_page>

    <ram_page id="1">
        <row offset="#0000" value="000102030405060708090a0b0c0d0e0f" />
        <row offset="#0010" value="000102030405060708090a0b0c0d0e0f" />
        <row offset="#0020" value="000102030405060708090a0b0c0d0e0f" />
        <!--...-->        
    </ram_page>

    <!--...-->        
</xml>

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

аналогично можно сделать в json формате, он занимает меньше места, но как показала практика хуже подходит для сложных структур, т.к. в таких структурах у json хуже читабельность и легче наделать ошибок в структуре. json более удобен для простых структур типа пар (key,value)

[Shiny]

в бинаре копаться удобнее, чем тут - придется парсить.

[ZXMAK]

в бинаре копаться удобнее, чем тут - придется парсить.

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

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

Например, в zxmak2 конфигурация матрицы клавиатуры спектрума задается в xml конфиге, вот как он выглядит в geany - все раскрашено и хорошо видно:

[Dexus]

В бинаре перед хекс строкой есть один только плюс. Это строковая форма. В хекс строках такое не найдешь и не исправишь.
Но остальное - одни "не плюсы". Метки, комментарии, структуры - не сохранишь. Что-то типа сейвстейта как в IDA разве что городить - гибридно, текстовые данные + фалы блобов (причем с отсылками с текстовой к блобам, таким образом и ромы сохранять нестандартные можно, и содержимое General Sound, если нужно) Запакованное в zip (то есть паковать больше и не нужно).
Но я бы вместо xml предпочел бы yaml. Больше на конфиг похоже, и без тэгов закрывающих, ненужных.

[Shiny]

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

Начнем с того, что я знаю, где и что находится.

[ZXMAK]

Начнем с того, что я знаю, где и что находится.

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