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

Цитата:

---

Сообщение от Barmaley_m

И вот еще что. Раз уж в теме появились авторы эмуляторов - то к ним вопрос. Не можете посоветовать, как лучше всего сделать специализированный эмулятор с трактом магнитофона - я хочу составить с его помощью лог работы загрузчика, а именно, в какие моменты вызывалась команда in. Быть может, в логе удастся увидеть какую-нибудь неоптимальность работы загрузчика, и пофиксить ее. Я так понимаю, что можно скачать какую-нибудь либу по эмуляции z80, либо же хакнуть существующий эмулятор Speccy. Что посоветуете?

---------- Post added at 13:00 ---------- Previous post was at 12:57 ----------

P. s. Хотелось бы работать с этим на c/c++ в ms visual studio.

---

Исходники эмулятора доступны на сайте https://zxmak2.codeplex.com/ (открываешь закладку SOURCE CODE и кликаешь ссылку Download на тулбаре справа вверху).
Открываешь солюшен в MS Visual Studio 2010, нажимаешь билд и через пол секунды у тебя в папке _binrelease свежая версия эмулятора :)

Логирование добавить - проще некуда, открываешь файл ZXMAK2\Engine\BusManager.cs, находишь метод WRPORT(ushort addr, byte value) и в его начало добавляешь чтонибудь типа:

Код:

