Просмотр полной версии : Новый, более эффективный кассетный формат
Barmaley_m
19.05.2013, 01:35
Предлагаю вашему вниманию реализацию нового кассетного формата для ZX Spectrum.
Среди современных ему компьютеров, кассетный формат ZX Spectrum всегда выглядел в выгодном свете. По сравнению с Atari, C64, Радио-86РК и др., он не требовал специализированных магнитофонов, имел относительно высокую плотность записи и надежность хранения информации на кассете. Тем не менее, мне издавна не давал покоя вопрос о некоторой неэффективности формата "FM", как его называли в литературе. Ведь для записи каждого бита используется два фронта сигнала, да и само слово "FM" всегда ассоциируется со словом "MFM", где применяется более эффективное кодирование. По прошествии лет я так и не придумал, как можно прикрутить MFM к кассете, зато наткнулся на более интересную вещь - код 8b/10b (http://en.wikipedia.org/wiki/8B/10B).
Этот код заменяет каждые 8 бит данных на последовательность из 10 бит, обладающую следующими важными свойствами:
1) Количество нулей и единиц в такой последовательности либо одинаково, либо отличается нормированно. Тем самым кодированный сигнал имеет нулевую постоянную составляющую, что позволяет записывать его на магнитофон, передавать по линии без связи по постоянному току и т.д. без потери информации.
2) Количество подряд идущих одинаковых бит никогда не превышает 4. Тем самым снижаются требования по передаче низких и ультранизких частот, а также гарантируется достаточно фронтов сигнала для синхронизации.
Меня заинтересовал вопрос реализации формата для записи на кассету в ZX Spectrum, использующего этот код, и я сначала сделал программу сохранения - чтобы послушать, как звучат данные в этом формате, а затем и загрузчик: ведь мало ли, как они звучат, если их загрузить нельзя!
При реализации формата я делал упор на устойчивость к типичным искажениям сигнала магнитофона, а именно: отличающаяся на разных магнитофонах скорость записи, ограниченный спектр пропускаемых частот. Так как оригинальный кассетный формат Sinclair весьма неприхотлив к качеству записи и состоянию кассеты - то я постарался сделать новый формат таким, чтобы он не уступал, а по возможности - и превосходил оригинальный формат в этом. Время между ближайшими фронтами сигнала было выбрано таким же: 0.25мс. В результате требуемый диапазон частот составляет 2кГц, причем его верхняя часть может быть даже подрезана. Я специально обрабатывал сигнал фильтром Баттерворта с частотой среза около 1700Гц (при этом 2кГц, хоть и ослабленная, но немного пропускается), и загрузка происходила без ошибок. Также я менял скорость записи в пределах +-30%, в том
числе плавно во время загрузки - и это тоже не приводило к ошибкам. Справедливости ради следует заметить, что оригинальный формат имеет примерно такие же требования к скорости и полосе частот сигнала.
Добиться такой устойчивости стало возможным только за счет тщательно разработанного загрузчика. В нем, для подстройки к скорости записи, используется программно реализованная система ФАПЧ (http://ru.wikipedia.org/wiki/%D0%A4%D0%90%D0%9F%D0%A7). Вместо ожидания фронта сигнала, как это сделано в загрузчике от Sinclair, в моем загрузчике используется фазовый детектор. При загрузке каждого бита производится два измерения сигнала магнитофона: одно в середине временного интервала, который приходится на этот бит, а второе - на границе между битами. Если два подряд идущих бита различны
(если был фронт) - то измерение "на границе" совпадет с предыдущим, либо последующим битом. И тогда, если оно совпало с предыдущим - значит "внутренние часы" загрузчика идут быстрее, чем скорость записи, а если совпало с последующим - то наоборот, медленнее. На этой основе
производится подстройка "внутренних часов" загрузчика. Подобным образом в современной электронике осуществляется прием данных по линиям связи с автоподстройкой к скорости и/или к задержке. При этом собственно данные считываются в наиболее выгодный момент времени - в середине временного интервала, в котором записан
бит. Это дает дополнительную устойчивость к шумам и искажениям сигнала. Не исключено, что устойчивость нового формата даже выше, чем оригинального, но тут надо еще проводить испытания. На реале я пока что ничего не испытывал, нет возможности. Поэтому, если кто-нибудь может проверить мою систему на реале с магнитофоном - это будет очень полезно для проекта.
Загрузчик также может корректно принимать инвертированный сигнал - для тех случаев, когда тракт магнитофона его инвертирует.
Скорость. Тут ситуация не очень простая. Формат 8b/10b дает постоянную скорость записи независимо от состава данных, однако скорость оригинального синклеровского формата зависит от их состава. У синклеровского формата на запись 8 нулей расходуется 16 временных интервалов по 0.25мс, а на запись 8 единиц - 32 интервала. У формата
8b/10b для записи любых 8 бит используется 10 интервалов. Поэтому, если все данные нулевые - то формат 8b/10b дает приращение скорости записи в 1.6 раза, если все единицы - в 3.2 раза, а если данные содержат примерно одинаковое количество нулей и единиц, что имеет место в случае компрессированных данных - то средняя скорость записи выше оригинала в 2.4 раза.
Контроль ошибок. В своей реализации формата я применил контрольную сумму Флетчера, которая имеет лучшую способность к обнаружению ошибок, чем простая битовая четность, примененная в оригинальном синклеровском формате.
Применение. Думаю, что формат мог бы найти применение у тех владельцев реалов, которые все еще используют магнитофон для загрузки программ. Можно делать новые кассетные релизы
дем или игр в этом формате. Также из него могла бы получиться неплохая защита от копирования, если бы это в настоящее время имело смысл.
"Музыка загрузки". Данный формат, как и оригинальный синклеровский, дает некоторую "музыкальность" на последовательностях данных, содержащих закономерности. Попробуйте сохранить в нем какой-нибудь экран, например! На случайных данных звук сигнала 8b/10b ближе к "белому шуму". Это и логично: повышение плотности записи при той же полосе частот должно приближать сигнал к шумоподобному виду.
Приложение. Программы сохранения и загрузки, имеющие такой же интерфейс, как и оригинальные синклеровские загрузчик и сохранялка. LD IX, addr, LD DE, len, LD A, flag. Также прилагается программа на Си, которая конвертирует tzx- и bin-файлы в tzx- или csw-файлы в кодировке 8b/10b, так что их можно подставить загрузчику на эмуляторе или реале.
Надеюсь, кому-нибудь будет интересно!
Вторая версия от 25.05.2013 (устарела)
Последнее обновление от 17.07.2013: существенно улучшена работа загрузчика, уменьшено фазовое дрожание ФАПЧ, верхний предел скорости записи поднят до +30% (было +25%). Новая программа на Си (исходник и екзешник) для создания tzx- и csw-файлов с данными в формате 8b/10b.
Какие возможности в организации красивых бордюрных эффектов?
Можно сделать пламя как в академии?
Barmaley_m
19.05.2013, 12:02
Какие возможности в организации красивых бордюрных эффектов?
Можно сделать пламя как в академии?
Я сделал бордюрные эффекты похожими на оригинальный синклеровский загрузчик. Но при желании можно сделать что угодно. Там много мест с задержками, которые можно (при условии строгого сохранения кол-ва тактов) заменять любым кодом. Вообще загрузчик в большей части своей строго рассчитан по времени выполнения каждого его участка. Если это нарушить - снизится надежность загрузки.
А в сухом остатке что?
1. Красивости при загрузке - под вопросом
2. Защита от копирования - не актуально
3. Скорость загрузки - тестов нет (хотя бы на 5-10 известных играх)
4. Нет сравнения длинны с оригинальным загрузчиком
SoftLight
19.05.2013, 12:48
Красивости при загрузке все те же что и в стандартном загрузчике. Скорость загрузки в среднем в 1,5 быстрее. Мне интересно с научной точки зрения.
1. Всё это, конечно, хорошо. Но требовать наличия на компьютере программы за 150 тысяч рублей, это конечно, круто, но
2. Не работает на реале. ZX-Spectrum +2 серый. Проблем с лентой нет, грузит турбированные лицензии, которым по 30 лет. Tape loading error.
Загрузил tape.bin с адреса 32768
сохранил экран (print usr 32768)
перемотал ленту
Загрузил loader.bin адреса 32768
randomize usr 32678
результат на скрине
http://www.sanarin.ru/pic/tape.jpg
Длительность записи получается действительно в разы меньше. Дело за малым - чтоб оно ещё работало.
Barmaley_m
19.05.2013, 13:15
Ндп, жаль, что первый тест на реале не удался. Я вел разработку на эмуляторе и, хоть и вносил в сигнал преднамеренные искажения, ничто не заменит тест в реальной жизни. Если кто-нибудь еще сможет провести тест на других реалах - буду благодарен. Со временем и сам доберусь до реала и буду выяснять, в чем проблемы, и дорабатывать загрузчик.
По скорости тесты проводить не надо: ее можно и теоретически предсказать. В среднем в 2.4 раза выше оригинала. Длина загрузчика - около 600 байт.
Длина загрузчика - около 600 байт.
А у фирменного?
Barmaley_m
19.05.2013, 14:23
А у фирменного?
У фирменного меньше. Но мой, думаю, тоже можно запихнуть в свободное место ПЗУ бейсика, если возникнет такое желание.
introspec
19.05.2013, 14:37
Мне кажется, работа очень интересная и полезная, даже если пока не работает до конца полноценно.
Во-первых, интересно лучше понять природу ошибок чтения с ленты с т.зр. кассетного загрузчика (что не то же самое, что базовые принципы, вполне себе очевидные). Например, я писал в своё время турбированный загрузчик, навеянный рассказами о загрузчике БК, который на моём магнитофоне работал очень ненадёжно. Было бы интересно понять, возможно ли найти схему турбирования, которая дала бы стабильное чтение при, скажем, двойной плотности.
Во-вторых, применён интересный нетривиальный код, что образовательно (для меня, по крайней мере).
В-третьих, не нужно забывать, что всё ещё есть люди пишущие на кассеты и читающие игры на реалах. Это мог бы быть неплохой для них подарок.
Barmaley_m
19.05.2013, 14:55
introspec, спасибо. Я даже планировал сделать конвертор из tap в tzx так, чтобы tzx-файл имел небольшой размер (формат это позволяет). Тем самым можно было бы делать красивые кассетные релизы в этом формате. Насчет того, что не работает - давайте подождем еще тестов на реалах. Все же интересно, какой окажется надежность загрузки в текущем состоянии на разных машинах. Рано или поздно мы его допилим, было бы время и энтузиазм, а он у меня на данный момент есть.
Что касается картинки с ошибкой - то поскольку я уже имею опыт диагностики ошибок загрузчика, то ситуация явно указывает на срыв синхронизации ФАПЧ. Хотя немного и странновато: вначале грузятся ошибочные биты, потом правильные нули, а потом опять ошибка. Ладно, подождем еще тестов. Люди с реалами, помогайте!
:v2_thumb:
---
Нарезал несколько картинок, для примера.
8b10b_example1.7z (https://yadi.sk/d/mRbw-IJJQlK_-w)
introspec
19.05.2013, 15:24
Насчет того, что не работает - давайте подождем еще тестов на реалах
Я сказал "пока не работает" ;)
Что касается картинки с ошибкой - то поскольку я уже имею опыт диагностики ошибок загрузчика, то ситуация явно указывает на срыв синхронизации ФАПЧ. Хотя немного и странновато: вначале грузятся ошибочные биты, потом правильные нули, а потом опять ошибка. Ладно, подождем еще тестов. Люди с реалами, помогайте!
Проблема в АЦП. Поскольку наш АЦП однобитный и имеет частотный потолок, вместо честного сигнала, мы читаем его сигма-дельта представление. Любые "честные" фронты размазываются, аппроксимируются скачущими битами. Нужно написать программу для реала, которая с хорошей частотой читала бы результат фактического чтения порта и загрузить в неё, какой там у нас максимум? (1Мб даст 1Мб*8 отсчётов) сэмпл сигнала твоего формата. Анализ такого сэмпла сразу покажет, в чём основные затруднения.
SoftLight
19.05.2013, 15:34
да, примеры DDp даже в спектакуляторе не захотели загрузиться без ошибки. В целом картинка просматривается, но часть битов испорчена и в конце tape loading error.
Barmaley_m
19.05.2013, 15:49
Нда, печально. На анриле грузится, и даже грузилось, когда я искажения в сигнал добавлял. Ладно, буду на досуге усиливать искажения и бороться с ошибками, а когда до реала доберусь - то и на нем вести диагностику.
---------- Post added at 14:46 ---------- Previous post was at 14:44 ----------
Есть еще одна идея - может я где-то что-то неправильно делаю для оригинального Спектрума, а на Пентагоне заработает? Тогда задача сводится к учету каких-то аспектов работы оригинала. Может быть, в медленную память не грузит. Попробуйте загрузить в быструю память на реале или на спектакуляторе - может, дело в этом.
---------- Post added at 14:49 ---------- Previous post was at 14:46 ----------
Кстати да. Стек ведь тоже в медленной памяти получается во время работы загрузчика при CLEAR 32767. Так что задержки возникают не только при записи свежезагруженных данных в память, но и во время вызова подпрограмм загрузчика и возврата из них. Попробуйте еще стек разместить в быстрой памяти на тех машинах, где загрузка не пошла.
Barmaley_m, а чего ты на хабре не рассказал о сабже?
Классно! Очень интересная тема, визуально видно что в том-же Unreal грузится быстрее. Спасибо DDp за примеры.
:v2_thumb:
---
Нарезал несколько картинок, для примера.
Не знаю, че там на унриле, но в спектакуляторе все грузятся с ошибками, что на конфигурации Spectrum 48, 128, что на Pentagon 128.
тема интересна еще и потому что современные форматы передачи видео сигнала на монитор (tft матрицу) используют LVDS ну и это: http://en.wikipedia.org/wiki/Transition-minimized_differential_signaling
так или иначе но на сегодняшний день нет других способов повышения скорости передачи данных чем сочитанием этих способов, и скорее всего скоро ВСЕ чипы будут иметь интерфейс передающий такие сигналы
Barmaley_m
20.05.2013, 03:42
Barmaley_m, а чего ты на хабре не рассказал о сабже?
Была такая мысль, но потом закралось сомнение, будет ли это там кому-нибудь интересно. Думаешь, стоит? Но что-то меня результаты тестов смущают. Надо будет хотя бы поставить себе спектакулятор.
Barmaley_m, ты сначала это все на реале запусти
Думаешь, стоит? Но что-то меня результаты тестов смущают.
Определенно стоит. Но после того как всё заработает.
Barmaley_m, а ты видел конверторы k7zx и OtlaPlayer ?
на реале игра грузится секунд за 40.
я программ 30 адаптировал http://zx.pk.ru/showthread.php?t=19193
единственный минус использование в загрузчике недокументированной команды in f,(c) которая как оказалось корректно исполняется не на всех процессорах.
А известно на каких именно процессорах и как именно некорректно?
А известно на каких именно процессорах и как именно некорректно? насколько я помню всё началось с журнала zxFormat, там использовалась команда out (c),0 и она точно не выполнялась на некоторых процессорах (кажется новое поколение z80 которые могли работать на большей тактовой частоте)
Это к OUT (C),0 относится. На z84c она как OUT (C),#FF работает. INF работает и на z84, и на z84c.
В загрузчике какой флаг проверяется после in f,(c)?
Barmaley_m
20.05.2013, 11:23
Barmaley_m, а ты видел конверторы k7zx и OtlaPlayer ?
на реале игра грузится секунд за 40.
Я слышал о подобных проектах, но они вроде нацелены на цифровые устройства воспроизведения (такие, как mp3-плееры), а не на магнитофон, т.е. задач устойчивости загрузки к меняющейся скорости записи, ограниченной полосе частот и т.д. не ставилось. Кто-нибудь проверял этот проект на реальных магнитофонах?
Barmaley_m, для того, чтобы было больше тестировщиков на реалах, всё же надо выложить что-то более юзер-френдли. Дело в том, что далеко не все являются программистами даже начального уровня, и вот то, что выложено, они до реала даже не донесут. Сделайте какой-нибудь звуковой файл, тогда вероятность найти желающих потестировать увеличится.
Отличная работа !!! Обязательно протестирую в на реале. Формат чем-то напомнил технологию паковки данных для передачи факсов.
Но требовать наличия на компьютере программы за 150 тысяч рублей, это конечно, круто, но
А что это значит ? Загрузчик платный ?
А что это значит ? Загрузчик платный ?
Для работы конвертера нужна программа Matlab, которая, какбэ, платная.
Для работы конвертера нужна программа Matlab, которая, какбэ, платная.
Аааа ... Так это мелочи ... Значит просто надо написать свою програмку. Главное что есть инструмент и способ его применения.
Если Barmaley_m будет не против, обязательно использую этот формат. Надо будет теперь составить битовую структуру разных образов и изучить надёжность поиска данных внутри потока.
Robus, там программа на реалах не совсем работает.
Robus, там программа на реалах не совсем работает.
Да .... Я видел ... Это значит надо допилить. Скорее всего получается последовательность типа "11011" или "00100". Ещё возможно, что срабатывает инверсия, если это не учтено, то может происходить сбой. Но это предположения которые без опытов просто слова.
Попробовал на эмуряторе zx-spin, z80stealth, zxmak.net — картинка со сбоями аналогично spectaculator'у.
Для работы конвертера нужна программа Matlab, которая, какбэ, платная.
А может просто переписать на С там или на Басике конвертор?
на питоне. там есть всякие нумпи и прочие либы, всё бесплатно, почти матлаб.
Barmaley_m
21.05.2013, 04:48
Для работы конвертера нужна программа Matlab, которая, какбэ, платная.
Если что, есть программа Octave, которая может исполнять код Matlab и которая бесплатная.
Кроме того, ничто не мешает перевести конвертор на другой язык программирования. Я просто делал его на Матлабе для тестирования загрузчика, т.к. это было для меня наиболее быстрым и простым решением. Алгоритм там простой, конвертор кодированием 8b/10b не занимается, а просто переводит 16-битный сигнал из формата wav в однобитный сигнал формата tzx. Впоследствии я планировал сделать другой, более эффективный конвертор, который бы использовал формат tzx более рационально, так что размер tzx-файлов был бы существенно меньше.
Barmaley_m, ты с проблемой загрузки то разобрался?
У меня на 8-ом спектакуляторе чудесным образом всё заработало. Галку Enable Fast Loading и Enable Auto Loading надо снять в настройках.
На Пентеве загружается с ошибками. как будто биты выпадают.
http://i060.radikal.ru/1305/72/3ade50e85cc5t.jpg (http://radikal.ru/F/i060.radikal.ru/1305/72/3ade50e85cc5.jpg.html)
Определил причину, когда ошибка возникает. Если мой tzx (test_load.tzx) загружать не трогая — картинка загружается без ошибок. А вот если после загрузки лоадреа нажать паузу, а затем продолжить — загружается уже с ошибкой. Можно попробовать загрузить несколько раз перезапустив лоадер, бывает случаются успешные случаи.
Отсюда можно сделать предположение, что баг возникает на начальном этапе загрузки и содержимое загружается с каким-то сдвигом.
Barmaley_m
21.05.2013, 11:21
Отсюда можно сделать предположение, что баг возникает на начальном этапе загрузки и содержимое загружается с каким-то сдвигом.
Интересно, спасибо. Там при старте загрузки, действительно, есть фрагмент, не очень точно выверенный по таймингу. Мне уже лень было его выравнивать, казалось, что несколько тактов не окажутся критичными, и на эмуляторе заработало. Попробую пофиксить это, и тогда проверим еще раз.
---------- Post added at 10:21 ---------- Previous post was at 10:20 ----------
Но из хороших новостей - то, что загрузка проходит до конца (хоть и с ошибкой). Если бы произошел срыв синхронизации ФАПЧ, как это у меня часто бывало в процессе наладки загрузчика - то долго бы оно не продержалось, вылетело бы с ошибкой до окончания загрузки. А так, получается, оно все биты принимало нормально, но, похоже, со сдвигом.
Barmaley_m, я так понимаю что предложенный тобой протокол записи кардинально отличается от защитого в ПЗУ?
там вроде как то так
/\__/ \_/\
0 1 1 0 0
взависимости от частоты смены фронта
При реализации формата я делал упор на устойчивость к типичным искажениям сигнала магнитофона, а именно: отличающаяся на разных магнитофонах скорость записи, ограниченный спектр пропускаемых частот. Так как оригинальный кассетный формат Sinclair весьма неприхотлив к качеству записи и состоянию кассеты - то я постарался сделать новый формат таким, чтобы он не уступал, а по возможности - и превосходил оригинальный формат в этом. Время между ближайшими фронтами сигнала было выбрано таким же: 0.25мс. В результате требуемый диапазон частот составляет 2кГц, причем его верхняя часть может быть даже подрезана. Я специально обрабатывал сигнал фильтром Баттерворта с частотой среза около 1700Гц (при этом 2кГц, хоть и ослабленная, но немного пропускается), и загрузка происходила без ошибок. Также я менял скорость записи в пределах +25% / -30%, в том
числе плавно во время загрузки - и это тоже не приводило к ошибкам. Справедливости ради следует заметить, что оригинальный формат имеет примерно такие же требования к скорости и полосе частот сигнала.
А какова полоса MFM при расстоянии между фронтами в 2 раза меньше, чем у тебя? Что-то мне подсказывает, что 2400 Гц. Так что я не вижу выгоды в 8b/10b со стороны полосы.
У Манчестера при той же частоте, что у MFM, вообще полоса 1200 Гц должна быть... Или я неправ?
По поводу формата - ещё хотелось бы иметь файл разбитым на блоки, чтобы можно было перематывать назад плохо прочитанное.
Я не вижу выгоды в 8b/10b со стороны полосы.
зато со стороны скорости есть выгода.
По поводу формата - ещё хотелось бы иметь файл разбитым на блоки, чтобы можно было перематывать назад плохо прочитанное.
а это формат чего? обычный tap тоже можно так сделать, лоадер только напиши соответствующий.
Сообщение от alone Посмотреть сообщение
Я не вижу выгоды в 8b/10b со стороны полосы.
зато со стороны скорости есть выгода.
Со стороны скорости как раз проигрыш - на 25%.
Со стороны скорости как раз проигрыш - на 25%. по ходу просто кто-то что-то недопонял.
Поэтому, если все данные нулевые - то формат 8b/10b дает приращение скорости записи в 1.6 раза, если все единицы - в 3.2 раза, а если данные содержат примерно одинаковое количество нулей и единиц, что имеет место в случае компрессированных данных - то средняя скорость записи выше оригинала в 2.4 раза.
psb, ещё раз: формат 8b/10b при частоте следования фронтов 2400 Гц (полоса, по экспериментам автора - 1700 Гц) даёт скорость 1920 бит/с. Манчестер же при частоте следования фронтов 4800 Гц (полоса 1200 Гц) даёт скорость 2400 бит/с.
psb, ещё раз: формат 8b/10b при частоте следования фронтов 2400 Гц (полоса, по экспериментам автора - 1700 Гц) даёт скорость 1920 бит/с. Манчестер же при частоте следования фронтов 4800 Гц (полоса 1200 Гц) даёт скорость 2400 бит/с.
Время между ближайшими фронтами сигнала было выбрано таким же: 0.25мс.
т.е. около 4кгц. что дает полосу в 2кгц.
блин, alone, в первом посте все расписано в деталях, все говорят, что оно по факту быстрее.
"топик не читай, комменты оставляй".
Barmaley_m
21.05.2013, 21:41
т.е. около 4кгц. что дает полосу в 2кгц.
Не около 4кГц, а точно 4кГц частота следования бит, а требуемая полоса пропускания тракта магнитофона составляет ровно 2кГц по теореме Котельникова. Если каждый бит представить в виде отсчета сигнала, полоса которого ограничена 2кГц, то восстановление этого сигнала возможно, если вести дискретизацию с частотой 4кГц.
Скорость записи, таким образом, составляет 4000бит/с брутто, но поскольку для кодирования каждого байта используется 10 бит - то полезная скорость составляет 400 байт в секунду, независимо от их состава.
Я вел речь о фильтре с частотой среза 1700Гц потому, что это был фильтр невысокого порядка (2-3), имеющий плавный спад частотной характеристики, поэтому частоты до 2кГц включительно подавляются им неполностью. И того, что оставалось, было достаточно, по крайней мере, для корректной загрузки под эмулятором unreal. Сейчас займусь более подробно выяснением причин, почему плохо грузится на спектакуляторе и реале. Возможно, мне потребуется для этого собственный эмулятор Z80 с модулем точной эмуляции тракта магнитофона. Это позволит мне, например, фиксировать точные моменты времени, когда загрузчик опрашивает входной сигнал и, соответственно, искать, где там возможные проблемы.
Barmaley_m, а как же реалы?
кстати у тебя пилоттон есть?
а как же реалы?
на реалах ваще мегаудобно реалтайм процессы отлаживать, да. он всегда этим славился...
Barmaley_m
21.05.2013, 23:18
кстати у тебя пилоттон есть?
Есть пилоттон. Я поначалу хотел сделать такой же пилоттон, как на оригинальном загрузчике. Он хорошо себя зарекомендовал, да и звук ностальгический. Но пришлось повысить слегка частоту пилоттона, потому что оригинальный был не кратен целому числу битовых интервалов. Тот пилоттон, который у меня сейчас используется, состоит из последовательности бит "11001100...". В качестве синхроимпульса в конце пилоттона используется "10", после чего идут биты данных. Загрузчик, поймав пилоттон, первое время измеряет время между фронтами. После 256 фронтов результат измерения пересчитывается в значения, которыми инициализируется ФАПЧ. После этого запускается ФАПЧ, и остаток пилоттона загружается уже той же подпрограммой, которая грузит биты. Поэтому бордюрные эффекты при загрузке пилоттона меняются, и на поздней стадии его загрузки используются те же цвета, что и для загрузки данных, что отличается от оригинального загрузчика, где весь пилоттон отображается красным и голубым цветами.
обычный tap тоже можно так сделать, лоадер только напиши соответствующий.
Ну всё же это уже не обычный tap, согласись. И формат деления на блоки надо делать сразу. Можно предусмотреть и избыточность для надёжности. По возможной плотности записи скажу, что когда у меня не было дисковода, то почти весь софт был у меня на кассете в двойной плотности. Проблем со считыванием не было. Кассеты обычные, но не левые.
Ну всё же это уже не обычный tap, согласись.
абсолютно обычный тап. просто лоадер синхронизироваться будет не по пилоттону, а по данным.
Vadim, Ты когда игру допишешь?
---------- Post added at 10:21 ---------- Previous post was at 10:19 ----------
Есть пилоттон. Я поначалу хотел сделать такой же пилоттон, как на оригинальном загрузчике. Он хорошо себя зарекомендовал, да и звук ностальгический. Но пришлось повысить слегка частоту пилоттона, потому что оригинальный был не кратен целому числу битовых интервалов. Тот пилоттон, который у меня сейчас используется, состоит из последовательности бит "11001100...". В качестве синхроимпульса в конце пилоттона используется "10", после чего идут биты данных. Загрузчик, поймав пилоттон, первое время измеряет время между фронтами. После 256 фронтов результат измерения пересчитывается в значения, которыми инициализируется ФАПЧ. После этого запускается ФАПЧ, и остаток пилоттона загружается уже той же подпрограммой, которая грузит биты. Поэтому бордюрные эффекты при загрузке пилоттона меняются, и на поздней стадии его загрузки используются те же цвета, что и для загрузки данных, что отличается от оригинального загрузчика, где весь пилоттон отображается красным и голубым цветами.
Вот судя по скрину сделанному на реале он у тебя начинает грузить еще с пилоттона а потом срывается.
Ты когда игру допишешь?
Не оффтопь. Я тебе отвечал уже.
Vadim, где? там почистили раньше чем я прочитал :)
Если что, есть программа Octave, которая может исполнять код Matlab и которая бесплатная.
Кроме того, ничто не мешает перевести конвертор на другой язык программирования. Я просто делал его на Матлабе для тестирования загрузчика, т.к. это было для меня наиболее быстрым и простым решением. Алгоритм там простой, конвертор кодированием 8b/10b не занимается, а просто переводит 16-битный сигнал из формата wav в однобитный сигнал формата tzx. Впоследствии я планировал сделать другой, более эффективный конвертор, который бы использовал формат tzx более рационально, так что размер tzx-файлов был бы существенно меньше.
Может лучше перевести с матлаба на язык R, среда для которого бесплатна?
---------- Post added at 10:16 ---------- Previous post was at 09:37 ----------
есть еще такой довольно важный вопрос - каким образом для этого формата записи можно реализовать автостарт магнитофона? Т.е. как определить в эмуляторе, что программа начала чтение с магнитофона?
С существующими алгоритмами новый формат не дружит, отчего и происходит ошибка чтения - эмулятор детектит окончание чтения и делает стоп магнитофона. Возможно можно доработать процедуру загрузки для совместимости с существующими алгоритмами автостарта?
---------- Post added at 10:23 ---------- Previous post was at 10:16 ----------
Чтобы загрузчик нового формата дружил с автостартом, нужно чтобы он учитывал, что магнитофон остается в режиме play в течении 0.5-1 сек, если соблюдаются следующие условия:
1) порт опрашивается чаще чем 96 тактов
2) значение PC соответствует предыдущему опкоду IN
3) изменился только один регистр из следующих: A,B,C,D,E,H,L
4) изменение регистра было на ±1
5) условия 1-4 выполнились 8 раз подряд
6) над прочитанным значением производится операция AND 32 или AND 64
Без поддержки автостарта новый формат записи врядли получит распространение, т.к. делает загрузку в эмуляторах неудобной.
а есть описанный стандарт для автостарта? или это одна конкретная реализация?
да и как бэ зачем делать хитрый (интересный) загрузчик, которым будет удобно (читай, незаметно) пользоваться в эмуляторе?
а есть описанный стандарт для автостарта? или это одна конкретная реализация?
да и как бэ зачем делать хитрый (интересный) загрузчик, которым будет удобно (читай, незаметно) пользоваться в эмуляторе?
Что значит зачем - люди привыкли что достаточно load "" набрать и можно откинуться на спинку кресла и наблюдать за процессом загрузки - все само включается, грузится и выключается. А так нужно кнопки постоянно переключать, причем вовремя успевать, следить за звуком...
Стандарт автостарта я выше описал.
Barmaley_m
24.05.2013, 01:05
Может лучше перевести с матлаба на язык R, среда для которого бесплатна?
А чем бесплатный GNU Octave (http://www.gnu.org/software/octave/) не устраивает?
Вообще это временный конвертор, который я использовал для целей отладки. На Матлабе писал, чтобы быстро получить результат, остальное не заботило. Выложил потому, что на данный момент другого нет. Когда полностью будет налажен формат, учитывая сообщенные в этой теме отрицательные результаты испытаний - появится смысл сделать другой, лучший конвертор, скорее всего, на C++. И не из формата wav, а из того же tap, чтобы сразу обрабатывать много блоков данных, как будто копировщиком скопировал.
Чтобы загрузчик нового формата дружил с автостартом, нужно чтобы он учитывал, что магнитофон остается в режиме play в течении 0.5-1 сек, если соблюдаются следующие условия:
Что-то уж больно жесткие условия. С ними я совместимости не могу сделать аж никак. Разве только во время ожидания пилоттона и первой стадии его загрузки, что делается в моем загрузчике таким же кодом, как в оригинале.
И да, присоединяюсь к вопросу psb: кто принял такой стандарт и в каких эмуляторах он используется?
---------- Post added 24.05.2013 at 00:05 ---------- Previous post was 23.05.2013 at 23:59 ----------
А так нужно кнопки постоянно переключать, причем вовремя успевать, следить за звуком...
Формат разрабатывался, главным образом, не для использования на эмуляторе, а для использования на реале, с реальными магнитофонами. Если в большинстве эмуляторов применяется ускорение процесса загрузки, так что в реальном времени проходят секунды - какой смысл увеличивать плотность записи, заботиться об устойчивости к помехам?
да и как бэ зачем делать хитрый (интересный) загрузчик, которым будет удобно (читай, незаметно) пользоваться в эмуляторе?
Как бэ зачем делать хитрый (интересный) загрузчик, который
а. не работает на реалах
б. не имеет нормальных средств перевода в свой формат и обратно
в. не обеспечивает защиту от сбоев
г. никому по-настоящему не нужен.
Каждый, кто в своё время плотно работал с лентой на спектруме, занимался тем, что разрабатывал свой формат записи, который был лучше, чище, быстрее, красивее etc. Где они, все эти форматы? В рамках в Третьяковской галерее висят? Кто их использует? Да никто, это просто часть истории спекрума.
Мое сугубо личное мнение, что в настоящее время эта разработка представляет лишь академический интерес, как любая другая разработка такого рода. Никакой практической пользы. Никакой.
Теоретическая польза есть - фазовая модуляция, фазовая манипуляция бла-бла-бла.
http://www.wired.com/images_blogs/gadgetlab/Wrenchware-3%201.jpg
Что значит зачем - люди привыкли что достаточно load "" набрать и можно откинуться на спинку кресла и наблюдать за процессом загрузки - все само включается, грузится и выключается.
да, и желательно мгновенно и без полосок. для этого интересные загрузчики только вредны.
Как бэ зачем делать хитрый (интересный) загрузчик, который
а. не работает на реалах
б. не имеет нормальных средств перевода в свой формат и обратно
в. не обеспечивает защиту от сбоев
г. никому по-настоящему не нужен.
именно академический интерес. пункты а-б-в - временные.
а так и сам спектрум никому по-настоящему не нужен, просто часть истории пк.
а так и сам спектрум никому по-настоящему не нужен, просто часть истории пк.
Ещё один могильщик. Кто вас сюда засылает?
мы сами приходим, покой сторожим...
Ещё один могильщик. Кто вас сюда засылает?
А вас? Людей с искаженным восприятием реальности?)
И да, присоединяюсь к вопросу psb: кто принял такой стандарт и в каких эмуляторах он используется?
Из тех что знаю - ZXMAK2, ZERO, SpecEmu - точно, еще несколько эмуляторов но каких именно не помню - давно уже этот вопрос обсуждали на WOS. Вроде этот-же алгоритм в Spectaculator используется. Ну в и других эмуляторах с поддержкой автостарта.
---------- Post added at 01:40 ---------- Previous post was at 01:35 ----------
Формат разрабатывался, главным образом, не для использования на эмуляторе, а для использования на реале, с реальными магнитофонами. Если в большинстве эмуляторов применяется ускорение процесса загрузки, так что в реальном времени проходят секунды - какой смысл увеличивать плотность записи, заботиться об устойчивости к помехам?
ты немного не понял, суть автостарта не в ускорении загрузки, а в том что магнитофон автоматически включается/выключается в режим проигрывания как только программа начинает читать магнитофон. Т.е. не нужно дергаться, нажимая Play/Stop - все происходит автоматически. Набираешь LOAD "" <ENTER> и магнитфон сам включился в режим проигрывания, закончилась загрузка и магнитофон сам остановил режим проигрывания. Это мега-удобно! Привыкаешь настолько что потом испытываешь дискомфорт от необходимости вручную включать выключать магнитофон.
---------- Post added at 01:43 ---------- Previous post was at 01:40 ----------
Что-то уж больно жесткие условия. С ними я совместимости не могу сделать аж никак. Разве только во время ожидания пилоттона и первой стадии его загрузки, что делается в моем загрузчике таким же кодом, как в оригинале.
если не будет поддержки автостарта, то большинство юзеров не сможет открыть tzx файлы в твоем формате, т.к. магнитофон будет автоматически стопаться. Не каждый додумается лезть в настройки отключать автостарт, чтобы потом дергаться включая/выключая проигрывание. В начале этой ветки - наглядный пример с Tape loading error, который именно из за отсутствия поддержки автостарта возникает.
Почему это проблематчино не представляю - ты сам говорил что в загрузчике есть свободные такты, если существующий IN не подходит, то можно добавить холостой.
Вот что меня реально выбесило — автостарт в ZXSpin. Этот эмулятор хорош, тестирую на нём свой код в slow mem. Есть ULAPlus, но... работа с лентой это нечто. При открытии tzx/tap файла он обнуляет память, подпихнуть другой tzx в процессе загрузки невозможно. ULAPlus в режиме пентагона не хочет работать, и отдельно не влючается никак.
Автору топика по поводу высказываний о нужности данного ладера. Он нужен и точка! Я даже его в своей игре использую, пока тоже довожу до ума код.
Загрузка с ленты — очень интересная тема! Для поднятия боевого духа все смотрим это демо http://pouet.net/prod.php?which=53846
Barmaley_m
25.05.2013, 15:25
Обновление версии. Интересующихся приглашаю провести испытания!
В первой версии загрузчика между пилоттоном и началом данных была не строго соблюдена выдержка по времени, что могло быть причиной неудачной загрузки на некоторых эмуляторах и реалах. Теперь она соблюдается с точностью до 2 тактов. Также улучшена обработка ситуации, когда пилоттон обрывается. Первая версия загрузчика при этом вылетала с ошибкой, а новая - возвращается в режим ожидания пилоттона. Также я разместил стек в быстрой памяти, что должно уменьшить вероятность некорректной работы на реалах с медленной памятью, т.к. обращения к медленной памяти теперь происходят только для размещения загруженных данных в ней.
Следуя пожеланиям телезрителей, я также сделал более дружественную версию пакета для тестов. Прилагается tap-файл, в котором находится тестовая программа на бейсике, загрузчик, сохранялка и картинка. tap-файл можно загрузить в эмуляторе или преобразовать в звук и загрузить на реале. После старта программы пользователю предлагается возможность сохранить картинку в формате 8b/10b на кассету, а затем загрузить ее. Программировать или совершать какие-то сложные манипуляции с файлами при этом не требуется. Если загрузка в новом формате произошла с ошибкой - программа вылетит с сообщением Tape loading error, перезапустить ее можно командой GO TO 30.
Удалил вложение, перевыложу в первом сообщении темы.
SoftLight, не достаточно - магнитофон не мрз плеер - у него лента тянется
Barmaley_m
26.05.2013, 00:44
не достаточно
Человек помог чем смог. Я думаю, не стоит придираться. Надеюсь, что кто-нибудь с магнитофоном сможет провести тест, тем более что новый пакет удобнее в использовании.
Следуя пожеланиям телезрителей, я также сделал более дружественную версию пакета для тестов. Прилагается tap-файл, в котором находится тестовая программа на бейсике, загрузчик, сохранялка и картинка.
а можно еще выложить TZX с самой картинкой в 8/10 формате? :v2_dizzy_photo:
Barmaley_m
26.05.2013, 02:46
а можно еще выложить TZX с самой картинкой в 8/10 формате?
Мой существующий конвертор генерирует слишком большие (сотни килобайт) tzx-файлы в этом формате. Существует возможность оптимизации так, чтобы размер tzx-файла был всего в ~2 раза больше, чем размер полезных данных, однако я еще не завершил работу над программой-конвертором. В этой теме в сообщении №13 (http://zx.pk.ru/showpost.php?p=602224&postcount=13) от DDp приложено несколько таких tzx-файлов, можно их попробовать.
Человек помог чем смог. Я думаю, не стоит придираться. Надеюсь, что кто-нибудь с магнитофоном сможет провести тест, тем более что новый пакет удобнее в использовании.
Я не придираюсь
Но это загрузчик с ленты. без ленты неполный тест :(
Исправленная версия стала хорошо грузить на спектакуляторе.
Интересно, на сколько алгоритм устойчив к плаванью скорости загрузки? Ведь стандартный загрузчик к подобным искажениям весьма устойчив.
perestoronin
26.05.2013, 13:59
на сколько алгоритм устойчив к плаванью скорости загрузки?
Поскольку нет магнитофона-реала, то нужен полноценный эмулятор магнитофона, с плавающими параметрами, манипулируя которыми можно тестировать устойчивость загрузчика. Возможно какие-то аудио-редакторы со скриптовой автоматизацией сгодились бы для этого.
Записывалка (128K, TR-DOS) - генерит loader и (те же самые) 12 картинок.
saver.scl.7z (https://yadi.sk/d/mRbw-IJJQlK_-w)
Поскольку нет магнитофона-реала, то нужен полноценный эмулятор магнитофона, с плавающими параметрами
:v2_laugh: Эмулятора нет, есть реальный магнитофон. Извините, если плохо "плавает". :v2_wink2:
realtape1 (wav csw mp3) - записано с zxevo.
http://yadi.sk/d/qrFQLGKh5B3rC
http://yadi.sk/d/m5OcxGII5B3sq
http://yadi.sk/d/A9BozfEf5B3ts
realtape1_copy (wav csw) - считанное, повторно записано на другую кассету.
http://yadi.sk/d/xHF5Ki4k5B3k2
http://yadi.sk/d/SCljQ-FZ5B3oe
realtape2 (wav csw) - записано с unreal (scorpion mode), кассета по-хуже.
http://yadi.sk/d/7c72B2NR5B3vI
http://yadi.sk/d/Y6a7o0e75B3wO
загрузка:
на zxevo (вообще, я не работал на нем с магнитофоном) - ошибки
wav на RealSpectrum 0.97.26 - ok
csw на Unreal 0.38 - ok
Думаю, качество входного компаратора будет сильно влиять на этот формат.
Barmaley_m
26.05.2013, 18:00
Интересно, на сколько алгоритм устойчив к плаванью скорости загрузки? Ведь стандартный загрузчик к подобным искажениям весьма устойчив.
Подстройка к меняющейся скорости загрузки - это центральная тема загрузчика, в основном обуславливающая его сложность. Применяется ФАПЧ. Пределы подстройки: +25%/-30% от номинальной скорости. Оригинальный загрузчик имеет примерно такую же область допусков. Проверял на unreal путем обработки wav-файла в CoolEdit, а затем преобразования в tzx. Загрузка идет надежно под этим эмулятором как при постоянной смещенной скорости, так и при плавающей скорости в обозначенных пределах.
Другое дело, что ФАПЧ не обеспечивает мгновенную реакцию на изменение скорости, в отличие от метода ожидания следующего фронта, который применен в оригинальном загрузчике. Если окажется, что на реальных магнитофонах скорость скачет слишком быстро - то от ФАПЧ придется отказаться. Но если не окажется - то этот метод должен обеспечить лучшую надежность загрузки, устойчивость к шумам и прочим искажениям.
---------- Post added at 15:48 ---------- Previous post was at 15:43 ----------
загрузка:
на zxevo (вообще, я не работал на нем с магнитофоном) - ошибки
Спасибо за проведенные испытания! Такой вопрос: а оригинальный синклерский загрузчик работает на этом компе нормально с тем же магнитофоном и кассетами?
---------- Post added at 16:26 ---------- Previous post was at 15:48 ----------
Скачал realtape1.wav и realtape1_copy.wav. Сигнал выглядит интересно, особенно на копии. После обработки моим конвертором в tzx, загрузились на unreal3.73 без ошибок все файлы как с оригинала кассеты, так и с копии. realtape2 пока не проверял, надо сбегать по делам.
---------- Post added at 17:00 ---------- Previous post was at 16:26 ----------
Проверил realtape2 ("плохая кассета"). Сигнал там действительно выглядит хуже, чем на первой кассете, но грузится на ура (под unreal).
а оригинальный синклерский загрузчик работает на этом компе нормально с тем же магнитофоном и кассетами?
Повторяю, я не работал на нем с магнитофоном.
Провёл ревизию кабелей, перепаял... На ZXEvo без ошибок.
realtape1_2 (wav csw) - пара файлов без загрузчика, слегка задерживал вращение подающей бобинки в кассете.
http://yadi.sk/d/Oq7QvOAM5BUbe
http://yadi.sk/d/x8ivvJSt5BUes
Barmaley_m
26.05.2013, 18:56
нужен полноценный эмулятор магнитофона, с плавающими параметрами, манипулируя которыми можно тестировать устойчивость загрузчика. Возможно какие-то аудио-редакторы со скриптовой автоматизацией сгодились бы для этого.
Для этого лучше всего подходит Matlab. Берется wav-файл, в него вносятся всевозможные искажения типа фильтров, шума, колебаний скорости, кратковременных падений уровня сигнала и Бог знает чего еще. Потом он сохраняется, конвертором преобразуется в tzx или еще что-нибудь, и скармливается загрузчику. Я, конечно, займусь этим, если тесты на реалах окажутся более-менее успешными.
---------- Post added at 17:56 ---------- Previous post was at 17:41 ----------
Проверил realtape1_2.wav с колебаниями скорости. Загрузилось на ура. ФАПЧ рулит :)
realtape1_3 (wav csw) - пара файлов без загрузчика. Продолжил издеваться над скоростью.
Первый:
Unreal - ok
RS - ok
Ленинград - ok
ZXEvo - ошибка на пилот-тоне. Видимо уже сказывается передискретизация сигнала в AVR.
Второй: ошибка везде.
http://yadi.sk/d/rgr8pQsB5Bc-K
http://yadi.sk/d/ecjAHPPt5Bc2G
Barmaley_m
26.05.2013, 19:40
Ленинград - ok
Это реал? Какая модификация?
Вообще, конечно, звук порублен неслабо. Я, когда жил на реале с магнитофоном, никогда не встречал кассет с такими проблемами скорости записи :) Но загрузилось! У меня первый файл тоже пошел на unreal.
Второй: ошибка везде.
Напомнило анекдот:
Нашим лесорубам в Сибири подарили суперсовременную японскую бензопилу. Ну и решили наши рабочие ее испробовать. Взяли они небольшое березовое полено...
"Вжи-и-х"- сказала пила.
"У-у-у мля..."- сказали рабочие.
Взяли бревно побольше...
"Вжи-и-и-и-и-х"- сказала пила.
"У-у-у-у-у-у мля..."- сказали рабочие.
Взяли огромадное бревно из векового дуба...
"Вжи-и-и-и-и-и-и-и-и-и-х"- сказала пила.
"У-у-у-у-у-у-у-у-у-у мля"- сказали рабочие...
Взяли рельс...
"Бздяк"- сказала пила...
"А-а-а мля!!!"-сказали рабочие.
Ленинград - ok
Это реал? Какая модификация?
Обычный Ленинград, плата 88г. Забыл добавить - компаратор на 561ЛН2.
---
Проверил на Компаньон-2 (http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%B0%D0%BD%D1%8C%D0%BE%D 0%BD_%28%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82 %D0%B5%D1%80%29) - ошибка на идеальном пилот-тоне. У него своеобразный компаратор, иногда приходится подстраивать уровень сигнала по гисторгамме (taper (http://www.worldofspectrum.org/infoseekid.cgi?id=0025418)).
Стоит перепроверить на аналогичных компах на Т34ВГ1(КА1515ХМ1-216) и на Балтиках.
суть в том что магнитофонам (особенно старым) характерна детонация. Вот как загрузчик справится с записью при детонации - весьма интересно... Жалко, что реала нет под рукой, я бы протестил на разных кассетниках начиная от Dual'а и заканчивая дерьмовеньким кассетным плеером...
Barmaley_m
26.05.2013, 22:28
Проверил на Компаньон-2[/URL] - ошибка на идеальном пилот-тоне. У него своеобразный компаратор, иногда приходится подстраивать уровень сигнала по гисторгамме.
Хм, а как проявляется ошибка? Загрузка не начинается или вылетает? Оригинальный загрузчик на этом компе работает?
---------- Post added at 20:42 ---------- Previous post was at 20:41 ----------
суть в том что магнитофонам (особенно старым) характерна детонация. Вот как загрузчик справится с записью при детонации - весьма интересно...
Детонация - это же колебания скорости вроде. До сих пор все тесты показывали, что с ними загрузчик справляется хорошо.
---------- Post added at 21:28 ---------- Previous post was at 20:42 ----------
Жалко, что реала нет под рукой, я бы протестил на разных кассетниках начиная от Dual'а и заканчивая дерьмовеньким кассетным плеером...
А реал тут даже не нужен. Если есть возможность записать звук на магнитофон, а потом оцифровать его - то выкладывай, я на эмуляторе проверю, как после такой манипуляции загрузчик справляется.
Если есть возможность записать звук на магнитофон, а потом оцифровать его - то выкладывай, я на эмуляторе проверю, как после такой манипуляции загрузчик справляется.
WAV есть? Могу попробовать.
загрузка:
на zxevo (вообще, я не работал на нем с магнитофоном) - ошибки
wav на RealSpectrum 0.97.26 - ok
csw на Unreal 0.38 - ok
Думаю, качество входного компаратора будет сильно влиять на этот формат.
ZXMAK2 v2748 из wav файла, конфиг PENTAGON - ok
ZXMAK2 v2748 из wav файла, конфиг PENTEVO - ok
Очень неудобно что нужно отключать автостарт.
Barmaley_m
26.05.2013, 23:09
Очень неудобно что нужно отключать автостарт.
Что поделаешь. Автостарт для этих эмуляторов разрабатывался тогда, когда моего формата еще не было. Не могу я сделать автостарт по таким требованиям, как ты описал. Слишком многое придется в загрузчике перелопачивать. Сейчас еще не тот этап, надо сначала убедиться, что он надежно работает.
И вообще, в tzx-файлах есть маркеры останова ленты - так что эмулятору даже не нужно определять, когда загрузчик завершает работу.
---------- Post added at 22:09 ---------- Previous post was at 22:03 ----------
WAV есть? Могу попробовать.
wav можно сделать, но нет возможности его так выложить, чтобы было удобно скачать. Попробуй скачать tzx-файлы из сообщения №13 (http://zx.pk.ru/showpost.php?p=602224&postcount=13) и преобразовать их в wav, есть же куча утилит.
realtape1_3 (wav csw) - пара файлов без загрузчика. Продолжил издеваться над скоростью.
Первый:
Unreal - ok
RS - ok
Ленинград - ok
ZXEvo - ошибка на пилот-тоне. Видимо уже сказывается передискретизация сигнала в AVR.
Второй: ошибка везде.
http://yadi.sk/d/rgr8pQsB5Bc-K
http://yadi.sk/d/ecjAHPPt5Bc2G
в ZXMAK2 первый читается ок, как из WAV файла, так и из CSW, второй на первой трети экрана tape loading error
---------- Post added at 22:27 ---------- Previous post was at 22:10 ----------
И вообще, в tzx-файлах есть маркеры останова ленты - так что эмулятору даже не нужно определять, когда загрузчик завершает работу.
даже в tzx маркеры редко когда встречаются, а уж в WAV или TAP файле точно никаких маркеров нет, а определять надо.
Barmaley_m
26.05.2013, 23:33
даже в tzx маркеры редко когда встречаются, а уж в WAV или TAP файле точно никаких маркеров нет, а определять надо.
Ну, значит, не судьба. Попробуй посмотри исходник загрузчика и прикинь, можно ли туда добавить холостые IN так, чтобы по тактам ничего не нарушить. Тот автостарт, который ты описал, рассчитан на обнаружение загрузчиков оригинального формата, которые, даже если они нестандартные, работают по одному принципу и используют цикл опроса порта FE с короткими интервалами. У меня подход другой - ФАПЧ.
мне вот интересно, а как детектятся всякие загрузчики со спидлоками, алькатразами и прочей мутью? так же ведь и юзаются блоки tape start и tape stop, не?
Barmaley_m
26.05.2013, 23:58
Мне кажется, что в таких загрузчиках везде одинаковый подход, подпрограмма из ПЗУ LD-EDGE там одна и та же везде используется. Я не вникал в детали этих форматов, но мне кажется, что там везде используется старый добрый FM, разве что, может быть, с нестандартной скоростью, пилоттонами, байтом четности и прочими несущественными мелочами.
---------- Post added at 22:58 ---------- Previous post was at 22:47 ----------
Хотя вот я краем уха слышал, что некоторые защиты прерывали загрузку (т.е. опрос порта магнитофона и прием данных) на время каких-то расксориваний, а сигнал в это время шел. В таких ситуациях, вероятно, автостарт тоже даст сбой.
мне вот интересно, а как детектятся всякие загрузчики со спидлоками, алькатразами и прочей мутью? так же ведь и юзаются блоки tape start и tape stop, не?
алгоритмом который я приводил выше
---------- Post added at 23:08 ---------- Previous post was at 23:04 ----------
Хотя вот я краем уха слышал, что некоторые защиты прерывали загрузку (т.е. опрос порта магнитофона и прием данных) на время каких-то расксориваний, а сигнал в это время шел. В таких ситуациях, вероятно, автостарт тоже даст сбой.
да, если пауза будет слишком длинной, то сработает автостоп, когда загрузчик начнет опять читать сработает автостарт. Конечно если загрузчик проверяет задержку до начала следующего блока, то за счет стоп/старта время нарушится и загузка будет неудачной. Я помню даже что была такая игрушка с защитой, которая на автостарте не хотела грузится, но это редкость.
Barmaley_m
27.05.2013, 00:20
В общем, Александр, учитывая высокую избирательность детектора загрузчиков в твоем эмуляторе, я не вижу никакой возможности реализовать его поддержку в своем загрузчике. Это обусловлено принципом его работы, который ранее в загрузчиках не применялся. Если не веришь - исходник лежит в открытом доступе, можешь сам убедиться.
В общем, Александр, учитывая высокую избирательность детектора загрузчиков в твоем эмуляторе, я не вижу никакой возможности реализовать его поддержку в своем загрузчике. Это обусловлено принципом его работы, который ранее в загрузчиках не применялся. Если не веришь - исходник лежит в открытом доступе, можешь сам убедиться.
высокая избирательность у этого алгоритма для того чтобы нейтрализовать ложные срабатывания. Есть некоторые программы, работа которых мало чем отличается от загрузки с магнитофона, хотя реальную загрузку они в это время не производят :smile:
Если нет возможности подстроить загрузчик под существующий алгоритм, тогда приветствуются предложения как доработать алгоритм, чтобы он понимал и новый загрузчик.
может, вместо того, чтобы проверять условия на предмет "магнитофон остается в режиме play", проверять условия для событий "старт ленты" и "стоп ленты". т.о., загрузчик перед началом загрузки создает событие "старт ленты" (ожидая пилоттон), затем проверяется условие на конец загрузки: лента запущена + не было ни одного in (#fe) за период 0.25мс (или 0.25/2). это все не точно, но смысл такой - ловить не процесс загрузки, а начало и конец. и тогда пофиг, как именно загрузка осуществляется, лишь бы раз в интервал был опрос.
проверяется условие на конец загрузки: лента запущена + не было ни одного in (#fe) за период 0.25мс (или 0.25/2).
довольно много дем и игрушек, в которых in (#fe) выполняется в цикле например чаще чем 90 тактов (0.025 мс), чтения с магнитофона при этом не производится, просто опрашивается клавиатура. Как отличить это от чтения с магнитофона?
Barmaley_m
27.05.2013, 01:47
Можно немного подождать, пока не убедимся, что загрузчик корректно выполняет свою основную функцию на максимально возможном количестве реалов/эмуляторов. После этого он, скорее всего, не будет изменяться, и тогда можно будет посмотреть, какие характерные особенности его работы можно детектировать эмулятором.
довольно много дем и игрушек, в которых in (#fe) выполняется в цикле например чаще чем 90 тактов (0.025 мс), чтения с магнитофона при этом не производится, просто опрашивается клавиатура. Как отличить это от чтения с магнитофона?
пусть условие СТАРТА остается то же, а вот условие не_останова изменить. точнее, добавить условие стопа вместо этого.
т.о., лоадер, хотящий автозапустить магнитофон должен в начале сделать некоторые хитрые манипуляции, аналогичные стандартному лоадеру. все остальное время он должен хотя бы раз в 0.25мс опрашивать порт. после загрузки у программы может быть время на инициализацию, это и будет таймаутом для останова магнитофона.
пусть условие СТАРТА остается то же, а вот условие не_останова изменить. точнее, добавить условие стопа вместо этого.
т.о., лоадер, хотящий автозапустить магнитофон должен в начале сделать некоторые хитрые манипуляции, аналогичные стандартному лоадеру. все остальное время он должен хотя бы раз в 0.25мс опрашивать порт. после загрузки у программы может быть время на инициализацию, это и будет таймаутом для останова магнитофона.
поверь всякие комбинации прорабатывались и тестились, алогоритм который я описывал ранее - это результат анализа множества загрузчиков и поведения софта с портом #FE. Если бы можно было сделать проще, никто не стал бы заморачиваться на такие сложные условия.
Именно что tzx имеет встроенные команды управления лентой
Не работает на реале сером +2. Tape loading error практически сразу же после начала загрузки. На экране ничего не появляется, только "Loading in 8b/10b" вверху, "Tape loading error" - внизу. Сохранил / загрузил экран стандартными средствами basic на том же железе, той же кассете, чтобы исключить проблемы с компьютером - всё ОК.
Barmaley_m, скажи, вот если у тебя растактовки точные в лоадере... как он поведёт себя с M1 циклами Z80? На некоторых схемах там по такту к командам добавляется... Скорпион зелёный например.
Barmaley_m, скажи, вот если у тебя растактовки точные в лоадере... как он поведёт себя с M1 циклами Z80? На некоторых схемах там по такту к командам добавляется... Скорпион зелёный например.
К слову,у зеленого скорпиона Even M1 (http://zx.pk.ru/showpost.php?p=590507&postcount=21) не активный.
Barmaley_m
27.05.2013, 15:58
Что будет на компьютерах, где растактовки отличаются от "чистого" Z80, такого как на Пентагоне или некоторых других "быстрых" клонах - сказать не могу. Кое-какие допуски там, конечно, есть, от которых процесс загрузки не нарушится. Но что будет в реальности - можно сказать, только проведя испытания, хотя бы на эмуляторах, эмулирующих соответствующие задержки.
То, что тест на реале опять не удался, звучит удручающе. Думаю, надо сделать на досуге другой загрузчик, работающий по старому доброму принципу ожидания фронта - и посмотрим, как он будет грузить. Но создание такого загрузчика займет время.
Вчера доделал конвертор в TZX, с эффективным хранением данных в формате 8b/10b так, что размер TZX-файла лишь немного превышает размер полезных данных. Но я использовал блок типа 0x19 (Generalized data), который, как оказалось, не поддерживается ни эмуляторами, ни утилитами конвертации в wav. Вероятно, такой тип блока был недавно добавлен в формат tzx, и никто его толком еще не использовал.
Вот такая повестка дня.
как он поведёт себя с M1 циклами Z80?
в анриле работает и с М1 и без. но это хз...
Но я использовал блок типа 0x19 (Generalized data), который, как оказалось, не поддерживается ни эмуляторами, ни утилитами конвертации в wav.
Только это блок не 0x19, а 0x13 (19 в десятичном представлении). Эмуляторами он поддерживается, просто не теми пользуетесь. В "отечественных" эмуляторах поддержка формата .tzx сделана по остаточному принципу. Не знают наши авторы, что почти вся лицензия шла с турбо загрузчиками, и не хотят это знать.
Вероятно, такой тип блока был недавно добавлен в формат tzx,
Да всегда он был там.
haywire, разве Unreal не поддерживет tzx?
Barmaley_m
27.05.2013, 17:11
Только это блок не 0x19, а 0x13 (19 в десятичном представлении).
Нет, именно 0x19. Все остальные идентификаторы блоков тоже заданы в шестнадцатеричном представлении, даже блок 0x10 (нормальные данные). Я также смотрел исходники конверторов в wav - в них поддерживаются не все типы блоков, но идентификаторы все шестнадцатеричные. Также мои файлы были правильно распознаны ZX-Blockeditor.
Эмуляторами он поддерживается, просто не теми пользуетесь. В "отечественных" эмуляторах поддержка формата .tzx сделана по остаточному принципу.
Каковы бы ни были причины, с ними приходится считаться. Что толку иметь хороший конвертор, если его файлы мало где поддерживаются. unreal поддерживает tzx. Мой старый конвертор на Матлабе создавал такие tzx-файлы, которые я использовал в unreal для тестов, но там используется другой тип блоков - 0x15 (Direct recording)
haywire, разве Unreal не поддерживет tzx?
В tzx довольно много видов блоков, и даже если формально поддержка формата tzx заявлена, может так оказаться, что не все виды блоков реализованы. Когда я пользовался этим эмулятором - натыкался на данные вещи, писАл автору, тогда это был ещё SMT, он просил прислать примеры файлов, реализовывал. В каком состоянии сейчас поддержка формата TZX в данном эмуляторе - не могу сказать. Но зная о том, что лицензии в нашем регионе почётом никогда не пользовались, подозреваю, что не полная.
Проверил на Компаньон-2 - ошибка на идеальном пилот-тоне. У него своеобразный компаратор, иногда приходится подстраивать уровень сигнала по гисторгаммеХм, а как проявляется ошибка? Загрузка не начинается или вылетает? Оригинальный загрузчик на этом компе работает?
Ошибка сразу после красно-голубых полос.
---
Напомню, в Балтиках и компах на Т34ВГ1
Z80 тактикуется от 4 МГц, но за счёт постоянного WAIT эффективная скорость = 3,5 МГц.
Оригинальные загрузчики, конечно, работают.
в анриле работает и с М1 и без. но это хз...
Я имел в виду что... сохранить с M1, загрузить без.
Я имел в виду что... сохранить с M1, загрузить без.
это будет кардинально отличаться от загрузки одного и того же файла с М1 и без?
это будет кардинально отличаться от загрузки одного и того же файла с М1 и без?
По идее не должно, но проверить стоит :)
Barmaley_m
28.05.2013, 15:00
Я тоже думаю, что проверить стоит. По идее, нарушение времянок сохранялки должно привести лишь к небольшому уменьшению скорости записи и некоторому фазовому дрожанию записанного сигнала, но загрузчик должен с этим справиться. По идее. Но испытать все равно необходимо.
И вот еще что. Раз уж в теме появились авторы эмуляторов - то к ним вопрос. Не можете посоветовать, как лучше всего сделать специализированный эмулятор с трактом магнитофона - я хочу составить с его помощью лог работы загрузчика, а именно, в какие моменты вызывалась команда in. Быть может, в логе удастся увидеть какую-нибудь неоптимальность работы загрузчика, и пофиксить ее. Я так понимаю, что можно скачать какую-нибудь либу по эмуляции z80, либо же хакнуть существующий эмулятор Speccy. Что посоветуете?
---------- Post added at 13:00 ---------- Previous post was at 12:57 ----------
P. s. Хотелось бы работать с этим на c/c++ в ms visual studio.
unreal speccy вполне себе c/c++ в ms visual studio.
И вот еще что. Раз уж в теме появились авторы эмуляторов - то к ним вопрос. Не можете посоветовать, как лучше всего сделать специализированный эмулятор с трактом магнитофона - я хочу составить с его помощью лог работы загрузчика, а именно, в какие моменты вызывалась команда 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.
Я имел в виду что... сохранить с M1, загрузить без.
это будет кардинально отличаться от загрузки одного и того же файла с М1 и без?
По идее не должно, но проверить стоит
Всё ещё не проверено? :dizzy_mad_old:
realtape2 (wav csw) - записано с unreal (scorpion mode)
http://yadi.sk/d/7c72B2NR5B3vI
http://yadi.sk/d/Y6a7o0e75B3wO
Или unreal плохо эмулилирует "Скорпионовский M1" ?
Barmaley_m
30.05.2013, 04:28
Проверил 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 ?
Barmaley_m
02.07.2013, 17:23
Barmaley_m, Не появился ли конвертор универсальный и поддержка в tzx ?
Пока не появились. Конвертор будет, а поддержка в tzx будет на уровне блоков общего назначения "CSW recording" только, потому что блоки вида "Generalized data block", для которых я сделал конвертор, не поддерживаются многими эмуляторами.
Я пока застрял на этапе модификации эмулятора для записи журнала работы загрузчика. ZXMAK не получилось скомпилировать (у меня нет VS2010), скачал свежие исходники Unreal, попробую скомпилировать их.
Пока не появились. Конвертор будет, а поддержка в tzx будет на уровне блоков общего назначения "CSW recording" только, потому что блоки вида "Generalized data block", для которых я сделал конвертор, не поддерживаются многими эмуляторами.
Я пока застрял на этапе модификации эмулятора для записи журнала работы загрузчика. ZXMAK не получилось скомпилировать (у меня нет VS2010), скачал свежие исходники Unreal, попробую скомпилировать их.
Можно скачать бесплатную vs 2010 express, она бесплатная
Barmaley_m
02.07.2013, 19:27
Можно скачать бесплатную 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."
Пробовал - бесплатной версией проект не открывается, говорит, что требуется более полная версия. Там используется C#, а VS Express поддерживает только C++, да и тот - без MFC.
Кроме Visual C++ Express Edition бывает и Visual C# Express Edition :)
doorsfan
02.07.2013, 23:24
Я слышал о подобных проектах, но они вроде нацелены на цифровые устройства воспроизведения (такие, как mp3-плееры), а не на магнитофон, т.е. задач устойчивости загрузки к меняющейся скорости записи, ограниченной полосе частот и т.д. не ставилось. Кто-нибудь проверял этот проект на реальных магнитофонах?
k7 абсолютно неработоспособен на реальной 3-головочной 2-тонвальной деке, перепробовал разные алгоритмы, на минимальных битрейтах.
в лучшем случае, ловит пилот-тон и секунду грузит нули в экран.
Не знаю, че там на унриле, но в спектакуляторе все грузятся с ошибками, что на конфигурации Spectrum 48, 128, что на Pentagon 128.
В восьмом всё нормально..
Пробовал - бесплатной версией проект не открывается, говорит, что требуется более полная версия. Там используется C#, а VS Express поддерживает только C++, да и тот - без MFC.
Так нужно было устанавливать не VS c++ express, а VS c# express. Это отдельные продукты. ZXMAK2 не на c++ написан, а на c# ;)
Barmaley_m
15.07.2013, 03:12
Спасибо пользователю TSL - он сделал для меня версию Unreal с протоколированием сигнала магнитофона и исполнения команд In. Сегодня погонял загрузчик и проанализировал протоколы его работы. Обнаружился мелкий баг - в одном из мест задержка была выдержана неточно на 1 такт. Не думаю, что это могло повлиять на надежность работы, поэтому новый релиз пока не делаю. В остальном в логах пока что ничего аномального не наблюдается - алгоритм подстройки скорости работает как и должен, времянки загрузчика выдержаны точно.
Анализ логов пока не завершен - буду реализовывать программы для более скрупулезного анализа. Также есть идея, как можно улучшить алгоритм подстройки - попробую и отпишусь по результатам.
Barmaley_m
15.07.2013, 19:01
Продолжаю вести анализ логов работы загрузчика. Построил нечто напоминающее eye diagram - наложение друг на друга фрагментов сигнала магнитофона, взятых со смещениями, кратными скорости записи. На них же наложил моменты, когда загрузчик выполняет команду IN для опроса порта магнитофона. Получившийся рисунок прилагаю.
Как его интерпретировать. Синие линии (частично закрыты красными) - это изменения сигнала на магнитофонном входе. Красные линии - это моменты выполнения команд In. По горизонтальной оси отложены такты Z80.
Отсюда видно, что в целом загрузчик работает так, как и должен был: опрос порта магнитофона идет в 2 раза чаще битовой частоты, при этом опросы, приходящиеся на середину битового интервала, используются для считывания информации, а те, которые приходятся примерно на моменты фронтов, служат для синхронизации со скоростью записи. Присутствует некоторый разброс, но это нормально до тех пор, пока фронты четко отделены от моментов считывания пустым пространством, что хорошо просматривается на рисунке. Как и задумывалось, информация в среднем считывается ровно посередине между фронтами (или теми местами, где они могли бы быть, в случае нескольких подряд идущих одинаковых бит).
Что мне в этой ситуации не нравится - это то, что моменты фронтов сигнала имеют существенный разброс, хотя сигнал этот не с реального магнитофона, а записан с эмулятора, т.е. практически не искажен. На данной картинке я отобразил примерно 100 идущих подряд бит, а при увеличении количества бит для отображения разброс существенно растет, как будто плывет скорость записи. Возможно, моя программа построения картинки где-то неправильно работает, буду еще разбираться.
Улучшать загрузчик можно в направлении того, чтобы сузить области красных полос при условии, что синие полосы сами имеют маленький разброс. Так что мне надо разобраться сначала с разбросом синих полос, а там видно будет. Также, исходя из дизайна загрузчика, я ожидаю, что сгущение области красных полос, соответствующее моменту считывания, должно быть смещено относительно середины битового интервала на несколько десятков тактов. Так что при необходимости можно будет постараться сместить момент считывания поточнее к центру.
В ходе анализа логов обнаружилась ошибка в программе кодирования и сохранения. Иногда (очень редко) попадаются подряд идущие 5 одинаковых бит. При правильном кодировании такая ситуация должна быть исключена, так что буду еще с сейвером разбираться.
Хорошо-бы анализ проводить на разных ULA, в особенности на оригинальном spectrum 128 с contended memory, т.к. там тайминги будут заметно другие
Barmaley_m
16.07.2013, 13:15
Нашел ошибку в сейвере. Действительно, при некоторых условиях формируется неправильный код, приводящий к возникновению в потоке 5 одинаковых бит подряд. При этом декодированные данные остаются правильными, поэтому данная ошибка долго оставалась незамеченной. Вряд ли это могло быть причиной неработоспособности формата на реалах, поэтому релиз пока тоже делать не буду, просто исправлю ошибку на будущее.
Тайминги программы сохранения во многих местах не выдержаны точно. Быть может, это и есть причина того, что мне пока не удается построить красивые графики, хотя на надежность загрузки это тоже влиять не должно: мелкие колебания скорости загрузчику не помеха. Я планирую сделать давно обещанный конвертор в tzx, тогда битовый поток будет идеальным и лишенным описанных недостатков. На нем можно будет строить и графики.
Что же касается причин, по которым загрузчик не заработал на многих реалах - они пока остаются невыясненными. По результатам анализа логов попробую улучшить алгоритм, а там посмотрим.
ZXMAK, действительно, хорошо бы проводить анализ на разных ULA, но не все сразу. Пока что буду работать с самой простой, "пентагоновской".
Barmaley_m
16.07.2013, 23:00
Сделал новую версию программы-конвертора на языке Си. Доступно к скачиванию в первом сообщении этой темы. Программа теперь записывает выходные данные не только в tzx-файлы, но и в csw-файлы. При этом при сохранении в tzx-файлы можно выбрать тип блока: Generalized data block или CSW recording. Входной файл может быть типа tzx или bin. Для tzx конвертируются все найденные блоки (заголовки и данные); для bin - создается один блок данных с флагом 0xFF, данными из bin-файла и правильной контрольной суммой.
К сожалению, оба использованных типа блоков формата tzx не поддерживаются эмуляторами Unreal и ZX-MAK, поэтому для них единственный рабочий вариант - это использовать выходные файлы формата csw. Также данные эмуляторы не отрабатывают "длинные" паузы в csw-файлах, поэтому при воспроизведении csw-файлов отсутствуют паузы между блоками.
Также данные эмуляторы не отрабатывают "длинные" паузы в 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
17.07.2013, 04:44
кодировка простая - если байт равен 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% длиннее исходных данных.
Может быть, дело в том, что я использую старый тип CSW V1.01 (а не V2)? У версии формата 1.01 в заголовке общее кол-во переключений сигнала (то, что ты, кажется, имел в виду под словом "паузы") не записывается.
не, для версии 1 поток читается до конца файла
Этот-то фрагмент как раз правильный.
хм, попробовал собрал сконвертил, а где там паузы должны быть? :v2_conf2: тул же только один блок производит...
Barmaley_m
17.07.2013, 13:11
а где там паузы должны быть? :v2_conf2: тул же только один блок производит...
Один блок - при конвертации из bin. А при конвертации из tzx может генерироваться столько блоков, сколько было в оригинальном tzx. Следует учесть, что формат входного файла должен быть задан явно в командной строке. Иначе оно и tzx без интерпретации (как bin) обработает.
Оч хочется попробовать на реале этот загрузчик, но с командной строкой не дружу. Может кто нить сделает графический интерфейс к нему?
с Generalized data block не понятно как его расшифровывать, есть детальная расшифровка как перевести Generalized data block в набор пауз?
возможно это поможет http://newton.sunderland.ac.uk/~mikie/tzxform120.html#TZXFORMAT (ID 19)
Barmaley_m
17.07.2013, 14:45
Оч хочется попробовать на реале этот загрузчик, но с командной строкой не дружу. Может кто нить сделает графический интерфейс к нему?
Тесты на реалах широко приветствуются! Но для этого не нужно пользоваться конвертором. В первом сообщении этой темы скачай архив "tape8b/10b_130525.zip", в нем есть tap-файл "test8b10b.tap". Запиши его содержимое на ленту, а потом загрузи на реале. Запустится программа, которая предложит сохранить на ленту блок в формате 8b/10b. Сначала запиши на ленту блок в этом формате, а потом с помощью той же программы можно проверять, как он загружается. В случае ошибки загрузки, для повторного входа в программу, нужно исполнить команду бейсика GO TO 30.
Вот еще есть хороший тестовый пакет (http://zx.pk.ru/showpost.php?p=604456&postcount=83) от DDp. Это образ дискеты, которую необходимо исполнить на реале, включив запись на магнитофоне. На кассету будет записан загрузчик и несколько картинок в формате 8b/10b. После этого делаем ресет, набираем LOAD "" - и наслаждаемся работой. В случае ошибок загрузки программу можно перезапустить командой RUN.
Barmaley_m
17.07.2013, 15:28
Вот я получил еще один, более информативный график по результатам логирования работы загрузчика во время загрузки экрана. В этот раз я использовал сгенерированный csw-файл, в котором времянки были выдержаны идеально. На графике - наложенные гистограммы. Синяя - это фронты сигнала магнитофона. Видно два узких пика, что свидетельствует об идеальной выдержке времянок. Красная гистограмма - это время, относительно фронтов, когда загрузчик исполнял команды IN. В идеале, если бы загрузчик смог точно подстроиться к скорости записи, красные гистограммы тоже должны были бы быть предельно узкими. На практике, как видно, они довольно размазаны, причем с перекосом влево. Загрузка происходила без ошибок, так что пики на красной гистограмме не сливаются. Но все равно, распределение оставляет желать лучшего. Теперь можно пытаться оптимизировать загрузчик с целью сузить красные пики на этом графике.
Barmaley_m
17.07.2013, 15:31
Кстати, версия Unreal с логированием от TSL корректно отрабатывает длинные паузы в CSW-файлах.
Это не связано с тем, что это "моя" версия. Оригинал десофта.
Тесты на реалах широко приветствуются!
Вот, только мафон востановлю, или для начала использую писи (вывод звука).
Ну чтож, первый этап проверки прошёл.
Система:
Робик (компаратор СА3)
nemowave редактор
Записал картинку из "test8b10b.tap". При воспроизведении грузит без ошибок.
транспонированием выводил от -2 до +2 semitones. Без ошибок. Более пилот не ловит. Попробовал во время загрузки плавно скорость менять - в небольших пределах - ошибки нету, скачками - выдаёт, но это и не удивительно.
Сделаю мафон, может, - проверю на нём.
Barmaley_m
17.07.2013, 20:31
транспонированием выводил от -2 до +2 semitones. Без ошибок. Более пилот не ловит.
Странное дело, что только в таких малых пределах ловит. Ты каким методом делал транспонирование? Допускается делать только resampling (то есть как будто скорость записи меняется), а всякие pitch shift существенно искажают сигнал, добавляют в него фронты, которых не было. Я проверял на Resampling, допуски в пределах около +-25% от оригинальной скорости грузятся уверенно, а это существенно больше, чем 2 semitones.
Ты каким методом делал транспонирование?Слева интервал, справа плавный интервал. Какой шаг там - хз.
Проверил это же, только на 7мц - те же яйца. То есть - полёт как и на 3,5.(на 7 мц имеется ввиду - запись и сохранение с удвоенной скоростью.)
PS левым -2 и +2
Вот еще есть хороший тестовый пакет от DDp.
Все картинки загрузились без ошибок с удвоенной скоростью.
Barmaley_m
17.07.2013, 22:03
Слева интервал, справа плавный интервал. Какой шаг там - хз.
По скриншоту трудно сказать, что там за алгоритм применяется. Но попробуй запиши фрагмент своего голоса и обработай. Если после обработки скорость речи не изменилась, а тон изменился - значит это метод Pitch Shift. Если же скорость изменилась, и так, что при понижении тона она стала медленнее, а при повышении - быстрее, то это Resample. Так вот, для обработки сигналов для теста загрузчика годится только метод Resample. Pitch shift вносит множество искажений, и применять его для этих целей нельзя. Когда у реального магнитофона скорость ниже или выше номинальной - то на сигнал это влияет так же, как обработка с помощью Resample.
Если же скорость изменилась
Скорость изменяется.
Когда ставить флажок "обслуживать оригинальную скорость" то скорость не меняется а только тон. Пробовал без флажка.
Вот мафон восстановлю - поиграюсь регулятором скорости.
Barmaley_m
17.07.2013, 23:37
Новый релиз. Файлы можно скачать в первом сообщении этой темы. С помощью нового подхода - анализу работы загрузчика по логам эмулятора - мне удалось повысить точность адаптации часов загрузчика к скорости записи сигнала. Благодаря этому стало возможным снизить константу "быстрой адаптации", что привело к существенному уменьшению фазового дрожания часов загрузчика при условии, что сигнал идет с постоянной скоростью. На приведенной картинке это явно видно: пики команд In сузились и стали более чем в 2 раза выше. Когда рассматриваешь развертку логов, то раньше команды In довольно сильно "гуляли" в окрестности фронтов сигнала, а теперь они практически везде совпадают. Так что можно ожидать повышения надежности работы загрузчика.
Я проверял загрузчик на доступных файлах, которые сгенерировал программой конверсии, а также на файлах с записями с реальной кассеты, которые в эту тему выкладывали пользователи форума. В том числе та запись, где человек пальцем притормаживал магнитофон, из-за чего скорость плавает. Ошибок загрузки вроде нет. Также загрузчик стал надежно грузить файл со скоростью 130% от номинальной (раньше не грузил). Приглашаю всех заинтересованных провести новые тесты на реалах. Спасибо!
Ошибку в сейвере пока не исправлял. Я вообще планирую серьезно перелопатить сейвер, подправить его времянки, которые выдержаны не очень точно. Но пока что он работает достаточно хорошо, так что отработка загрузчика все же кажется мне важнее.
Barmaley_m
17.07.2013, 23:40
Картинку забыл добавить. Вот она.
Один блок - при конвертации из bin. А при конвертации из tzx может генерироваться столько блоков, сколько было в оригинальном tzx. Следует учесть, что формат входного файла должен быть задан явно в командной строке. Иначе оно и tzx без интерпретации (как bin) обработает.
странно, cгенерировал CSW файл открыл в последней версии, паузы между блоками около секунды. А какие должны быть?
Кстати, а ты какую версию ZXMAK2 используешь?
Barmaley_m
17.07.2013, 23:53
А какие должны быть?
Такие и должны быть. Но в версии ZXMAK2 2.7.5.0 [beta] слышимых пауз между блоками нет вообще. Может версия устарела?
Кстати, версия 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
Такие и должны быть. Но в версии ZXMAK2 2.7.5.0 [beta] слышимых пауз между блоками нет вообще. Может версия устарела?
конечно устарела ей уже 4 месяца, эта версия еще в мае выкладывалась. уже скоро месяц как 2.7.5.7 (https://zxmak2.codeplex.com/releases/view/108700) выложена, баги CSW я исправлял в 2756 (10 июня)
Теперь ничё не грузит, вобще, даже пилот не ловит.
Barmaley_m
18.07.2013, 00:04
Привет. Это опять Баба Яга. Серый ZX-Spectrum +2. Tape loading error.
Да что же это такое. Твой опыт портит всю статистику! Можешь оцифровать запись с кассеты, которую ты пытался грузить, и выложить на файлообменник? Попробую хотя бы на эмуляторе загрузить то, что твой спек отказался грузить с кассеты.
Серый ZX-Spectrum +2. Tape loading error.
а ты грузишься с кассеты или врезал свой вход ?
выход со встроенного мафона своеобразный (музыку на нём точно невозможно нормально слушать)
Barmaley_m
18.07.2013, 00:07
Теперь ничё не грузит, вобще, даже пилот не ловит.
Ты турбо отключил? И еще, как проявляется то, что не ловит пилот? Есть ли такое, что короткое время идут красно-голубые полосы, а потом бордюр останавливается на желтом или синем цвете?
Привет. Это опять Баба Яга. Серый ZX-Spectrum +2. Tape loading error.
ты бы файл выложил чтоли, чтобы не гадать на кофейной гуще где ошибка - толи изначально в файле, толи за счет искажений возникает...
Во, в турбе еррор, без турбы загрузилось. Знач стало хуже.
Мафон ушёл из жизни полностью... Головку негде достать... (BRG)
---------- Post added at 23:18 ---------- Previous post was at 23:16 ----------
Или сейвер доделывай, мож он глючит.
---------- Post added at 23:20 ---------- Previous post was at 23:18 ----------
Кстати, в турбе пару полос и эррор на пилоте
Barmaley_m
18.07.2013, 00:23
Во, в турбе еррор, без турбы загрузилось. Знач стало хуже.
Когда у меня на унриле было турбо включено, старая версия загрузчика тоже не ловила пилот. Так что это зависит от тонкостей. В любом случае я не рассчитывал загрузчик на работу в турборежиме, когда данные идут с нормальной скоростью. Там все времянки переколбашиваются.
Или сейвер доделывай, мож он глючит.
Известные мне глюки сейвера не должны критически сказываться на тестах, которые мы сейчас проводим. Да, из-за неточно выдержанных времянок будет немного плавать скорость; из-за ошибки кодирования будут появляться 5-битовые последовательности чаще, чем необходимо. Но загрузчик должен с этим справляться.
Да что же это такое. Твой опыт портит всю статистику! Можешь оцифровать запись с кассеты, которую ты пытался грузить, и выложить на файлообменник? Попробую хотя бы на эмуляторе загрузить то, что твой спек отказался грузить с кассеты.
Нет никаких проблем, вы бы раньше сказали - я бы раньше это сделал. Я ведь тупой бот, и не знаю, что надо. У меня смутные подозрения, что компаратор (или ХЗ что там в кишках Спектрума) как-то не так работает, а кассету я цифрую с мафона, там совсем другая система. Вот пожалуйста оцифровка этой кассеты с мафона, а как цифровать со Спектрума - я не знаю, как и откуда брать сигнал. Если подскажите - сделаю.
http://www.sanarin.ru/download/Untitled7.wav
вот еще пример CSW файла который в unreal неправильно работает, в этом случае файл открывается корректно, но чтото не так с паузами - сразу конец ленты наступает...
Когда у меня на унриле было турбо включено
Какая разница, турбо\нетурбо? Работало же. Всего лишь скорость в два раза выше, и времянки, соответственно те же, но с удвоеной скоростью. Проверяю я то на реале. В качестве касеты использую писи, так что искажений нет.
Головку негде достать... (BRG)
(оффтоп) они запиливаются будь здоров... на маяке у меня такая почти до дыр запилена, но как ни странно звучит!
Barmaley_m
18.07.2013, 00:58
Нет никаких проблем, вы бы раньше сказали - я бы раньше это сделал. Я ведь тупой бот, и не знаю, что надо.
Да ладно, при чем здесь бот... Я и сам раньше не знал, что так можно :)
У меня смутные подозрения, что компаратор (или ХЗ что там в кишках Спектрума) как-то не так работает, а кассету я цифрую с мафона, там совсем другая система. Вот пожалуйста оцифровка этой кассеты с мафона,
Спасибо! Наконец-то мы сможем приблизиться к пониманию того, почему на твоем реале не грузится.
Послушал запись. Сразу заподозрил неладное. Потом посмотрел в звукоредакторе. Нда. Такого качества записи я давно не встречал даже на мафонах! Неудивительно что оно не грузилось. Полоса частот задавлена настолько, что отдельных битов не видно. Даже пилот еле пробивается, хотя его частота в 2 раза меньше битовой частоты. Кроме того присутствует наводка около 4кГц.
Загрузить это шансов нет никаких. Ни с каким угодно хорошим компаратором. Тут не то что загрузчику - тут человеку ничего не видно!Отдельных бит в записи не видно, они пропадают, т.к. очень сильно задавлена полоса частот или сильные фазовые искажения.
Я бы удивился, если бы с записи с таким качеством что-нибудь загрузилось в стандартном формате. Если ты говоришь, что у тебя грузится записанное стандартным синклерским загрузчиком - можешь выложить небольшую запись, сделанную на твоем спеке на ту же кассету в стандартном формате? Просто хочу сравнить и понять, как такое может грузиться.
Головку магнитофона (спековского и того, на котором цифруешь) пробовал спиртом протирать? Такая запись еще часто бывает, если головка загажена.
Фух. У меня прямо гора с плеч. Я-то думал, что дело в несовершенстве загрузчика или зависимости его работоспособности от компаратора, а тут - просто запись плохая.
Послушал запись. Сразу заподозрил неладное. Потом посмотрел в звукоредакторе. Нда. Такого качества записи я давно не встречал даже на мафонах! Неудивительно что оно не грузилось. Полоса частот задавлена настолько, что отдельных битов не видно. Даже пилот еле пробивается, хотя его частота в 2 раза меньше битовой частоты. Кроме того присутствует наводка около 4кГц.
интересно, а если фильтром обработать, можно будет чтото вытянуть?
Barmaley_m
18.07.2013, 01:14
интересно, а если фильтром обработать, можно будет чтото вытянуть?
Мысли прочитал. Я как раз пытался это сделать. Эквалайзером обработал, подавил низкие частоты - потому что они забивали все. Вроде стало лучше выглядеть, на глаз стали различимы биты. Но под эмулятором все равно не грузится. Я не очень большой спец в работе с эквалайзерами, да и инструментов нормальных нет - так, чтобы было видно форму сигнала сразу при подстройке параметров эквалайзера. Но это уже чисто спортивный интерес. Очевидно, что такая запись если и может быть загружена - то только после профессионального ремастеринга.
---------- Post added at 00:14 ---------- Previous post was at 00:13 ----------
Сейчас еще попробую отфильтровать наводку 4кГц - может из-за нее не грузится.
Пожалуйста, вот стандартный загрузчик, грузится без единой проблемы
http://www.sanarin.ru/download/Untitled4.wav
---------- Post added at 01:24 ---------- Previous post was at 01:15 ----------
> Головку магнитофона (спековского и того, на котором цифруешь) пробовал спиртом протирать?
С этой головки грузятся фирменные кассеты, которым по 30 лет. Не имею привычки чинить то, что работает.
Цифрую я с мафона, это отдельный аппарат, с него игры не гружу. Гружу со встроенного мафона спектрума +2. Это маленький мафон, встроенный в Спек, у него вся платка - это один операционник + пассивные элементы, как правильно с неё цифровать - не знаю. Подскажите - сделаю.
Barmaley_m
18.07.2013, 02:13
Спасибо. Такая запись тоже без обработки эквалайзером не загрузится, хотя и выглядит немного чище. Возможно, дело в головке того магнитофона, с которого ты цифровал кассету. В любом случае протирка головки ваткой, смоченной спиртом - это безопасная операция, от которой хуже не станет.
Как правильно цифровать со встроенного мафона - не знаю. Рыться надо в инете, инфу искать, сейчас уже сил нет.
---------- Post added at 01:13 ---------- Previous post was at 00:46 ----------
Можно попробовать такой вариант оцифровки - подключить комп к звуковому выходу Спека+2. Туда вроде как выводится сигнал с магнитофона, правда, после компаратора - но это даже лучше. Большой плюс - не надо вскрывать комп и работать паяльником. haywire - сможешь оцифровать этот сигнал? Для записи в стандартном и 8b10b-форматах. При этом в стандартном формате, если не трудно, запиши что-нибудь поинтереснее, чем пустой экран. Например, SAVE "a" CODE 0,6912 - будет кусочек ПЗУ, там шумоподобные данные. Для возможности более детально проанализировать сигнал.
вот небольшая статья про мафон в +2 со схемой (на чешском)
http://cygnus.speccy.cz/popis_spectrum128plus2_mgf.php
Оцифровки с выхода Спектрума :
сабжеввый формат, не грузится
http://www.sanarin.ru/download/Untitled8.wav
первые 6912 байт ПЗУ, стандартный загрузчик, грузится отлично
http://www.sanarin.ru/download/Untitled9.wav
Barmaley_m
19.07.2013, 00:09
haywire, большое спасибо. Сигнал в этих записях выглядит отлично в обоих форматах. Вероятно, причина плохой записи в тех файлах, что ты раньше присылал - это состояние того магнитофона, на котором шло воспроизведение. Тем не менее, после конвертации в tzx файл в формате 8b/10b не грузится у меня под эмулятором! Буду разбираться. Твои записи в этом плане получаются очень ценными, не только давая отрицательный результат, но и давая мне какие-то зацепки для выяснения причин.
---------- Post added at 23:09 ---------- Previous post was at 21:45 ----------
Изучил, почему не грузится. Хоть импульсы и красивые (после работы встроенного компаратора), их длительность гуляет в широких пределах. Половина битового интервала - запросто. В таких условиях у ФАПЧ нет никаких шансов отследить эту пляску. Что ж - попробую еще реализовать загрузчик на том же принципе, что синклерский, тупое измерение времени между фронтами. Можно даже сделать для начала обработчик сигнала на языке высокого уровня, чтобы проверить, можно ли его загрузить таким методом.
Относительно природы искажений, мне кажется, что скорее всего (хотя это и не заметно на сигнале после компаратора), что-то очень нехорошее делается с полосой частот в аналоговом тракте. Очень высокая неравномерность коэффициента передачи, хотя и не такая, как на тех файлах, что я вчера смотрел. Но это лишь догадки. Одно ясно - синклерский формат оказался более устойчивым к такого типа искажениям, чем 8b10b. Буду думать дальше.
Изучил, почему не грузится. Хоть импульсы и красивые (после работы встроенного компаратора), их длительность гуляет в широких пределах. Половина битового интервала - запросто. В таких условиях у ФАПЧ нет никаких шансов отследить эту пляску.
можно скорость записи в два раза снизить, это увеличит устойчивость к искажениям...
Barmaley_m
19.07.2013, 02:00
можно скорость записи в два раза снизить, это увеличит устойчивость к искажениям...
Если снижать скорость записи - то зачем вообще нужен этот формат? Я так считаю, что он имеет право на жизнь только если обеспечит существенный прирост скорости при сохранении надежности. В противном случае это менять проверенное шило на непроверенное мыло. Нужно еще учитывать конкуренцию от турбированного синклерского формата (с повышением битовой частоты). Кассетные турбы ведь и раньше существовали, только их распространение было ограничено снижением надежности загрузки. Вот и хотелось заполнить этот пробел новым форматом.
Ладно. Посмотрим, что получится после полного переписывания загрузчика. Сможет ли новый загрузчик загрузить файл, присланный haywire.
ram_scan
19.07.2013, 07:38
Если у вас гуляет длительность импульса на половину битового интервала то это все, сливай масло. Как вы значащий момент то будете вылавливать ?
Тут только интергирование остается, по значащему моменту импульс определить нельзя, надо искать передний фронт, по переднему фронту надо делать кучу замеров до заднего фронта, а потом пытаться понять сколько там бит влезло. Но поскольку у вас на полбита минимум длительность гуляет на один бит просчитаться запросто.
Разве только помехоустойчивое кодирование попытаться добавлять...
Кассетные турбы ведь и раньше существовали, только их распространение было ограничено снижением надежности загрузки.
Не знаю, не замечал никакого снижения надёжности. Вот кассета terminator 2. x1.6 turbo, 1991 год. Грузится как новенькая, ни разу не сбоила. А насчёт распространённости - практически все фирменнае загрузчики - турбированные в той или иной степени. Просто из-за того, что сам загрузчик надо загрузить, причём, на стандартной скорости, результирующий выигрыш был не особо впечатляющим.
Barmaley_m
19.07.2013, 21:00
Не знаю, не замечал никакого снижения надёжности. Вот кассета terminator 2. x1.6 turbo, 1991 год. Грузится как новенькая,
Мой кассетный опыт в 1992-1993гг говорит о снижении надежности. Хотя я использовал гораздо более быстрые турбы. Вот ходило у нас в Днепропетровске турбо 3х на базе копировщика Sormos-3 и бейсика "Рапид". Для быстрой загрузки игр или рабочих файлов (которые часто перезаписывались) годилось, а для архивации данных - сомнительно.
Просто из-за того, что сам загрузчик надо загрузить, причём, на стандартной скорости, результирующий выигрыш был не особо впечатляющим.
Это смотря какой загрузчик. В принципе можно сделать турбозагрузчик на сотню с небольшим байт. Это если он скопирует загрузчик из ПЗУ в ОЗУ, релоцирует его и подставит другие значения констант скорости. По сравнению с порядка 30-40кБ данных для средней игры это большая разница, и выигрыш в скорости получается существенный. Другое дело, что в фирменных загрузчиков была навороченная защита, ксорки всякие, и их приходилось долго загружать.
Barmaley_m
20.07.2013, 23:14
Изучал возможность загрузки файла с искажениями магнитофона Spectrum+2 в формате 8b10b альтернативным методом - измерение интервала между фронтами сигнала.
Прежде, чем писать загрузчик на ассемблере Z80, я решил проверить принципиальную возможность загрузки этим методом. Для этого была написана небольшая программа на Матлабе, которая измеряет время между фронтами сигнала и строит гистограмму этих интервалов. Поскольку в формате 8b/10b встречаются интервалы длиной в 1, 2, 3, 4 и 5 битовых интервалов - то логично было бы увидеть на гистограмме 5 пиков. Что я и увидел при обработке одного из вав-файлов в формате 8b/10b, записанного на эмуляторе. Пики четко разделены между собой, что позволяет различать биты путем сравнения измеренного интервала со средним значением между соседними пиками.
Я построил аналогичную гистограмму для wav-файла, присланного haywire. Из нее четко видно, что пики сливаются и, следовательно, различение битов путем сравнения с пороговыми числами интервалов между фронтами невозможно.
Картинки прилагаю.
Быть может, этот файл все же можно загрузить, но уже не на Спеке и не в реальном времени, а с помощью какой-нибудь более умной программы на том же Матлабе, которая бы использовала более тонкий ФАПЧ, чем тот, который в загрузчике. Который бы, к примеру, лучше подавлял фазовое дрожание входного сигнала. Более точно подстраивался к частоте за счет использования чисел с плавающей точкой и имел бы фазовый детектор, который не просто дает ответ вида "1/0", т.е. опережает ли фронт импульса внутренние часы или отстает от них, а также измерял бы, насколько. Может быть, с такими средствами этот файл и можно загрузить, кто знает.
Но я склоняюсь к мысли, что на Спектруме в реальном времени это невозможно. И обусловлено это не качеством загрузчика, а самим форматом 8b/10b, который оказался менее устойчивым к тому типу искажений, которые возникают в магнитофонной системе у Haywire, чем стандартный синклерский формат.
На этом, пожалуй, я сдаюсь и заканчиваю работу над проектом. Спасибо всем, кто участвовал и наблюдал! Опыт был поучительный - надеюсь, не только для меня. Работая над этим форматом и, в особенности, над загрузчиком, я попрактиковался в вещах, которые не делал никогда раньше, и не исключено, что этот опыт пригодится в каких-то будущих проектах.
Синклерский же кассетный формат в очередной раз утер всем нос и заслужил дополнительное почтение. Респект инженерам, которые его разработали.
Ящитаю, начать стоит с того, чтоб проанализировать характер искажений, вносимых в сигнал мафоном. Исходя из этого, думать об алго модуляции, коррекции и детекции сигнала. Уровнем выше делать 8->10 и коррекцию ошибок.
Barmaley_m
21.07.2013, 01:45
Ящитаю, начать стоит с того, чтоб проанализировать характер искажений, вносимых в сигнал мафоном.
Я думаю, вероятнее всего, это искажения вида "неравномерность частотной характеристики". Вероятно, на низких частотах имеется большой горб. Из-за этого сигнал как бы "едет" на длинной волне, компаратор каждый раз сравнивает импульсы на разном участке их фронта. Отсюда и переменное расстояние между фронтами каждый раз.
Я даже считаю, что на нормальном магнитофоне таких сильных искажений быть не должно. У меня был магнитофон "Легенда-404" четвертой (т.е. самой худшей) группы сложности - и то лучше звучал; я звуковой сигнал, оцифрованный в конце 2000х с кассет, записанных на этом маге в начале 90х годов, смотрел в звукоредакторе - конфетка по сравнению с тем, что прислал Haywire. Может быть, у него головка давно не чищена или вообще расстроена, может быть еще что-то... Но факт - что синклерский формат при этом выжил, а 8b10b - нет.
В телекоммуникациях, где находил применение этот формат, обычно нет большой неравномерности АЧХ. Там обычно высокие частоты только задавлены, но низкие хотя бы не выпирают. Я тестировал и 8b/10b с задавленными высокими еще до того, как тему эту открыл. Все грузилось. Но кто же знал, что так будет.
Исходя из этого, думать об алго модуляции, коррекции и детекции сигнала. Уровнем выше делать 8->10 и коррекцию ошибок.
Если делать модуляцию - то вся скорость сойдет на нет. А коррекция тут лучше всего - это эквалайзером обработать сигнал, но это должен быть аналоговый эквалайзер, программно на Спеке его не реализуешь.
Barmaley_m
21.07.2013, 13:16
Хоть я и оставляю формат 8b/10b как бесперспективный для Спектрума, я задумался над интересной задачей - контроль спектра битовой последовательности. В коде 8b/10b подавляется постоянная составляющая, т.е. сам спектр последовательности заполняет всю полосу от 0 до 2кГц, однако на постоянной составляющей имеет нуль. В ходе некоторых размышлений я понял, что в битовой последовательности, содержащей неограниченную информацию, нули могут быть только на конечном количестве частот. Если сделать несколько нулей на низких частотах - там, где, предположительно, АЧХ имеет горб - то может быть удастся победить проблему. В общем, я на досуге попытаюсь разработать или найти другую схему кодирования - а там посмотрим, удастся ли с ее помощью добиться чего-нибудь интересного на Спектруме.
Barmaley_m
21.07.2013, 15:57
Нашел интересную книжку John R. Barry, Edward A. Lee , David G. Messerschmitt "Digital communication", ее 19 глава, посвященная контролю спектра кодированных данных, имеется в свободном доступе. Там как раз рассматривается теория построения блочных кодов, вроде 8b/10b (он является лишь частным случаем). Читаю запоем. Надежда есть!
Barmaley_m
21.07.2013, 18:42
Провел эксперимент на устойчивость форматов к неравномерности частотной характеристики. Обработал две записи, одну в синклерском формате, а другую в 8b/10b, сначала фильтром Баттерворта 4 порядка с частотой среза (по -3дБ) на 1800Гц. Оба формата с этим справились. Затем обработал эквалайзером, сделав пик на частоте 183Гц амплитудой 12дБ и добротностью 2. После этого синклерский загрузчик смог загрузить файл, а 8b/10b - нет. Процесс сорвался на первых же байтах, аналогично тому, как это происходило у Haywire. Поэтому думаю, что я нашел "образцовую" конфигурацию искажений, на которой можно тестировать форматы. Есть идея сделать формат попроще, чем 8b/10b, который был бы не так эффективен в скорости, зато более устойчив к горбам на низких частотах. Этот "компромиссный" формат имеет простое кодирование и немного выигрывает в скорости по сравнению с синклерским. Как сделаю для него сейвер и загрузчик - отпишусь.
ram_scan
25.07.2013, 08:00
Нашел интересную книжку John R. Barry, Edward A. Lee , David G. Messerschmitt "Digital communication", ее 19 глава, посвященная контролю спектра кодированных данных, имеется в свободном доступе. Там как раз рассматривается теория построения блочных кодов, вроде 8b/10b (он является лишь частным случаем). Читаю запоем. Надежда есть!
В любом случае коды типа 8b/10b для работы с лентой не стрельнут. У них широкий спектр, поэтому ФАПЧ будет постоянно пролетать мимо тазика. Такой метод кодирования можно использовать на "линии связи" на которой задержка и крутизна фронта не гуляет.
Магнитофон в этом смысле штука очень капризная (очень сильно гуляет как скорость так и АЧХ/ФЧХ тракта), а для того чтобы от ФАПЧ была реальная польза нужно чтобы сигнал в спектре имел всего один ярко выраженный пик, то есть либо манчестер, либо дифференциальный манчестер.
Собственно очень похожая (почти такая-же но другая, там FM в чистом виде) кухня и реализована в фирменном спековском загрузчике.
На мой взгляд у метода есть реальный запас по увеличению символьной скорости, правда придется добавлять помехозащищенное кодирование (магнитная лента имеет склонность к выпадениям сигнала), причем хэмминг на большой скорости не потянет (будет выпадать пачка мит идущих подряд), и надо использовать пакетный код, что-нть вроде рида-соломона (да дохрена их).
По умозрительным прикидкам символьная скорость будет расти быстрее избыточности корректирующего кода, поэтому выигрыш в 1.5...1.75 раза по сравнению со стандартной я думаю получить можно без снижения надежности считывания по сравнению со стандартной.
На мой взгляд у метода есть реальный запас по увеличению символьной скорости, правда придется добавлять помехозащищенное кодирование (магнитная лента имеет склонность к выпадениям сигнала), причем хэмминг на большой скорости не потянет (будет выпадать пачка мит идущих подряд), и надо использовать пакетный код, что-нть вроде рида-соломона (да дохрена их).
Если на магнитной ленте выпадают биты, то обычно это десятки-сотни бит. С такой коррекцией никаким обозримо простым лоадером не обойдешься.
Еще одна проблема - это сильный завал АЧХ в области высоких частот, неравномерность АЧХ в процессе одной записи, изрядное гуляние скорости, а так же в некоторых случаях фазово-частотные искажения, из-за которых слепляются кобинации 1->0 и 0->1 в нечто среднее и сложноразличимое.
ram_scan
26.07.2013, 07:40
Если на магнитной ленте выпадают биты, то обычно это десятки-сотни бит. С такой коррекцией никаким обозримо простым лоадером не обойдешься.
Еще одна проблема - это сильный завал АЧХ в области высоких частот, неравномерность АЧХ в процессе одной записи, изрядное гуляние скорости, а так же в некоторых случаях фазово-частотные искажения, из-за которых слепляются кобинации 1->0 и 0->1 в нечто среднее и сложноразличимое.
От пылинок выпадают обычно два-три бита (зажеванность ленты не рассматриваем). На самом деле рид-соломон позволяет исправлять и 100 выпавших бит и 200, просто вычислительных мощностей надо больше, и избыточной информации тоже.
Завал АЧХ влияет только на крутость фронтов, при манчестере это некритично. Гуляние скорости - тоже, спектр сигнала сосредоточен либо на символьной скорости N либо на N/2 (в зависимости от того нули или единицы пишутся), причем манчестер самосинхронизирующийся (то есть в каждом бите можно выделить несущую).
Единственная серьезная проблема - выпадения сигнала и достаточно большая вычислительная сложность рида-соломона.
От пылинок
разве что металлическая стружка...:) либо достаточно большой слой пыли
разве что металлическая стружка... либо достаточно большой слой пыли
осыпание ленты - первое, что вызывает выпадения.
осыпание ленты
не спорю, лента сыпется, но вот усомнился в выпадении битов от пылинки.
От пылинок выпадают обычно два-три бита (зажеванность ленты не рассматриваем). На самом деле рид-соломон позволяет исправлять и 100 выпавших бит и 200, просто вычислительных мощностей надо больше, и избыточной информации тоже.
Завал АЧХ влияет только на крутость фронтов, при манчестере это некритично. Гуляние скорости - тоже, спектр сигнала сосредоточен либо на символьной скорости N либо на N/2 (в зависимости от того нули или единицы пишутся), причем манчестер самосинхронизирующийся (то есть в каждом бите можно выделить несущую).
Единственная серьезная проблема - выпадения сигнала и достаточно большая вычислительная сложность рида-соломона.
Нет, от пылинок, пожалуй, не выпадает.
Завал АЧХ влияет не просто на крутизну фронтов, а в плохих случаях способно вообще уничтожить нулевые биты:
http://s018.radikal.ru/i513/1307/a8/ca16a4a5179d.png
Гуляние скорости тоже может тоже быть весьма интенсивным, затрудняя синхронизацию даже в стандартном ЧМ сигнале.
Barmaley_m
28.07.2013, 21:39
Новости следующие.
Начитавшись теории и по результатам размышлений, я реализовал еще один кассетный формат для экспериментов. Он очень похож на синклерский формат, как по смыслу, так и по звуку и скорости. Однако у него постоянная (в отличие от синклерского) скорость записи, которая равна скорости записи нулей в синклерском формате. Поэтому, в наихудшем случае скорость нового формата совпадает с синклерским; в наилучшем - превосходит его в 2 раза, а в среднем - превосходит его в полтора раза. Так как выигрыш в скорости незначительный, формат подходит главным образом для испытаний на магнитофоне haywire. Я испытывал его на эмуляторе, создавая сигнал с выбросами АЧХ на низких частотах при заваленных высоких - грузится не хуже, чем синклерский. Так что надеюсь, что на этот раз все пойдет. Прилагаются, как обычно, исходники загрузчика и сохранялки, программа-конвертор с исходником, и tap-файл с тестовой программой, которую следует запустить на реале.
Загрузчик не на 100% вылизан по тактам, но вроде работает. Вылизывать загрузчик буду, когда создам формат с приемлемой работоспособностью.
Кодировка в новом формате является простейшим бимодальным блочным кодом, преобразующим каждый бит данных в 2 кодированных бита следующим образом. В первом состоянии кодера, "0" кодируется как "10", а "1" - как "11". Во втором состоянии все инвертируется: "0" кодируется как "01", а "1" - как "00". Состояния кодера переключаются всякий раз, когда кодируется бит данных "1".
Отсюда можно заметить, что код сбалансирован по постоянному току, а максимальная длина последовательности одинаковых бит составляет 2. Максимальное значение текущей битовой суммы (Running Digital Sum, RDS) составляет +-1. Эти характеристики кода такие же, как у синклерского формата.
Этот код также можно описать так, что лог. "0" соответствует два фронта сигнала, а лог. "1" - один фронт. Такой же код применяется при передаче сигнала по кабелю S/PDIF. Формат этот применяется и на дискетах, где он называется "FM".
Просьба к haywire - провести испытания формата на своем реале. По результатам испытаний будем изобретать более эффективные форматы.
Не работает.
http://www.sanarin.ru/pic/r4.jpg
Barmaley_m
29.07.2013, 02:44
Ну и ну! Это уже начинает напоминать детективную историю! Haywire, можешь прислать вав-файл с сигналом магнитофона? Попробую покумекать, в чем еще может быть дело. Если можешь, пришли два файла: первый со Спектрума, с аудиовыхода, а второй - с другого магнитофона. Спасибо!
я кстати достаточно много кассет из середины 90х оцифровал именно с +2мафона.
makeTZX почти всё распознал без проблем.
Barmaley_m
29.07.2013, 13:34
именно с +2мафона.
Тут интересен вопрос, как пойдут мои форматы на других +2 магнитофонах. То есть, вот этот горб на низких частотах - он характерен для всех +2 магнитофонов или только для того экземпляра, которым владеет haywire, из-за плохого технического состояния / загрязненной головки?
Тут интересен вопрос, как пойдут мои форматы на других +2 магнитофонах.
вечером откопаю свой и попытаюсь понять в каком он состоянии
Что мне сделать, чтобы доказать, что всё у меня с техникой нормально ? Этих голов куча в ящике лежит, я даже не знаю, что надо делать, чтобы загрязнить её настолько, чтобы с неё лента начала соскакивать. C кассет cопли не отслаиваются, они новые, специально упаковку по такому случаю открыл.
Barmaley_m
29.07.2013, 16:18
Что мне сделать, чтобы доказать, что всё у меня с техникой нормально ?
У тебя с техникой ненормально. Даже магнитофон 4й группы сложности по ГОСТу не дает такой неравномерности АЧХ, чтобы так убить запись. Это было видно по присланным файлам. То, что на нем грузится синклерский формат, говорит лишь об исключительной устойчивости формата к таким искажениям. Могу даже предположить, что загрузка идет на пределе этой устойчивости. Это как с левыми CD-R и DVD-R: они вроде бы читаются после записи, но лишь за счет коррекции ошибок на пределе возможностей алгоритма. И тогда любые дополнительные искажения приведут к неисправимым ошибкам чтения. Тогда как на болванках хорошего качества изначальный уровень ошибок низкий, и тем самым имеется некоторый запас по накоплению исправимых ошибок в будущем вследствие старения и износа дисков и приводов.
Вопрос только в том, имеют ли все +2 магнитофоны такую неравномерность АЧХ по своей природе, или же это именно твой магнитофон дает такие искажения вследствие плохого технического состояния.
Между делом, я тут экспериментировал по созданию формата записи с еще одним нулем в спектре сигнала на низких частотах, чтобы уменьшить чувствительность его к выбросам АЧХ на низах. Пока получилось создать нуль на 250Гц и ее нечетных гармониках, но лишь ценой огромной избыточности формата (6b->16b). Кроме того, нечетные гармоники подавлять не нужно, а наоборот вредно, т.к. от этого усиливаются низкие частоты. Буду думать дальше.
---------- Post added at 15:18 ---------- Previous post was at 15:11 ----------
Кстати говоря, турбированные форматы (с повышенной битовой скоростью) должны в таких условиях грузиться надежнее, так как у них в спектре сигнала присутствует меньше низких частот, на которых в твоем магнитофоне присутствует горб.
Я думаю, что просто не совсем правильно цифровать со спектрумовского аудио выхода - там звук после компаратора + какой-то феерической аналоговой цепи, представляющей из себя толи усилитель, толи ослабитель, толи улучшайзер, никогда не понимал, зачем там все эти тразисторы напаяны. А вот откуда правильно брать сигнал для оцифровки - этого я не знаю. Магнитофоны у меня есть ещё штуки 3, могу поменять, но уверен, что это пустая трата времени.
Barmaley_m
29.07.2013, 17:46
Я думаю, что просто не совсем правильно цифровать со спектрумовского аудио выхода - там звук после компаратора + какой-то феерической аналоговой цепи, представляющей из себя толи усилитель, толи ослабитель, толи улучшайзер, никогда не понимал, зачем там все эти тразисторы напаяны.
Я смотрел схему в ZX Spectum +2 Service Manual.pdf (гуглится). Там стоит усилитель на транзисторе, а после него - усилитель на операционнике. Конденсаторы в этих цепях обеспечивают развязку по постоянному току (подавление постоянной составляющей), а также некоторый эффект ФНЧ. Ввиду малой емкости этих конденсаторов подавление высоких частот там не должно быть особенно сильным. Кроме того, в цепи обратной связи операционного усилителя конденсатор подключен параллельно с резистором, что также ослабляет ФНЧ-эффект от этого конденсатора. По-видимому, коэффициент усиления каскада на операционнике столь велик, что в большей части диапазона входного сигнала этот каскад находится в насыщении, т.е. работает как компаратор. Аналоговый сигнал в этой цепи, возможно, присутствует на входе операционника, если только транзисторный усилитель тоже не входит в насыщение. Если есть осциллограф - можно попробовать туда "заглянуть". Других транзисторов на пути аналогового сигнала нет - сигнал с выхода операционника поступает на звуковой выход компьютера через смесительные цепи. Они содержат конденсаторы, что дает дополнительный нуль на постоянной составляющей.
Откуда там взяться выбросу на низких частотах - пока не вижу. Может быть, что этот выброс дает тракт записи магнитофона. Это тем более вероятно потому, что сигнал, оцифрованный другим магнитофоном, выглядел очень плохо. Как вариант для проверки - произвести запись на другом магнитофоне, подготовив csw-файл с помощью моей программы-конвертора, а потом попробовать его загрузить на твоем Спектруме. Еще один вопрос. Ты головку магнитофона крутишь, или она у тебя выставлена на заводе?
---------- Post added at 16:46 ---------- Previous post was at 16:36 ----------
Хотя нет, не заглянешь ты туда осциллографом. Усилительный каскад на ОУ имеет токовый вход, т.е. на линейном участке характеристики там напряжение всегда постоянное, а когда ОУ входит в насыщение - то напряжение меняется, но это тем более делает запись сигнала оттуда невозможной.
Тут, чтобы записать аналоговый сигнал, надо разорвать цепь, выпаять конденсатор C317, и тогда с того его вывода, который соединен с коллектором транзистора, можно будет снять сигнал. Вероятно, его потребуется еще и усилить с помощью ОУ. Но пока что я не думаю, что это необходимо. Лучше всего было бы провести описанный выше эксперимент, записав сигнал на другом магнитофоне.
Мой спектрум не грузится с внешнего магнитофона, только с того, который в него встроен. Головку - не помню, крутил или нет. Всё ОК с ней, гарантирую.
там звук после компаратора
А как это? После компаратора, то ведь, цифра идёт.
Вы тут выкладывайте свои файлы и оцифровки. А то беседуете между собой, а предмета разговора не видно.
Barmaley_m
29.07.2013, 20:01
Мой спектрум не грузится с внешнего магнитофона, только с того, который в него встроен.
Я предлагаю записать кассету на внешнем магнитофоне с PC, а потом вставить эту кассету во встроенный магнитофон и попробовать с нее загрузить файл в одном из моих форматов (1b/2b или 8b/10b).
Головку - не помню, крутил или нет. Всё ОК с ней, гарантирую.
Если крутил - то может быть попробовать ее покрутить еще раз, добиваясь наилучшей возможной настройки к кассете, которая записана наиболее правильным образом? Есть такая программа "Tape head", еще в 1992г, помню, у меня была. Она измеряет время между фронтами сигнала и выводит на экран в виде скроллирующегося графика. Получается что-то типа тех гистограмм, которые я строил по логам эмулятора. Нужно добиться, чтобы две вертикальные полосы (они соответствуют интервалам между фронтами в один или два битовых периода) были как можно более узкими. При плохой настройке головки высокие частоты обычно зарубаются, и это сказывается на нестабильности интервалов между фронтами: полосы будут расплываться.
Я предлагаю записать кассету на внешнем магнитофоне с PC
Это тоже невозможно к сожалению. Мой магнитофон умеет записывать только с радио и компакт-дисков, но болванки не читает, и входа для записи у него нет. Через пару недель или позже приедет нормальная кассетная дека, если будет актуально, помучаю её, но сейчас такой возможности пока нет. Есть возможность загрузиться через самодельный девайс - Bluetooth-"кассету", но это будет явно не то, что надо.
Если крутил - то может быть попробовать ее покрутить еще раз, добиваясь наилучшей возможной настройки к кассете, которая записана наиболее правильным образом?
Что значит правильным ? Пишет и читает одна и та же голова.
Есть такая программа "Tape head"
Если найду - попробую.
Barmaley_m
29.07.2013, 20:49
Что значит правильным ? Пишет и читает одна и та же голова.
Я имею в виду, какая-нибудь кассета, записанная на лучшем известном тебе магнитофоне. Фирменная, например. Жаль, что нельзя использовать в этой ситуации измерительную ленту, хотя и достать такую ленту проблематично.
Оцифровка с аудио выхода Спектума (http://www.sanarin.ru/download/Untitled10.wav)
Barmaley_m
29.07.2013, 22:45
Нашел программу, о которой говорил: Tape signal analyser (http://www.worldofspectrum.org/infoseekid.cgi?id=0012161). В ней есть два режима анализа, и оба очень полезные.
Первый режим - Tape tester. В нем измеряются некоторые параметры импульсов, приходящих на порт магнитофона. Параметры можно выбирать клавишами 1-5. Для наших целей, главным образом, нужны параметры 1 и 2. При анализе загрузки стандартного формата также может пригодиться параметр 3.
Если запустить на воспроизведение кассету - то на экране начнет отображаться измеренная длительность импульсов, приходящих на порт магнитофона. При хорошем качестве сигнала в синклерском формате должны появиться две вертикальные полосы, соответствующие разной длительности импульсов для лог. "0" и "1". Когда сигнал качественный - полосы будут жирные и узкие. Можно проверить на эмуляторе. Когда АЧХ неравномерная, головка расстроенная, или запись плохая - полосы будут расплываться. Например, на файлах в синклерском формате, которые прислал haywire, у меня в режиме "1" полосы нормальные получились, а в режиме "2" они настолько размыты, что между ними нельзя провести четкую грань. Для синклерского формата это не страшно, а мои форматы убивает. Но любопытно. Получается, что длительность импульсов гуляет только в состоянии лог. "0". Буду еще разбираться.
Если же подсунуть этой программе кассету в формате 8b/10b - то в режимах "1" и "2" можно будет наблюдать четыре четкие полосы. Это соответствует тому, что в записи встречаются последовательности одинаковых бит длиной до 4 (иногда бывают и 5, но очень редко). Разумеется, загрузка будет невозможна, если искажения сигнала таковы, что четыре полосы на этом графике окажутся неразделимы.
С помощью этой программы уже можно крутить головку, добиваясь, чтобы сигнал приобрел вид двух четких полос, на синклерском формате.
Выход из первого режима - по CS/Break. Второй режим работы - "Spectrum analyzer" - также любопытный. Хотя, строго говоря, это не спектральный анализатор, а построитель гистограмм длительности интервалов между фронтами. На синклерском формате должно быть две горизонтальных полосы - опять же, можно проверить на эмуляторе. На формате 8b/10b должно быть четыре полосы. В записи от Haywire на синклерском формате между двух обычных полос появляется дополнительный пик. На формате 8b/10b в записях от haywire вообще все сливается, хотя должно быть четыре полосы. Выход из "спектрального анализатора" - клавиша Q.
Я имею в виду, какая-нибудь кассета, записанная на лучшем известном тебе магнитофоне. Фирменная, например.
Да работают отлично фирменные кассеты. Абсолютно убитые экземпляры, на которые жалко смотреть, и которые во времена актуальности явно не отличались качеством, работают.
И это, я вот что вспомнил. У меня же на тюнере выставлено усиление низких частот +6db. Из-за этого мог быть завал НЧ на записи.
Barmaley_m
30.07.2013, 01:55
Да работают отлично фирменные кассеты. Абсолютно убитые экземпляры,
А ты запусти программу Tape Signal Analyser и посмотри на сигнал. Может быть, его можно улучшить путем подстройки/очистки головки, если, конечно, ты рискнешь этим заниматься.
И это, я вот что вспомнил. У меня же на тюнере выставлено усиление низких частот +6db. Из-за этого мог быть завал НЧ на записи.
Ох-ох. Вскрываются интересные подробности! Это что за тюнер? Тот, через который ты цифровал сигнал в присланных ранее записях? Можешь убрать усиление НЧ и отключить прочие эквалайзеры, ревербераторы, хорусы и системы шумоподавления и сделать еще одну запись сигнала в моих форматах (8b/10b и 1b/2b)?
Тюнер - Beholder H8. Хороший тюнер, ест RGBs, это единственное изделие в классе с такой способностью. Есть у него возможность добавить усиление по частотам, я воспользовался возможностью, сохранил, и забыл. Это, конечно, моя ошибка, но не грузится не по этой причине. Как раньше цифровал - не помню. Возможно, через тюнер, возможно, к звуковой карте подключал. Завтра переделаю, что смогу и если смогу.
Barmaley_m
30.07.2013, 03:24
Спасибо. Делай как сможешь - будем разбираться.
Barmaley_m
30.07.2013, 12:51
Продолжаю теоретические наработки по созданию кода с подавленными низкими частотами. Удалось добиться промежуточной цели - создать нули на 0 и 250Гц в битовой последовательности. Сгенерировал последовательность длиной 16000 бит, в которой закодировано 13652 бит случайных данных. Избыточность кода получается около 15%, что даже лучше, чем у кода 8b/10b. Правда, этот код переменной длины и вообще на каждом шаге кодирует дробное число бит, поэтому для практической реализации это не подходит. Только как теоретически достижимый максимум.
Привожу картинку со спектром полученной битовой последовательности и вав-файл с ее записью. Кому интересно - можете лично убедиться в наличии указанных спектральных нулей при использовании только двух уровней сигнала!
К сожалению, нуль на 250Гц получился узкий, и он не дает большого подавления в своей окрестности, что было, собственно, целью его создания. Придется или смещать его в область более низких частот, или добавлять еще нули.
Подкидываю идею для более оптимального формата.
В основе лежит кодирование комбинации бит фронтами сигнала разной длительности.
Т.е. в простейшем случае это:
00 - |--------|_______|
01 - |------|_____|
10 - |----|___|
11 - |--|__|
В сложном случае можно кодировать даже по 3 бита одним периодом сигнала, но это усложнит программу и увеличит требования к стабильности АЧХ и скорости тракта.
Т.к. в следствие разброса АЧХ длительность считываемых периодов никогда не будет строго соответствовать записанным, то после синхронизирующего пилоттона должна идти пачка комбинаций бит 00, 01, 10, 11 для замера эталонной длительности для данной записи. Так же должна быть постоянная подстройка длительности эталонов в течение всей записи из-за вероятной нестабильности АЧХ тракта, качества пленки и, самое главное, нестабильной скорости.
Так же, перед записью можно просканировать блок кода, для определения, какие комбинации встречаются чаще всего, и присвоения им самого короткого периода. И так далее.
Barmaley_m
30.07.2013, 15:14
Titus, хорошая идея. Надо будет попробовать. В этом коде автоматически получается баланс по постоянному току и, возможно, сохраняются преимущества синклерского формата по устойчивости к неравномерности АЧХ. Эталонную длительность замерять, думаю, нет необходимости. Начальную скорость записи можно померить по пилоттону. А адаптацию к меняющейся скорости производить путем накопления средней длительности периодов сигнала, и соответственно ей выставлять пороги детектирования. Для этого хорошо подходит простейший ФНЧ первого порядка на 16-битовом регистре: y[i] = x[i]+255*y[i-1]/256, где x[i] - измеренная длительность последнего периода, high(y[i]) - среднее значение длительности за последнее время.
---------- Post added at 13:52 ---------- Previous post was at 13:50 ----------
Хотя, с другой стороны, если длительность периода для комбинации "00" будет по времени в 2 раза длиннее (или короче) длительности для "11" - то получим тот же самый синклерский формат по скорости.
---------- Post added at 14:14 ---------- Previous post was at 13:52 ----------
Научился управлять шириной спектральных нулей в битовой последовательности. Правда, уширение нулей дается ценой резкого увеличения избыточности кода. Но зато удается добиться более высокого подавления на НЧ без введения дополнительных нулей. Здесь должна быть какая-то фундаментальная закономерность. Подозреваю, что максимальная информационная емкость последовательности должна быть равна площади под ее спектром, деленной на площадь под спектром того же сигнала без спектральных ограничений. То есть, нули мы добавляем или просто частоты давим - любые эти действия приводят к повышению избыточности. Если, допустим, вообще почти начисто подавить половину спектра сигнала ниже 1кГц - то максимальная информационная емкость должна по идее упасть вдвое. Буду еще кумекать. Жутко интересно!
Хотя, с другой стороны, если длительность периода для комбинации "00" будет по времени в 2 раза длиннее (или короче) длительности для "11" - то получим тот же самый синклерский формат по скорости.
Почему же? В стандартном формате 0 кодируется |-|_|, а единица |--|__|, а у нас такими комбинациями будут кодироваться два нуля и две единицы, т.е. выигрыш в два раза.
ram_scan
01.08.2013, 12:18
Друзья, вы велисапед же изобретаете. Ну чесслово. Причем наощупь.
Есть теоретически обоснованные и математически доказанные модели для всей этой кухни. Но для этого надо прочесть учебник для ВУЗов "Шувалов В.П. Передача дискретных сообщений", "Зюко, А.Г.; Кловский, Д.Д.; Назаров, М.В. и др.
Теория передачи сигналов: Учебник для вузов", и чего-нибудь сверху по теории информации.
Это я не к тому что я тут такой дАртаньян а вы все тупые. Просто после прочтения учебников многое становится понятно и не надо будет вслепую тыкаться и впустую неудачные варианты изобретать. А сразу изобрести вариант который в данных конкретных условиях будет теоретически обоснован и практически применим.
Формат форума не позволяет мне читать тут за это лекции (да и за 15 лет у меня подстерлось многое из головы), а лень и отсутствие свободного времени - написать свой загрузчик.
SoftLight
01.08.2013, 12:29
Учебник это прекрасно если сесть и начать сначала теоретизировать. Тут другая ситуация - есть готовый уже формат но в каких-то ситуациях он не прокатывает. Можно конечно и учебник почитать, но лучше сразу подсказать в чем загвоздка.
ram_scan
02.08.2013, 05:13
Для того чтобы понимать в чем загвоздка нужно знать теорию. Иначе получится как с первым вариантом загрузчика, когда "гладко было на бумаге".
Для того чтобы понимать в чем загвоздка нужно знать теорию. Иначе получится как с первым вариантом загрузчика, когда "гладко было на бумаге".
Для того, чтобы понять, в чем загвоздка, нужно ОЧЕНЬ ХОРОШО знать практику (и теорию) искажений и характеристик характерных ИМЕННО для магнитофонных трактов и входных цепей спектрум-совместимых компов.
ram_scan
03.08.2013, 21:11
Для того, чтобы понять, в чем загвоздка, нужно ОЧЕНЬ ХОРОШО знать практику (и теорию) искажений и характеристик характерных ИМЕННО для магнитофонных трактов и входных цепей спектрум-совместимых компов.
Для начала нужно хорошо понимать где в принципе могут лежать грабли и какие именно. Понимание расположения граблей может позволить не упираться попусту рогом в частности навроде нюансов в реализации входных цепей.
На реальной ленте в реальном кассетном магнитофоне (который сейчас поди неубитый найди еще) самая большая проблема это нестабильность движения ленты и выпадения сигнала. С АЧХ (и завалом фронтов) там выше 250 Гц и примерно до 6000 Гц как правило проблем нету вообще никаких (при условии что исправная лента используется и магнитофон в принципе звуки издавать способен). Ну еще если магнитофон в части звуковоспроизводящего тракта неисправен приходится иногда подымать уровень сигнала, что влечет за собой отчаянное ухудшение отношения сигнал/шум, но это отдельная песня я думаю. В любом случае загрузить стандартную спековскую запись удается на любых дровах, при условии что она была правильно и на неубитую ленту записана и лентопротяжный механизм воспроизводящего магнитофона внушает своими параметрами доверие. Исправность звуковоспроизводящего тракта практически поуху, главное чтобы "звук был".
Большинство "наглядных" примеров показывающих "вот глядите, тут в записи целый импульс пропал" это не проблема тракта, это проблема системы головка-лента (либо при воспроизведении но чаще при записи). Либо "эффект змейки", либо выпадения сигнала из-за пыли, осыпания, козявок налипших на ленту и представляющих из себя концентрат продуктов пыли и осыпания, паразитной амплитудной модуляции и пр. Поверьте человеку который уже лет как 20 занимается магнитной записью звука. Причем "на ухо" запись может выглядеть идеально, так как ухом уверенно нельзя фиксировать подобные "косяки" продолжительностью менее 30 мс.
Поэтому все форматы где на полутора-двух битовых интервалах нет возвращения к нулю на бытовом магнитофоне потенциальные трупы, и что-то полезное можно сделать только из манчестера. Иначе просто встает дилемма скорость против синхронизации (кстати тут есть парадокс, повышение символьной скорости начинает нивелировать детонацию, так как размеры деталей ЛПМ вполне себе конечны и гуляния скорости соответственно тоже, и на медленном битовом потоке синхронизацию ловить труднее чем на быстром, но при этом восстановление потерянной синхронизации занимает больше времени ессно). Либо нужно искусственно синхроимпульсы в сигнал вонзать.
Собсно вышеприведенные книжки (если их правильно осознать) и дают верное понимание в какую сторону двигаться перспективно, а в какую нет.
В моем понимании, не меняя в архитектуре ничего единственная верная дорога - на стандартном или манчестеровском формате просто увеличивать символьную скорость, а неизбежные выпадения сигнала компенсировать добавляя простейший корректирующий код (выпадения как правило короткие, 8-16 бит максимум, где можно малой кровью обойтись).
Увеличение символьной скорости на спекки в три раза даст полосу примерно до 7 кГц по моим умозрительным прикидкам, причем АЧХ тракта особенно в этих рамках погоды делать не будет даже на самом дрянном магнитофоне, но начнут очень сильно роялить выпадения, которые можно бодать только корректирующими кодами.
На реальной ленте в реальном кассетном магнитофоне (который сейчас поди неубитый найди еще) самая большая проблема это нестабильность движения ленты. С АЧХ (и завалом фронтов) там выше 250 Гц и примерно до 6000 Гц как правило проблем нету вообще никаких (при условии что исправная лента используется и магнитофон в принципе звуки издавать способен). Ну еще если магнитофон в части звуковоспроизводящего тракта неисправен приходится иногда подымать уровень сигнала, что влечет за собой отчаянное ухудшение отношения сигнал/шум, но это отдельная песня я думаю. В любом случае загрузить стандартную спековскую запись удается на любых дровах, при условии что она была правильно и на неубитую ленты записана и лентопротяжный механизм воспроизводящего магнитофона внушает своими параметрами доверие. Исправность звуковоспроизводящего тракта практически поуху, главное чтобы "звук был".
Большинство "наглядных" примеров показывающих "вот глядите, тут в записи целый импульс пропал" это не проблема тракта, это проблема системы головка-лента. Либо "эффект змейки", либо выпадения сигнала из-за пыли, осыпания, паразитной амплитудной модуляции и пр. Поверьте человеку который уже лет как 20 занимается магнитной записью звука.
Поверьте человеку, который проанализировал сотни кассет с записями для Спекки, и сделал универсальную программу, которая вытаскивает практически любые 'убитые' записи - я знаю практику предмета обсуждения)
Сфера магнитной записи звука вообще, и практика считывания кассет с записями для Спекки - вовсе не одно и то же.
---------- Post added at 21:46 ---------- Previous post was at 21:31 ----------
Кстати, к слову о кодировании длительностью, которое я предложил выше (4 ширины фронта), можно попробовать средний вариант с 3-мя видами фронтов. Фактически почти не потеряем в скорости относительно варианта с 4-мя видами, однако придется добавить немножко перекодирования из троичной системы счисления в двоичную.
Таким образом, при двоичной системе кодирования нам на байт нужно 8 периодов, при четверичной 4 периода, а при троичной... 5.05 периода.
Есть на иппее такая (http://www.ebay.com/itm/231020221385) хреновина.
Вот только она рид-онли.
Barmaley_m
08.08.2013, 17:03
Большинство "наглядных" примеров показывающих "вот глядите, тут в записи целый импульс пропал"
Выпадения сигнала - это, конечно, хорошо, но они не являются причиной, почему в конкретном случае магнитофона Haywire мои форматы не грузились.
Защиты от выпадения сигнала оригинальный синклерский формат не дает. Поскольку надежность этого формата до сих пор всех устраивала, я не вижу смысла решать эти надуманные проблемы в своих проектируемых форматах. По крайней мере, на данном этапе разработки.
Поэтому все форматы где на полутора-двух битовых интервалах нет возвращения к нулю на бытовом магнитофоне потенциальные трупы, и что-то полезное можно сделать только из манчестера.
Ну вот в синклерском формате манчестер не применяется - и ничего, живет. Чем он так хорош, этот манчестер? По сути дела то же самое, что и второй экспериментальный формат 1b/2b, который я просил опробовать Haywire: для записи одного полезного бита используется два битовых интервала.
"Возвращение к нулю" в контексте спектрумовского магнитофонного интерфейса реализовать в принципе невозможно, т.к. поддерживаются только два уровня сигнала.
Собсно вышеприведенные книжки (если их правильно осознать) и дают верное понимание в какую сторону двигаться перспективно, а в какую нет.
Я не везде в этой теме сыпал теоретическими терминами, чтобы сообщения были всем понятны, но теоретическая подготовка у меня присутствует. Если есть сомнения - прошу указать на конкретные ошибки.
В моем понимании, не меняя в архитектуре ничего единственная верная дорога - на стандартном или манчестеровском формате просто увеличивать символьную скорость,
А почему? Ты разве уже разобрался, почему именно коды 8b/10b и 1b/2b не пошли? Я вот думаю, что на магнитофоне Haywire даже манчестерский код не пойдет. Там явные проблемы с АЧХ в низкочастотной области, а она манчестерским кодом не подавляется.
Защиты от выпадения сигнала оригинальный синклерский формат не дает. Поскольку надежность этого формата до сих пор всех устраивала, я не вижу смысла решать эти надуманные проблемы в своих проектируемых форматах. По крайней мере, на данном этапе разработки.
Именно, что на данном этапе разработки. Поскольку, пока разрабатывается сигнальный уровень, думать о системах защиты не время. Но в дальнейшем, необходимо обеспечить коды коррекции и работу с независимыми блоками - остановил, перемотал, дочитал.
Barmaley_m
15.08.2013, 17:20
Размышлял над возможностями борьбы с существенной неравномерностью АЧХ в низкочастотной области, которая, предположительно, имеется в магнитофонной системе Haywire. На сегодняшний день я считаю, что проблему можно решить путем создания такого кода, чтобы кодированный сигнал имел минимальную энергию в области низких частот, где присутствуют искажения.
Мои попытки создать для подавления низких частот нули в спектре битовой последовательности не привели к желаемому результату, поскольку получаемые спектральной нули дают низкое подавление в своей окрестности. Если же менять параметры кодера таким образом, чтобы нули имели большую "ширину" - то это приводит к существенному уменьшению эффективности кода, его информационной емкости.
Сейчас я временно оставил в стороне вопросы собственно построения кода, а обратился к решению более фундаментальной задачи: как получить битовую последовательность с заданными спектральными свойствами. И вот результаты, полученные на настоящий момент.
Во-первых, при создании нулей в спектре битовой последовательности теми методами, которые я это делал, создаются не только нули, но и полюсы - около тех же частот. Иными словами, я как бы пропустил белый шум через фильтр, который имеет на некоторой частоте нуль, но на ней же (на некотором расстоянии внутри единичной окружности z-плоскости) имеет и полюс. Чем ближе этот полюс к окружности - тем больше он нейтрализует влияние нуля в своей окрестности, тем "у'же" будет нуль и тем меньше будет подавление спектральных компонентов в его окрестности. Одновременно растет информационная емкость полученного кода. Но тогда и польза от спектрального нуля в деле подавления низких частот нивелируется.
Аналогичным образом полюс образуется и при подавлении постоянной составляющей. Наименее эффективные коды, такие как манчестерский или приведенный мною в этой теме 1b/2b, дают широкий нуль на постоянной составляющей, подавляя попутно низкие частоты, а более эффективные коды, такие как 8b/10b и некоторые другие, которые я испытывал в своей "лаборатории", наоборот, дают на постоянной составляющей узкий нуль. Такие коды также характеризуются большей чувствительностью к колебаниям базового уровня при прохождении через канал, не имеющий связи по постоянному току.
Сегодня я провел ряд вычислительных экспериментов, которые показывают, что для успешной записи на магнитофон нет необходимости подавлять до нуля постоянную составляющую. Достаточно и того, чтобы обеспечить некоторую неравномерность спектра кодированного сигнала, так чтобы низкие частоты (включая постоянную сост.) были подавлены по сравнению с основной полосой частот, которая занимается сигналом.
Я нашел в интернете статью, в которой приводится метод генерации битовых последовательностей с заданным спектром типа "все полюсы": "Generating Binary Processes with All-Pole Spectra", Petros Boufounos. Иными словами, спектр полученных последовательностей является отфильтрованным белым шумом, причем применяемый (косвенно) фильтр может иметь только полюсы в своей передаточной функции. Таким фильтром нельзя создать нуль на постоянной составляющей или какой-либо другой частоте, но это и не требуется. К сожалению, на коэффициенты фильтра накладываются довольно жесткие ограничения. Создавая фильтры путем ручной вариации коэффициентов и наблюдения полученной АЧХ, я смог создать лишь около 8дБ неравномерности в частотной области. Этого уже достаточно для того, чтобы такой сигнал можно было записать на магнитофон и достоверно считать, как я убедился путем пропускания полученной последовательности через ФВЧ с частотой среза 50Гц. Но все же хотелось бы больше. В статье говорится, что условия накладываемые на коэффициенты фильтра, являются достаточными, но не необходимыми. Таким образом, есть шанс получить фильтры с более подходящими характеристиками.
С практической точки зрения я планирую поступить следующим образом. Сделать сохранялку и загрузчик без какого-либо кодирования, которые сохраняют или загружают произвольный битовый поток. Подготавливать кодовые последовательности на Матлабе и тестировать их на спеке. Надеюсь, Haywire снова сможет предоставить свою технику для таких испытаний. Тем самым надеюсь выяснить, какие ограничения на спектр кодированного сигнала являются достаточными, чтобы он грузился с магнитофона Haywire.
Barmaley_m, кстати, ты случаем не видел защищенное кодирование в играх?
Точно не вспомню, надо поискать, но была загрузка совершенно по звуку отличающаяся... то ли сохранялка в каком-то Boulder Dash... начинала загружаться без пилота... звук глухой какой-то был.
---
upd нашел
Barmaley_m
18.08.2013, 15:21
Изобрел новый метод генерации битовых последовательностей, спектр которых является продуктом фильтрации белого шума, причем фильтр теперь может содержать не только полюсы (как это было в статье, на которую я ранее давал ссылку), но и нули, причем на любых частотах независимо друг от друга. Порядок фильтра также особо ничем не ограничен. Это позволяет реализовывать фильтры Кауэра (эллиптические) с очень резким спадом АЧХ. Также можно, по желанию, подавлять до нуля постоянную составляющую, хотя в этом, как я недавно выяснил, нет особой необходимости.
Вот спектр полученной мной сегодня битовой последовательности на базе фильтра Кауэра 3 порядка. Фильтры нечетного порядка имеют нуль на постоянной составляющей. Кому как, но меня впечатлило!
Информационная емкость этой последовательности составляет примерно 0.5475, т.е. на 1000 записанных на кассету бит будет в среднем 548 полезных. Метод генерации, однако, очень медленный: даже PC считает долго, а на Спектруме применять этот метод и вовсе невозможно, даже если кодировать/декодировать данные не в реальном времени. Но ничего, не в один день Москва строилась, решать проблемы будем постепенно.
Честно - не могу понять, чего ты этим хочешь сказать) Слишком много теории, причем, не совсем из той сферы, которой надо бы. Да и никаких конкретных примеров кодирования.
Barmaley_m
18.08.2013, 17:31
Titus, ситуация заключается в следующем. На магнитофоне Haywire имеют место сильные неравномерности АЧХ в области низких частот. То ли это высокий горб, то ли, как мне теперь кажется, это может быть провал. Возможно, ФВЧ, образованные в тракте магнитофона проходными конденсаторами, дают относительно высокую частоту среза. Может быть, в районе 250Гц. То есть все составляющие кассетного сигнала ниже этой частоты существенно ослабляются, а на постоянной составляющей - подавляются полностью.
С точки зрения приема сигнала, подавление на НЧ и горб на НЧ имеют примерно одинаковый эффект. Они приводят тому, что сигнал как бы "едет на волне", т.е. его огибающая совершает колебания с некоторой низкой частотой. В английской терминологии это называется "baseline wander" - "гуляние базовой линии". Эти колебания приводят к тому, что на границе соседних бит сравнение уровня сигнала с нулем происходит каждый раз в разном месте фронтов между битами. А эти фронты имеют конечную длительность вследствие ограниченной полосы пропускания со стороны ВЧ. И тем большую длительность, чем ниже частота среза по ВЧ. Детектирование фронтов по разным уровням, таким образом, приводит к дрожанию измеренных интервалов времени между фронтами - то, что и убивало мой загрузчик на основе ФАПЧ.
Иными словами, у нас полоса задавлена с обеих сторон, и оба этих ограничения усиливают неблагоприятное влияние друг друга.
В случае горба на НЧ, усиливается НЧ-составляющая полезного сигнала и переходит в "волны". В случае провала на НЧ, эта же составляющая вычитается из сигнала. Так как до вычитания сигнал был ровный, то после вычитания опять-таки появляются "волны".
Снизить амплитуду "волн" можно путем создания такого сигнала, который бы имел малую мощность на низких частотах. В этом случае вычитание из сигнала его НЧ-компонент не приведет к образованию больших "волн" потому, что эти НЧ-компоненты изначально были малы. Аналогичным образом, добавление к сигналу его же усиленной НЧ-компоненты ("горб на НЧ") также не приведет к образованию больших "волн" потому, что эта НЧ-компонента изначально была мала.
Собственно говоря, многие коды как раз и строятся с целью уменьшить эффект Baseline wander. Для этого обычно подавляется постоянная составляющая кодированного сигнала. В коде 8b/10b, как и в других блочных кодах, этому уделяется значительное внимание. С точки зрения спектра, на постоянной составляющей создается нуль, влияние которого также распространяется на низкие частоты в окрестности. Они подавляются, что и уменьшает "волны", однако во многих книгах говорится о необходимости полного подавления п.с., что, с моей точки зрения на данный момент, является ошибочным. "Волны" создает не постоянная составляющая, а низкие частоты в ее окрестности, поэтому давить нужно в первую очередь их. Наличие же в сигнале постоянной составляющей небольшой амплитуды приведет всего лишь к небольшому смещению уровня сравнения сигнала с нулем. Но величина этого смещения и амплитуда "волн" от НЧ оказываются одного порядка, поэтому незачем давить п.с., если НЧ не подавлены. А если НЧ подавлены, то и п.с. обычно подавлена (хоть, может быть, и не до нуля) из-за того, что применяемые фильтры имеют плавную АЧХ. Фильтры не всегда применяются явно (как, например, в коде 8b/10b), но они всегда есть в системе, их просто нужно увидеть, посмотрев на систему под нужным углом.
Таким образом, на данный момент я вижу решение задачи в том, чтобы создать битовый код с подавленными НЧ в кодированном сигнале. Это сложная задача, потому что сигнал у нас битовый, имеющий только два уровня. Как управлять спектром такого сигнала? Это невозможно осуществить методами, которые применяются в ЦОС для сигналов с большим количеством уровней. Там-то все просто. Фильтр применил - и дело в шляпе. В случае двоичной последовательности применение явных фильтров невозможно, и приходится конструировать системы, в которых неявно содержится фильтр с нужной АЧХ.
Так вот, мне бы хотя бы для начала научиться получать битовые последовательности с нужным спектром, а потом уже пытаться придумать код на их основе.
Titus, ситуация заключается в следующем. На магнитофоне Haywire имеют место сильные неравномерности АЧХ в области низких частот.
Кусок записи в студию.
Barmaley_m
18.08.2013, 20:38
Кусок записи в студию.
Уже пробегали в этой теме куски записи. Только они мало помогают: встроенный магнитофон ZX Spectrum +2 не имеет аналогового выхода. Более того, там даже негде в схеме подключиться, чтобы снять аналоговый сигнал: входной усилитель воспроизведения на транзисторе имеет токовый выход, а за ним сразу идет операционник с высоким коэффициентом усиления, так что он работает как компаратор. Тут, чтобы снять сигнал, надо разрывать связь между транзистором и компаратором и вставлять в нее новый, ненасыщенный каскад на операционнике. Кто это будет делать?
Выкладывались записи после компаратора, но там уже от оригинальной АЧХ остаются только следы в виде дрожания фронтов сигнала. Если же кассету считать и оцифровать на другом магнитофоне - то там ситуация вообще очень печальная, даже на оригинальном формате ZX иногда теряются импульсы, т.е. искажения сигнала невосстановимые. Только что посмотрел усредненный спектр этой аналоговой записи - уровень 200Гц выше уровня 1400Гц на 20дБ. Что это, как не горб?
Честно, без каких-либо примеров - все это сферические кони в вакууме)
Barmaley_m
18.08.2013, 21:33
Что значит "без примеров"? Ты тему вообще читал? Haywire выкладывал файлы. После этого шло их обсуждение.
Что значит "без примеров"? Ты тему вообще читал? Haywire выкладывал файлы. После этого шло их обсуждение.
Скачал один из его файлов (последний) - ничего особенного не увидел. Обычная встречающаяся АЧХ.
Barmaley_m
19.08.2013, 00:10
Последние файлы записаны с выхода Спектрума, т.е. после компаратора. Оригинальная (аналоговая) АЧХ при этом не сохраняется. Нужно качать файлы, записанные через другой магнитофон, которые появлялись ранее в этой же теме.
Не совсем понимаю, зачем стараться получить какую-то особенную АЧХ на магнитофонном выходе. Ведь записавшись и воспроизведясь сигнал может претерпеть широчайшие и невиданные изменения АЧХ и так же ФЧХ. А стало быть, упор надо делать не на то, чтобы получить какую-то специфическую АЧХ, а наоборот, чтобы быть толератным к широким диапазоном ее искажения. Единственное, избавить сигнал от постоянки, но это в предложенных вариантах и так есть.
Barmaley_m
19.08.2013, 19:20
В том-то и дело, что именно не может сигнал претерпеть "широчайшие и невиданные изменения АЧХ и ФЧХ". Если бы это было так - то загрузить любой широкополосный сигнал было бы невозможно ни в каком формате. Искажения АЧХ и ФЧХ (это также называется термином "линейные искажения") допускаются в некоторых пределах, но начиная с определенной величины загрузка станет невозможной. Да это и логично. Кому нужен магнитофон с АЧХ, прыгающей на десятки децибел в пределах звукового диапазона частот? На нем и музыку нормально не послушаешь, не то что программы грузить.
Скажем, в ГОСТ 24863-87 ("Магнитофоны бытовые. Общие технические условия") для малогабаритных магнитофонов четвертой группы сложности (то есть самых худших магнитофонов, приемлемых для категории "бытовые") установлено следующее:
коэффициент передачи в области 250-4000Гц должен находиться между 0 и -4дБ. Т.е., если принять за средний уровень -2дБ - то отклонение должно быть не более +-2дБ;
нижняя пропускаемая частота с ослаблением не более -7дБ - не более 80Гц
верхняя пропускаемая частота с ослаблением не более -7дБ - не менее 8000Гц
Можно было бы разрабатывать формат для применения на магнитофонах, удовлетворяющих хотя бы этим минимальным требованиям из процитированного стандарта, но кто же виноват, что магнитофон ZX Spectrum +2 (по своей природе или в связи с техническим состоянием экземпляра Haywire) далеко не вписывается в эти допуски, и при этом синклерский формат на нем грузится.
Не совсем понимаю, зачем стараться получить какую-то особенную АЧХ на магнитофонном выходе.
Я пытаюсь получить не "особенную АЧХ" (АЧХ магнитофонного тракта вообще неподконтрольна программисту), а особенный спектр сигнала для записи на магнитофон. Зачем?
Линейные искажения, какими являются выбросы или провалы в АЧХ, имеют интересную особенность. Они могут усиливать или ослаблять имеющиеся спектральные составляющие сигнала, но не могут добавить новые, которых в сигнале нет. Также искажениям подвергаются только те спектральные составляющие, которые лежат в области, где АЧХ неравномерна.
Отсюда простая идея: удалить из сигнала составляющие, которые лежат в области с неравномерной АЧХ тракта магнитофона. Пусть магнитофон пытается исказить сигнал на этих частотах, но если в нашем сигнале таких частот нет - то ничего ему исказить не удастся.
А стало быть, упор надо делать не на то, чтобы получить какую-то специфическую АЧХ, а наоборот, чтобы быть толератным к широким диапазоном ее искажения.
Невозможно быть толерантным к широким диапазонам искажения АЧХ. Синклерский формат оказался толерантным к тем искажениям, которые имеются на магнитофоне Haywire. Думаю, что можно подобрать такую конфигурацию искажений на других частотах, которая, не превышая по величине имеющиеся у Haywire искажения, сможет убить и синклерский формат. Единственная возможность защитить сигнал от неравномерности АЧХ - это иметь узкополосный сигнал, в пределе - на одной частоте. Но такой сигнал не несет полезной информации.
---------- Post added at 18:20 ---------- Previous post was at 16:35 ----------
Появилась еще одна идея.
Нужно измерить АЧХ тракта магнитофона Haywire.
Традиционный способ мог бы заключаться в записи на кассету тест-сигнала, с последующей его оцифровкой и обработкой. Однако мы не можем оцифровать аналоговый сигнал с этого магнитофона, так как сигнал доступен только на выходе компаратора. Также сам тест-сигнал в нашем случае не может быть произвольным, а должен генерироваться Z80 с его однобитным "ЦАП".
Думаю, что даже в этих условиях можно что-то сделать. Раз неравномерность АЧХ существенным образом проявляется на записи данных в разных форматах, в виде искажения длительности импульсов - то на основе этих искажений длительности должно быть возможным сделать какие-то конкретные выводы об АЧХ, особенно если подобрать тест-сигнал нужным образом.
Например, если записывать на кассету короткие импульсы, а потом измерять их длительность при загрузке - то можно оценить частоту среза по ВЧ. Но это лишь грубые прикидки. Должен быть более систематический подход.
Есть тут кто-нибудь, кто достаточно силен в теории, чтобы реализовать подобную схему измерений? Обрабатывать сигнал при воспроизведении не обязательно на Спектруме, достаточно и оцифровать его с выхода компаратора, а обработку вести на PC с применением мощных методов, таких как преобразование Фурье и т.д. Я мог бы и сам этим заняться, но это займет время, так что содействие могло бы помочь ускорить дело.
В том-то и дело, что именно не может сигнал претерпеть "широчайшие и невиданные изменения АЧХ и ФЧХ". Если бы это было так - то загрузить любой широкополосный сигнал было бы невозможно ни в каком формате. Искажения АЧХ и ФЧХ (это также называется термином "линейные искажения") допускаются в некоторых пределах, но начиная с определенной величины загрузка станет невозможной. Да это и логично. Кому нужен магнитофон с АЧХ, прыгающей на десятки децибел в пределах звукового диапазона частот? На нем и музыку нормально не послушаешь, не то что программы грузить.
Все, что ты приводишь в пример (ГОСТ'Ы, рациональные доводы о том, кому нужны такая АЧХ) - это все теория, оторванная от практики.
Я, когда писал униеверсальную читалку, перелопатил сотни реальных записей, и самое общее, что можно сказать - это практически непредсказуемая АЧХ, со спадом почти любой крутизны в сторону высоких (хотя бывает и наоборот), причем не то, что на 10, бывает и на 20дб и более. Причина - всевозможные искажения сложенных между собой трактов всей цепочки магнитофонов, на которых это переписывалось, так же особенности и истрепанности пленки, так же неправильные режимы записи, так же сточенные головки, и так же неподстроенные головки (что совсем часто встречается).
Опираться в построении устойчивого формата на одну только отстраненную от практики теорию, а так же специфический магнитофон уважаемого Haywire, на мой взгляд, просто абсурдная идея.
---------- Post added at 22:40 ---------- Previous post was at 22:35 ----------
Линейные искажения, какими являются выбросы или провалы в АЧХ, имеют интересную особенность. Они могут усиливать или ослаблять имеющиеся спектральные составляющие сигнала, но не могут добавить новые, которых в сигнале нет. Также искажениям подвергаются только те спектральные составляющие, которые лежат в области, где АЧХ неравномерна.
Отсюда простая идея: удалить из сигнала составляющие, которые лежат в области с неравномерной АЧХ тракта магнитофона. Пусть магнитофон пытается исказить сигнал на этих частотах, но если в нашем сигнале таких частот нет - то ничего ему исказить не удастся.
Помимо линейных искажений, есть еще и нелинейные, такие, как насыщение (дисторшн).
Сигнал, полученный на выходе среднестатистического спектрума - это меандр с целой кучей гармоник, от которых не избавиться.
Как удалить из меандра гармоники? Как сделать синус?
Где найти гарантированную область равномерной АЧХ?
На мой взгляд, это фантастика.
Barmaley_m
19.08.2013, 23:30
Я, когда писал униеверсальную читалку, перелопатил сотни реальных записей, и самое общее, что можно сказать - это практически непредсказуемая АЧХ, со спадом почти любой крутизны в сторону высоких (хотя бывает и наоборот), причем не то, что на 10, бывает и на 20дб и более.
Я не делаю универсальную читалку, тем более на ZX, где нет возможности применять сколько-нибудь сложные методы обработки сигналов в реальном времени. Эти записи, о которых ты говоришь - они в таком виде читались на реале? Или данные удалось извлечь только после обработки сигнала эквалайзерами и т.д.?
Кстати, можешь дать ссылку на свою читалку? Интересно посмотреть, если она настолько продвинутая.
Опираться в построении устойчивого формата на одну только отстраненную от практики теорию,
Ну вот почему ты постоянно пытаешься повесить ярлык отстраненности от практики? Тут на протяжении всей темы в основном практика идет - люди проводят испытания, и я провожу. На том, что доступно. По результатам практических испытаний ведутся дальнейшие разработки. Куда тебе еще практики-то?
а так же специфический магнитофон уважаемого Haywire, на мой взгляд, просто абсурдная идея.
Знаешь, хорошо, конечно, иметь огромную статистику и парк магнитофонов и реалов для испытаний. Но в моем распоряжении всего этого нет. Я пытаюсь получить наилучший результат в тех условиях, что имеются. Это и отличает человека от робота: последний работает только в известных заранее условиях, а человек иногда может выкрутиться и тогда, когда все обстоятельства против него. Вот ты, например, занимаешься сейчас неконструктивной критикой, а мог бы вместо этого предложить свои ресурсы для решения проблем, с которыми столкнулся проект.
Что касается специфического магнитофона ув. Haywire - то это единственный из магнитофонов, участвовавших в испытаниях, который работал с синклерским форматом и отказал со всеми моими форматами. Разве не логично в таком случае добиться устойчивой работы нового формата сначала на этом, наиболее проблемном из доступных для испытаний магнитофонов, а потом уже идти дальше?
Помимо линейных искажений, есть еще и нелинейные, такие, как насыщение (дисторшн).
У тебя есть конкретные причины считать, что на магнитофоне Haywire именно этот вид искажений вносит существенный вклад в общую картину?
Сигнал, полученный на выходе среднестатистического спектрума - это меандр с целой кучей гармоник, от которых не избавиться.
Как удалить из меандра гармоники? Как сделать синус?
Меандр - это прямоугольный сигнал на постоянной частоте, а у нас шумоподобный, широкополосный битовый сигнал. Слово "гармоника" в этом контексте не имеет никакого смысла. Спектром битового сигнала возможно управлять в некоторой степени. Я это продемонстрировал несколькими сообщениями ранее, прислав образец спектра. Прислать тебе сам сигнал, чтобы ты посмотрел его спектр и убедился?
Где найти гарантированную область равномерной АЧХ?
На мой взгляд, это фантастика.
Я ставлю цели поскромнее. Задача - сделать такой формат, который бы не убивался такими искажениями, которыми не убивается синклерский. Если неравномерности АЧХ в какой-то области или какие-то иные искажения убивают синклерский формат - то мне нет дела до того, будет ли мой формат работать в таких условиях. Будет - хорошо. Нет - и ладно.
Я не делаю универсальную читалку, тем более на ZX, где нет возможности применять сколько-нибудь сложные методы обработки сигналов в реальном времени. Эти записи, о которых ты говоришь - они в таком виде читались на реале? Или данные удалось извлечь только после обработки сигнала эквалайзерами и т.д.?
Кстати, можешь дать ссылку на свою читалку? Интересно посмотреть, если она настолько продвинутая.
Да, многие записи читались.
Ссылки прямой у меня нет, но на форуме где-то тут проскакивала. Кажется, newart владеет информацией.
---------- Post added at 01:50 ---------- Previous post was at 01:48 ----------
Ну вот почему ты постоянно пытаешься повесить ярлык отстраненности от практики? Тут на протяжении всей темы в основном практика идет - люди проводят испытания, и я провожу. На том, что доступно. По результатам практических испытаний ведутся дальнейшие разработки. Куда тебе еще практики-то?
Знаешь, хорошо, конечно, иметь огромную статистику и парк магнитофонов и реалов для испытаний. Но в моем распоряжении всего этого нет. Я пытаюсь получить наилучший результат в тех условиях, что имеются. Это и отличает человека от робота: последний работает только в известных заранее условиях, а человек иногда может выкрутиться и тогда, когда все обстоятельства против него. Вот ты, например, занимаешься сейчас неконструктивной критикой, а мог бы вместо этого предложить свои ресурсы для решения проблем, с которыми столкнулся проект.
Эти испытания и практика на очень узком количестве реальных магнитофонов. Практически только на одном.
Это хорошо, что ты пытаешься получить лучшее, но при этом почему-то сильно привязываешься именно к единственному варианту от Haywire.
---------- Post added at 01:53 ---------- Previous post was at 01:50 ----------
Меандр - это прямоугольный сигнал на постоянной частоте, а у нас шумоподобный, широкополосный битовый сигнал. Слово "гармоника" в этом контексте не имеет никакого смысла. Спектром битового сигнала возможно управлять в некоторой степени. Я это продемонстрировал несколькими сообщениями ранее, прислав образец спектра. Прислать тебе сам сигнал, чтобы ты посмотрел его спектр и убедился?
Целый период - это уже частота. Да даже если б был не целый - свойства, по которым прямоугольный сигнал раскладывается на гармоники - сохраняются. По факту - стандартный спектрумовский сигнал - это двухчастотный сигнал с кучей гармоник, обусловленных его прямоугольной формой и модулированностью.
Пришли. Правда, я не совсем понимаю, что за сигнал ты хочешь прислать. Спектры стандартного спектрумовского сигнала я много раз видел.
---------- Post added at 01:54 ---------- Previous post was at 01:53 ----------
Я ставлю цели поскромнее. Задача - сделать такой формат, который бы не убивался такими искажениями, которыми не убивается синклерский. Если неравномерности АЧХ в какой-то области или какие-то иные искажения убивают синклерский формат - то мне нет дела до того, будет ли мой формат работать в таких условиях. Будет - хорошо. Нет - и ладно.
Т.е. цель сделать такой же по устойчивости формат? Но при этом большей плотности?
Barmaley_m
20.08.2013, 13:16
Да, многие записи читались.
В таком случае у тебя есть шанс помочь проекту. Пришли мне несколько таких убитых записей, которые читались без обработки. Я попытаюсь по записям понять характер искажений и буду тестировать свои форматы на похожих искажениях.
Ссылки прямой у меня нет, но на форуме где-то тут проскакивала. Кажется, newart владеет информацией.
Это же твой проект. Ты разве его не релизил где-то, хотя бы в теме на форуме?
Эти испытания и практика на очень узком количестве реальных магнитофонов. Практически только на одном.
Ты специально отрицаешь очевидные вещи? Мне уже надоело повторять. Испытывалось на нескольких магнитофонах. Прочитай тему с начала. На одном не заработало, но те магнитофоны, на которых заработало, нельзя исключать из статистики.
Это хорошо, что ты пытаешься получить лучшее, но при этом почему-то сильно привязываешься именно к единственному варианту от Haywire.
Я уже объяснял причины, по которым сосредоточил сейчас внимание на этом магнитофоне. Тебе они непонятны? Если тебе кажется, что я "слишком сильно" сосредоточился на этом магнитофоне - то потрудись объяснить, почему, с твоей точки зрения, это неправильно.
Целый период - это уже частота.
Сигнал записи на магнитофон непериодический, хоть в синклерском формате, хоть в любом другом. Если бы он был периодический - то информацию нес бы только первый период сигнала, а второй и последующий не несли бы, т.к. повторяли бы еще раз то, что уже загружено.
свойства, по которым прямоугольный сигнал раскладывается на гармоники - сохраняются.
И что же это за свойства, которые ты имеешь в виду?
Что такое вообще "разложение на гармоники"? Разложение в ряд Фурье (http://ru.wikipedia.org/wiki/%D0%A0%D1%8F%D0%B4_%D0%A4%D1%83%D1%80%D1%8C%D0%B5) ? Но в ряд Фурье можно разложить только периодическую функцию (сигнал). Тогда его спектр будет дискретным, и в нем будет пик на основной частоте и ее гармониках. В случае же непериодической функции (сигнала) разложение в ряд Фурье невозможно и, соответственно, не имеют смысла такие термины, как "гармоники".
Непериодический сигнал можно разложить в интеграл Фурье; также существуют и другие способы оценки его спектра. В общем случае такой сигнал имеет непрерывный спектр, т.е. содержит колебания не на дискретном наборе частот, а на их континууме.
По факту - стандартный спектрумовский сигнал - это двухчастотный сигнал с кучей гармоник,
Вот тебе спектр спектрумовского сигнала на записи ПЗУ (т.е. более-менее случайных данных). На рисунке 1 спектр от 0 до 22050Гц, на рис. 2 - его часть от 0 до 2000 с небольшим Гц (та часть, где содержится полезная информация; все, что выше, может быть безболезненно удалено фильтром). Покажи мне тут двухчастотность и гармоники.
Т.е. цель сделать такой же по устойчивости формат? Но при этом большей плотности?
Да.
Barmaley_m
20.08.2013, 13:23
Вот что лично я увидел интересного в этих спектрах - это то, насколько сильно в них подавлены низкие частоты. Так, уровень на 200Гц подавлен на 16.5дБ по сравнению со средним уровнем в основном диапазоне частот, где находится сигнал (800-2000Гц). Неудивительно, что такой сигнал устойчив к горбам АЧХ на низких частотах.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot