Новый, более эффективный кассетный формат

[ZXMAK]

Пробовал - бесплатной версией проект не открывается, говорит, что требуется более полная версия. Там используется C#, а VS Express поддерживает только C++, да и тот - без MFC.

Так нужно было устанавливать не VS c++ express, а VS c# express. Это отдельные продукты. ZXMAK2 не на c++ написан, а на c#

[Barmaley_m]

Спасибо пользователю TSL - он сделал для меня версию Unreal с протоколированием сигнала магнитофона и исполнения команд In. Сегодня погонял загрузчик и проанализировал протоколы его работы. Обнаружился мелкий баг - в одном из мест задержка была выдержана неточно на 1 такт. Не думаю, что это могло повлиять на надежность работы, поэтому новый релиз пока не делаю. В остальном в логах пока что ничего аномального не наблюдается - алгоритм подстройки скорости работает как и должен, времянки загрузчика выдержаны точно.

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

[Barmaley_m]

Продолжаю вести анализ логов работы загрузчика. Построил нечто напоминающее eye diagram - наложение друг на друга фрагментов сигнала магнитофона, взятых со смещениями, кратными скорости записи. На них же наложил моменты, когда загрузчик выполняет команду IN для опроса порта магнитофона. Получившийся рисунок прилагаю.

Как его интерпретировать. Синие линии (частично закрыты красными) - это изменения сигнала на магнитофонном входе. Красные линии - это моменты выполнения команд In. По горизонтальной оси отложены такты Z80.

Отсюда видно, что в целом загрузчик работает так, как и должен был: опрос порта магнитофона идет в 2 раза чаще битовой частоты, при этом опросы, приходящиеся на середину битового интервала, используются для считывания информации, а те, которые приходятся примерно на моменты фронтов, служат для синхронизации со скоростью записи. Присутствует некоторый разброс, но это нормально до тех пор, пока фронты четко отделены от моментов считывания пустым пространством, что хорошо просматривается на рисунке. Как и задумывалось, информация в среднем считывается ровно посередине между фронтами (или теми местами, где они могли бы быть, в случае нескольких подряд идущих одинаковых бит).

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

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

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

[ZXMAK]

Хорошо-бы анализ проводить на разных ULA, в особенности на оригинальном spectrum 128 с contended memory, т.к. там тайминги будут заметно другие

[Barmaley_m]

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

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

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

ZXMAK, действительно, хорошо бы проводить анализ на разных ULA, но не все сразу. Пока что буду работать с самой простой, "пентагоновской".

[Barmaley_m]

Сделал новую версию программы-конвертора на языке Си. Доступно к скачиванию в первом сообщении этой темы. Программа теперь записывает выходные данные не только в tzx-файлы, но и в csw-файлы. При этом при сохранении в tzx-файлы можно выбрать тип блока: Generalized data block или CSW recording. Входной файл может быть типа tzx или bin. Для tzx конвертируются все найденные блоки (заголовки и данные); для bin - создается один блок данных с флагом 0xFF, данными из bin-файла и правильной контрольной суммой.

К сожалению, оба использованных типа блоков формата tzx не поддерживаются эмуляторами Unreal и ZX-MAK, поэтому для них единственный рабочий вариант - это использовать выходные файлы формата csw. Также данные эмуляторы не отрабатывают "длинные" паузы в csw-файлах, поэтому при воспроизведении csw-файлов отсутствуют паузы между блоками.

[Advertiser]

[ZXMAK]

Также данные эмуляторы не отрабатывают "длинные" паузы в csw-файлах, поэтому при воспроизведении csw-файлов отсутствуют паузы между блоками.

тут ты что-то путаешь, в ZXMAK2 CSW работает правильно.
Нужно учитывать что CSW формат подразумевает сжатие длинные паузы с помощью Z-RLE. Подозреваю что ты пишешь код который пишет поток без Z-RLE сжатия. Не знаю насчет unreal, но в ZXMAK2 я не так давно фиксил баг (обрезался конец ленты в некоторых случаях) и все работает правильно - работают и большие и маленькие паузы. Тестил и большие и маленькие паузы в обоих версиях и со сжатием и без сжатия.

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

Кол-во пауз записано в заголовке (4 байта по смещению 0x1D).
В заголовке записана также версия (байт по смещению 0x17).
Если версия 2, то поток сжат InflaterStream, частота дискретизации записана в четырех байтах и длина заголовка больше на 0x14 байт. Иначе частота дискретизации записана в двух байтах.
Частота дискретизации находится в заголовке по смещению 0x19.

