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

[Barmaley_m]

можно скорость записи в два раза снизить, это увеличит устойчивость к искажениям...

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

Ладно. Посмотрим, что получится после полного переписывания загрузчика. Сможет ли новый загрузчик загрузить файл, присланный haywire.

[Advertiser]

[ram_scan]

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

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

Разве только помехоустойчивое кодирование попытаться добавлять...

[haywire]

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

Не знаю, не замечал никакого снижения надёжности. Вот кассета terminator 2. x1.6 turbo, 1991 год. Грузится как новенькая, ни разу не сбоила. А насчёт распространённости - практически все фирменнае загрузчики - турбированные в той или иной степени. Просто из-за того, что сам загрузчик надо загрузить, причём, на стандартной скорости, результирующий выигрыш был не особо впечатляющим.

[Barmaley_m]

Не знаю, не замечал никакого снижения надёжности. Вот кассета terminator 2. x1.6 turbo, 1991 год. Грузится как новенькая,

Мой кассетный опыт в 1992-1993гг говорит о снижении надежности. Хотя я использовал гораздо более быстрые турбы. Вот ходило у нас в Днепропетровске турбо 3х на базе копировщика Sormos-3 и бейсика "Рапид". Для быстрой загрузки игр или рабочих файлов (которые часто перезаписывались) годилось, а для архивации данных - сомнительно.

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

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

[Barmaley_m]

Изучал возможность загрузки файла с искажениями магнитофона Spectrum+2 в формате 8b10b альтернативным методом - измерение интервала между фронтами сигнала.

Прежде, чем писать загрузчик на ассемблере Z80, я решил проверить принципиальную возможность загрузки этим методом. Для этого была написана небольшая программа на Матлабе, которая измеряет время между фронтами сигнала и строит гистограмму этих интервалов. Поскольку в формате 8b/10b встречаются интервалы длиной в 1, 2, 3, 4 и 5 битовых интервалов - то логично было бы увидеть на гистограмме 5 пиков. Что я и увидел при обработке одного из вав-файлов в формате 8b/10b, записанного на эмуляторе. Пики четко разделены между собой, что позволяет различать биты путем сравнения измеренного интервала со средним значением между соседними пиками.

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

Картинки прилагаю.

Быть может, этот файл все же можно загрузить, но уже не на Спеке и не в реальном времени, а с помощью какой-нибудь более умной программы на том же Матлабе, которая бы использовала более тонкий ФАПЧ, чем тот, который в загрузчике. Который бы, к примеру, лучше подавлял фазовое дрожание входного сигнала. Более точно подстраивался к частоте за счет использования чисел с плавающей точкой и имел бы фазовый детектор, который не просто дает ответ вида "1/0", т.е. опережает ли фронт импульса внутренние часы или отстает от них, а также измерял бы, насколько. Может быть, с такими средствами этот файл и можно загрузить, кто знает.

Но я склоняюсь к мысли, что на Спектруме в реальном времени это невозможно. И обусловлено это не качеством загрузчика, а самим форматом 8b/10b, который оказался менее устойчивым к тому типу искажений, которые возникают в магнитофонной системе у Haywire, чем стандартный синклерский формат.

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

Синклерский же кассетный формат в очередной раз утер всем нос и заслужил дополнительное почтение. Респект инженерам, которые его разработали.

[TSL]

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

[Barmaley_m]

Ящитаю, начать стоит с того, чтоб проанализировать характер искажений, вносимых в сигнал мафоном.

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

Я даже считаю, что на нормальном магнитофоне таких сильных искажений быть не должно. У меня был магнитофон "Легенда-404" четвертой (т.е. самой худшей) группы сложности - и то лучше звучал; я звуковой сигнал, оцифрованный в конце 2000х с кассет, записанных на этом маге в начале 90х годов, смотрел в звукоредакторе - конфетка по сравнению с тем, что прислал Haywire. Может быть, у него головка давно не чищена или вообще расстроена, может быть еще что-то... Но факт - что синклерский формат при этом выжил, а 8b10b - нет.

В телекоммуникациях, где находил применение этот формат, обычно нет большой неравномерности АЧХ. Там обычно высокие частоты только задавлены, но низкие хотя бы не выпирают. Я тестировал и 8b/10b с задавленными высокими еще до того, как тему эту открыл. Все грузилось. Но кто же знал, что так будет.

Исходя из этого, думать об алго модуляции, коррекции и детекции сигнала. Уровнем выше делать 8->10 и коррекцию ошибок.

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

[Barmaley_m]

Хоть я и оставляю формат 8b/10b как бесперспективный для Спектрума, я задумался над интересной задачей - контроль спектра битовой последовательности. В коде 8b/10b подавляется постоянная составляющая, т.е. сам спектр последовательности заполняет всю полосу от 0 до 2кГц, однако на постоянной составляющей имеет нуль. В ходе некоторых размышлений я понял, что в битовой последовательности, содержащей неограниченную информацию, нули могут быть только на конечном количестве частот. Если сделать несколько нулей на низких частотах - там, где, предположительно, АЧХ имеет горб - то может быть удастся победить проблему. В общем, я на досуге попытаюсь разработать или найти другую схему кодирования - а там посмотрим, удастся ли с ее помощью добиться чего-нибудь интересного на Спектруме.

[Barmaley_m]

Нашел интересную книжку John R. Barry, Edward A. Lee , David G. Messerschmitt "Digital communication", ее 19 глава, посвященная контролю спектра кодированных данных, имеется в свободном доступе. Там как раз рассматривается теория построения блочных кодов, вроде 8b/10b (он является лишь частным случаем). Читаю запоем. Надежда есть!

[Barmaley_m]

Провел эксперимент на устойчивость форматов к неравномерности частотной характеристики. Обработал две записи, одну в синклерском формате, а другую в 8b/10b, сначала фильтром Баттерворта 4 порядка с частотой среза (по -3дБ) на 1800Гц. Оба формата с этим справились. Затем обработал эквалайзером, сделав пик на частоте 183Гц амплитудой 12дБ и добротностью 2. После этого синклерский загрузчик смог загрузить файл, а 8b/10b - нет. Процесс сорвался на первых же байтах, аналогично тому, как это происходило у Haywire. Поэтому думаю, что я нашел "образцовую" конфигурацию искажений, на которой можно тестировать форматы. Есть идея сделать формат попроще, чем 8b/10b, который был бы не так эффективен в скорости, зато более устойчив к горбам на низких частотах. Этот "компромиссный" формат имеет простое кодирование и немного выигрывает в скорости по сравнению с синклерским. Как сделаю для него сейвер и загрузчик - отпишусь.