---

        private void WRPORT(ushort addr, byte value)
        {
                if (addr == 0xFE)
                {
                        LogAgent.Info("OUT (#FE),#{0:X2} @ pc=#{1:X4}", value, m_cpu.regs.PC);
                }
......

---

Задача решена, ура! Землекопа - полтора! :v2_cool:

Если нужно логировать IN, делаешь то-же самое в методе RDPORT

Заодно проверишь как ведет себя загрузчик на различных моделях спектрума. ZXMAK2 поддерживает оригиналы с медленной памятью (48к early/late, 128k early/late) и русские клоны (пентагон, скорпион, профи, АТМ1, АТМ2, пентева, ленинград, байт, Дельта-С, кворум, LEC-48/528K, СПРИНТЕР). В отладчике напротив каждой инструкции отображается время ее исполнения для текущего состояния регистров. Можно смело в любой момент менять значение frmT - это такт кадра. Эмулятор корректно обработает изменение и продолжит исполнение с указанного такта.

Из магнитофонных форматов поддерживаются TAP, CSW, TZX и WAV.

Цитата:

---

Сообщение от drbars

Я имел в виду что... сохранить с M1, загрузить без.

---

Цитата:

---

Сообщение от psb

это будет кардинально отличаться от загрузки одного и того же файла с М1 и без?

---

Цитата:

---

Сообщение от drbars

По идее не должно, но проверить стоит

---

Всё ещё не проверено? :dizzy_mad_old:

Цитата:

---

Сообщение от DDp

realtape2 (wav csw) - записано с unreal (scorpion mode)
http://yadi.sk/d/7c72B2NR5B3vI
http://yadi.sk/d/Y6a7o0e75B3wO

---

Или unreal плохо эмулилирует "Скорпионовский M1" ?

Проверил realtape1.wav на ZXMAK со следующими типами ULA:
- ZX Spectrum 48 (Early model, Late model, Snow)
- ZX Spectrum 128 (Early model, Late model)
- BYTE (early model)
- Delta-C (Cheboksary-91/74)
- Leningrad
- Pentagon
- PENTEVO
- Profi 3.xx
- Scorpion (Green)
- Scorpion (Yellow)

Везде работает!

Barmaley_m, Не появился ли конвертор универсальный и поддержка в tzx ?

Цитата:

---

Сообщение от drbars

Barmaley_m, Не появился ли конвертор универсальный и поддержка в tzx ?

---

Пока не появились. Конвертор будет, а поддержка в tzx будет на уровне блоков общего назначения "CSW recording" только, потому что блоки вида "Generalized data block", для которых я сделал конвертор, не поддерживаются многими эмуляторами.

Я пока застрял на этапе модификации эмулятора для записи журнала работы загрузчика. ZXMAK не получилось скомпилировать (у меня нет VS2010), скачал свежие исходники Unreal, попробую скомпилировать их.

Цитата:

---

Сообщение от Barmaley_m

Пока не появились. Конвертор будет, а поддержка в tzx будет на уровне блоков общего назначения "CSW recording" только, потому что блоки вида "Generalized data block", для которых я сделал конвертор, не поддерживаются многими эмуляторами.

Я пока застрял на этапе модификации эмулятора для записи журнала работы загрузчика. ZXMAK не получилось скомпилировать (у меня нет VS2010), скачал свежие исходники Unreal, попробую скомпилировать их.

---

Можно скачать бесплатную vs 2010 express, она бесплатная

Цитата:

---

Сообщение от ZXMAK

Можно скачать бесплатную vs 2010 express, она бесплатная

---

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

Вот цитата сообщения:
"'(path)\ZXMAK2.csproj' cannot be opened because its project type (.csproj) is not supported by this version of the application.

To open it, please use a version that supports this type of project."

Цитата:

---

Сообщение от Barmaley_m

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

---

Кроме Visual C++ Express Edition бывает и Visual C# Express Edition :)

Цитата:

---

Сообщение от Barmaley_m

Я слышал о подобных проектах, но они вроде нацелены на цифровые устройства воспроизведения (такие, как mp3-плееры), а не на магнитофон, т.е. задач устойчивости загрузки к меняющейся скорости записи, ограниченной полосе частот и т.д. не ставилось. Кто-нибудь проверял этот проект на реальных магнитофонах?

---

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

Цитата:

---

Не знаю, че там на унриле, но в спектакуляторе все грузятся с ошибками, что на конфигурации Spectrum 48, 128, что на Pentagon 128.

---

В восьмом всё нормально..

Цитата:

---

Сообщение от Barmaley_m

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цитата:

---

Сообщение от Barmaley_m

Также данные эмуляторы не отрабатывают "длинные" паузы в 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 ----------

Цитата:

---

Сообщение от Barmaley_m

Generalized data block или CSW recording.

---

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

Цитата:

---

Сообщение от ZXMAK

кодировка простая - если байт равен 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-файла не слышно паузы между заголовком и данными.

Цитата:

---

Сообщение от ZXMAK

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

---

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

Цитата:

---

Сообщение от ZXMAK

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

Код:

---

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

---

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

---

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

Цитата:

---

Сообщение от ZXMAK

с 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% длиннее исходных данных.

Цитата:

---

Сообщение от Barmaley_m

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

---

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

Цитата:

---

Сообщение от Barmaley_m

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

---

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

Цитата:

---

Сообщение от ZXMAK

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

---

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

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

Цитата:

---

Сообщение от ZXMAK

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

---

возможно это поможет http://newton.sunderland.ac.uk/~miki...html#TZXFORMAT (ID 19)

Цитата:

---

Сообщение от lisica

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

---

Тесты на реалах широко приветствуются! Но для этого не нужно пользоваться конвертором. В первом сообщении этой темы скачай архив "tape8b/10b_130525.zip", в нем есть tap-файл "test8b10b.tap". Запиши его содержимое на ленту, а потом загрузи на реале. Запустится программа, которая предложит сохранить на ленту блок в формате 8b/10b. Сначала запиши на ленту блок в этом формате, а потом с помощью той же программы можно проверять, как он загружается. В случае ошибки загрузки, для повторного входа в программу, нужно исполнить команду бейсика GO TO 30.

Вот еще есть хороший тестовый пакет от DDp. Это образ дискеты, которую необходимо исполнить на реале, включив запись на магнитофоне. На кассету будет записан загрузчик и несколько картинок в формате 8b/10b. После этого делаем ресет, набираем LOAD "" - и наслаждаемся работой. В случае ошибок загрузки программу можно перезапустить командой RUN.

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

Кстати, версия Unreal с логированием от TSL корректно отрабатывает длинные паузы в CSW-файлах.

Это не связано с тем, что это "моя" версия. Оригинал десофта.

Цитата:

---

Сообщение от Barmaley_m

Тесты на реалах широко приветствуются!

---

Вот, только мафон востановлю, или для начала использую писи (вывод звука).

Ну чтож, первый этап проверки прошёл.
Система:
Робик (компаратор СА3)
nemowave редактор

Записал картинку из "test8b10b.tap". При воспроизведении грузит без ошибок.
транспонированием выводил от -2 до +2 semitones. Без ошибок. Более пилот не ловит. Попробовал во время загрузки плавно скорость менять - в небольших пределах - ошибки нету, скачками - выдаёт, но это и не удивительно.
Сделаю мафон, может, - проверю на нём.

Цитата:

---

Сообщение от lisica

транспонированием выводил от -2 до +2 semitones. Без ошибок. Более пилот не ловит.

---

Странное дело, что только в таких малых пределах ловит. Ты каким методом делал транспонирование? Допускается делать только resampling (то есть как будто скорость записи меняется), а всякие pitch shift существенно искажают сигнал, добавляют в него фронты, которых не было. Я проверял на Resampling, допуски в пределах около +-25% от оригинальной скорости грузятся уверенно, а это существенно больше, чем 2 semitones.

Цитата:

---

Ты каким методом делал транспонирование?

---

Слева интервал, справа плавный интервал. Какой шаг там - хз.
Проверил это же, только на 7мц - те же яйца. То есть - полёт как и на 3,5.(на 7 мц имеется ввиду - запись и сохранение с удвоенной скоростью.)
PS левым -2 и +2

Цитата:

---

Сообщение от Barmaley_m

Вот еще есть хороший тестовый пакет от DDp.

---

Все картинки загрузились без ошибок с удвоенной скоростью.

Цитата:

---

Сообщение от lisica

Слева интервал, справа плавный интервал. Какой шаг там - хз.

---

По скриншоту трудно сказать, что там за алгоритм применяется. Но попробуй запиши фрагмент своего голоса и обработай. Если после обработки скорость речи не изменилась, а тон изменился - значит это метод Pitch Shift. Если же скорость изменилась, и так, что при понижении тона она стала медленнее, а при повышении - быстрее, то это Resample. Так вот, для обработки сигналов для теста загрузчика годится только метод Resample. Pitch shift вносит множество искажений, и применять его для этих целей нельзя. Когда у реального магнитофона скорость ниже или выше номинальной - то на сигнал это влияет так же, как обработка с помощью Resample.

Цитата:

---

Сообщение от Barmaley_m

Если же скорость изменилась

---

Скорость изменяется.
Когда ставить флажок "обслуживать оригинальную скорость" то скорость не меняется а только тон. Пробовал без флажка.
Вот мафон восстановлю - поиграюсь регулятором скорости.

Новый релиз. Файлы можно скачать в первом сообщении этой темы. С помощью нового подхода - анализу работы загрузчика по логам эмулятора - мне удалось повысить точность адаптации часов загрузчика к скорости записи сигнала. Благодаря этому стало возможным снизить константу "быстрой адаптации", что привело к существенному уменьшению фазового дрожания часов загрузчика при условии, что сигнал идет с постоянной скоростью. На приведенной картинке это явно видно: пики команд In сузились и стали более чем в 2 раза выше. Когда рассматриваешь развертку логов, то раньше команды In довольно сильно "гуляли" в окрестности фронтов сигнала, а теперь они практически везде совпадают. Так что можно ожидать повышения надежности работы загрузчика.

Я проверял загрузчик на доступных файлах, которые сгенерировал программой конверсии, а также на файлах с записями с реальной кассеты, которые в эту тему выкладывали пользователи форума. В том числе та запись, где человек пальцем притормаживал магнитофон, из-за чего скорость плавает. Ошибок загрузки вроде нет. Также загрузчик стал надежно грузить файл со скоростью 130% от номинальной (раньше не грузил). Приглашаю всех заинтересованных провести новые тесты на реалах. Спасибо!

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

Картинку забыл добавить. Вот она.

Цитата:

---

Сообщение от Barmaley_m

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

---

странно, cгенерировал CSW файл открыл в последней версии, паузы между блоками около секунды. А какие должны быть?
Кстати, а ты какую версию ZXMAK2 используешь?

Цитата:

---

Сообщение от ZXMAK

А какие должны быть?

---

Такие и должны быть. Но в версии ZXMAK2 2.7.5.0 [beta] слышимых пауз между блоками нет вообще. Может версия устарела?

Цитата:

---

Сообщение от Barmaley_m

Кстати, версия Unreal с логированием от TSL корректно отрабатывает длинные паузы в CSW-файлах.

---

в unreal CSW файлы вообще неправильно читаются, в аттачменте пример CSW который unreal читает с ошибками еще на этапе открытия файла...

При его открытии в логе пишет красным текстом error: pulse table full!
Что это значит непонятно, воспроизведение внезапно обрывается посредине образа и начинается какой-то жужащий шум...

такое поведение в unreal на многих CSW файлах получается... Еще насколько помню, в unreal с CSW еще какой-то баг был, часть данных откусывалась или чтото типа того...

Привет. Это опять Баба Яга. Серый ZX-Spectrum +2. Tape loading error.

http://www.sanarin.ru/pic/tle.jpg

Цитата:

---

Сообщение от Barmaley_m

Такие и должны быть. Но в версии ZXMAK2 2.7.5.0 [beta] слышимых пауз между блоками нет вообще. Может версия устарела?

---

конечно устарела ей уже 4 месяца, эта версия еще в мае выкладывалась. уже скоро месяц как 2.7.5.7 выложена, баги CSW я исправлял в 2756 (10 июня)