PS: посмотрел исходник - так и есть, ты пишешь некорректный CSW, у тебя все задержки урезаются до байта. Отсюда и отсутствие пауз. Более того если младший байт паузы окажется 0, то последующие три паузы будут восприняты как большая пауза, что может обернуться в многочасовую паузу.

например чтобы исправить нужно вот этот фрагмент:

 if(putc(runlength*PULSE_SAMS_CSW,ft) == EOF)
                goto return_write_error;

заменить на такой:

 int pulseCsw = (int)(runlength * PULSE_SAMS_CSW + 0.5);
 if (pulseCsw > 0 && pulseCsw <= 255)
 {
    putc(pulseCsw, ft);
 }
 else
 {
    putc(0x00, ft);
    putc((pulseCsw >> 0) & 0xFF, ft);
    putc((pulseCsw >> 8) & 0xFF, ft);
    putc((pulseCsw >> 16) & 0xFF, ft);
    putc((pulseCsw >> 24) & 0xFF, ft);
 }

---------- Post added at 01:46 ---------- Previous post was at 01:18 ----------

Generalized data block или CSW recording.

с Generalized data block не понятно как его расшифровывать, есть детальная расшифровка как перевести Generalized data block в набор пауз?

[Barmaley_m]

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

Именно так я и записываю файл. Вот, например, фрагмент файла, который соответствует паузе в 1с между заголовком и данными. Частота дискретизации - 44100:

... 16 0B 16 16 00 44 AC 00 00 16 16 ...

Я ожидал, что 4 байта после нуля будут 32-битным значением паузы (0x0000AC44=44100), однако как в ZXMAK v2.7.5.0 beta, так и в Unreal, при воспроизведении указанного CSW-файла не слышно паузы между заголовком и данными.

Кол-во пауз записано в заголовке (4 байта по смещению 0x1D).

Может быть, дело в том, что я использую старый тип CSW V1.01 (а не V2)? У версии формата 1.01 в заголовке общее кол-во переключений сигнала (то, что ты, кажется, имел в виду под словом "паузы") не записывается.

например чтобы исправить нужно вот этот фрагмент:

 if(putc(runlength*PULSE_SAMS_CSW,ft) == EOF)
                goto return_write_error;

заменить на такой:

Этот-то фрагмент как раз правильный. Если взглянуть на несколько строк кода назад, то видно, что runlength - целое и может принимать значения от 1 до 5, а PULSE_SAMS_CSW=11. Там даже ругается программа, если вдруг из-за ошибки кодирования runlength>5. Таким образом, нуль или переполнение исключаются, и дополнительных проверок и ветвлений делать не требуется. Длинная пауза записывается отдельной веткой алгоритма в функции convert_file_part().

с Generalized data block не понятно как его расшифровывать, есть детальная расшифровка как перевести Generalized data block в набор пауз?

Я так понимаю описание Gen. data block, что для него задается алфавит. Каждый символ алфавита соответствует одной или нескольким командам управления сигналом магнитофона. Команды могут быть такие: проинвертировать текущий сигнал; оставить его как есть; установить 0 или установить 1. После выполнения команды идет задержка, измеряемая в тактах Z80. Полагаю, что перевести такие символы алфавита в эмулируемый сигнал магнитофона не сложнее, чем обрабатывать csw-поток. После объявления алфавита в Generalized data block помещается "строка" из символов этого алфавита. Иными словами, идет вызов коротких подпрограмм управления сигналом.

При этом, если в алфавите всего 2 символа - то на их кодирование используется по 1 биту, если до 4 - то 2, если до 8 - то 3 и т.д. Записывая данные в формате Generalized data block, я использовал два символа алфавита. Первый из них устанавливает сигнал магнитофона в 0, а второй - в 1, независимо от предыдущего состояния, и дает фиксированную задержку в 875 тактов. После этого "строка символов" представляет собой просто кодированный в 8b/10b битовый поток, который лишь на 25% длиннее исходных данных.

[ZXMAK]

Может быть, дело в том, что я использую старый тип CSW V1.01 (а не V2)? У версии формата 1.01 в заголовке общее кол-во переключений сигнала (то, что ты, кажется, имел в виду под словом "паузы") не записывается.

не, для версии 1 поток читается до конца файла

Этот-то фрагмент как раз правильный.

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

[Barmaley_m]

а где там паузы должны быть? тул же только один блок производит...

Один блок - при конвертации из bin. А при конвертации из tzx может генерироваться столько блоков, сколько было в оригинальном tzx. Следует учесть, что формат входного файла должен быть задан явно в командной строке. Иначе оно и tzx без интерпретации (как bin) обработает.