Просмотр полной версии : ROM-формат: автозапуск, защита, секреты
В "Справочном руководстве по компьютеру "Вектор-06Ц" (http://sensi.org/~svo/scalar/ware/632), в котором подробно описан ROM-формат, упоминается об оригинальном способе ROM-автозапуска. Метод заключается в формировании ROM-файла таким образом, чтобы при его загрузке были модифицированы служебные ячейки начального загрузчика в области ОЗУ (стек, точки перехода). Таким образом загружаемая программа перехватывает управление и может делать свои "черные" дела. Естественно, при этом есть некоторое ограничение: нет возможности осуществить переход на собственную процедуру обработки прерываний, т.к. ПЗУ остается включенным.
Основное назначение метода - защита программ от нелегального копирования, но есть и прикладное применение - ROM-дампинг. Можно создать такую программу, которая, получив управление, прочитает содержимое ПЗУ и выведет ее на магнитофонный выход или на разъем ПУ. Польза очевидна - нет нужды выковыривать ПЗУ, чтобы прочитать его содержимое.
Вот примеры программ, использующих метод ROM-автозапуска разными способами:
Копировщик FTT-Copy (http://sensi.org/~svo/scalar/ware/718/) - работает только с базовым (самым распространенным) начальным загрузчиком 512 байт.
Копировщик TURBO-COPY (http://sensi.org/~svo/scalar/ware/719/) - работает с большинством загрузчиков. Пример загрузки можно посмотреть здесь http://www.youtube.com/watch?v=NMQ09QdirCg
Защита от тиражирования программ "по имени"
Байт-3 (http://www.sensi.org/~svo/scalar/ware/130)
Типичная внешняя защита. Основана на внутренней структуре программы COPY. Дело в том, что эта программа после загрузки копируемого файла и перед выводом его на магнитофон делает проверку символов его имени. Если очередной символ не удовлетворяет определенным требованиям, то загорается "НЕЛЬЗЯ" и программа сбрасывается.
Точные требования к символам имени неизвестны, нужно смотреть внутрь копировщика.
С помощью конвертера Rom2wav (http://www.sensi.org/~svo/scalar/ware/556) можно получить WAV-файл "без защиты", если исходное имя ROM-файла написано латинскими заглавными буквами и "с защитой", если используются прописные или русские буквы.
Защита представляет только исторический и исследовательский интерес, т.к. большинство копировщиков (исключая базовый 2.1) ее игнорируют. Кишиневский центр "Компьютер" распространял свой софт с этой защитой. Пока не было других копировщиков элементарно снималась через монитор-отладчик.
Нигде не сказано, что подблоки в блоке ROM-файла должны грузиться последовательно и никак иначе. Дык надо проверить! Грузим подблоки нормально, инверсно, туды-сюды, внутрь, наружу, интерлейсно, случайным образом, чередуем это все по два блока. Работает! Реальное видео (из эмулятора, не фейк) http://www.youtube.com/watch?v=gleNQY-oDLk
Tim0xA, здорово, только звука не хватает.
Заменил видео на другое со звуком.
Нигде не сказано, что подблоки в блоке ROM-файла должны грузиться последовательно и никак иначе.
Так не зря же большие блоки в записывались по 2 раза... Если первый раз неверно прочиталось -во второй прочитывалось. В некоторых загружчиках и большие блоки можно грузить в любом порядке, а вот Uniload 2 у меня не читал программу, если после блока не шел его повтор, даже если с первого раза всё прочиталось... видимо разработчики это жестко прошили в коде.
Так не зря же большие блоки в записывались по 2 раза... Если первый раз неверно прочиталось -во второй прочитывалось.
Да можно хоть по 20 раз ;) Это никак не ограничивается.
В некоторых загрузчиках и большие блоки можно грузить в любом порядке
Это возможно в LoadByte (http://www.sensi.org/~svo/scalar/ware/559/). Я уже пробовал грузить блоки хаотично. Видео потом выложу.
а вот Uniload 2 у меня не читал программу
Этот загрузчик сохранился?
Продолжаем исследовать ROM-формат. На этот раз проверим его избыточность. Не вся информация используется при подсчете контрольной суммы и при чтении файла, а значит чем-то можно пожертвовать.
Вот, например, один блок из знаменитого Pillars:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
55 55 55 55 E6 00 00 00 00 4E 4F 44 49 53 43 30 UUUUж NODISC0
30 30 30 30 30 30 30 70 69 6C 6C 61 72 73 20 20 0000000pillars
20 20 00 00 01 13 13 DE 00 00 00 00 E6 82 DE 8A ☺‼‼Ю ж'Ю_
AB 0F 4F 0A C9 47 0E F1 2D 24 24 2D 24 24 24 2D <☼O◙ЙG♫с-$$-$$$-
2D 24 24 24 E7 4F 06 53 25 2C 25 25 25 25 2C 80 -$$$зO♠S%,%%%%,_
00 00 00 00 E6 85 DE E0 9C 51 09 3D 30 7D 08 BC ж:Юа_Q○=0}◘_
FC 67 42 40 09 BB 83 07 38 40 09 BB 07 70 2F 3F ьgB@○>_•8@○>•p/?
08 BC 0E 5B 9C 9B 32 D1 00 00 00 00 E6 87 DE 60 ◘_♫[_>2С ж╪Ю`
30 73 C2 D6 E0 FB E7 C6 27 D9 DD 5D 15 E9 9A 35 0sВЦаызЖ'ЩЭ]§й_5
F2 E8 D1 AD B4 62 EC C4 3B FB 5F 09 9A 1C 93 94 тиС-_bмД;ы_○_∟""
00 00 00 00 E6 80 DE C3 C3 12 0E 49 E7 4F 06 38 ж_ЮГГ↕♫IзO♠8
2D 24 2D 2D 24 2D 2D 24 E7 4F 06 83 E7 47 0E 1F -$--$--$зO♠_зG♫▼
2C 25 25 25 2C 25 E7 FB 00 00 00 00 E6 81 DE E3 ,%%%,%зы ж_Юг
1F 8B 99 AE 4F 2B 1F 98 8E 9A 47 E3 3B 3B F1 33 ▼<TRO+▼___Gг;;с3
33 D5 53 88 A9 5F 33 92 D5 C1 3E 00 F5 C8 47 D8 3ХS_c_3'ХБ> хИGШ
00 00 00 00 E6 83 DE 2C 25 25 2C 25 25 25 25 25 ж_Ю,%%,%%%%%
2C 25 25 25 2C 25 25 25 2C 25 2D 25 25 25 25 2C ,%%%,%%%,%-%%%%,
2C 25 25 2C 25 25 2C 48 00 00 00 00 E6 86 DE AD ,%%,%%,H ж┼Ю-
B2 0B 92 35 64 E8 EA 5D 8D 66 92 95 CB 68 F6 9E _♂'5dик]_f'•Лhц_
8E 33 02 AC F4 FA B0 16 59 3E E0 36 81 9B 69 5E _3☻┐фъ°■Y>а6_>i^
00 00 00 00 E6 84 DE 25 E7 47 0E AD E7 4F 06 94 ж"Ю%зG♫-зO♠"
24 2D 24 2D 24 2D 24 24 E7 4F 06 DA E7 47 0E 4C $-$-$-$$зO♠ЪзG♫L
E7 F0 88 CE 17 1F 19 95
Красным цветом выделены байты, с которыми мы попрощаемся. Их 42 штуки.
Pillars - состоит из 19 блоков. Экономия 798 байт. Выигрыш в скорости загрузки 2 секунды.
Бластер - 98 блоков. Экономия 4116 байт - более 4 килобайт! Выигрыш в скорости загрузки 12 секунд!
Конечно, в эмуляторе все красиво, но надо проверить на реале. Работает!
Смотрим видео загрузки Pillars http://www.youtube.com/watch?v=fkEcZfCtHLA
Чтобы было веселее, заодно сделана случайная загрузка подблоков.
В некоторых загрузчиках и копировщиках отображается имя загружаемого ROM-файла. Возникла шальная мысль - сделать текстовый скролл, подставляя в поле имени ROM-блока какой-нибудь свой текст, постепенно смещая его на один символ влево от блока к блоку. Но, к сожалению, реализовать эту задумку не удалось, т.к. имя файла считывается и отображается всего один раз. Зато попутно выяснилось, что поле имени каким-то образом используется при вычислении адреса загрузки следующего блока. Т.е. если во втором блоке ROM-файла изменить всего один символ имени, то блоки уже могут загружаться через одну или несколько позиций. И это несмотря на то, что номер блока, их количество и начальный адрес указаны правильно! Надо подумать, можно ли это использовать как-нибудь.
Те 42 байта, которые я выкинул из ROM-блока в предыдущем сообщении, можно использовать для скрытой передачи данных и создать еще один метод защиты от копирования. В этом случае программа может поставляться в виде двух ROM-файлов.
Первый ROM-файл - это загрузчик (один блок, запускается по БЛК+СБР, как в кишиневском ROM1, или автозапуском), который "знает", что в обычно неиспользуемых полях ROM-блока есть полезная информация, например, ключ декодирования по XOR.
Второй ROM-файл - закодированная программа, ключ декодирования которой находится в неиспользуемых полях подблоков. Загрузчик, считывая подблоки, извлекает ключ дешифровки и загружает в память уже корректные данные.
Если скопировать второй закодированный файл обычным копировщиком, ключ будет утерян и программа будет неработоспособна.
Во время загрузки ROM-файла можно писать поверх загрузочной таблицы и даже рисовать. Правда всего лишь одним цветом. Но зато это работает в любом из табличных магнитофонных загрузчиков. В приложении WAV-файл, скриншот и можно посмотреть видео http://www.youtube.com/watch?v=-hU9__2JB00
Версии (https://yadi.sk/d/rVInVPvVnw4zV) rom2wav с устраненной избыточностью, по результатам (http://zx-pk.ru/showthread.php?t=10002&p=195801&viewfull=1#post195801) Tim0xи
Не совсем по теме, но близко. Попробовал сделать сильно турбо загрузку, в духе современных достижений для спека. Это не для хранения на магнитной ленте, строго wav->магнитофонный вход. Остановился на примерно 6200 бит/сек, putup грузится за 23 секунды. Загрузчик в рабочем виде, без сервиса и возможно для реала потребовал бы тюнинга (может пришлось бы несколько сбавить скорость). Заодно узнал, что в одном из эмуляторов сигнал с "магнитофона" инвертируется, а в другом без инверсии, что было неожиданно.
Заодно узнал, что в одном из эмуляторов сигнал с "магнитофона" инвертируется, а в другом без инверсии, что было неожиданно.
Теоретически это не имеет значения (тем более усилитель магнитофона может инвертировать сигнал на раз), но для экстремальных скоростей возможно что и имеет :)
Сделал более консервативный вариант (https://yadi.sk/d/tN6tb6KYoBtSN) (примерно 3700 бит/сек), но зато надеюсь он сможет работать и на реале. PUTUP грузит 36 секунд, все же заметно быстрее, чем самый быстрый rom-формат.
Rom2fm.exe - для конверсии ромов в wavы в этом формате (спасибо Ramirosу за выкладывание исходника Rom2wav!). loadfm - загрузчик для вектора. Сначала нужно загрузить (3 секунды) и запустить loadfm, потом можно грузить wavы конверснутые rom2fmом. Если загрузчик нашел синхропоследовательность, то нарисует 2 метки справа - нижняя соответвует начальному блоку, верхняя - конечному. В процессе загрузки справа будет расти столбик от начального блока к конечному.
- - - Добавлено - - -
Кстати, можно найти этому формату еще одно нестандартное применение. Получающиеся wavы звучат довольно неприятно (шипящее жужжание) и если их воспроизвести погромче через колонки, то можно выгнать из комнаты лишних людей (или животных).
Попробовал turbo-copy (автор vladtru, Tim0xA упомянул эту программу в первом посте (http://zx-pk.ru/showthread.php?t=10002&p=195190&viewfull=1#post195190) треда). Когда у меня еще был реал, я пробовал этот копировщик и определил, какую максимальную скорость реал еще переваривает, но сейчас не смог найти ту информацию, поэтому попробовал в v06cc (для меня это актуально, чтобы грузить отладочные версии программ без sd). Почти грузит при константе 15, уверенно грузит при константе 16. Скорость при этом примерно как у loadfm, поэтому я доработал свой вариант, чтобы обогнать turbo-copy.
Rom2fm2 (https://yadi.sk/d/xCD9UIInoRmgt) - изменились и конвертер и загрузчик. Скорость увеличилась примерно до 4200 бит/сек, putup загружается 32 секунды.
А можно попробовать объединить загрузку и упаковку (в смысле распаковку)? Или распаковщику не поспеть за битиками?
Высокие скорости с распаковкой на ходу проблематично объединить, разве что поблочно - загрузил блок и пока идет какой-нибудь заполнитель (нули или еще что) между блоками распаковать. А в чем цель, для сокращения общего времени от начала загрузки до старта? Распаковщик b2mа для megalz быстрый, с ним задержка на распаковку мало ощутима. Резервы для ускорения загрузки еще есть, но боюсь до современных спековских турбо-лоадеров я не дотяну, все же и проц помедленнее.
Понятно, что программа сама себя может запаковать, но интересно было бы, если бы это происходило на уровне системы, незаметно для программы. Ясно, что способ упаковки нужен какой-то нересурсоемкий.
Мне вообще всегда было интересно, чего можно было бы достичь, если бы подсистема общения с лентой не была бы ограничена в ресурсах и развитие носителей продолжалось бы с предпочтением ленте, а не дискам. Эдакий тейп-панк. Я пробовал играться с этой идеей в gnuradio. Получалось интересно, пока это все было в компьютере —*даже с динамика на микрофон хорошо ловилось (сейчас уже не помню битрейт, думаю, что поболее 4кбит). Но все мои попытки рассыпались о совершенно фатальную детонацию в моем рассохшемся магнитофоне. Ничего из традиционных модемных технологий справиться с ней не в состоянии. И тогда у меня просто запал кончился.
Выглядел тестбенч примерно вот так:
http://i.imgur.com/UU2qp5d.png
Плохо помню, если верить имени файла, то получалось выжать 1330cps, то есть примерно 10кбит.
Интересная картинка. Не могу найти на рисунке перемежителя/деперемежителя, для "канала с памятью" он бы помог. КМК детонация в некотором смысле близка к многолучевому распространению, но практически без наложения а только со смещением во времени туда-сюда. В данном случае целесообразным представляется переход к COFDM, биты отдельных несущих станут намного длиннее ну и защитные интервалы помогут.
COFDM был следующим в планах, но на него не хватило пороху. Готовые модули OFDM в gnuradio не то были плохо документированы (как будто бы там хоть что-то документировано хорошо), не то покрывали только какие-то частные случаи. В общем не разобрался и забил. Я видел ютубы, где DRM сигнал записывался на хорошую деку и потом успешно проигрывался.
Еще у меня была идея добавлять пилотный тон, чтобы по его девиации восстанавливать расплывшийся сигнал. Но это надо думать и самому писать модуль. Сейчас я это уже немного умею (в смысле писать модули, думать увы), так что может быть как-нибудь.
Правда с тем кассетофоном, что у меня сейчас, по-моему экспериментировать нелепо. Только если искать какие-то экстремально устойчивые виды модуляции. Даже Квазар-303 времен моего детства имел меньшую детонацию. А покупать другой кажется еще глупее, там будут все пасики в таком же плачевном состоянии.
Rom2fm3 (https://yadi.sk/d/4bzV7LLjorGKb) - скорость не менее 5800 бит/сек. Если есть преобладание нулей или единиц (в любую сторону), то будет еще быстрее - putup грузит 22 секунды (6400 бит/сек). Самый большой rom, который нашел - JOEBLADE.ROM, 46336 байт, загружается за 64 секунды. exp1.rom чуть побольше (46848 байт), но там некоторое преобладание нулей, поэтому он грузится чуть быстрее - за 62 секунды.
- - - Добавлено - - -
На всякий случай напомню - чтобы грузить быстро в emu, надо в конфиге закомментить, т.е. добавить - (минус) в начале строки
noisefilterfreq=3000
Или просто удалить эту строку.
Ускорение за счет изменения принципа кодирования. fm и fm2 использовали практически классический fsk, а fm3 гибрид Biphase mark coding (https://en.wikipedia.org/wiki/Differential_Manchester_encoding) и pwm. Интересно, получится ли еще ускорить.
Сфотал спектрограммы:
http://imgur.com/a/vCxis
В альбоме коментарии.
Полоса доходит теперь ажно до 8кГц, но интересно, что она расползается только на участках с большим количеством нулей, или единиц. Наверное в более взрослой системе использовался бы скремблер для убелошумливания данных. Если я все правильно понимаю, это уменьшит пропускную способность, но позволит остаться в более узкой полосе?
Неплохо было бы профильтровать, чтобы срезать все образы. Еще наверное лидер надо сделать таким, чтобы он обозначал собой пределы полосы. В оригинальном формате, уж не знаю случайно, или специально, это соблюдено.
Интересно было бы с пленкой попробовать. Или хотя бы найти хороший симулятор магнитофонных искажений.
Увше: еще подумал, что сжатие на ходу выполнило бы функцию скремблера.
Моя очередь постить картинки (http://imgur.com/a/2b8vI)
Верхняя - спектрограммы putupа
1. Самый быстрый rom, который может сгенерировать rom2wav Ramirosа (чтобы грузился нужно хакать загрузчик)
2-4. fm-fm2-fm3
Нижняя - использовавшиеся настройки построения спектрограмм audacity
Фильтр надо бы, это я согласен. Ramiros вот реализовал при генерации romа простую интерполяцию. Насколько помню, в спековском генераторе турбы тоже фильтрация реализована.
Если я правильно понял, про что ты, то "лидер" в fm3 - это 256 нулей после служебной части, которые дают время напечатать имя, если вдруг понадобится. На данный момент я их просто пропускаю.
Скремблирование можно заменить нормальным сжатием, только не на ходу. При таких скоростях каждый такт на счету, я даже подсчет контрольной суммы вынес из цикла загрузки. С ним (скремблированием или сжатием) вид спектра, понятное дело, станет более "предсказуемым", но имхо на скорость в данных условиях (PC -> v06cc на de1/de1-soc/de2-115 или, тем более, в эмулятор) это вряд ли повлияет.
Насчет использования fmов с магнитофоном - я сразу написал, что на это не нацеливался, в лучшем случае (PC или плеер) -> реал. Да, это было бы интересно, но нужен магнитофон, кассеты (или катушки) - у меня сейчас нет такой возможности.
- - - Добавлено - - -
В audacity подобрал минимальную частоту среза ФНЧ (выбрал максимальную доступную скорость спада АЧХ в полосе задерживания - 48 дБ/октаву), при которой еще грузит - 6400 Гц. Вот картинка (http://imgur.com/TMC32gW) (вверху без фильтра, внизу - после фильтрации).
- - - Добавлено - - -
И насчет параметров построения спектрограммы. Для последней картинки (putup fm3 оригинальный и с фильтрацией) попробовал 4 варианта размера окна (http://imgur.com/a/xBFuj) 2048/4096/8192/16384. Мне в данном случае больше понравились 4096 и 8192
Интересные картинки, разница в длине впечатляет!
(Кстати, предчувствую, что в районе ширины окна 2048 спектрограмма будет выглядеть почетче).
Наверное да, для таких экспериментов не существенно ни что пищит в начале, ни насколько регулярно выглядлит спектр. Хотя, если бы это была настоящая пленка, мне кажется, что иметь спектр поуже и подальше от 8кГц могло бы быть спасительно. Даже если где-то заявлено, что у пленки 10кГц полоса (не знаю, сколько обещается для обычной FeO2 кассеты, особенно в магнитофоне Квазар-303, но думаю, что не больше), в этой полосе у него небось +/- 3dB. Да и то все это прыгает и скачет по прихоти заменяющей пасик резинки от трусов на тонвале и сплющенного в геоид прижимного вала.
Ха, я успел дополнить тот пост картинками с фильтром и разными размерами окна до твоего поста :)
- - - Добавлено - - -
Думаю, что влияние непостоянства скорости на чтение данных у старых/плохих магнитофонов страшнее узкого АЧХ.
Думаю, что влияние непостоянства скорости на чтение данных у старых/плохих магнитофонов страшнее узкого АЧХ.
Видел в воскресенье деку с двумя тонвалами, но чего-то нету доверия тому, что простояло неизвестно сколько лет в едва отапливаемом ангаре.
Поискал симуляторы детонации, нашел один вот тут (WOW & FLUTTER): http://www.interruptor.ch/vst_donationware.shtml — но не знаю, как его настроить, чтобы было аутентично, да и все ли аспекты он симулирует. Поэтому решил подышать пылью и прогнал все через свою Айву. Надо заметить, что она и новой не слыла особым хай-фаем, так что мои результаты — это еще не приговор. Опять же, кассета, через которую я это пропускал, та еще.
Вот файлы, пропущенные через деку и обратно. Входной уровень был средний, усилил в Audacity с умолчательными параметрами минус 1dB.
https://www.dropbox.com/s/idi2kollyx0em3h/deck-loader.wav?dl=0 — лодырь
https://www.dropbox.com/s/52of6kxu1xranka/deck-putup.wav?dl=0 — путап
https://www.dropbox.com/s/kj44vdql3rcdx9s/deck-xorz.wav?dl=0 — хорьки
https://www.dropbox.com/s/ryauqi1mv7eaqh5/deck-xorz-ac.wav?dl=0 — попытка убрать постоянную составляющую из хорьков
Лодырь загружается. Остальное — нет. Исходные вавы грузятся суперски.
В принципе, прочитанное выглядит не так уж ужасно, просто слегка страшненько. Видно, что фильтрация могла бы немного скрасить фронты, а скремблинг, может быть, чуть чуть успокоить АРУ:
http://i.imgur.com/uOWSBlI.png
В чем причина такого сильного плаванья середины — не знаю. Может быть, прижимной ролик елозит ленту по сторонам? Я недостаточно знаком с нюансами кассетной звукозаписи.
Вот фрагмент начала, вообще почти ровно по-моему:
http://i.imgur.com/aGUhiza.png
По этой картинке наверное можно судить о детонации (двойной, сначала запись, потом чтение):
http://i.imgur.com/O8Fs0Vo.png
Экстремальный зум:
http://i.imgur.com/Z2VGNUK.png
Разнос где-то 100 Гц. Если там можно выделить период, то он наверное в районе 7.5 Гц. Не знаю, как считают коэффициент детонации. Поверхностно мне кажется, что это аргумент в пользу переезда моего кассетофона в район городской свалки. Но лучшего у меня нет пока, да и помнится я тестировал какую-то условно хайфайную деку в предположительно хорошем состоянии и тогдашние результаты замера меня расстроили не меньше.
P.S. В эмуляторе Ramiros-а у меня вообще все эти вавы не открываются. Говорит, плохой формат. WAV, PCM 16-bit signed, куда уж лучше?
- - - Добавлено - - -
Поиграл еще немного с кассетой. Померил, что получается, если записать и прочитать:
Белый шум с разными уровнями (условно, 0 и -20dB): http://asdasd.rpg.fi/~svo/b/tape-frequencies/whitenoise.html
Пробег по частотам, линейный и логарифмический: http://asdasd.rpg.fi/~svo/b/tape-frequencies/swipe.html
Чистый тон 3 кГц: http://asdasd.rpg.fi/~svo/b/tape-frequencies/fm.html
Мониторя процесс, заметил, что моя тестовая кассета в очень печальном состоянии. Надо поискать другую, или хотя бы попробовать записать ivagor-овские примеры на менее заезженный участок.
P.S. В эмуляторе Ramiros-а у меня вообще все эти вавы не открываются. Говорит, плохой формат. WAV, PCM 16-bit signed, куда уж лучше?
лучше ненадо, надо хуже :) 8бит только.
svofski, спасибо за тесты с магнитофоном! Если вдруг найдешь еще силы для экспериментов, то вот замедленный fm3 (https://yadi.sk/d/bfi4g0AFoua7Y) (3200 бит/сек, все равно быстрее чем rom). Спектр и спектрограммы (по крайней мере для "скремблированного" xorzа) ровные и аккуратные. В качестве примера приложен xorz (т.к. он короткий и сжатый) в трех вариантах: без ФНЧ, после ФНЧ с частотой среза 6400 Гц и после ФНЧ с частотой среза 4800 Гц (в эмуляторы и de1 все грузится). Тут в принципе есть небольшой резерв для тюнинга загрузчика, если приложенный вариант не сможет загрузить.
Кстати, а куда ты грузишь, в эмуляторы и/или de1?
UPD: добавил в архив вариант с частотой дискретизации 11025.
Кстати, а куда ты грузишь, в эмуляторы и/или de1?
Я гружу в b2m's b2m.
Постараюсь сегодня продолжить эксперименты. Заодно задействую менее заезженный участок пленки.
- - - Добавлено - - -
лучше ненадо, надо хуже 8бит только.
Просто 8-бит PCM не всякой программой нынче запишешь. Чтобы в Audacity такое записать, надо погружаться в страшный диалог с параметрами ffmpeg-a (кто не пробовал, проще научиться проводить операцию на мозге по видео урокам на ютубе).
Просто 8-бит PCM не всякой программой нынче запишешь. Чтобы в Audacity такое записать, надо погружаться в страшный диалог с параметрами ffmpeg-a (кто не пробовал, проще научиться проводить операцию на мозге по видео урокам на ютубе).
Древние версии Sound Forge 4.x (ещё когда она принадлежала Sonic Foundry, до того, как её испохабила SONY), делают ресэмплинг в 8 бит на лету, "лёгким движением руки".
Сегодня сделал уровень на выходе поменьше и прокатал по новому куску кассеты. Кроме того, читал на той же деке, что и писал.
Медленный вариант объективно лучше. Все варианты цепляются загрузчиком и прогресс, кажется, доходит до конца, но потом либо сбрасывается в ноль, либо засыхает. После минимальной обработки загрузился один файл: 11кГц. Пришлось сделать нормализацию с убиранием постоянной составляющей и затем усиление +20dB, так что все ушло в далекий клиппинг.
Удачный файл после обработки:
https://www.dropbox.com/s/i8r95peib4j1jt0/slow-11khz-normalized-clipping.wav?dl=0
До обработки:
https://www.dropbox.com/s/jsaedaeimymrte4/slow-11khz.wav?dl=0 (грузится, но с ошибкой, сбрасывается)
Волнующая форма удачного файла до обработки:
http://i.imgur.com/SqNUSvk.png
Я думаю, что тут скорее повезло с участком пленки, или просто была удачная позиция прижимного геоида, чем возымели эффекты фильтрации и ресемплинга. Вряд ли стоит в этом случае тратить много сил на спектральную оптимальность.
Быстрый вариант на новом куске: увы, результат тот же -- совсем глухо. И как есть, и с обработкой. Если бы хотя б зацепил начало, я б попробовал записать просто 10 раз подряд в надежде, что один удастся.
Еще у меня есть ванкман Aiwa, которым я пользуюсь для перемотки (деки работают только в одну сторону). Механическое состояние у него пожалуй получше, но из него идет такой шум, треск и откровенная глухня, что нету даже желания пробовать чего-то им грузить.
Вооооообще, у меня есть еще кассетофон от C64. У него нету аналогового интерфейса в принципе (просто компаратор стоит внутри). Было бы любопытно попробовать с ним.
- - - Добавлено - - -
Древние версии Sound Forge 4.x (ещё когда она принадлежала Sonic Foundry, до того, как её испохабила SONY), делают ресэмплинг в 8 бит на лету, "лёгким движением руки".
Спасибо. На самом деле уже и в Audacity нашлось как это делать без прохождения курса управления звездолетом. Но пока проще обходиться 16-битными файлами.
Здорово! В принципе ведь можно вообразить коробочку с фильтром и усилителем, подключаемую к магнитофонному входу (т.е. типа и в реал теоретически могло бы загрузится) :)
В de1 грузится даже файлик без обработки, хотя и не каждый раз. Сместил в загрузчике на 1 порог различения 0 и 1 и вроде стало грузится чаше (мало пробовал, чтобы утверждать наверняка). Возможно сказывается то, что в кодеке включен ФВЧ, удаляющий постоянную составляющую. Помню, что была проблема с загрузкой в emu каких то файлов с постоянной составляющей, помогала предварительная фильтрация.
Есть предположение, что помог бы возврат синхробита к каждому байту, как я делал в fm. Для pc->de1 это лишнее, а для ленты может и помогло бы. Ну и наверно стоит при генерации файла максимизировать уровни сигнала.
Наверное, многое зависит от реализации компаратора. В реал интересно было бы как-нибудь, но мне сейчас не осилить. Количество плат и проводов на кубический метр в жертвенной комнате превышает способности коры головного мозга все это разруливать и находить.
Уровни сигнала в файле при ленточных экспериментах вряд ли сильно что-то поменяют. Все равно все это проходит через звуковую карту, через АРУ магнитофона и в результате получается чего-то среднее неизвестно что. Я думаю, что моей погремушкой ленту принципиально не насытить, например.
Вот, кстати, как звучит записанный и прочитанный 3 кГц тон: https://instaud.io/jtQ
На слух слышно такое ваувау где-то в районе 1 Гц, не считая прочих шумов. Обычным софтом трудно такие колебания анализировать. Может быть попробую демо версию Capstan-a. Любопытно, чего она скажет. Пробовал на скорую руку скормить в NBFM демодулятор в GNU Radio, но получается чего-то совершенно невнятное.
У меня приземленный вопрос - планируешь еще мучить ленту? Если да, то я добавлю синхробиты в fm3slow, кажется это может помочь.
fm3slowSync (https://yadi.sk/d/k1onefeoozDfn) - здесь у каждого байта есть синхробит, поэтому хотя скорость модуляции сохранилась, но информационная уменьшилась до 2900 бит/сек. Загрузчик подходит предыдущий, от fm3slow
svofski, а что это за магнитофон такой отвратительный?
BYTEMAN, Aiwa NSX-AV65. Он не отвратительный, просто старый. Пасики высохли и ролики сплющились.
- - - Добавлено - - -
Записывал с 0dB и -20dB. -20dB прочиталась с первого раза без обработки. Вот удачный файл:
https://www.dropbox.com/s/9hsz8v8ncozj2ae/deck-20db-ok.wav?dl=0
Может быть плоскость характеристики на -20dB все-таки чем-то помогает. Решил попробовать еще раз самую быструю версию. И тут наткнулся на что-то не совсем мне понятное в b2m. Когда я запускаю играться файл, в котором 6 раз подряд записаны хорьки, загрузчик цепляет начало, правда рисует огромный размер. Какое-то время грузит, столб растет выше обычного, потом виснет. Я решил попробовать разбить файл на отдельные записи. Ожидал, что первая запись точно так же сработает. Но нет, первая запись, вырезанная в отдельный фрагмент, вообще никак не обращает на себя внимание загрузчика.
Проверил, что вырезанный фрагмент точно совпадает. Инвертировал и сложил, все в нулях.
Вот файлы на пробу:
Все вместе: https://www.dropbox.com/s/71g4l15ce5dtss2/fast-20db-6x.wav?dl=0
Разбитое на записи:
https://www.dropbox.com/s/oyfcfccclrccj82/deck-20db-0.wav?dl=0
https://www.dropbox.com/s/r5b61uwl5ucj8ye/deck-20db-1.wav?dl=0
https://www.dropbox.com/s/pwhejj1r66yrqpz/deck-20db-2.wav?dl=0
https://www.dropbox.com/s/pwhejj1r66yrqpz/deck-20db-2.wav?dl=0
https://www.dropbox.com/s/rafr4pi4xpufdmy/deck-20db-3.wav?dl=0
https://www.dropbox.com/s/3kez2viw9dpth9o/deck-20db-4.wav?dl=0
https://www.dropbox.com/s/6h11hvx5pxfwg2k/deck-20db-5.wav?dl=0
2900 на магнитофоне в тяжелом состоянии - думаю это неплохо! Помню фразу, вроде из старой книжки про msx - типа "если у вас хороший магнитофон, то можете попробовать увеличить скорость до 2400 бит/сек". Не исключено, что можно побыстрее, но наверно игра не стоит свеч.
Насчет быстрой версии - учитывая, что без обилия животворящих синхробитов не хотело грузится даже 3200 бит/сек, то здесь особо ловить нечего. А для загрузки в de1 я попробую еще ускорить, небольшие резервы есть.
Спасибо за тесты с магнитофоном, это было познавательно!
Это очень круто, но все же тема по-моему еще не исчерпана. Во-первых, мой магнитофон, как было неоднократно подмечено, совершенно убитый. Во-вторых, мы еще не пробовали промежуточные варианты, типа быстро-но-с-синхробитами. Ну и совсем еще не исследована тема EEC/FEC. Пользуясь медиумом на пределе возможностей, крайне наивно рассчитывать на то, что не придется корректировать ошибки. Можно делать паузы между блоками, чтобы алгоритм успевал. Мы же не знаем, например, сколько там ошибок. На файл в несколько килобайт у нас одна метрика: получилось, или нет.
А вот может быть у BYTEMAN-а есть магнитофон поприличней?
- - - Добавлено - - -
Заглянул в схему реала, не нашел там ОС в схеме компаратора. Удаление постоянной составляющей, замысловатый фильтр и прямо на инвертирующий вход компаратора. Все.
BYTEMAN, Aiwa NSX-AV65. Он не отвратительный, просто старый. Пасики высохли и ролики сплющились.
Ничего себе... NSX-R71 таких выкрутасов не устраивает вроде...
- - - Добавлено - - -
А вот может быть у BYTEMAN-а есть магнитофон поприличней?
Основной сейчас Вега-120 :)
Ничего себе... NSX-R71 таких выкрутасов не устраивает вроде...
Этой лет 20, из которых 15 она простояла забытой в углу, где ей шваброй периодически тыкали в самооткрывающееся забрало, а закрывать забывали.
Может быть ты хотел бы попробовать повторить эксперимент на блестящей трехмоторной Веге (с двумя тонвалами?) ? Умудренный опытом, я могу описать всю методику. Так что это не займет слишком много времени.
svofski, я согласен, что тема в принципе не исчерпана, но ковырять ее в сторону ускорения уже не так просто. Например, введение помехоустойчивого кода - в примерах, которые ты выкладывал, не было редких отдельных ошибок, т.е. не было условий для применения какого-нибудь простого кода типа хэмминга. А если что-то более сложное, то придется корректировать уже после загрузки. Ну и надо смотреть, какая избыточность будет из за кода, может проще будет сбавить скорость. Без магнитофона под рукой сложно оценивать работоспособность предлагаемых решений и искать хорошие варианты. Т.е. если ты или BYTEMAN или еще кто-нибудь сделает скоростной магнитофоннодружественный формат, то я только за. Кстати, может стоит попробовать с лентой turbo-copy, который упоминал Tim0xA в первом посте (и я потом тоже)? Для загрузки pc->de1 (может и в реал) он проиграл, но может для твоего магнитофона он подойдет лучше fm3slow?
- - - Добавлено - - -
Еще пара слов по поводу fm3 (не slow) и магнитофона - считаю, что это не очень удачное сочетание. Как минимум надо добавить синхробиты к каждому байту, как в последнем варианте fm3slow.
svofski, тонвал там один) Но аппарат фунциклирует нормально :) Напиши пожалуйста по шагам что надо сделать, я попробую до конца недели проверить. Заеду сегодня на склад за чистой кассеткой.
в примерах, которые ты выкладывал, не было редких отдельных ошибок, т.е. не было условий для применения какого-нибудь простого кода типа хэмминга
А понятно что было? Допустим, ты мог бы написать декодер этого файла не для Вектора: не ограниченный скоростью процессора и накладными расходами писания на ассемблере? Или там все печально?
- - - Добавлено - - -
BYTEMAN, супер! Я приготовлю один большой wav-чик в котором будет все сразу, и отпишусь.
Ну по предыдущему варианту я увидел, что синхра после заголовка и первого байта сбивается, поэтому предложил добавить везде синхробиты.
Насчет нерилтаймового декодирования - только сейчас подумал, что можно сначала просто оцифровать (короткий, на сколько памяти хватит) в вектор битики с магнитофонного входа и потом уже его как-нибудь обработать.
Можно попробовать и не для вектора декодер (например на матлабе), но дело в том, что я уже неоднократно делал нечто подобное по работе и мне сложно заставить себя еще раз заняться этим.
- - - Добавлено - - -
Лучше O.T.L.A. (http://zx-pk.ru/showthread.php?t=23952) попробовать, я его (пока? :) ) не догнал по скорости. И я не смотрел исходники, честно изобретал велосипед.
BYTEMAN, держи мегатест!
https://www.dropbox.com/s/ydo97j4oodpxmd4/megatest.wav?dl=0
Вав на 36Мб. Жирный, но я решил, что надежнее будет без изысков. Самплрейт 44100. Если в карте можно настроить внутренний клок на 44100, лучше наверное это сделать, чтобы избежать лишнего ресемплинга, хотя заморачиваться об это слишком сильно тоже не надо. Поставь громкость выхода на 100%.
Если не трудно, лучше в качестве плеера и рекордера поставить Audacity (или любую другую специальную программу). Так точно будет понятно, что все работает без примочек, пришлепок и т п. VLC, например, легко может пропустить звук через компрессор. Кроме того, она может легко обрезать начало и конец (хотя я специально сделал начало и конец чисто декоративными).
Сначала идут сигналы с большим уровнем. На трехмоторке белый шум должен показывать 0dB. Если больше, или меньше, подкрути уровень там, где его проще крутить.
С такими настройками запускай писаться с начала. Когда все запишется до конца, оцифруй обратно в моно вавчик на те же 44100 16 бит (стерео тоже ок) и срочно на анализ ivagor-у.
Как быть с уровнем на оцифровку я не подскажу, потому что это все зависит от аналогового тракта и карты. Просто визуально можно сравнить амплитуду. Смысл есть сравнивать части на -20dB, ибо те, что в 0dB, будут вести себя непредсказуемо.
Спасибо тебе огромное!
P.S. тарахтенья в конце — это мои эксперименты с OFDM. Вектор вряд ли получится научить его читать своими силами, но интересно, насколько это совместимо с пленкой в принципе.
Rom2fm4 (https://yadi.sk/d/V-1e4J06p6eWJ) - очередное ускорение загрузки pc->de1 (и, надеюсь, реал). Минимальная скорость возросла до 6750 бит/сек (всего то в 2 раза медленнее OTLA), что позволяет загружать любой rom менее чем за минуту. PUTUP грузится 19 секунд (7450 бит/сек). Заметное изменение - уменьшил частоту дискретизации в 2 раза (22050 вместо 44100), wavы теперь в 2 раза легче.
ivagor, есть смысл добавить в мегатест, если BYTEMAN его еще не запустил? Я вечером смогу обновить.
Не знаю, что в OTLA, но подозреваю, что там какой-то компромисс. Что-нибудь типа того, что в последовательном порту. Стоп бит, старт бит, дальше просто сколько-то бит PCM и так далее.
ivagor, есть смысл добавить в мегатест, если BYTEMAN его еще не запустил? Я вечером смогу обновить.
Не стоит, в fm3 (не slow) и fm4 все на грани, шаг влево-шаг вправо и не будет грузится.
Судя по wav, в OTLA нечто похожее на ЧМ, но уверен не на 100%.
Все же у вектора и частота поменьше и торможение и 8080 вместо z80 - все это не позволит догнать спек, но ускорить еще можно. Понятно, что каждую оптимизацию загрузчика можно использовать либо для увеличения скорости либо для повышения помехоустойчивости, т.ч. потенциальный fm4slow мог бы быть чуть быстрее fm3slow.
ivagor, есть смысл добавить в мегатест, если BYTEMAN его еще не запустил? Я вечером смогу обновить.
К тестам результаты будут в субботу либо воскресенье с утра.
ivagor, вот что можно попробовать https://en.wikipedia.org/wiki/Group_code_recording
Признаюсь, в магнитной записи я совершенно темный. Не знаю, почему много единиц подряд можно, а много нулей - нет. И разве произвольный бытовой магнитофон гарантирует, что он запишет именно "прямо", а не инверсно? А для передачи по шнурку от pc сразу в вектор (v06cc или 06ц) думаю это вобще не поможет.
- - - Добавлено - - -
Кроме того, перекос в сторону единиц дает постоянную составляющую. Наверно я что-то недопонимаю.
Если они говорят, что 0 это отсуствие инверсии потока, то видимо 1 — это ее присуствие. То есть это не буквальные нули и единицы. В таком случае понятно, почему много нулей подряд плохо (получается перевес в одну из сторон, теряем зацепку клока), а перевес в сторону единиц дает больше инверсий.
Пардон, читал по диагонали и пропустил "...zero bits (which are represented by lack of a flux reversal)..."
- - - Добавлено - - -
Избыточность gcr 20% (без учета помехоустойчивого кодирования). Избыточность fm4 - 33% (без учета синхробитов, которые понадобятся и при программной реализации gcr). Т.е. gcr эффективноее, но. Так получилось, что в fm3/fm4 используется универсальная (неоптимальная) процедура getbit, которая фактически может быть использована для gcr (различение 1, 10 и 100). И я планирую разделить ее на две процедуры, оптимизировать и попробовать уменьшить длительность бита, что для gcr не получится, т.к. там еще нужно время на преобразование 5->4 (как бы не пришлось наоборот увеличивать длительность бита).
- - - Добавлено - - -
Rom2fm5 (https://yadi.sk/d/IcG6BJIBpAmTi). Оптимизация сказалась даже лучше, чем я предполагал - минимальная скорость выросла до 9300 бит/сек, что примерно соответствует OTLA с поправкой на разницу в быстродействии спека и вектора. PUTUP грузит за 13,745 сек (почти 10300 бит/сек!). Два недостатка:
1. Пришлось вернуться к высокой частоте дискретизации 44100 Гц
2. Emu не переваривает такую скорость. Главное целевое устройство "v06cс на de1" и VV грузят без проблем.
ivagor, это бешено круто. Как я понимаю, проблема взаимодействия с реальной пленкой в таких запределах упирается скорее в недостаточное быстродействие Вектора, чем в физические особенности канала. Жаль, что ты не показываешь код, а заморачиваться с дизассемблером мне чего-то невмоготу. Может быть можно оптимизировать ввод бита. Например, в стандартном загрузчике написано так:
MASK: .EQU 00010000B ;бит ввода с мг.
IZMSIG: IN 01 ;
ANI MASK ;
CMP E ;
JZ IZMSIG ;
RLC ;
RLC ;
RLC ;
RLC ; итд
И все это еще в цикле. Что если цикл развернуть, а с тестом на бит схитрить так, чтобы избавиться от сравнений. Например, такой грубый псевдокод:
...
lxi h, adj_middle
mvi e, MAGIC ; то, что при сложении со значением в порте 01, будет давать или нет флаг переноса
...
adj_longest:
in 01
add e
rlc ; или jc xxx...
adj_long:
in 01
add e
rlc
adj_middle:
...
adj_shorter:
...
adj_shortest:
; тут магия, декодирование, группировка и проч
; по результатам, когда определено изменение входа, вносим временную поправку в длину цикла - меняем HL на один из adj_...
pchl
Может быть это все ерунда, но вдруг какая-то полезная идея в этом найдется.
P.S. Кстати, github теперь поддерживает закачку файлов простым дрег-н-дропом в браузере ;)
Источник loadfm5 выкладываю, вряд ли там ты или кто-нибудь найдет нечто хитрое. Но я для разнообразия в этот раз нигде не списывал.
Насчет чтения бита (группы бит) я так понимаю ты думаешь про gcr. Ради спортивного интереса можно подумать, но вряд ли получится быстрее, чем fm5.
drag&drop в github - это круто
Я думал просто про ожидание/захват перепада, не применительно к кодированию.
- - - Добавлено - - -
Как так получается, что RST7 = GetByte, а прерывания при этом разрешены. Это ничему не мешает разве?
Там ei, hlt и они остаются запрещенными.
А, точно. Ступил.
- - - Добавлено - - -
BYTEMAN, если ты еще не занимался кассетой — сделай, пожалуйста, еще вот этот файл:
https://www.dropbox.com/s/o806qn5lnnwzob8/gcrtest.wav?dl=0
Чистую новую ленту на складе найти не смог, фиг знает куда я ее запихнул... Взял мк-60-6, на которую ранее записывал игрушки для СРС464.
Пока что только мегатест, гцр через 20 минут будет. Запись стерео, правый канал немного барахлил, возьмете тот канал который получше будет.
https://drive.google.com/file/d/0B6VbJTvOxhWCcncwS1lRdjJIdjQ/view?usp=sharing
- - - Добавлено - - -
https://drive.google.com/file/d/0B6VbJTvOxhWCVFdrdzBXU3VwY2c/view?usp=sharing
BYTEMAN, спасибо огромное! Буду анализировать.
- - - Добавлено - - -
Пока несколько картинок.
Белый шум на 0 и -20dB.
http://i.imgur.com/c8DfmTj.png
Странно ранний завал, я думаю, что это эксклюзивность кассеты МК-60 так проявляется.
Линейный пробег по частотам 0-20кГц.
http://i.imgur.com/5YVCcrK.png
Неземной красоты картинка, то же самое в логарифмической шкале.
http://i.imgur.com/psY1c3h.png
Оно же просто в виде амплитуды. Фактически это АЧХ в линейном масштабе.
http://i.imgur.com/bQY19h3.png
Отдельно можно послушать: https://instaud.io/jK9
По поводу этих трех картинок у меня вопросы. Какая была звуковая карта и, если у нее известны параметры, то какими они были? Потому что эти красоты выглядят как наложения спектров от не самого аккуратного ресемплинга при проигрывании. Еще похоже на прием гравитационных волн от столктовения черных дыр. Но очень странно было бы, если бы это был эффект магнитофона (хотя я ничего не понимаю в магнитофонах).
Биения вала. Вал очень хороший по-моему. В районе 1Гц видно какой-то перекос, но размах очень небольшой.
http://i.imgur.com/20ipcs7.png
http://i.imgur.com/NiPv72Q.png
Ну вот, можно начинать пробовать загружать файлы.
Писалось на AC97, родная частота была то ли 48 то ли 44.1, цифровалось на sblive 5.1
Если что могу попробовать перезаписать, дайте файлики а 48.000
У меня есть ноут с эталонной звуковухой (есть завал от 0 до 100гц где-то по оцифровке, но думаю что здесь у нас это не сильно влияет). П все что выше - очень красивая АЧХ. Но сдохла система три дня назад, а поднять времени не было...
BYTEMAN, спасибо! Я думаю пока и так есть над чем поразмыслить, а потом приготовлю новый тест, если покажется нужным.
Окей, сделай его пожалуйста в 48000, я в 48 и оцифрую, это родная частота для обоих используемых мной звуковух.
Про тонвал магнитофона - там прямой привод тонвала, может быть где-то перекос катушек есть, либо датчик холла съехавший...
ivagor, а насколько гибок твой кодер rom-wav? Ты по семплам пишешь? В принципе можно же просто чуток ускорить, разница 44.1-48.0 получается малозначительная.
- - - Добавлено - - -
Про тонвал магнитофона - там прямой привод тонвала, может быть где-то перекос катушек есть, либо датчик холла съехавший...
А, то-то частоты нетипично высокие. Забавно. Я думаю, там ничего так особенно не съехало, просто обычный cogging — когда мотор обладает бóльшим моментом, когда в роторе и статоре выравниваются полюса.
Кстати, я еще заметил, что все перевернуто на 180 градусов. Это особенность магнитофона? В принципе это не проблема, инвертировать сигнал несложно.
ivagor, пока успеха добился только с самым медленным вариантом на -20dB. После инверсии, но без другой дополнительной обработки, загрузился фрагмент, который начинается с 04:26:47000. Остальные в принципе ведут себя многообещающе, даже самый быстрый (fm3, не fm5) вариант определяется и рисует прогресс до конца, но после этого разочаровывает.
На глаз сигнал выглядит гораздо лучше, чем у меня. Но, видимо не везде.
- - - Добавлено - - -
Маркеры для Audacity (Import->Markers) для удобства разбора megatest: http://pastebin.com/4LuMhgwR
Ты по семплам пишешь? В принципе можно же просто чуток ускорить, разница 44.1-48.0 получается малозначительная.
Да, по семплам. fm5 при разгоне до 48 кГц читается только в VV, в de1 уже грузит с ошибками, подбор порога не помогает.
Можно, конечно, наоборот сделать - замедлить fm5, чтобы было легче для магнитофона (типа как fm3slow из fm3). Имеет смысл?
- - - Добавлено - - -
Решил, что некоторый смысл есть и сбацал fm5slow (https://yadi.sk/d/jka1QC3npGquo). Там 3 частоты дискретизации: 16 кГц, 24 кГц и 32 кГц (эти варианты читаются везде, в т.ч. в emu). Скорости примерно 3100, 4700 и 6200 бит/сек. Загрузчики отличаются только порогом различения 0 и 1. Синхробиты к каждому байту не прибавлял, т.е. формат потока аналогичен полноскоростному fm5.
Про инверсию оч интересно... Надо для начала тракт цифровой проверить...
Вроде это известный факт, что в некоторых магнитофонах усилители "прямые", а в некоторых - инвертирующие. В форматах, в которых нужно знать абсолютные значения бит с компаратора, определяют полярность по синхробайту.
В первой версии retexа программист не стал определять полярность и та версия читала только с "прямых" магнитофонов. Потом поправили.
я помню что когда писал кассеты для Commodore 16 и Commodore 64, то всегда (подчёркиваю) всегда приходилось выставлять Inverse. Связано это с особенностью комодоровского мага, либо же все кассетники пишут с инверсией (в то время я писал на RRR М-7301, Электронике-302 и Aiwa NSX-R71), я так и не понял.
fm5 заработает в emu, если в конфиге увеличить частоту среза фильтра, например так
noisefilterfreq=22050
Rom2fm6 (https://yadi.sk/d/xybpBvyQpXVmX) - планка минимальной скорости поднялась до 10250 бит/сек, почти на 1000 по сравнению с fm5. Везде, где могу попробовать (de1, vv, emu), грузит, но нужно учитывать пару моментов:
1. Для загрузки в de1 потребовалось сменить частоту дискретизации звуковухи. У меня доступны варианты 44.1/48/96/192. При 96 и 192 fm6 грузит с ошибками, при 44.1 и 48 все ОК.
2. Для загрузки в emu нужно задать высокую частоту среза фильтра в конфиге, как написано в предыдущем посте (http://zx-pk.ru/showthread.php?t=10002&p=859367&viewfull=1#post859367)
ivagor, пора попробовать MFM? Там в два раза реже перепады, а декодировать в общем то же самое, что бифаза.
Насчет перепадов - это как считать. Если в расчете на исходный бит, то у меня сейчас по 1 перепаду/бит, а в MFM 0.75/бит. Если считать, условно говоря, на семпл, тут неоднозначная картина, т.к. в fm5 "длинные" биты в 2 раза длиннее "коротких", в fm6 аж в 3, а в mfm будет поровну - но не факт, что в mfm (при программном декодировании на векторе) удастся сохранить длину битов по минимуму. Для ленты mfm несомненно лучше, а вот для шнурка я не на 100% уверен.
Мм не имея перед глазами картинок, честно говоря, очень трудно все это представлять. Заходи почирикать http://www.webwhiteboard.com/#pnd86254
- - - Добавлено - - -
Протокол заседания двух Леонардо:
http://i.imgur.com/U9TOXXY.png
А чего сразу не RLL ???
https://en.wikipedia.org/wiki/Run-length_limited
Или он не регулярный (или как это там называется когда один принятый бит не всегда равен одному биту)...
KTSerg, RLL на 8080 очень сложно декодировать в реальном времени, даже (1,7). Скорости так точно не добиться. Вот если бы разработчики мудро использовали таймер, это возможно могло бы дать возможность заниматься декодированием пока замеряется очередной интервал. И тогда, может быть, можно было бы успевать делать что-то нетривиальное во время загрузки. Но ничего такогов Векторе, увы, нет.
Немного подтюнинговал fm6 и получился fm7 (https://yadi.sk/d/XLVh5M5npdANA) - планка минимальной скорости поднялась до 11950 бит/сек. Темой турбо-загрузки я заинтересовался после того, как побаловался со спектрумом Ewgeny7 на de1. Диска там нет, приходилось грузить с магнитофонного входа и турбо-варианты грузились быстро и впечатлили меня. Но замечу, что в de1 грузились только файлы полученные при сравнительно "медленных" настройках, в районе 12600 бит/сек. Не ожидал, что на векторе почти удастся догнать. Может даже еще смогу немного ускорить.
Rom2fm7new (https://yadi.sk/d/b6avebVRphQhv) - конвертер и примеры старые, только доработал загрузчик. Теперь в de1 грузит при установке любой частоты дискретизации звуковой карты от 44.1 до 192 включительно. В эмуляторы, конечно, тоже грузит, как и раньше.
попробовал на реальном векторе всё это - работает. Спасибо.
Пищат (точнее, скорее, шипят) они противнооо.. у меня итак зуб болел.. А тут хуже стало :)
vazman, спасибо за проверку на реале! Сейчас уже есть еще более быстрый вариант Rom2fm8 (https://yadi.sk/d/66_15z7UqD5vF) - скорость передачи информации 13500 бит/сек (без синхробитов было бы 14700). Заметно увеличить скорость уже вряд ли получится, но по мелочам возможно еще что-нибудь доработаю, например подсчет контрольной суммы.
Спасибо! Rom2fm8 тоже попробовал -работает. Конечно, всё без участия магнитофона, напрямую с выхода звуковухи.
Кстати - почему то часто сам "загрузчик" двухблоковый не запускается с первого раза.. загружаешь два блока, мигает рус/лат, нажимаешь блк/сбр.. что то непонятное на экране. удерживая ус нажимаешь ввод/блк. потом опять блк/сбр - тогда запускается (очищается экран и загружает).
Если нужно - могу потом попробовать прогнать всё через магнитофон
И иногда не загружает. вот я создал дос (у меня пока нет ФДД рабочего). с первого раза не запустился, только со второго
почему то часто сам "загрузчик" двухблоковый не запускается с первого раза
Это бывает только с loadfm или другие программы тоже иногда не стартуют с первого раза (может вектор не на 100% исправен)? Речь про старт из загрузчика? Из под дос может не стартовать - доработал в Rom2fm8new3 (https://yadi.sk/d/Uxh1Ciz5qDeaR) - этот вариант стартует и из любого доса.
Если нужно - могу потом попробовать прогнать всё через магнитофон
Спасибо, но высокоскоростные варианты пробовать с магнитофоном смысла нет.
И иногда не загружает.
Т.е. в loadfm8 столбик доходит до конца, потом сбрасывает, а если еще раз попробовать, то столбик доходит до конца и программа запускается? А fm7 всегда грузил с первого раза или там тоже так бывало?
почему то часто сам "загрузчик" двухблоковый не запускается с первого раза.
С другими программами не бывает, Вектор, вроде, работает нормально. речь про старт из загрузчика
И иногда не загружает
Визуально столбик не доходит немного до конца. и всё, программа не стартует, ничего дальше не происходит
Хотя, может, столбик и доходит, просто программа не стартует....
С другими программами не бывает
Скорее всего с new3 тоже проблем не будет
Визуально столбик не доходит немного до конца. и всё
Ага, понятно. А с fm7 такое было?
c 7 не было, вроде.. но я запускал то по разу :)
Загрузку в de1 я проверяю на примерно 10 файлах разного размера. Некоторые по несколько раз. В de1 fm8 грузит без проблем, ошибок не было. Но понятно, что характеристики магнитофонного входа реального вектора отличаются. Да и звуковая карта оказывает влияние. Кстати, для загрузки я выкручиваю громкость на максимум, при меньшей громкости может грузить хуже. Думаю, что в принципе можно дожать до стабильности и загрузку fm8 в реал, но т.к. я не могу это отладить, наверно сделаю выбор скорости, хотя бы 2-3 варианта. Сам буду грузить в de1 на максимале, а более умеренные варианты может пригодятся кому-нибудь еще.
Могу, кстати, на de2 тоже погонять.. хотя наверняка от de1 ничем не отличается?
Тут даже немного смешно получается. У меня три плисовые девборды и на всех аудиокодек wm8731. Плюс еще платка от waveshare, которую можно подключать к GPIO - там тоже wm8731. И на de2 тоже 8731. В общем de2 можно на эту тему не мучать. Если останется запал, то лучше потом потратить его на пробу доработанной версии.
Еще, например, в плане удобства использования :) Как я говорил - пока нет дисковода. поэтому в первую очередь гружу дос с магнитофона. Так вот, в первый раз после его загрузки при старте надо удерживать УС (тогда, как я понимаю, форматируется квазидиск) Так вот, с быстрой загрузкой так не получается. Пытался начать удерживать ус ещё при загрузке.. но тогда после загрузки всё виснет и ничего не получается
Про удержание клавиш при старте я как-то не подумал. Добавил (https://yadi.sk/d/kxTSkDv7qF6Fa) второй вариант загрузчика, без автостарта - после успешной загрузки замигает рус/лат и будет ждать нажатия сбр+блк
Rom2fm9 (https://yadi.sk/d/h5jhydUsqGCA6) - теперь можно выбрать один из двух вариантов скорости (меньшая примерно соответствует fm7, большая - fm8). Сразу приложены два варианта загрузчика - один запускает загруженный fm9, другой мигает рус/латом и ждет блк+сбр.
Сделал загрузчик с определением длительности бита по таймеру - работает! Профит в увеличении точности определения длительности.
Раньше делал так:
inr b\ in 01\ cmp d\ jz $-4
Дискретность 36 тактов.
Убираем увеличение счетчика и уменьшаем дискретность до 28 тактов. А чтобы узнать, сколько мы там крутились, используем таймер. Т.е. фактически точность как в развернутом цикле, который предлагал svofski, но без развертывания. Преимущество таймера перед развертыванием - легко подстроить (изменением порога сравнения) под разные скорости и код компактнее.
- - - Добавлено - - -
С другой стороны у развертывания меньше накладные расходы между битами и таймер (причем согласованный по частоте с процом) не нужен (это если не для вектора делать). Но накладные расходы на запись/чтение таймера между битами для частоты дискретизации 44100 имхо вполне приемлемы, т.к. один интервал дискретизации 68 тактов и даже при использовании развертывания имеет смысл добавить балластные команды (короткие, но долгие), чтобы сократить код. А тут вместо балласта взаимодействие с таймером.
Супер! Это новое слово в использовании таймера на Векторе.
Да я даже немного горжусь :)
Пока не выложил, т.к. сделал альтернативный загрузчик только для fm8, надо бы для fm9 с поддержкой задания скорости.
Интересно, а на других ретрокомпах были примеры использования таймера при загрузке?
- - - Добавлено - - -
Вспомнил, С. Бергич использовал таймер для приема чего-то радиолюбительского
Интересно, а на других ретрокомпах были примеры использования таймера при загрузке?
АРМ ШК Башкирия :) Причём совместно с контроллером прерываний.
Совсем оффтоп
Похоже в идее использования таймера при загрузке есть что-то башкирское или уфимское. Наверно экология сказывается
Идея не уникальная, но только у вас водятся безумцы, готовые ее воплотить ;)
Rom2fm9_2 (https://yadi.sk/d/vlAjNkU-qKAnh) - добавил загрузчики (с автостартом/без автостарта) использующие таймер
А на эмуляторе это работает?
Реал я пока не подключил к компу через выход на динамики. А на эмуляторе чет у меня не получается, или что-то не так делаю. После запуска загрузчиков fm9, просто чёрный экран? или что-то должно быть?
Забыл вчера написать - в VV загрузчики использующие ви53 работают если отключить ускорение при загрузке (To Force CPU Speed, по умолчанию включено). Не трассировал, но скорее всего проц при включении этой фичи ускоряется, а таймер нет.
- - - Добавлено - - -
После запуска загрузчиков fm9, просто чёрный экран?
Да, так и должно быть. Теперь можно грузить wavы полученные с использованием Rom2fm9. При начале загрузки справа появится две метки, обозначающие начальный и конечный блок. При загрузке будет расти столбик от начального блока к конечному.
Про эмулятор, я в emu пробовал.
Подключил, Вектор к компу через выход на динамики. Чувствительный зараза... :(
При подключенных параллельно активных динамиках или наушниках, Вектор (в штатном загрузчике) вообще даже синхру не ловит...
Если к выходу подключен только Вектор, то в очень узком диапазоне, около максимальной громкости, Вектор начинает грузить. Но, только на низкой скорости (штатным загрузчиком).
Оба загрузчика fm9, сделал wav-ы на низкой скорости утилитой rom2wav (из пакета эмулятора VV).
Оба загрузчика нормально грузят файлы из папки exemples\11700, и видимо с ошибками грузят из папки 13500, т.к. после загрузки экран снова - просто чёрный. Хоть-бы какие-то точки или полоску, для идентификации, или как в штатном - стек на экран выводить.
Если пробую изменить громкость, даже "столбик" расти перестаёт (в обоих загрузчиках).
Спасибо за проверку на реале!
видимо с ошибками грузят из папки 13500, т.к. после загрузки экран снова - просто чёрный.
Да, значит при проверке контрольной суммы обнаруживается ошибка и загрузчик рестартует.
У vazmana fm8 (13500) тоже грузился не со 100% результатом, но как я понял, как минимум один раз загрузился правильно. Но 11700 грузится стабильно, и это здорово (все же значительно быстрее romа). Возможно добавлю промежуточный вариант - соотношение длительностей как в 11700, но с частотой 48000 - результирующая скорость 12800, de1 грузит (но она и 13500 грузит без проблем).
Хоть-бы какие-то точки или полоску, для идентификации, или как в штатном - стек на экран выводить.
Вот тут не понял, идентификации чего? Загружаемого файла? Можно бы добавить вывод имени, но тогда резко разбухнет загрузчик.
Или речь про отслеживание процесса загрузки? Сейчас прогресс загрузки показывает столбик справа.
- - - Добавлено - - -
Только что сообразил, в принципе можно грузить имя в графическом виде в самом файле.
...
Только что сообразил, в принципе можно грузить имя в графическом виде в самом файле.
Ну можно и так. Но возрастёт длительность загрузки, весь "выигрыш" во времени пропадёт...
Я имел в виду, хоть какую-то идентификацию, что работает загрузчик. А то просто чистый экран, смущает...
- - - Добавлено - - -
Найду стерео-штекер и экранированный провод, сделаю нормальный переходник, надеюсь будет меньше искажений, и может будет грузить стабильнее ...
- - - Добавлено - - -
Кстати, ещё, стоит-ли закоротить каналы, или подавать на вход Вектора только один какой-то канал?
Но возрастёт длительность загрузки
Если в состав загрузчика включить шрифт, то это 768 байт на низкой скорости, а если грузить рисунок букв в преамбуле, то это 8*11=88 байт, причем на высокой скорости. Т.е. все же второй вариант лучше. Но я понял, что речь про индикацию того, что загрузчик живой в моменты, когда загрузка не производится. Наверно можно при ожидании загрузки мигать бордюром.
Насчет моно/стерео - когда грузили с магнитофона, у меня был коммутатор, можно было выбрать левый, правый или сумму, вроде суммой практически не пользовался. При загрузке по шнурку с PC вряд ли имеет смысл объединять каналы в один, да и заметной разницы между правым и левым в данном случае не будет, т.ч. скорее всего можно взять любой один канал.
Записывал сигнал, прошедший по достаточно длинному шнурку в de1 и обратно - особых шумов там не видно, проблема в некотором расплывании фронтов. Скорее всего магнитофонный вход вектора еще сильнее растягивает фронты.
Ну да, "лишние" 88 байт к программе, это не критично :)
В схеме Вектора на входе дифференцирующая RC цепь, а на de1 есть такая?
По моно/стерео - понял.
Сегодня не дома, схему de1 сейчас не буду качать, да и не факт, что с ходу пойму, что там в аналоговой части аудиовхода. Насчет цифровой обработки - точно помню, что в 8731 есть отключаемый фвч, удаляющий постоянную составляющую, и в v06cc он включен.
ivagor, а блоки, как в исторических загрузчиках, у тебя остались? Если да, то можно просто в начало засовывать блоки с соответствующими адресами, которые будут загружаться прямо в экранную память в качестве иконки. Плюс в том, что не надо ограничивать никого количеством байт — сколько захотел, столько и сгенерировал. А если сделать размер блока не фиксированным, то можно вообще разойтись — сделать дырявый сплешскрин на весь экран.
Блоки есть, но кроме синхробайта там никакой служебной информации - ни начального адреса (все по порядку), ни размера (фиксированный 256 байт). Грузить заставки в принципе неплохо бы, но где их брать?
По умолчанию генерировать текст в битмапе. Но оставить возможность указать свой битмап.
Возможно действительно стоит увеличить гибкость. Но каждая дополнительная возможность приводит к разбуханию загрузчика и, в некоторых случаях, к замедлению.
Для эксперимента, можно попробовать сделать первый блок служебным (изменяемого размера), для (спрайта) имени файла или картинки. Байт идентификации (есть ли спрайт, или блок 0-вой длины), пара байт на адрес на экране для "спрайта", пара байт на размеры. Остаётся для "спрайта" 48*42 пикселя (если делать его почти квадратным). По горизонтали можно с шагом 8 пикселей, чтоб сильно загрузчик не перегружать...
Если все блоки равноправные, загрузчику проще.
Загрузчику проще, но возникает вопрос, как отображать прогресс загрузки. Сейчас черточки в правом столбце соответствуют загружаемым блокам по количеству и положению. Если разрешить грузить вразнобой, то положению уже лучше не соответствовать, разве что количество оставить.
Еще думаю, может две плоскости под картинки выделить. Три не получится, т.к. есть romы по 45 кб.
Можно и набор плоскостей и палитру сделать опциональными в заголовке. Рому на 45кБ будет не до этого, зато на тех, что поменьше, можно будет оторваться.
Загрузчику проще, но возникает вопрос, как отображать прогресс загрузки. Сейчас черточки в правом столбце соответствуют загружаемым блокам по количеству и положению. Если разрешить грузить вразнобой, то положению уже лучше не соответствовать, разве что количество оставить.
Еще думаю, может две плоскости под картинки выделить. Три не получится, т.к. есть romы по 45 кб.
В разнобой это слишком много изменений протокола, хотя и круто бы выглядело, если речь о загрузке картинки в перемешку с данными. Думаю, для начала достаточно одного первого блока 256 байт, для одного спрайта, а далее уже существующий протокол без изменений.
Просто мысль вслух - при достигнутых скоростях возможно нечто вроде медленного видео. Если размер кадра 64x64, то примерно 3 кадра в секунду. Или если 128x128, то 0.7-0.8 кадра/сек.
Просто мысль вслух - при достигнутых скоростях возможно нечто вроде медленного видео. Если размер кадра 64x64, то примерно 3 кадра в секунду. Или если 128x128, то 0.7-0.8 кадра/сек.
Крутизна.
Вот прикинул, по ЛВС, меньше чем в два раза быстрее получается (2.5КБ/сек), а там можно сказать в Вектор инфа в параллельном виде поступает.
ЛВС можно как-то ускорить?
ЛВС можно как-то ускорить?
Конечно можно.
Там протокол жутко "не оптимален", и скорость СОМ-порта я использую 57600, хотя можно и выше, изменив гальваническую развязку.
А можно ещё и одновременно данные передавать с РС на контроллер ЛВС, и с контроллера в Вектор. Только процессор контроллера должен иметь достаточно встроенной памяти. Сейчас сначала пакет (32 Байта данных + служебные) передаётся с РС в контроллер, потом весь пакет перегружается в Вектор. Если пакет принят корректно, запрашивается у РС следующий пакет...
Оптимизировал загрузчик fm9 и теперь получается считать контрольную сумму на ходу. Это более чем на треть сокращает интервал от завершения загрузки до старта программы.
Пара слов про скоростные возможности ROM-формата. На примере файла размером 33.25 Кб. Использовался модифицированный ROM2WAV Ramirosa. Две модификации: устранение избыточности по результатам Tim0xи и изменение задержки между байтами (1/2).
Сначала самый неинтересный вариант - рекорд скорости при загрузке в VV с использованием хакнутого загрузчика kish3 - 1:07.
Дальше подобрал вариант, который грузится и в VV и в emu при использовании kish2/UNBOOT2K (загрузчики Tim0xи ведут себя аналогично) - 1:57.
Еще попробовал 512 байтный загрузчик FirstBoot. В него рекорд загрузки в районе двух с половиной минут.
Самый привередливый загрузчик в 6128. В него получилось загрузить примерно за 3 минуты, но возможно резервы еще есть.
Хотел поднять интересную тему (если она ещё не поднималась). прочитал недавно в одном из векторовских журналов, что были нестандартные загрузчики, которые были "а-ля Спектрум". Полосы на бордере, картинка при загрузке, да и сам физический формат был не фазовый, а ЧМ (чистый спектрум по сути). Кому-нибудь подобные кассеты встречались?
lafromm31
06.07.2018, 18:48
У меня в детстве была "Планета птиц" со своим загрузчиком. Сначала грузился загрузчик. А в него дальше - уже игра. В середине было написано "Планета птиц". При загрузке шел таймер оставшегося времени, а по бокам были полосы как при загрузке на Спектруме. По окончании загрузки - игра сама запускалась. БЛК+СБР нажимать не нужно было. Я пробовал как-то загрузить игру - минуя загрузчик - она грузилась, но не запускалась.
нестандартные загрузчики, которые были "а-ля Спектрум". Полосы на бордере, картинка при загрузке
Сталкивался с "отголоском" такой штуки. Это была хакнутая версия планеты птиц, вероятно при хаке рудименты загрузчика остались и если в процессе загрузки (не дожидаясь окончания) стартануть, то по бордюру шли цветные полосы. С рисованием картинки во время загрузки на векторе не сталкивался.
Еще были "проприетарные" загрузчики попроще, без полос и без рисования.
- - - Добавлено - - -
Оп, я не успел, и тоже планета птиц :)
- - - Добавлено - - -
Кстати, если вспоминать волгоградские игрушки, в фатаксе вроде подгрузка уровней (в оригинальной, не хакнутой версии) сопровождалась цветными полосами на бордюре, надеюсь я не спутал.
Вроде у Кристы там картинка при загрузке прорисовывается, но это совсем другое дело было вроде как...
Блин, было бы круто, если бы у кого такие "своеобразные" записи сохранились бы...
Насчет рисования помню оригинальую версию BASIC-M. Сразу после загрузки она рисовала на весь экран, как бы от руки курсивом название (Basic M или что-то в этом духе). В хакнутой версии такого нет.
- - - Добавлено - - -
И, кстати, у Basic-M исходно был свой загрузчик.
http://sensi.org/scalar/categories/33/
Блин, было бы круто, если бы у кого такие "своеобразные" записи сохранились бы...
Да, круто бы было. Вдруг еще сохранились у кого-то.
Сталкивался с "отголоском" такой штуки. Это была хакнутая версия планеты птиц, вероятно при хаке рудименты загрузчика остались и если в процессе загрузки (не дожидаясь окончания) стартануть, то по бордюру шли цветные полосы.
Я бы это, скорее, списывал на переход на обработчик прерывания RST 7 при прямом ходе луча, в результате чего мы наблюдаем на бордюре процесс записи физических цветов палитры :)
- - - Добавлено - - -
Кстати, если вспоминать волгоградские игрушки, в фатаксе вроде подгрузка уровней (в оригинальной, не хакнутой версии) сопровождалась цветными полосами на бордюре, надеюсь я не спутал.
Ну я в подростковом возрасте и сам подобный эффект делал, там же ничего сложного. Другое дело, что для меня действительно новость, что на "Векторе" вообще существовали "кассетные" игры с подгрузкой уровней.
переход на обработчик прерывания RST 7 при прямом ходе луча, в результате чего мы наблюдаем на бордюре процесс записи физических цветов палитры
При этом менялись бы цвета не только на бордюре, а везде.
были нестандартные загрузчики, которые были "а-ля Спектрум". Полосы на бордере, картинка при загрузке, да и сам физический формат был не фазовый, а ЧМ (чистый спектрум по сути). Кому-нибудь подобные кассеты встречались?
В наших пенатах не встречались. Сам в начале 90х носился с идеей сделать такое, но потом забил, т.к. Вектор это вам не Спектрум, ждать загрузки 32 кб картинки мало кто захочет (ну пусть даже в RLE она сожмётся в 20 кб - это, по времени, всё равно больше чем загрузка, скажем, Бейсика).
Ну и, в довесок, я осознавал, что загрузчик родного ROM формата, точнее, его автоподстройку под константу чтения, я не осилю - а форматы что монитора-отладчика, что спекрумовский ЧМ будут сильно проигрывать в надёжности.
- - - Добавлено - - -
При этом менялись бы цвета не только на бордюре, а везде.
Вполне возможно, мог перепутать за давностью лет. С детства в памяти отложилось, что некоторые игры после перегрева Вектора начинали сбоить и нажатый со злости Блк-Сбр иногда приводил к "радуге" именно на бордюре. ХЗ, вероятно, просто ложные воспоминания.
С другой стороны... вроде бы порт 02 отвечал за цвет только бордюра, а цвет фона задавался нулевым математическим цветом? А в обработчике прерывания в цикле в порт 02 писались именно математические цвета от 0 до 15, или я гоню?
вроде бы порт 02 отвечал за цвет только бордюра, а цвет фона задавался нулевым математическим цветом?
Если на запись, то это бордюр/номер цвета палитры плюс режим экрана 256/512.
в обработчике прерывания в цикле в порт 02 писались именно математические цвета от 0 до 15
Да, но если вызывать процедуру программирования палитры не в невидимой области, то в качестве номера палитры будут использоваться не только значения из порта 2, но и цвета активной области изображения, если моменты программирования палитры попадут (а они иногда точно попадут) на активную область.
если вызывать процедуру программирования палитры не в невидимой области, то в качестве номера палитры будут использоваться не только значения из порта 2, но и цвета активной области изображения, если моменты программирования палитры попадут (а они иногда точно попадут) на активную область.
Точно, вспомнил, были и такие артефакты в виде цветных полос на всю ширину экрана.
Так а как это выглядело в загрузчике Планеты Птиц? Именно целенаправленная анимация цветов бордюра, как в игре "Клад"?
Так а как это выглядело в загрузчике Планеты Птиц? Именно целенаправленная анимация цветов бордюра, как в игре "Клад"?
Анимацию цветов бордюра в игре клад не помню.
Могу сравнить с монитором-1200, в котором есть попытка изобразить нечто на бордюре во время загрузки. В планете птиц было намного лучше, полосы не 2х, а может даже 8 цветов (насчет 8 точно не уверен, но цветов было не менее 3х), плюс полосы сравнительно широкие, не просто как штришки. Выглядело хорошо. Пожалуй было похоже на спековский bomb jack (https://youtu.be/-2dSNRSHMlE?t=56).
У меня в детстве была "Планета птиц" со своим загрузчиком. Сначала грузился загрузчик. А в него дальше - уже игра. В середине было написано "Планета птиц". ...
А вот интересно, "Планету птиц" с таким загрузчиком, продавали у разных "распространителей". Значит была специальная программа, генерирующая запись на магнитофон загрузчика и самой игры. Если бы это был просто универсальный "копировщик", то с таким эффектом писали бы на кассеты все игры. Неужели не сохранились архивы если не разработчиков, то хотя-бы "распространителей"...
Со своим загрузчиком распространял разве что центр Компьютер (Кишинев) и, возможно, сам автор. Подавляющее большинство пиратов продавали обычный файл в формате загрузчика.
Вот, например, фатакс с подгружаемыми уровнями (если не путаю, реально там подгружались не уровни, а типа сигнатуры) распространяла разве что волгоградская контора (забыл название), у остальных был обычный (хакнутый) rom. Неудобно же переписывать левый формат, и делать свой генератор для записи тоже особого смысла не было. Да и пользователям удобнее. Защиты нужны были только авторам и "официальным" распространителям.
- - - Добавлено - - -
Кстати, иногда и пираты изобретали свои уникальные форматы. Например отец покупал в какай-то кишиневской конторе пару кассет и там оказалось нечто со своим загрузчиком. И я их потом ломал и переделывал в обычные ромы.
Центр Компьютер (Кишинев), с какого-то момента, продавал практически всё с загрузчиком. Только он был без наворотов, просто загружал основной файл в своём формате.
Improver
30.06.2020, 12:34
Rom2fm9_2 (https://yadi.sk/d/vlAjNkU-qKAnh) - добавил загрузчики (с автостартом/без автостарта) использующие таймерivagor, а есть описание формата вывода loadfm9? Т.е. какие там заголовки, синхробайты, в каком порядке надо "пищать байтами файла" и т.п. Что-то я впечатлился им по этому видео (https://zx-pk.ru/threads/9532-vektor-06ts-sredstva-razrabotki.html?p=1070566&viewfull=1#post1070566), хочу попробовать добавить в свой "магнитофон на ардуино"...
ivagor, а есть описание формата вывода loadfm9? Т.е. какие там заголовки, синхробайты, в каком порядке надо "пищать байтами файла" и т.п. Что-то я впечатлился им по этому видео (https://zx-pk.ru/threads/9532-vektor-06ts-sredstva-razrabotki.html?p=1070566&viewfull=1#post1070566), хочу попробовать добавить в свой "магнитофон на ардуино"...
Так вот же буквально здесь, все задокументировано в самой твердой форме, кодом:
https://github.com/svofski/bin2wav/blob/master/tape.js#L370
data[dofs++] .. -- байт за байтом собирается формат, потом кодируется функцией encode(). encode() кодирует каждый байт функцией fmbyte(). Служебная информация кодируется медленно, по 3/6 отсчетов, основная полезная нагрузка быстро по 2/5 отсчетов.
Improver, вся задокументрованность благодаря svofski, он ссылку привел. И еще он картинку рисовал (https://zx-pk.ru/threads/10002-rom-format-avtozapusk-zashchita-sekrety.html?p=859510&viewfull=1#post859510), там написано fm6, но идея сохранилась до fm9, только уменьшалось число отсчетов/бит.
Improver
30.06.2020, 14:35
Мои познания JS не настолько велики, но попробую разобраться. Без учёта кодировки функцией fmbyte() получается так:
1. Заголовок:
- 256 байт 0FFh
- синхробайт 0E6h
- 4 байта, 'FM9'5 (046h 04Dh 039h 005h)
- 11 байт -- имя файла (8 байт, дополняется пробелами)+(3 байта расширение)
- 1 байт -- номер начального блока
- 1 байт -- количество блоков
- 256 байт 0FFh
2. Блоки данных:
- 1 байт 0FFh
- 1 байт 0E6h
- 256 байт из файла поXORенные с неким флипом???, с подсчётом контрольной суммы
3. Завершение:
- 1 байт -- контрольная сумма данных
- 1 байт -- флип??? (полагаю, для раскодировки данных)Не совсем понятно, как работает этот флип, полагаю это нечто для лучшего утрамбовывания данных. А дальше, при кодировании, вообще происходит какая-то магия... И единственное, что я понял из рисунка, это то, что единица передаётся за полтора цикла несущей частоты, а ноль -- за половину цикла.
В общем, по-быстрому добавить FM9 не получится, надо углублённо изучить инфу, но уже этих сведений достаточно, чтобы прикинуть, что в ардуине не хватит места сразу для всех форматов, надо будет чем-то жертвовать.
JS это такой цирковой Си для клоунов. Там все как бы просто, но можно сложить 2 и 3 и получить строку, например.
Флип для лучшего утрамбовывания, но он не работает в текущей версии, потому что на момент флипанья ПЗУ не отключено, а флипанье на лету невозможно потому, что признак записывается в конце потока. Я его как раз только что запретил. Можно считать, что он всегда 0, то есть его как бы нет.
С форматом -- вроде все правильно.
- 4 байта, 'FM9'5 (046h 04Dh 039h 005h)
Дальнейшую информацию можно игнорировать, она больше для исторической полноты. Если использовать rom2fm, то там вместо 5 может быть и 4, этот байт соответствует скорости передачи (5 для 11700; 4 для 13500). Т.к. в железный вектор 13500 грузится нестабильно, то можно считать, что скорость всегда 11700. 13500 из железок грузится в de1, но разница небольшая. Теоретически можно попробовать дожать и 13500 для реала, но тут уже для отладки нужен реал, т.к. эмулятор стабильно грузит 13500 (как и de1), а реал - нестабильно.
Не помню где я слышал, но засело в памяти, что дескать у Вектора такой крутой формат, что блоки можно в любом порядке и сколько хочешь раз. Я вроде знаю, что это не совсем так и в этой теме это уже не раз обсуждалось. Но я все же проверил еще раз сам и пришел к тем же выводам, что и предыдущие исследователи. Два важных принципа стандартных загрузчиков: 1) номера последовательных блоков обязаны быть равны (повтор) или уменьшаться на один (нумерация идет от максимального до 1) и 2) перейти к очередному блоку невозможно, если текущий не был загружен полностью. Понятно, что альтернативные загрузчики могут грузить более расслабленно, но если делать какой-то трюк для стандартного Вектора, рассчитывать на это нельзя.
Ограничение, причем двойное (ах ты номер увеличил, а данные пропустил, ну так вот тебе пункт 2), мне кажется совершенно бессмысленным. Как-то вот просто чтобы было "тупо зло". Зачем мне это я не знаю, видимо просто внутреннее неприятие зла :)
Ограничения есть, но все же формат сравнительно гибкий, видео Tim0xИ (https://zx-pk.ru/threads/10002-rom-format-avtozapusk-zashchita-sekrety.html?p=195538&viewfull=1#post195538), которое теперь недоступно, меня в свое время впечатлило.
Это другое, подблоки можно грузить в произвольном порядке и грузить данные поверх экрана можно, если при этом не забывать включать в эти данные то, что загрузчик распознает, как "блок загружен". Но вот целые блоки переставить местами, или например загрузить блок по адресу 0, а другой по адресу $8000 -- никак, ни за что. Опять же, в этом не много практического смысла было бы в любом случае, но чему служит такое напряженное отношение к последовательности блоков я тоже понять не могу.
Тут можно поспекулировать, что если мы сопротивляемся дефектам на пленке, например, повторять блоки друг за другом, то есть вероятно в одной области повреждения, может быть менее надежно, чем повторять запись целиком, когда повторные копии физически отстоят друг от друга на большом расстоянии. Хотя психологически это не воспринимается так эффектно, конечно. Это же тогда просто вторая копия.
У меня есть версия, что может быть фрагменты кода как-то повторно использовались в возможных экспериментах с ЛВС и они может быть боялись, что допустим будут принимать пакеты не тому адресату, но почему бы тогда не включить в формат пакета собственно адресата. В общем это левая идея.
Есть еще загадочный фрагмент кода по крайней мере в одной из версий загрузчиков (который называется newrom v(2.0)), который делает так:
; пересылка 32 байт (с очисткой источника?)
; h = &src[0]
; b = &dst[0]
; в процессе производятся странные ритуалы - может быть это связано с кодом в ПЗУ? не понятно
PUSH D ; push: d = число блоков e = cs0
PUSH B ; push: b = org_hi
INX H ; HL=нач.данных (ABUFF + 2, 32 байта, остаеется еще checksum_data)
LXI D,207EH ; из буфф. в озу d = 32 байта, e = $7e = битмап столбика в карте загрузки
LOA14: MOV A,M ; a = *src - взять из буфф.
STAX B ; *dst = a - поместить в озу
LDAX B ; a = *dst - взять из озу -- ну зачем это все ?..
XRA M ; a ^= *src - чего это все ради? может быть потому что ПЗУ?
MOV M,A ; *src = a -- что? -- уст.ошибку в буфф.
LOA15: INX H ; src++
INR C ; dst++ (только младший байт, мы внутри блока B)
DCR D ; счет байт
JNZ LOA14 ; D<>0
POP B ; восст.(BC)
MOV L,C ; (BC)=(HL)
MOV H,B ; --//--
тут вперемешку фарш из комментариев из архива с моими. Понятно, что так ничего не понятно: это процедура окончательного копирования прочитанного подблока с уже верифицированной контрольной суммой из буфера $DED0 (многозначительно, исп. el dedo = палец) в память. Казалось бы, можно ли тут изобрести что-то новое? Но вот чему могли бы служить инструкции ldax b \ xra m \ mov m, a, кроме как быть частью какого-то мрачного ритуала ? Комментарий "уст.ошибку в буфф." наводит мысли на то, что предыдущий исследователь тоже уже слишком долго вглядывался в бездну.
чему служит такое напряженное отношение к последовательности блоков я тоже понять не могу.
Я бы поставил на то, что авторы хотели побыстрее написать загрузчик влезающий в 512 байт и упростили себе задачу.
Но вот чему могли бы служить инструкции ldax b \ xra m \ mov m, a, кроме как быть частью какого-то мрачного ритуала ?
Если все без ошибок (чтение из памяти и запись в память), то в итоге область источника будет обнулена.
Если все без ошибок (чтение из памяти и запись в память), то в итоге область источника будет обнулена.
Хорошо, тогда у меня такие вопросы:
- обнулена область будет при отключенном ПЗУ или адресах, куда ПЗУ не отображается. При включенном ПЗУ в младших адресах мы считываем назад не то, что записали. Значит загрузка в младшие адреса -- это "ошибка" ?
- что если все же с ошибками? Разве это тест ОЗУ? Может быть я не нашел, но вроде бы область буфера на нули нигде не проверяется.
Но в общем я согласен, что время было ограниченно, а средства разработки неприступны. Скорее всего замариновали ту версию, которая наконец заработала.
Последовательность загрузки все же по-моему задачу не упрощает. Это больше похоже на ложную цель, не знаю есть ли у этого какое-то классическое название. Когда ты при выполнении задачи зацикливаешься на достижении чего-то, что почему-то запало как нечто архиважное, но на самом деле не имеющего к делу никакого отношения.
- обнулена область будет при отключенном ПЗУ или адресах, куда ПЗУ не отображается. При включенном ПЗУ в младших адресах мы считываем назад не то, что записали. Значит загрузка в младшие адреса -- это "ошибка" ?
- что если все же с ошибками? Разве это тест ОЗУ? Может быть я не нашел, но вроде бы область буфера на нули нигде не проверяется.
А я не смотрел newrom v(2.0), возможно это предполагаемое обнуление (или необнуление в случае пересылки в область пзу) никак и не проверяется дальше. Вещь в себе. Может бездумно скопипастили с другого компа фрагмент.
Ага. Мне просто он попался под руку. Не нашел с ходу записи с прошлого разбора загрузчиков, когда делал автостарт для loadfm. Заглянул и удивился.
А мне кажется, что это "защита" загружаемой информации.
Штатный загрузчик принимает данные с ленты и помещает их в буфер на экране. Это потенциальная уязвимость. Поскольку данные можно переписать с экрана, и восстановить их даже если они защищены от копирования.
Собственно так вскрывались начальные загрузчики программ, записанных на ленту в собственном формате... их загрузчик переписывался из экранного буфера на листочек, набирался, модифицировался, и игрушка копировалась.
А тут, экранный буфер практически сразу после заполнения модифицируется (при его копировании на положенное место), и данные "переписать" значительно сложнее.
Я так думаю.
их загрузчик переписывался из экранного буфера на листочек, набирался, модифицировался, и игрушка копировалась
Если их загрузчик по любому грузился стандартным загрузчиком, не было проще загрузить этот промежуточный загрузчик своим измененным не-стандартным загрузчиком и спокойно разобрать его устройство? Идея взламывать чего-то перерисовывая с экрана битмапы, со скоростью 50 кадров в секунду мне кажется достойным комментария на хабре.
Ну и кроме того, неиспорченные данные ведь уже успели промелькнуть к этому моменту на экране по любому, значит их можно было успеть перерисовать.
... Идея взламывать чего-то перерисовывая с экрана битмапы, со скоростью 50 кадров в секунду мне кажется достойным комментария на хабре.
На заре, даже кваза ещё не было. Выкручивались как могли. До получения исходников начального загрузчика или хотя-бы самого кода загрузчика было ещё ой как далеко.
А написать амому загрузчик с лены, это не тривиальная задача, даже имея описание формата ром-а в Вектор-Юзере.
Ну и кроме того, неиспорченные данные ведь уже успели промелькнуть к этому моменту на экране по любому, значит их можно было успеть перерисовать.
Когда данные не уничтожаются, то есть достаточно времени нажать БЛК+ВВОД, что-бы "поймать" кадр с нужным битмапом, перед тем как он будет переписан новыми данными, а вот когда он сразу после получения уничтожается (при копировании), поймать будет значительно сложнее.
Для современных технологий, знаний, и опыта, такой "финт" конечно выглядит не понятно, или наивно. Но если-бы такое было изначально в штатном загрузчике...
Я только не понял, причём тут 50 кадров в секунду?
Для современных технологий, знаний, и опыта, такой "финт" конечно выглядит не понятно, или наивно. Но если-бы такое было изначально в штатном загрузчике...
Да нет, как раз когда смотришь рассказ как какую-нибудь очередную приставку ломают итд, там и не такие финты выделывают. Классика жанра -- ловко гличануть питанием так, чтобы что-нибудь зависло и не успело стереться, а в это время успеть память слить. Это как раз вполне. Но все равно, в загрузчике если данные уничтожаются, они это делают только во время переписывания, все равно проходят через буфер и на экране какое-то время висят. Так что БЛК+ВВОД так же точно можно нажать, просто тяжелее это сделать.
Если бы я правда хотел таким наивным способом что-то скрыть от глаз, я бы сделал буфер в невидимой области экрана.
Про 50 кадров в секунду я переборщил, тут привязка к скорости записи конечно.
... Но все равно, в загрузчике если данные уничтожаются, они это делают только во время переписывания, все равно проходят через буфер и на экране какое-то время висят. Так что БЛК+ВВОД так же точно можно нажать, просто тяжелее это сделать.
Значительно тяжелее.
Уровень защиты должен усложнять взлом на столько, что-бы усилия по взлому обходились дороже, чем польза от преодоления защиты.
Ловить кадры даже не удаляемых данных очень сложно, а если бы они ещё и портились сразу после отображения на экране, то поймать их было-бы ещё сложнее.
Я в то время вообще не знал как пользоваться ассемблером. Знал о его существовании, но как им пользоваться не знал. Писал программы сразу в НЕХ-кодах, набирая их в SID-е или чём-то подобном.
Если бы я правда хотел таким наивным способом что-то скрыть от глаз, я бы сделал буфер в невидимой области экрана.
...
Думаю, что отображение буфера загрузки на экране это очень прикольная "фишечка" у Вектора.
Когда данные не уничтожаются, то есть достаточно времени нажать БЛК+ВВОД, что-бы "поймать" кадр с нужным битмапом, перед тем как он будет переписан новыми данными, а вот когда он сразу после получения уничтожается (при копировании), поймать будет значительно сложнее.
Так данные уже переписаны по месту финального залегания (куда их переслали), проще их там посмотреть. Например по УС+ВВОД+БЛК и подгружаем монитор-отладчик в боевом состоянии, как предлагал Черезов, если не путаю.
Так данные уже переписаны по месту финального залегания (куда их переслали), проще их там посмотреть. Например по УС+ВВОД+БЛК и подгружаем монитор-отладчик в боевом состоянии, как предлагал Черезов, если не путаю.
Загрузочные блоки, сразу после того как приняли всю программу, передавали ей управление, и она начинала вносить какие-то изменения в память... распаковываться, ещё что-то...
Цель переписывания кода, воссоздания и модификации начального блока была именно в том, чтобы зациклить этот JMP-переход на выполнение кода загруженной игрушки. И дать время на УС+ВВОД+БЛК, до того как загруженная игрушка начнёт изменяться.
Загрузочные блоки, сразу после того как приняли всю программу, передавали ей управление, и она начинала вносить какие-то изменения в память... распаковываться, ещё что-то...
Требования к реакции одинаковые, нужно успеть нажать после того как нужный блок загружен
Цель переписывания кода, воссоздания и модификации начального блока была именно в том, чтобы зациклить этот JMP-переход на выполнение кода загруженной игрушки. И дать время на УС+ВВОД+БЛК, до того как загруженная игрушка начнёт изменяться.
Если вопрос в том, что нужно хакнуть что-то в районе 0000-00FF, то в варианте с "развернутым" монитором-отладчиком добавляется релокатор, который после загрузки сначала переместит нужные данные из 0000-00FF куда-нибудь и запишет на это место соответствующий фрагмент монитора-отладчика.
Improver
25.07.2022, 11:02
Если вопрос в том, что нужно хакнуть что-то в районе 0000-00FF, то в варианте с "развернутым" монитором-отладчиком добавляется релокатор, который после загрузки сначала переместит нужные данные из 0000-00FF куда-нибудь и запишет на это место соответствующий фрагмент монитора-отладчика.Для этих целей был монитор-взломщик (http://www.sensi.org/scalar/ware/730/), он умел писать считанный R0M в память со сдвигом, адреса 100h. А ещё загрузчик на 32кБ (http://www.sensi.org/scalar/ware/541/) имел функцию реанимации 0 блока монитора по нажатию УС+F1+F3, но там нужно восстанавливать нулевой блок вручную.
KTSerg написал про время, когда
На заре, даже кваза ещё не было. Выкручивались как могли. До получения исходников начального загрузчика или хотя-бы самого кода загрузчика было ещё ой как далеко.
А написать амому загрузчик с лены, это не тривиальная задача, даже имея описание формата ром-а в Вектор-Юзере.
Потом понятно, что появились и программные и аппаратные средства для упрощения взлома.
Загрузочные блоки, сразу после того как приняли всю программу, передавали ей управление, и она начинала вносить какие-то изменения в память... распаковываться, ещё что-то...
Цель переписывания кода, воссоздания и модификации начального блока была именно в том, чтобы зациклить этот JMP-переход на выполнение кода загруженной игрушки. И дать время на УС+ВВОД+БЛК, до того как загруженная игрушка начнёт изменяться.
Эх, жаль, что ничего этого не сохранилось в первозданном виде.
Что до смутившего меня кода, для достижения цели KTSerg проще было написать на его месте mvi m, 0.
Эх, жаль, что ничего этого не сохранилось в первозданном виде.
Что до смутившего меня кода, для достижения цели KTSerg проще было написать на его месте mvi m, 0.
Согласись, просто очистить буфер, это не так прикольно, как захорить его кодом из ПЗУ, фактически постоянно (для каждого кадра) разным... ;)
Сейчас прикинул, когда ПЗУ закончится, буфер будет инвертироваться? Ведь за пределами ПЗУ скорее всего будет читаться FF. И только когда выйдет за пределы схемной блокировки будет читаться записанный в ОЗУ код, т.е. буфер начнёт просто очищаться.
Согласись, просто очистить буфер, это не так прикольно, как захорить его кодом из ПЗУ, фактически постоянно (для каждого кадра) разным...
Ну я вижу, что ты одержим этой идеей и просто за компанию готов примкнуть к узкому кругу ее сторонников =)
Потом как-нибудь загляну в другие загрузчики посмотреть, нет ли там тоже чего-нибудь похожего.
Я вообще начал с того, что хотел сделать демку с автостартом. Но потом прикинул и решил, что как ни вертись будет лажа. Потому что все равно почти у всех или эмулятор с 32К бутом, а единицы рабочих реалов тоже скорее всего с 32К ПЗУ. Получается что запустить такую демку будет проблематично. Для loadfm с автостартом это прокатывает, потому что он-то прекрасно может жить в экранной области, а после загрузки основного содержимого все равно требуется нажатие БЛК+СБР.
Получается что запустить такую демку будет проблематично.
Планируется большая дема или нужны все 4 плоскости?
Планируется большая дема или нужны все 4 плоскости?
Для этой плоскости все нужны. Ну да ничего, будут другие.
Для этой плоскости все нужны. Ну да ничего, будут другие.
Что-то я на вскидку не представляю как программно отключить ПЗУ, т.е выполнить автостарт на Векторе, когда он аппаратно не предусмотрен.
Можно запустить программу перехватив указатель РС у программы ПЗУ во время загрузки программы штатным загрузчиком. Но половина ОЗУ (при ПЗУ 32К) останется для загруженной программы недоступной/бесполезной, так как в ней будет висеть активная ПЗУ.
Т.е. полезного кода в загружаемой программе, перехватывающей управление у ПЗУ, может быть ну чуть больше 16КБ, т.е. с адреса 8000 по BFFF, ну чуть больше, если кусками на С000-DExx рассовать... :)
Что-то я на вскидку не представляю как программно отключить ПЗУ, т.е выполнить автостарт на Векторе, когда он аппаратно не предусмотрен.
Можно запустить программу перехватив указатель РС у программы ПЗУ во время загрузки программы штатным загрузчиком. Но половина ОЗУ (при ПЗУ 32К) останется для загруженной программы недоступной/бесполезной, так как в ней будет висеть активная ПЗУ.
Все так и есть. Автозапуск в loadfm прокатывает просто потому что там сам он работает в верхней области памяти. А после загрузки все равно надо жать на БЛК+СБР.
Кстати надо бы обновить bin2wav с фиксом от Pyk.
Никогда не считал плотность записи на кассету. Решил прикинуть -- если считать, что происходит максимум 4800 инверсий в секунду, то при скорости 47.6 мм/с имеем 100 инверсий на миллиметр пленки. Похоже на правду?
Похоже, а если катушечник, то скорость можно взять в 2 или 4 раза больше.
Да и кассетникам люди выкручивали скорость, говорят. Меня просто удивила такая большая по бытовым меркам плотность.
А еще есть VHS Hi-Fi Stereo, у которого полоса вообще до 20КГц с 0.005% wow & flutter и 80dB динамического диапазона. Запись идет спирально вместе с видео, с FM-модуляцией на раздельных несущих для левого и правого каналов. Режимы LP и даже SLP не сказываются негативно на звуковой дорожке. На такое по идее fm5 можно спокойно записывать.
удивила такая большая по бытовым меркам плотность.
Ну все же 4800 на кассетниках массово не использовали, 2400 было более-менее нормально на хорошем кассетнике.
Про видюшник для ретрокомпьютерных 8 биток - оригинальная идея, только дороговато было на видеокассетах звук хранить (с игнорированием видео). Но в качестве потенциальной возможности интересно. Думаю FMx пришлось бы маленько допилить для согласования с хранением на ленте, или в обязательном порядке использовать в связке с упаковщиками.
Ну все же 4800 на кассетниках массово не использовали, 2400 было более-менее нормально на хорошем кассетнике.
Я прикинул, что если 2400 бит/с и по две инверсии на бит, получится 4800 инверсий в секунду.
Да, ступил, ты про инверсии при Манчестере (в худшем случае), а я в уме держу биты/секунду.
Improver
30.04.2023, 06:44
Про видюшник для ретрокомпьютерных 8 биток - оригинальная идея, только дороговато было на видеокассетах звук хранить (с игнорированием видео). Но в качестве потенциальной возможности интересно.Извиняюсь за оффтоп, но напомню, что в 90-е уже был разработан АрВид (https://ru.m.wikipedia.org/wiki/%D0%90%D1%80%D0%92%D0%B8%D0%B4), и, думаю, при желании можно было бы сделать то же самое и для восьмибиток, так что идея не сильно оригинальная. И да, это было бы относительно дорого.
Про арвид я подумал первым делом, но это уже другой уровень, а svofski предложил вариант который может работать без дополнительной аппаратуры между вектором и видюшником.
Improver
30.04.2023, 08:10
ivagor, если уж сейчас что-то делать на магнитной ленте, то я бы предложил всё-таки использовать обычный магнитофон, только использовать стерео-сигнал. Да, идея тоже не новая, раньше уже использовали на Векторах запись по разным каналам стерео, но это были разные записи. Я же предлагаю записывать в два канала одновременно со сдвигом на полфазы несущей частоты, а при чтении суммировать, что увеличит полосу пропускания в два раза и, думаю, будет не хуже видеомагнитофонов.
Если вернутся в конец 80х - начало 90х, то тогда проще чем видеомагнитофон было найти катушечник со скоростью 19 (у нас был такой). Еще наш позволял отключать каналы/дорожки при записи и можно было записывать с наложением или удваивать объем информации. Но если говорить о сегодняшнем дне, то лента это уже не способ хранения информации, а точка приложения сил для экспериментов "что можно было сделать в давние времена". Упомяну FMx - это простейший способ получить приемлемую скорость загрузки реала с компа (или смартфона).
Improver
30.04.2023, 09:40
ivagor, в те годы я, кстати, записывал и на катушечник, но на скорости 9см/с, 19 не помню, чтобы пробовал. По качеству записи мало отличалось от кассетника, а по максимальной скорости было даже хуже. Возможно мне "бобинники" попадались не очень, или наоборот, кассетник хороший... :)
Если сейчас ставить эксперимент "чего максимально можно было достигнуть", то я, всё-таки, попробовал стерео. Сейчас сложность записи не имеет значения, можно сгенерировать любую wav-ку и записать на магнитофон, главное, как наиболее просто потом преобразовать в сигнал для Вектора, а смикшировать стерео в моно даже по тем временам было не сложно. Может, и FMx адаптировать под это выйдет.
Если использовать стерео, то возникает вопрос с подключением к вектору дополнительных бит на запись и чтение (через ПУ?). Но есть еще вариант с "прозрачным" для вектора стереовариантом - дифференциальное кодирование, в одном канале +, в другом - и между вектором и магнитофоном устройство которое на запись делает 2 противоположных канала, а на чтение складывает их в противофазе. Правда я не знаю, насколько это полезно именно для магнитной записи, для передачи то это очень хорошо. Ну по крайней мере можно сделать длинный шнур. Еще ведь был/есть пример океана-240, в котором пытались за счет аппаратных наворотов выхода и входа улучшить высокоскоростную запись и чтение с магнитофона, но об успешных результатах использования в наше время не читал.
Но есть еще вариант с "прозрачным" для вектора стереовариантом - дифференциальное кодирование, в одном канале +, в другом - и между вектором и магнитофоном устройство которое на запись делает 2 противоположных канала, а на чтение складывает их в противофазе. Правда я не знаю, насколько это полезно именно для магнитной записи, для передачи то это очень хорошо.
У меня тоже была такая идея. Смысл чисто теоретически может быть тот же самый, что и в передаче по проводу -- общая помеха пропорционально исказит оба канала. Но я не нашел никаких глиняных табличек про это, как будто никакого опыта предков в этой области не было. Возможно тем, кто хорошо понимает в магнитной записи, очевидно, что просто сделать головку в два раза шире дает лучший результат, например.
Идея с интерливом инверсий между двумя каналами мне нравится, потому что безумная. Может быть проще реализовать производную от этой идеи -- разделить клок и данные.
Арвид я конечно знаю, но все-таки Арвид это не просто воткнул проводок и нажал на запись. И там софтовая часть мощна, хотел бы я посмотреть как Вектор декодирует CIRC. Тема хайфайного трека на VHS в том, что это практически прозрачный канал. Фазовых искажений в нем считай что нет, никакого вау и флаттера. Частотная характеристика практически линейная во всем диапазоне до 20кГц. Поэтому есть надежда, что FMx на нем мог бы бодро работать. Если не изменяет память, fm5 это примерно 11кбит/c, то есть почти 30МБ на кассету E-180 в режиме SLP. В таком альтернативном видеопанковом прошлом это неплохой объем. Если прибавить к этому автоматическую подмотку к нужному месту, как у Арвида, можно сделать мощное файлохранилище с произвольным доступом. Приделать к нему робота из фильма Хакеры.
Видео поток тоже можно использовать, правда с тормознутостью Вектора это челлендж. Нужна схема выделения ССИ, но потом вообще все круто. Даже если кодировать по одному биту на строку, это уже будет 15 кбит/с (по-моему два бита на строку Вектор не сможет, даже если все сигналы будут супер ровные). Сложнее сделать, потому что не просто проводок, зато в качестве устройства хранения сгодится любой помоечный видеоплеер без хай-фай стерео.
Видео поток тоже можно использовать
Интересно бы сравнить цены 91-93 на
1) видеоплеер+устройство согласования и дисковод+КНГМД
2) видеокассету и дискету
Плюс на стороне дисков - произвольный доступ и сложившаяся вокруг система. У видео потенциальный плюс в емкости, но тут все же скорости под вопросом.
А в 94 уже можно говорить о винтах и это другая история.
Не могу даже приблизительно представить себе эти цены и не доверяю никому, кто говорит, что их помнит. Но в 93 пишущие видеоплееры были у многих -- их было всяко больше, чем компьютеров. Ну и если представить себе, что компьютер подключается к тому же телевизору в стенке между сервантом и комодом напротив ковра, не так трудно вообразить себе и двойное использование видака по крайней мере у некоторых энтузиастов.
Но это какой-то лабораторный анализ. В контексте тейп-видео-вектор-панка это прикольно, любая привязка к реальному миру давно потеряла смысл.
Забацать в эмуляторе симулированный видео поток вполне можно. Но это конечно надо заморочиться.
Да, видеоплеер или видеомагнитофон могут показывать и записывать фильмы, у дисковода с этим сложнее.
https://youtu.be/yeFfn9LYlhQ была такая система бекапа на Амиге. На запись там уже был композит (теоретически у Вектора тоже слегка композит), а на чтение похоже просто компаратор собранный внутри корпуса от разъема.
- - - Добавлено - - -
Вот такой вот колхоз внутри (https://web.archive.org/web/20140426071836/http://www.bigbookofamigahardware.com/bboah/media/download_photos/amigavbs_2_big.jpg). Микросхема -- это какой-то древний компаратор. Судя по всему, эта штука на чтение выдает сигнал вполне пригодный для последовательного порта. Умно!
Improver
30.04.2023, 18:45
Микросхема -- это какой-то древний компаратор.Так Вектор его штатно имеет на входе. :)
- - - Добавлено - - -
Ещё вариант, если не привязываться к магнитной ленте, то можно взять старый CD-ROM с аудиовыходом и просто нарезать аудиодиск (не мп3). Стандарт был разработан задолго до Вектора, так что вполне возможно было появление и такого варианта в те годы. Может он потянул бы и максимальную скорость ROM, и с FMx справился бы.
ак Вектор его штатно имеет на входе
Имеет, но без последовательного порта с DMA. А так практически Амига, да.
система бекапа на Амиге
Прикольная штука, для записи формируем изображение на экране, при чтении пытаемся разобрать что там выдает видюк. Может вектор и успел бы бит/строку.
взять старый CD-ROM с аудиовыходом и просто нарезать аудиодиск
Вполне рабочий вариант, но например у меня пишущий привод появился кажется в 97, если не позже.
Может вектор и успел бы бит/строку.
Бит на строку по-моему легко, но можно же сделать и байт на строку, если прикрутить последовательный порт. Но вряд ли на Векторе можно было бы сделать какую-нибудь осмысленную коррекцию ошибок.
Improver
30.04.2023, 19:21
Вполне рабочий вариант, но например у меня пишущий привод появился кажется в 97, если не позже.Чисто теоретически, в те годы какой-нибудь кооператив мог бы даже заказать выпуск партии дисков с программами, как продавали игры на кассетах и дискетах.
вряд ли на Векторе можно было бы сделать какую-нибудь осмысленную коррекцию ошибок.
Думал на эту тему, пару простейших вариантов Хэмминга можно по таблицам декодировать даже на ходу. Или (7,4) с получением полубайтов из 7 бит или укороченный (12,8) с байтами из 12 бит.
выпуск партии дисков с программами
Если бы к вектору прилагался заводской CD со штатными программами - это было бы впечатляюще, но пришлось бы и кассету тоже прилагать.
Improver
02.05.2023, 10:35
Хочу немного вернуться по теме и дать пояснения поводу предложения использовать стереозапись, в картинках будет понятнее. Я предлагал (https://zx-pk.ru/threads/10002-rom-format-avtozapusk-zashchita-sekrety.html?p=1177768&viewfull=1#post1177768) примерно такой вариант, вот так будет выглядеть несущая частота:
78843
По левому и правому каналам идёт запись с максимально возможной для магнитофона частотой, а результирующая несущая получается при объединении каналов через "исключающее или", в результате несущую частоту можно будет повысить в два раза по отношению к возможностям магнитной ленты, и не надо никаких видеомагнитофонов. А вот пример наложения кода на несущую частоту, при этом на выходе можно получить сигнал, пригодный для магнитофонного входа Вектора:
78844
Один ньюанс: на больших блоках с повторяющимися значениями 55h или AAh надо будет инвертировать оба канала так, чтобы частота сигналов не стала меньше минимальной для записи на магнитофон, а остальное всё просто.
Это получается не дифференциальный сигнал для длинных линий, это увеличение плотности записи. И да, аппаратный кодировщик для такого сигнала будет, возможно, сложен, но как я писал выше, на этом не стоит заострять внимание -- сейчас сгенерировать WAV-ку можно запросто, а декодер хоть и потребуется, но его схема будет достаточно простой. Так можно выжать максимум из бытового магнитофона 90-х годов. :)
Вопрос (для меня, как неспециалиста в магнитной записи) в том, что является главным ограничивающим фактором - частотный диапазон, непостоянство скорости ленты или что-то еще. Аппаратная простота конечно тоже важна.
В бытовом случае мы знаем, что при обычной скорости на железную кассету больше 11кГц не запишется, на хром наверное до 15 влезет. Есть еще Металл, но он стоит сейчас таких абсурдных денег, да и вроде как требует других головок, не знаю.
Метод, который предлагает Improver, приколен тем, что позволяет в два раза сделать все плотнее за счет сдвига фаз. Мне это напомнило как например в осциллограф запихивают 1Gsps при пропускной способности АЦП и ОЗУ 250Msps -- берем четыре штуки и сдвигаем по фазе. Мой контраргумент этому методу -- мы по-моему ничего не выигрываем по сравнению с просто добавлением второго канала. Плотность в итоге та же самая, помехоустойчивость ниже (потому что физически меньше количество материала на бит). И появляется неудобная зависимость одного канала от другого, так что даже частичное восстановление в случае сбоя затруднительно.
Если брать в руки паяльник, я бы взял лентопротяг, к нему бы приделал схему из Commodore 1530 - но может быть двойную для стерео каналов, чтобы была возможность играться с этим. И наверное попробовал бы отломать у мотора стабилизатор скорости и заменить его на что-нибудь в два раза быстрее. Таким образом можно повысить скорость записи, оставаясь в рамках физических ограничений пленки. Если головки, конечно, позволят.
- - - Добавлено - - -
Вопрос (для меня, как неспециалиста в магнитной записи) в том, что является главным ограничивающим фактором - частотный диапазон, непостоянство скорости ленты или что-то еще. Аппаратная простота конечно тоже важна.
По-моему при цифровой записи полезнее оперировать количеством инверсий на мм (см, дюйм, локоть, пуд, фут, футбольное поле). На старинных дискетах даже писали по-моему количество байт на дюйм.
CodeMaster
02.05.2023, 12:56
мы по-моему ничего не выигрываем по сравнению с просто добавлением второго канала
А скорость загрузки?
ничего не выигрываем по сравнению с просто добавлением второго канала.
Насколько понял выигрыш в том, что в вектор с магнитофона в итоге приходит один бит.
А скорость загрузки?
Загрузить последовательно два бита со скоростью 2х, или два бита параллельно со скоростью 1х -- теоретически по крайней мере это одно и то же. Конечно тут нельзя так говорить сразу, учитывая что мы вообще говорим о скоростях, которые для Вектора могут оказаться предельными.
- - - Добавлено - - -
Насколько понял выигрыш в том, что в вектор с магнитофона в итоге приходит один бит.
Это да.
Я правда вообще не особенно радею за то, чтобы строго на Векторе все декодировать в софте.
Improver
05.05.2023, 14:00
ivagor, svofski, нашёл глюк в загрузчике FM9, или в его реализации в bin2wav, а именно если сгенерировать wav-ку с программой с нулевого адреса, то после первого этапа загрузки происходит "тайна чёрного экрана", т.е. ничего не грузит. :( Файл wav делал так:
bin2wav test.r0m test.wav -s 0 -m v06c-turbo
С других адресов, отличных от 0, всё работает.
К сожалению просто загрузка с 0000 не поддержана в имеющемся варианте загрузчика FM9.
Improver
05.05.2023, 15:22
К сожалению просто загрузка с 0000 не поддержана в имеющемся варианте загрузчика FM9.Это можно исправить? Как я понял, проблема в проверке номера первого блока, он должен быть ненулевым, вот тут:
L_DBB2: CALL L_DB3D
DCR C
JNZ L_DBA3
CALL L_DB3D
ORA A
JZ L_DB80
Если тут в отладчике остановить и сбросить признак Z, то дальше всё грузится, с некоторыми оговорками, причём проверки на общее количество блоков там нет, оно может быть и нулевым. Это проверка на ошибки чтения, или тут возможно пересечение с каким-нибудь другим форматом записи Вектора?
Ограничение не принципиальное, можно убрать
1) проверку на 0 в начале
2) записи в район 0-FF в конце. Ну и убрать еi.
Вроде это все. Изначально ограничение на загрузку с 0 было связано с тем, что в области 0-FF размещались процедуры чтения байт, которые вызывались по rst. Для загрузки с неотключенным пзу это не подходит и svofski (или я, уже не помню, но скорее всего svofski) переделал на call, вроде это прокатило и загрузка не поломалась.
HardWareMan
06.05.2023, 09:05
Improver, картинка красивая, если юзать AudioCD. А на реальной ленте с реальным мафоном 2го или чаще 3го класса у нас будут фазы плыть как та шлюпка по течению реки.
HardWareMan, из-за амплитудных отклонений, или из за взаимного влияния каналов? Механически левый-правый дб рядом вместе. А что ты думаешь про запись в противофазе, как дифф. канал, только на пленке?
Improver
06.05.2023, 13:41
HardWareMan, это пока только теория, требующая проверку опытом.
HardWareMan
06.05.2023, 13:41
HardWareMan, из-за амплитудных отклонений, или из за взаимного влияния каналов? Механически левый-правый дб рядом вместе. А что ты думаешь про запись в противофазе, как дифф. канал, только на пленке?
Дифф, возможно, будет более устойчив. Взять какой-нибудь NRZI как в USB и долбануть его как битовый поток.
ivagor, а ты видел Slushload ? Я не следил за развитием турболодырей, но похоже, что Slushload справляется с аж 13700 бит/сек на стандартной датасетте в хорошем состоянии. В нем используется 4 (опционально 3) длины импульсов. Наверное ими кодируется 4 символа. К сожалению я не нашел более подробного описания.
Интуитивно кажется странным то, что 4 длительности импульса надежно декодируются и оказываются устойчивыми к вау и флаттеру.
С комодом мне тяжко, я какой-то спековский турболодырь смотрел, он вроде в этом районе или даже быстрее.
Да, разбирать комодовский код это мрачняк. Но лодырь в общем можно анализировать на слух. Думаю, как называется кодирование в котором 4 разных длины импульса кодируют 4 символа? Правда я попробовал сгенерить сам и вижу только три длины, не знаю где четвертая. Лодырь самим слашем называется "4 pulse huffman loader".
Могу только сказать, что мне именно такой подход (разные длительности импульсов) представляется самым продуктивным, я его в FM и использовал. Правда у меня только 2 варианта, но у меня нет реала, а как оказалось различия с эмуляторами при высоких скоростях есть. 2 варианта длин все же проверены на реале и работают. А дальше карты в руки реальщикам.
HardWareMan
06.05.2023, 21:54
Могу только сказать, что мне именно такой подход (разные длительности импульсов) представляется самым продуктивным, я его в FM и использовал. Правда у меня только 2 варианта, но у меня нет реала, а как оказалось различия с эмуляторами при высоких скоростях есть. 2 варианта длин все же проверены на реале и работают. А дальше карты в руки реальщикам.
Я просто напомню: Codemasters CD (https://www.cpcwiki.eu/index.php/Codemasters_CD)
Не знал про такую штуку, Improver тоже предложил CD, идея носилась в воздухе.
metamorpho
22.05.2023, 22:34
Есть скоростной загрузчик ROM с автозапуском.
https://www.youtube.com/watch?v=B64Wzztin-o&t=9s
Возможно ли на основе этого загрузчика сделать следующее - грузится загрузчик с автозапуском, далее запущенный скоростной загрузчик начинает грузить в экран заставку (причём рисуется непоследовательно,а в разные части экрана). Далее грузится игра по своим адресам и запускается.
Теоретически это частично возможно, потому что скоростной загрузчик сам живет в экране. Но он в нем занимает совсем чуть-чуть. Вот исходник loadfm, который используется в автозагрузчике https://github.com/svofski/bin2wav/blob/master/loadfm/loadfm-db00.asm Совсем немного покумекав, наверное можно сделать в нем перемежение данных с адресами, чтобы допустим для каждого блока из 8 байт указывался адрес загрузки. Но готового ничего такого нет.
Improver
23.05.2023, 05:06
грузится загрузчик с автозапуском, далее запущенный скоростной загрузчик начинает грузить в экран заставкуКак заметил svofski, это возможно, но ещё не стоит забывать про палитру -- чтобы её изменить нужно прерывание, а т.к. к 38h адресу доступ заблокирован ПЗУ, то либо заставка будет в жёлто-синих цветах, либо это будет загрузчик без автозапуска.
В загрузчиках по адресу 38h или процедура задержки, как оригинальном загрузчике, или просто ret, как в более новых, поэтому палитру запрограммировать можно. Вот отключить пзу программно никак не получится, тут потребуется содействие пользователя, чтобы он нажал БЛК+СБР. Поэтому из перечисленного
грузится загрузчик с автозапуском, далее запущенный скоростной загрузчик начинает грузить в экран заставку (причём рисуется непоследовательно,а в разные части экрана). Далее грузится игра по своим адресам и запускается.
автоматически возможно все, кроме "запускается". Хотя были векторы с автозапуском, но наверно не стоит рассчитывать на них, лучше написать пользователю, чтобы он нажал БЛК+СБР для старта игрушки.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot