Просмотр полной версии : Спецификация формата .SNV (SNap for View)
Spectramine
06.08.2023, 17:20
Текущая спецификация формата .snv. (Формат разработан на основе идеи Lethargeek об удобном для просмотра и модификации формате состояния компьютера ZX Spectrum)
С самого начала файла сохраняется содержимое страниц памяти, без какого-либо сжатия. Есть два размера страницы памяти - 16384 и 8192, размер страницы специфицируется в битовом поле конфигурации системы далее.
Порядок сохраняемых страниц указывается в списке номеров страниц, расположенных сразу после содержимого последней сохраненной в файле страницы, количество сохраняемых страниц сохраняется в конце файла в дескрипторе. Таким образом, начало списка номеров страниц выравнивается по началу сегмента файла длиной, равной длине страницы (удобно найти в шестнадцатеричном просмотрщике).
Номера страниц в списке обычно однобайтовые, но могут быть двухбайтовыми, если необходимо адресовать более 128 страниц ОЗУ или ПЗУ. Старший бит номера страницы - 0 - ОЗУ, 1 - ПЗУ. Номера страниц 0..7 ОЗУ соответствуют нумерации страниц 128кб Спектрума. Номера страниц ПЗУ должны быть специфицированы дополнительно, включая страницы ПЗУ периферии. Длина номера страницы в списке специфицируется соответствующим битом поля конфигурации далее.
В конце файла идет постфикс-блок (хвост, описатель) с остальной информацией снапшота. Все поля постфикс-блока имеют фиксированное смещение от конца файла - таким образом, перейдя на конец файла в хекс-вьювере, мы можем легко прочитать нужные данные по фиксированным смещениям. Все поля длиной больше одного байта записывются в формате big-endian (старшие байты в начале поля, младшие в конце), для удобства просмотра в хекс-вьювере.
В первоначальной спецификации описаны 4 16-байтовых строк описателя. Порядок полей описан слева направо, как они будут выглядеть в хекс-вьювере, т.е. последнее поле имеет самое меньшее смещение от конца файла.
1я строка с конца файла:
регистры Z80 PC,SP,IX,IY,IR,MemPtr(WZ);
последний вывод в вспомогательный порт конфигурации (#1FFD +3 и Скорпиона, #EFF7 для Пентагона 1024, #FF для таймекс моделей)
последний вывод в основной порт конфигурации (#7FFD для 128х моделей, #F4 для Таймекс-моделей)
байт инфы по прерываниям и флагов состояния системы (предпоследний байт файла):
7й бит: 0 - последней была выполнена команда по адресу PC-1, 1 - в остальных случаях (после переходов и длинных команд), нужен для определения флагов временного запрета прерываний и состояния Halted процессора: после команды EI и префиксов #DD/#FD прерывания запрещены, если PC не выставлен на данный адрес после команды перехода или длинной команды. Аналогично после команды HALT процессор находится в состоянии Halted, если PC не выставлен на данный адрес после команды перехода или длинной команды;
5й бит IFF2,
4й - IFF1,
1й-0й биты - режим прерываний. Пока содержимое 6го, 3-го и 2го бита не специфицировано, они должны быть нулевыми. Данные номера битов выбраны исходя из удобства чтения в хекс-файле.
(Снэпшот должен сохраняться после подтверждения прерывания, если оно должно было быть после последней выполненной команды Z80, поэтому нет необходимости хранить флаг временного запрета прерывания после команды EI или индексных префиксов).
код модели ZX Spectrum или его клона (последний байт файла).
2я строка с конца файла - регистры Z80 AF,BC,DE,HL,AF',BC',DE',HL' (самые значимые регистры по краям и в центре строки хекс-вьювера);
3я строка с конца файла:
общее количество сохраненных в файле страниц памяти (2 байта).
турбо-множитель стандартной частоты Z80 для турбо режимов (1 байт)
последний вывод в порт #FE
Битовое поле флагов конфигурации системы (4 байта).
Флаги поля конфигурации, заданные на данный момент:
snv8kbPages = $80000000 - если не 0, длина страницы 8кб
snvLongPageNumber = $40000000 - если не 0, длина номеров страниц 2 байта
snvLateTimings = $00000001 - поздние тайминги
snvCMOSZ80 = $00000002 - CMOS z80
snvIssue2 = $00000004 - Issue 2 48кб модели
snvMainAYpresent = $00000008 - наличие стандартного AY (Дидактик Мелодик для 48кб, может быть отключен для 128х машин)
FramesCounter (4 байта) - счетчик фреймов от сброса Z80
TStates (4 байта) - счетчик тактов Z80 от начала фрейма. 4 байта на случай турбо-режимов.
4я строка с конца - определяет состояние регистров звукового чипа AY, начиная с нулевого. Может быть исключена, если AY не имеется в конфигурации системы, и нет более поздних расширений описателя за ней, при наличии более поздних расширений должна присутствовать в любом случае.
В 4х старших битах 2го байта с начала строки (1й регистр) - дополнительная информация:
4й бит - модель звукового чипа - 0-AY-3-8910/12 , 1 - YM2149F
В 4х старших битах 14го байта с начала строки (13й регистр) хранится номер выбранного регистра AY (последний вывод в порт номера регистра - #FFFD для 128х и Дидактик Мелодик, #F5 для таймекс-моделей, #3F для Fuller Box)
Расширение формата делается путем добавления дополнительных строк перед основными, чтобы смещения полей основных строк от конца файла не менялись. Предписания по расширениям формата:
1) каждое расширение занимает целое число 16байтных строк
2) каждое расширение имеет фиксированное смещение от конца файла
3) при выборе полей и их порядка следует руководствоваться принципом удобства чтения полей из хекс-вьювера, так, более важные поля следует располагать по краям строки и в центре 16-байтной строки
4) страницы памяти периферии должны сохраняться в общем формате страниц памяти, за страницами ОЗУ/ПЗУ модели, а их номера должны быть закодированы в общем порядке номеров страниц памяти
Lethargeek
06.08.2023, 17:33
7й бит - Was Jump (1 - последней была выполнена команда перехода), нужен для определения флагов временного запрета прерываний и состояния Halted процессора: после команды EI и префиксов #DD/#FD прерывания запрещены, если PC не выставлен на данный адрес после команды перехода. Аналогично после команды HALT процессор находится в состоянии Halted, если PC не выставлен на данный адрес после команды перехода
как определяется "после"? если чисто по расположению байт, то кроме перехода код префикса или команды ei может оказаться частью данных на самом деле
Spectramine
06.08.2023, 18:54
как определяется "после"? если чисто по расположению байт, то кроме перехода код префикса или команды ei может оказаться частью данных на самом деле
Мда. Логично. Значит, одним WasJump не обойдешься, или он вообще не нужен, а нужны отдельные флаги Halted и TempDI.
- - - Добавлено - - -
А может и TempDI не нужен, т.к. прерывание должно быть обработано сразу после выполнения команды, если оно подтверждено, и PC указывает на ISR.
Bedazzle
06.08.2023, 23:42
Расширение формата делается путем добавления дополнительных строк перед основными
1. Кем и как будет утверждаться расширение формата?
2. Кмк, важнее не то, что в файле удобно "глазами" что-то искать, а хотя бы простенькая утилита (вин-лин-мак) для парсинга и выплёвывания нужной инфы в консоль в текстовом виде (список страниц, состояние регистров, модель и т.п.)
Spectramine
07.08.2023, 02:22
1. Кем и как будет утверждаться расширение формата?
2. Кмк, важнее не то, что в файле удобно "глазами" что-то искать, а хотя бы простенькая утилита (вин-лин-мак) для парсинга и выплёвывания нужной инфы в консоль в текстовом виде (список страниц, состояние регистров, модель и т.п.)
1) В этой и параллельной теме на Spectrum Computing можно предлагать расширения, обсуждать и утверждать их. Но, честно говоря, я не вижу серьёзных причин для расширения формата. Описывать состояние подключенной периферии? Можно, но придется решать вопрос и с образами носителей и именами их файлов, придется вводить в формат строки и данные произвольной длины, для них нужна отдельная область в формате. Тоже решаемо в принципе, но вообще на текущий момент формат не претендует на исчерпывающее описание состояния системы, включая подключенную периферию и связанные с нею образы носителей, как SZX. Это всего лишь удобная для просмотра/исследования альтернатива форматам снапшотов .sna и .z80. Хотя можно заморочиться, конечно, и с состоянием периферии, если формат окажется востребован, и появится такая необходимость.
2) Для данного формата важно именно то, что в файле удобно искать и читать нужную инфу глазами в хекс-вьювере. Утилиту для парсинга и вывода нужной инфы можно написать для любого существующего формата, или нескольких, новый формат для этого не нужен.
NEO SPECTRUMAN
07.08.2023, 02:39
и параллельной теме на Spectrum Computing
на Гадском Спецтрум Компутенге форматы не пообсуждаешь
ибо тамашний капиталистический админ иноагент не дает людям править посты через пару часов...
- - - Добавлено - - -
а как без обновления первого пста фиксироватоь результаты науке неизвестна
Spectramine
07.08.2023, 02:40
а как без обновления первого пста фиксироватоь результаты науке неизвестна
Я уже делал - пишешь админу, он обновляет первый пост. Заморочно, конечно, немного.
vlad-kras
10.08.2023, 14:42
удобном для просмотра и модификации формате состояния компьютера ZX Spectrum
Если предполагается модификация, а не только просмотр, тогда должен быть конвертер обратно в снапшоты для загрузки в эмулаторы?
Spectramine
10.08.2023, 17:58
Если предполагается модификация, а не только просмотр, тогда должен быть конвертер обратно в снапшоты для загрузки в эмулаторы?
Этот формат и есть формат снапшота для загрузки/выгрузки в/из эмулятор/а, альтернатива SNA и Z80. Просто его основное преимущество перед существующими - удобство просмотра/редактирования вне эмулятора.
Скорее всего, эмулятор, поддерживающий этот формат, поддерживает и другие, так что, при желании, можно загрузить в этом формате и выгрузить в SNA, Z80 или SZX.
marinovsoft
10.08.2023, 20:34
Для удобства просмотра и редактирования делайте на базе xml. Содержимое страниц можно хранить либо в base64 строках, либо в дополнительных файлах.
Spectramine
10.08.2023, 21:43
Для удобства просмотра и редактирования делайте на базе xml. Содержимое страниц можно хранить либо в base64 строках, либо в дополнительных файлах.
Вы делайте, как считаете нужным, я сделал, как считал нужным. Собственно и просматривать-редактировать в первую очередь нужно память, регистры и остальное гораздо реже. И шарься потом по base64 строкам или дополнительным файлам.
marinovsoft
11.08.2023, 04:53
Хамите, парниша.
Spectramine
11.08.2023, 07:25
Хамите, парниша.
Это вы хамите, "парниша", а я вам ответил корректно, по существу вашего совета.
marinovsoft
11.08.2023, 07:33
https://cs8.pikabu.ru/post_img/2017/11/11/10/1510416118115526142.jpg
vlad-kras
11.08.2023, 12:53
Просто его основное преимущество перед существующими - удобство просмотра/редактирования вне эмулятора
Тогда почему не воспользоваться форматом SNA + hex edit с поддержкой настраиваемого смещения? Задать во hiew смещение 16384-27 байт и наслаждаться? Все 48К попадают в нужные адреса. Кстати, какие-то еще редакторы поддерживают такое виртуальное смещение? Возможно beye, но он у меня показывает просто черное окно, давно заброшен, вероятно работает только в досе.
https://ru.wikipedia.org/wiki/Beye
И вообще какие задачи должен решать этот формат, что эмулятор оказывается непригодным? Поиск строк с поддержкой произвольного регистра и кодировок? Глобальная замена по файлу? Редактирование с использованием вставки, а не только замены? Копирование участков во внешний файл? Массовый поиск в нескольких файлах?
Lethargeek
11.08.2023, 15:26
Задать во hiew смещение 16384-27 байт и наслаждаться?
лишние телодвижения мешают наслаждаться
к тому же hiew под винду платный
Все 48К попадают в нужные адреса.
в sna вообще-то может быть и больше 48k, что потребует еще больше лишних телодвижений, и уже возможно неоднократных
И вообще какие задачи должен решать этот формат, что эмулятор оказывается непригодным?
да мало ли почему, например, в отладчике тупо маловато окошко или навигация неудобная
Spectramine
11.08.2023, 16:37
Тогда почему не воспользоваться форматом SNA + hex edit с поддержкой настраиваемого смещения? Задать во hiew смещение 16384-27 байт и наслаждаться? Все 48К попадают в нужные адреса. Кстати, какие-то еще редакторы поддерживают такое виртуальное смещение? Возможно beye, но он у меня показывает просто черное окно, давно заброшен, вероятно работает только в досе.
Можно и воспользоваться, конечно. Но это требует слегка навороченного хекс эдитора, а не любого.
И вообще какие задачи должен решать этот формат, что эмулятор оказывается непригодным? Поиск строк с поддержкой произвольного регистра и кодировок? Глобальная замена по файлу? Редактирование с использованием вставки, а не только замены? Копирование участков во внешний файл? Массовый поиск в нескольких файлах?
Основная задача снапшота - хранить состояние эмулируемого Спектрума, дополнительная задача этого формата - чтобы это состояние можно было без напрягов исследовать внешними инструментами, в первую очередь хекс-вьювером.
Да, эмулятор с хорошим отладчиком может убрать необходимость в других инструментах, но - много вы знаете эмуляторов с хорошими отладчиками? Отладчик Спектакулятора, например, не позволяет просматривать память в хекс-дампе. У других отладчиков другие ограничения.
Ну вот, например, задача. Вы сохраняете несколько снапшотов в данном формате, чтобы найти ячейки, изменившиеся заданным образом. Далее в тотал командере сравниваете попарно такие снапшоты, и слету получаете адреса нужных ячеек в памяти Спектрума. А используя sna формат, вы ещё навозитесь с вычислением их адресов, вычитая нужные смещения.
Spectramine
14.08.2023, 21:31
Решил, что нет необходимости хранить текущую конфигурацию памяти в списке номеров страниц. Активные страницы памяти можно сохранить в начале снапшота, если нужно, и это желательно, но уже не обязательно.
Таким образом, нет необходимости в байте битов состояния страниц конфигурации памяти. Вместо него я решил хранить турбомножитель штатной частоты Z80.
Также я решил хранить номер страницы главного ПЗУ в порядке, обратном порядку номеров страниц ПЗУ внутри него (с битом 7=1 - $80, $81 и т. д.). Таким образом номер страницы Бейсик 48 для всех фирменных машин и Пентагона - $80 (но не для Скорпионов).
Необходимо зафиксировать номера ПЗУ периферии, поэтому их номера начинаются с $FF, $FE и т. д. Но я еще не давал номера периферийным ПЗУ (и вообще пока не специфицировал периферию в формате).
Флаги поля конфигурации, которые я задал на данный момент:
snv8kbPages = $80000000;
snvLongPageNumber = $40000000;
snvLateTimings = $00000001;
snvCMOSZ80 = $00000002;
snvIssue2 = $00000004;
snvMainAYpresent = $00000008;
Реализовал формат .SNV в первом приближении в своём эмуляторе, и - мне нравится, как смотрится содержимое .snv файлов в хекс-вьювере: 79270 .
Обновил спецификацию формата в первом посте темы.
Lethargeek
15.08.2023, 01:39
надо было положить в архив и совпадающие (насколько возможно) снапы в других форматах
Spectramine
15.08.2023, 05:41
надо было положить в архив и совпадающие (насколько возможно) снапы в других форматах
Зачем?
Почему бы вместо бинарных блобов не хранить хекс строки по например 64 символа (32 байта) и вообще все в текстовом виде? В принципе ширину любую можно, игнорируя при чтении перевод строк. Всего в 2 раза больше бинарника размером получится, красиво и наглядно, и редактируемо и просматриваемо в любом текстовом редакторе, в случае чего. Кроме того, само название формата “SNap for View” намекает на легкую просматриваемость, что больше соответствует текстовому виду.
А hex-view для просмотра это совсем не view.
Формат нужен текстовый. Interchangeable. Ну или не понятно зачем вообще эту тему затевать, выводя в общественность, если он все равно будет очередным 101м стандартом, который кроме своего эмулятора нигде не будет работать.
Spectramine
15.08.2023, 07:06
Почему бы вместо бинарных блобов не хранить хекс строки по например 64 символа (32 байта) и вообще все в текстовом виде? В принципе ширину любую можно, игнорируя при чтении перевод строк. Всего в 2 раза больше бинарника размером получится, красиво и наглядно, и редактируемо и просматриваемо в любом текстовом редакторе, в случае чего.
Чтобы было красиво и наглядно, надо не в два а в 3 раза больше места, потому что хекс-значения, не разделенные пробелом, малочитабельны. А точнее в 4 раза, потому что на каждый байт нужно ведь ещё вывести его представление в ASCII, дабы достичь той же функциональности просмотра. Плюс, чтобы находить адреса ячеек, надо в начале каждой строки выводить их, а это в целом ещё + 8 байт на строку.
Далее, такой файл конечно можно будет открыть любым текстовым редактором, но вот дизассемблировать его уже будет слегка проблематично, равно как и просматривать его графику и т.п. Равно как и редактировать - как вы собираетесь редактировать текстовый файл, в котором присутствует два значения для каждого байта (хекс и аски)?
Кроме того, само название формата “SNap for View” намекает на легкую просматриваемость, что больше соответствует текстовому виду.
А hex-view для просмотра это совсем не view.
Думаю, человеку, у которого возникла необходимость просмотра снапшота в хекс-виде, должен быть знаком такой инструмент, как хекс-вьювер. Я им пользуюсь регулярно - потому что он позволяет просмотреть любой тип файла, а не только текстовый.
Формат нужен текстовый. Interchangeable. Ну или не понятно зачем вообще эту тему затевать, выводя в общественность, если он все равно будет очередным 101м стандартом, который кроме своего эмулятора нигде не будет работать.Текстовый формат будет настолько же интерчанжабл, насколько и бинарный, поскольку чтобы он был интерчанжабл, его всё равно надо поддерживать в других эмуляторах. Все его преимущества - что его можно будет смотреть в текстовом редакторе вместо хекс-вьювера. Но, как я уже сказал, человек, нуждающийся в просмотре файла в хекс-виде, скорее всего имеет под рукой хекс-вьювер.
Ок. Делайте свой формат который кроме этого эмулятора нигде не будет использоваться.
Добавлю только одно, что в хекс редакторе переставить страницы местами, или просто дополнить какими-то чанками (блоками бинарников) вы не сможете. В отличие от текстового файла.
Spectramine
15.08.2023, 08:48
Ок. Делайте свой формат который кроме этого эмулятора нигде не будет использоваться.
Добавлю только одно, что в хекс редакторе переставить страницы местами, или просто дополнить какими-то чанками (блоками бинарников) вы не сможете. В отличие от текстового файла.
Ну как раз мой формат позволяет очень легко переставлять страницы местами, если бы вы вникли, вы бы знали. И почему нельзя в хекс-редакторе дополнить блоками бинарников? Это зависит от его функциональности, есть ли в нем работа с блоками или нет. А дополнять текстовый файл бинарным блоком может быть очень нетривиальной задачей - вам нужно сначала какой-то тулзой сконвертировать бинарный блок в текстовый хекс-вид, а потом вставить его в текстовый файл - это легко сделать, если блок выровнен по границам хекс-строк, а если нет? К тому же придется возиться с адресами в начале строк - тулза должна быть умной и подставлять правильные адреса при конверсии, иначе кто знает, что там распарсит эмулятор при чтении такого текстового файла.
- - - Добавлено - - -
Интересно, почему вы думаете, что текстовый формат внезапно стал бы использоваться в других эмуляторах?) На текущий момент распространенных текстовых форматов снапшотов нет, и наверно не потому, что эта идея никому не приходила в голову.
Наверное потому что такова традиция эмуляторописателей - делать свои форматы (самое простое - бинарный, тк не надо кодировать/декодировать строки), и забивать на всех остальных болт.
Редактируя бинарник хекседитом нужно понимать всю внутреннюю структуру, где заголовки чанков где длины (которые нужно сообразно править), а если там ещё и таблицы смещений до чанков (каталог типа) то вообще гаси свет.
В текстовом же просто нашёл нужную секцию по ctrl+f, и скопипастил там что надо или подредактировал значения.
У вас видимо какая-то профдеформация на почве хекс едиторов, которые стоЯт отнюдь не у всех, и вообще на самом деле мало у кого, и стОят они денег (если не ломанное что-то).
Lethargeek
15.08.2023, 11:35
Зачем?
чтобы разница понятнее и нагляднее
- - - Добавлено - - -
хекс едиторов, которые стоЯт отнюдь не у всех, и вообще на самом деле мало у кого, и стОят они денег (если не ломанное что-то)
ВНЕЗАПНО: https://hexed.it
Spectramine
15.08.2023, 11:46
Наверное потому что такова традиция эмуляторописателей - делать свои форматы (самое простое - бинарный, тк не надо кодировать/декодировать строки), и забивать на всех остальных болт.
Для всех остальных есть такая вещь, как дизассемблирование в текстовый файл с разметкой кода. Это намного удобнее, информативнее и модифицируемее, чем любые текстовые снапшоты с хекс-инфой.
Редактируя бинарник хекседитом нужно понимать всю внутреннюю структуру, где заголовки чанков где длины (которые нужно сообразно править), а если там ещё и таблицы смещений до чанков (каталог типа) то вообще гаси свет.
Вот именно поэтому и был разработан этот формат, в котором нет ни чанков, ни заголовков, ни длин, ни таблиц смещений. Есть сплошной массив содержимого памяти, строка номеров страниц памяти, и несколько строк остальной информации с фиксированными смещениями от конца файла.
В текстовом же просто нашёл нужную секцию по ctrl+f, и скопипастил там что надо или подредактировал значения.
А не получится просто скопипастить - надо ещё потом ручками править адреса будет, в отличие от хекс-редактора. И значения редактировать получится, только если инфа в текстовом файле хранится либо в хекс, либо в ascii виде - иначе парсер не будет знать, какое из значений читать в память.
У вас видимо какая-то профдеформация на почве хекс едиторов, которые стоЯт отнюдь не у всех, и вообще на самом деле мало у кого, и стОят они денег (если не ломанное что-то).
Так отнюдь не все и занимаются просмотром и редактированием снапшотов) а те, кто занимается, в состоянии найти себе бесплатный хекс-редактор.
Вот интересно, много ли вы занимались просмотром/исследованием/редактированием снапшотов, что вам не хватало возможности сохранить их в текстовый файл и наслаждаться потом? Насколько умозрительны ваши соображения?
Вот Lethargeek перелопатил кучу игр для их раскраски под ULAX. Но почему-то при этом у него не возникла простая и понятная идея - написать сохранение состояния в текстовый файл, в котором так удобно потом всё смотреть и редактировать. Правда, надо ещё написать загрузку таких файлов, но это тоже не слишком сложная задача.
А я знаю, почему я не стал этого делать. Потому что у меня в эмуляторе есть нормальный дизассемблер в текстовый файл, с предварительной разметкой кода, и на этом фоне текстовый снапшот просто не нужен. А вот удобный бинарный формат снапшота всё ещё нужен. Потому что все существующие, как вы справедливо заметили, не особо удобны для просмотра и модификации, когда что-то нужно сделать по-быстрому.
- - - Добавлено - - -
чтобы разница понятнее и нагляднее
Те, кто ранее открывал снапшоты в хекс-вьювере, и так представляют себе разницу, а остальные разницы не оценят.
> Вот Lethargeek перелопатил кучу игр для их раскраски под ULAX.
Ну вот примерно про такое я и говорю (профдеформацию), когда вместо кучи иероглифов и закорючек (хексов) уже начинаешь видеть блондинку, брюнетку...
> Есть сплошной массив содержимого памяти, строка номеров страниц памяти, и несколько строк остальной информации с фиксированными смещениями от конца файла.
Очень мило. А если мне надо переместить кусок данных на 300 байт вперед? Границ-то нету, добавил даже один байт вначале и привет, нужно смотреть что куда сместилось. Чанки в этом смысле лучше. Но хуже в другом - нужно "длины" корректировать, чтобы они все не поехали. И для таких ситуаций, когда нужна куча разнородных и необязательных данных, которые можно просмотреть глазками и поискать "проблему", и придумали текстовые форматы (xml/json-derived), как например тот же docx (который очевидно прогрессивнее бинарного .doc). Для эмулятора с 1050 вариантов конфигураций подобный подход к сохранению файла состояния (снапшота) очевидно более универсален и удобен, чем бинарник, да еще и без чанков.
К тому же, есть прекрасная встроенная возможность для всяких обратных-прямых совместимостей между версиями, и вариантами наполнения.
Spectramine
15.08.2023, 17:05
> Вот Lethargeek перелопатил кучу игр для их раскраски под ULAX.
Ну вот примерно про такое я и говорю (профдеформацию), когда вместо кучи иероглифов и закорючек (хексов) уже начинаешь видеть блондинку, брюнетку...
Ну так а вы же предлагаете те же хексы, но в текстовом формате))
> Есть сплошной массив содержимого памяти, строка номеров страниц памяти, и несколько строк остальной информации с фиксированными смещениями от конца файла.
Очень мило. А если мне надо переместить кусок данных на 300 байт вперед? Границ-то нету, добавил даже один байт вначале и привет, нужно смотреть что куда сместилось. Чанки в этом смысле лучше. Но хуже в другом - нужно "длины" корректировать, чтобы они все не поехали. И для таких ситуаций, когда нужна куча разнородных и необязательных данных, которые можно просмотреть глазками и поискать "проблему", и придумали текстовые форматы (xml/json-derived), как например тот же docx (который очевидно прогрессивнее бинарного .doc). Для эмулятора с 1050 вариантов конфигураций подобный подход к сохранению файла состояния (снапшота) очевидно более универсален и удобен, чем бинарник, да еще и без чанков.
К тому же, есть прекрасная встроенная возможность для всяких обратных-прямых совместимостей между версиями, и вариантами наполнения.
Видимо вы умозрительно переносите свой профессиональный опыт на узкую хобби задачу . Переместить любой кусок данных на любое количество байт в хекс-редакторе, имеющем функции работы с блоками, не проблема. То, что там может что-то там сместиться - так оно точно также сместится, если вы сделаете это же, но внутри текстового файла.
Здесь нет кучи разнородных и необязательных данных - здесть есть однородное байтовое содержимое памяти, незачем огород городить с текстовым форматом. Плюс некоторое число полей, описывающих состояние Z80 и системы, с которыми иметь дело вне эмулятора приходится намного реже. Вот они в текстовом формате выглядят приличнее и понятнее - но ради редкой необходимости их посмотреть-отредактировать нерационально завязываться с текстовым форматом. Достаточно привязать их к удобным смещениям в бинарнике.
Чтобы появилась куча разнородных данных, которые можно посмотреть глазками и поискать проблему - есть разметка кода и текстовый дизассемблер, вот в нем можно делать что хочешь, и удобно редактировать, и адреса автоматически корректируются при ассемблировании.
А текстовый формат снапшота ничего не даст, кроме того, что поля состояния системы будут выглядеть читаемее и модифицироваться легче - но не ради них это всё затевалось в основном, а ради содержимого памяти, которое в текстовом формате и редактировать сложнее (потому что адреса строк надо править), и занимает в 5 раз больше памяти, и плюс легко накосячить с синтаксисом, когда после нескольких правок файл внезапно станет непринимаемым эмулятором из-за потери скобки или запятой.
можно просто оставить sna формат как есть, просто записывать вначале банки памяти, а потом блок регистров, который искать относительно конца файла. Назвать такой снэпшот ANS (реверсное SNA), чтобы подчеркнуть что данные в нем сохранены наоборот. Тогда смещение банок памяти в снэпшоте будет начинаться с нуля :)
Назвать такой снэпшот ANS (реверсное SNA)
Неудачный выбор: .ans относится к ansii-art и к направлению textmode scene.
ну SNV тоже относится к Data files containing Single Nucleotide Variations (SNV).
Так можно на любое сочетание трех букв найти уже используемый формат
Spectramine
27.11.2024, 22:05
можно просто оставить sna формат как есть, просто записывать вначале банки памяти, а потом блок регистров, который искать относительно конца файла. Назвать такой снэпшот ANS (реверсное SNA), чтобы подчеркнуть что данные в нем сохранены наоборот. Тогда смещение банок памяти в снэпшоте будет начинаться с нуля :)
В предложенном формате ещё и значения регистров и прочей инфы удобонаходимые и удобочитаемые, в отличие от .sna. Ещё бы это было кому-то надо)
Lethargeek
28.11.2024, 18:54
ну SNV тоже относится к Data files containing Single Nucleotide Variations (SNV).
Так можно на любое сочетание трех букв найти уже используемый формат
да лишь бы в ретроэмуляции не встречалось, на посторонние нуклеотиды можно забить)
И для таких ситуаций, когда нужна куча разнородных и необязательных данных, которые можно просмотреть глазками и поискать "проблему", и придумали текстовые форматы (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)
в бинаре копаться удобнее, чем тут - придется парсить.
в бинаре копаться удобнее, чем тут - придется парсить.
как может быть удобнее в бинарнике копаться, если там не видно где что находится. Даже если на память знаешь смещения всех значений - промазал на байт и уже отредактировал чтото другое. Скопипастить кусок памяти из одного места в другое вообще нереально.
А парсить ничего не нужно текстовые редакторы прекрасно умеют парсить xml и подскажут подсветокой где начало/конец определенного блока, подскажут выпадающими списками автокомплит, покажут где какая ошибка и т.п. И если xml правильно отформатирован, то там и без подсветки все прекрасно видно.
Например, в zxmak2 конфигурация матрицы клавиатуры спектрума задается в xml конфиге, вот как он выглядит в geany - все раскрашено и хорошо видно:
https://i.imgur.com/75yKwER.png
В бинаре перед хекс строкой есть один только плюс. Это строковая форма. В хекс строках такое не найдешь и не исправишь.
Но остальное - одни "не плюсы". Метки, комментарии, структуры - не сохранишь. Что-то типа сейвстейта как в IDA разве что городить - гибридно, текстовые данные + фалы блобов (причем с отсылками с текстовой к блобам, таким образом и ромы сохранять нестандартные можно, и содержимое General Sound, если нужно) Запакованное в zip (то есть паковать больше и не нужно).
Но я бы вместо xml предпочел бы yaml. Больше на конфиг похоже, и без тэгов закрывающих, ненужных.
как может быть удобнее в бинарнике копаться, если там не видно где что находится.
Начнем с того, что я знаю, где и что находится.
Начнем с того, что я знаю, где и что находится.
значит вам мало в каких файлах приходится копаться, но всеравно - это вопрос времени, сегодня знаете, через 5-10 лет уже врядли вспомните даже примерно где что было.
Bedazzle
06.12.2024, 13:26
значит вам мало в каких файлах приходится копаться
берём например https://construct.readthedocs.io/en/latest/
и ничего не забудется
берём например https://construct.readthedocs.io/en/latest/
и ничего не забудется
Не, бесполезно объяснять азы автору, с трудом осилившему ассемблер z80
Не, бесполезно объяснять азы автору, с трудом осилившему ассемблер z80
Ваш выпад с переходом на личности и оскорбления удивил, но раз уж вы решили подчеркнуть свою экспертизу в разработке комплияторов ассемблера для z80, мне будет интересно услышать, какой именно компилятор ассемблера для Z80 вы реализовали и что он умеет?
Если вернуться к сути моего вопроса по ассемблеру, он касался не трудностей в понимании ассемблера Z80, а поиска оптимального и классического подхода к интерпретации меток в грамматике lex/yacc для компилятора ассемблера, а именно - синтаксис каких меток считать допустимым, а каких нет.
Для контекста: я попробовал написать свой компилятор ассемблера на замену существующим, чтобы реализовать недостающие фичи которых мне не хватает при отладке эмулятора, у меня получилось два варианта грамматик с разным подходом к обработке меток, учитывающий разные подходы принятые для z80. Насколько увидел - все варианты синтаксисов поддержать одной грамматикой не получится (по крайней мере мне так показалось), т.к. они конфликтуют и я хотел обсудить, какой из них ближе к общепринятому подходу в компиляторах для z80.
И кстати дизассемблер и ассемблер для Z80, поддерживающие все недокументированные инструкции, были включены еще 20 лет назад в первую версию zxmak, где использовались в его отладчике. Это конечно был ассемблер однострочный, для одной инструкции, а не полноценный компилятор, но тем не менее он корректно обрабатывал все возможные инструкции z80, поэтому странно видеть ваше заявление.
Если у вас есть конструктивные замечания по теме, буду рад услышать.
Что касается форматов хранения данных, в рамках работы мне неоднократно приходилось разрабатывать и отлаживать процессы сериализации в различных форматах. Исходя из этого опыта, могу уверенно сказать, что отладка и редактирование данных в формате XML/json значительно проще и удобнее по сравнению с бинарными форматами. Бинарные форматы - это ужас для отладки, особенно когда формат зависит от версии и одна и та-же переменная может быть по разным смещениям в зависимости от версии.
Если вы считаете, что редактирование данных в бинарных форматах проще, вероятно, ваш опыт работы с такими задачами был ограничен или сводился к относительно простым случаям, например, заменой одного значения на другое, я так это вижу.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot