Вид для печати
Так уж получилось, что взломом и дискованием игр я почти (за исключением пары любимых игрушек) не занимался. И копаться в фирменных загрузчиках типа тех, что для «спидлоков», не приходилось. Но вот какой вопрос всегда возникал: почему для увеличения надежности и скорости в процедуры загрузки-выгрузки на ленту не встраивали алгоритмы избыточности и отказоустойчивости? Или что-то подобное было (пусть и в единичных случаях), ведь TAPE LOADING ERROR была бичем кассетных машин?
1. Просто тогда общая методология работы с бинарными вычислительными машинами была развита достаточно слабо... Механизм циклических сумм тогда был развит?Цитата:
Сообщение от Conan
2. Аудиокассеты по сути являются очень ненадёжными носителями, турбозагрузчики, которые появились годах так в 88-90 пытались опровергнуть это утверждение, но на практике так не получалось. После года-двух хранения программ, записанных в турборежиме их попросту нереально было бы прочитать
Механизм циклически сумм (CRC) был развит (известен) еще до появления ZX Spectrum. Его в частности встраивали в контроллеры дисководов, а кроме того были и менее сложные методы (ECC).Цитата:
Сообщение от GriV
Безусловно, аудиокассеты (в сочетании с бытовыми магнитофонами) не самый надежный носитель. Но тем паче желание (пусть не увеличивая емкость) увеличить надежность.Цитата:
Сообщение от GriV
P.S. Кстати на e-Bay до сих пор продаются кассеты с играми, записанными 20 лет назад.
могу лишь присоединиться к вопросу и добавить - почему подавляющее большинство софта было непаковано? не то что lzss каким-нить, а хотя бы rle, коим очень нелохо паковалось (в кассетные времена помню весьма успешно занимался этим и параллельно учил асм по пакеру из журнала "ZX+ЕЩЕ N1", который сохранился у меня в бумажном виде!)
а по каким программам ты судишь?
скажем Trantor распаковывается после вступительного ролика
это наверное исключение. вообще в противовес можно сказать, что почти все "мультифейсные" игры были запакованы.
вообще просматривая игры в .tzx могу предположить что размер подгружаемого кода также являлся какбы защитой пример Tau Ceti, FairLight где загрузка шла с экрана и почти до конца
с другой стороны паковать с кассеты неудобно
а за "мультифейсность" иногда хотелось когонибудь придушить...
чего стоил например Argggghhh! дернутый при загрузке первого уровня с включенным кемпстон джойстиком
Ребята, я хочу вам напомнить, в каком виде выпускались _фирменные_ игры производителями.
На одной кассете-одна игра. Поэтому паковать нет смысла, даже наоборот.
Кассеты записывались на _специальном_ оборудовании, поэтому качество записи сами понимаете. Даже существовала система защиты, замерявшая уровень шума в паузах.
Каждая кассета в собственной коробочке и с книжечкой, подтверждающей законность приобретения
Сам по себе метод записи на кассету FM 1200/2400 очень стоек к изменению скорости носителя и качеству, ведь он до сих пор применяется для передачи данных.
А на счет нестандартных методов загрузки, так это в кажтой первой игре конца 80-х для защиты от копирования. В это время уже можно сказать все игры загружались нестандартно.
А что касается всего того что есть у нас на кассетах, так их уже ломали-переломали и т.д.
у меня осталось несколько фирменных кассет, вроде бы всё считывалось без проблем, и турбо запись в защите alkatraz тоже,
а насчёт компрессии могу вспомнить только игрушки от grafgold - flying shark, soldier fortune, rainbow island, также сжатие применялось в защите alkatraz 2, каждый блок был заксорен и запакован: shadow dancer, strider 2
outrun europa и.т.д.
да ещё вспомнил head over heels и batman 3d
Кстати в одном из фильмов (по-моему в Ocean vs. Imagine) показан процесс записи на таком оборудовании. Вопрос в другом, качество магнитофонов и процесс считывания.Цитата:
Сообщение от Paul_ls
К изменению скорости стоек, но к выпадениям отдельных бит не очень. Достаточно царапины на ленте или пылинки (не говоря уже об отпечатке пальца) и все пропало. Кроме того приличных фильтров по питанию ни у магнитофонов, ни у Speccy обычно не ставили. И включившийся холодильник или выключатель запросто моги привести к сбою при считывании с самой идеальной ленты.Цитата:
Сообщение от Paul_ls
Нестандартные загрузчики были, но вот пытался кто ни будь использовать программные решения для повышения отказоустойчивости при чтении?Цитата:
Сообщение от Paul_ls
вспомнился загрузчик BleepLoad от Firebird: игра грузилась кучей блоков байт по 256, в случае ошибки перематываем чуть назад и пытаемся грузить снова: RickDangerous, Savage, Sentinel (кстати в последнем есть проверка на кол-во тактов ZX и если всё О.К. идёт scroll по бордюру)
похожую защиту делала фирма Dinamic в играх от CreepSoft: rescate atlantida и AstroMarineCorps там блоки были байт по 20
Меньше байтов - быстрее загрузка.Цитата:
Сообщение от Paul_ls
а вот интересно реально ли найти фирменную кассету Deus Ex Mashine?
в одном из тредов всплывала про нее интересная инфа
http://zx.pk.ru/showthread.php?t=333&highlight=deus
Думаю реально только на е-Bay http://pages.ebay.co.uk/sitemap.htmlЦитата:
Сообщение от jerri
А чем не подходит вариант в WOS? Там есть даже вставки в кассету и инструкции (не говоря о музыке).
Быстрее загрузка-меньше ленты. Меньше ленты - кассета дешевле, программа глупее (психология). Ведь встречают по одежке? Если что-то большое, то дорогое, а маленькое - деньги на ветер (наблюдение микрософт).Цитата:
Сообщение от bpm
Да ладно. Lemmings, умятые RST#7 в один файл (и интрой и txt) хуже старинной версии на весь диск?Цитата:
Сообщение от Paul_ls
Надо потратить больше ленты - делай как Медный - пиши по 2 раза для надежности.
что сравнивали там метод загрузки спектрума и вектора.
Так вот вектор имел малые блоки с контрольной суммой и потом эти блоки повторялись.
Реально же используя амлитудно фазовую модуляцию можно записать большое количество информации (вплоть до десятков мегабайт на кассету). Однако такой метод имеет множество недостатков: прежде всего это стоимость (по сути такое устройство является стриммером) - она сравнимо со стоимостью очень хорошего спектрума, а в то время оно и подавно...
В принципе, можно организовать данные на ленте, как на CD, вот только избыточность будет раза в 2, но зато можно ленту рвать и клеить, а программы грузиться будут.
Но почему-то так никто и не сделал. Единственное объяснение, которое пока вижу, это необходимость стандартной процедуры загрузки (встроенной в ПЗУ), хотя бы для первого блока. То есть, какой смысл делать надежной «продолжение», если начало все равно стандартное? НО! Первый блок короткий, а сбои (по теории вероятности) более часты на длинных блоках.
У кого есть tzx файлы с блоками DirectRecording (ID=0x15) дайте ссылку плиз. Зачем надо см. тут http://zx.pk.ru/showthread.php?t=423 :-)
Если разрезать длинный файл на мелкие кусочки, то вероятность сбоя не уменьшится, т.к. общая длина не изменилась и все части одинаково важны. Вероятность сбоя в загрузчике равна вероятности сбоя по всей длине программы.Цитата:
Сообщение от Conan
Вот если сделать как в CD, т.е. некоторые блоки можно пропускать, то другое дело.
Все верно: «по всей длине программы», то есть если вероятность сбоя на одно чтение одной программы равна 1, то на ее половине? а одной десятой? Природа сбоев носила именно вероятностный характер: выбросы по питанию, механические повреждения ленты и т.д. На коротком кусочке, вероятность сбоя ниже.Цитата:
Сообщение от Paul_ls
Если разрезать программу на короткие кусочки, общая вероятность сбоя не уменьшится, но вероятность сбоя на отдельно взятом кусочке будет меньше.
я могу сделать такой вывод, что отказоустойчивых программ на ленте (как впрочем и на всех остальных носителях на ZX) я не встречал.
Причин здесь несколько:
- Фирменная запись производилась на хорошие кассеты с промышленного оборудования, поэтому вообще то говоря там проблем с качеством не должно быть (заявление где-то в посте про кассету, лежащую 20 лет).
- Пираты делали своё дело - записать на кассету и продать, качество записи их не волновало, единственное что было - желание уместить поболее (что и проявляется в сжатии ПО, даже на кассетах).
- Стоимость оборудования для поддержки нестандартного способа записи соизмерима со стоимостью самого спектрума (если не значительно её превышает), поэтому такое оборудование использовали разве что промышленные производители.
Природа сбоев при загрузке не всегда связана с качеством записи. Например помехи по питанию, пылинки на ленте, неидеальные контакты. Причем претензии к качеству чтения были и на фирменном железе. Не с проста же появился TAPE TESTER в ZX Spectrum 128Цитата:
Сообщение от GriV
Пираты работали на рынок (пусть и черный) поэтому качество считывания играло роль и для них. Иначе просто приносили кассеты взад.Цитата:
Сообщение от GriV
Для реализации избыточной отказоустойчивости, не всегда требуется дополнитльное оборудование, возможно и прораммное решение. А уж если говорить про запись (массовую), так ничего кроме специальной мастер-копии не требуется. Дальше только тиражирование.Цитата:
Сообщение от GriV
Name: Celina Elima-TapeloaderЦитата:
Sinclair Spectrum Hardware Index
Manufacturer: Celina Ltd.
Price: г14.99
Blurb: Eliminate tape loading errors !
Device that connected between the cassette recorder and
the Spectrum to remove unwanted noise for the signal.
Source: Your Spectrum issue 15. June 85
Name: Hilderbay Tape-Aid
Manufacturer: Hilderbay Ltd.
Price: г5.95 / г7.95
Blurb: Cure tape loading problems with this interface.
Stop drop-outs and load even poor quality tapes.
Deluxe version (г7.95) has a larger meter.
Source: Sinclair User - Mar 83
Name: ZX Loader Aid
Manufacturer: Fulcrum Products
Price: г12.20
Blurb: An interface to aid tape loading. LED's indicate correct
volume setting.
Source: ZX Computing Aug/Sep 83
Name: ZX Tapeloader
Manufacturer: Elinca Products Ltd.
Price: г14.99
Blurb: Trouble free loading and saving. Switchable load/save.
Meter shows level. Filters cut out the noise to create
the best signal possible.
Source: ZX Computing Oct/Nov 83
Еще удивительнее, что на фоне такого количества фильтров и предусилителей (которые продавались за деньги) никто не реализовал простые и бесплатные алгоритмы избыточной отказоустойчивости. Остается лишь отнести этот вопрос к категории неразрешимых загадок.
Конечно счаз правды не "нарыть", но мне так кажется, что ПЗУ SOS для ZX писали сторонние от (С) Sinclair Research ltd программисты, и скорей всего после выпуска первой версии ПЗУ (в которой поддержали аудиокассеты как недорогую альтернативу более надёжным носителям) планировалось в недалёком будущем отходить от касссет и идти на более другие носители (которые кстати и появились лет через 5). Однако потом, после того как практика показала что фирмы разработчики напрямую работают с SOS пришлось отказаться от этой идеи, что скорей всего и подвигло к разработке 128КБ машины с теневым альтернативным ПЗУ с сохранением в целях совместимости старого ПЗУ.Цитата:
Сообщение от Conan
А если тебя всё же интересует, как же её можно реализовать (отказоустойчивость т.е.), то можно использовать уже готовые решения (например алгоритм скрэмблирования 8 бит в 14 для CD дисков).
С другой стороны, компакт диски, в отличие от аудикассет, не могут быть изжёваны, не могут иметь вырезки, поэтому здесь тоже надо думать.
Тогда необходимо все данные представлять следующим образом:
- Каждая программа состоит из нескольких блоков
- Весь файл, записанный на аудиокассете представляется в виде блока
- Блок бьётся на элементы
- Каждый элемент выделяется синхрозаголовком (длинная еденица и длинный ноль, их комбинации), а также сопровождается контрольной суммой
- Каждый элемент имеет уникальный номер
- Обязательно следуют друг за другом два (или более, в зависимости от требований надёжности) элемента с одинаковыми номерами. Если один элемент вдруг запорчен, то другой может быть считан. Уже считанные элементы естественно повторно не считываются.
- Каждый байт представляется в виде 14бит данных.
Подсчитаем:
- 1бит имеет длительность около 1000 тактов обслуживания (эта цифра является определяющей, от неё зависят все остальные выкладки, если её уменьшать, то увеличится скорость загрузки, но уменьшится надёжность и наоборот)
- 1 байт записывается в виде 14 бит, итого около 14*1000=14000 тактов
- В секунду умещается 250 байт "чистыми", при использовании синхрозаголовков и контрольных сумм это число будет на 10-15%% меньше, итого - около 220 байт
- При записи дублирующих блоков эта цифра будет уменьшаться пропорционально количеству дублтирующих блоков (для 2х - 110, для 3х - 70 и т.д.).
А что получается неплохо...
Неразрешимая загадка :D
Очень оригинальный взгляд на историю Speccy.Цитата:
Сообщение от GriV
ROTFL! Честное слово.
Могу лишь сказать, что правду «нарывать» не надо, поскольку есть вполне доступные и достоверные источники, тот же самый WOS и Planet Sinclair. Это к вопросу об авторах и планах при разработке встроенного ПО Speccy.
Как можно реализовать алгоритмы избыточной отказоустойчивости, мне рассказывать не надо, я немножко с этим знаком. Вопрос был в том, почему это не сделали, хотя потребность явно была.Цитата:
Сообщение от GriV
Еще как могут. И дыры тоже (вспомните технические болванки). А царапины чем не жувастики? Надо отметить, что сейчас диски читаются всегда с ошибками, только они исправляются на соответствующих уровнях коррекции. Ведь задачи прочитать диск на 100 процентов там не стоит. Нужно прочитать столько, чтобы хватило для коррекции, и только.Цитата:
Сообщение от GriV
Я понимаю, проблема в магнитофоне не в нечитаемости какого-то блока (их можно дублировать), а в востановлении синхронизации чтения. С этим сложнее, если учесть уровень шумов на обычной ленте. Или перед каждым блоком, скажем 256 байт, давать пилот?
А вот это уже наверно ближе к истинным причинам, рассинхронизация при чтении - еще одна причина сбоев. Кстати длинный пилот тон появился в ZX Spectrum. В его предшественнике (ZX81) пилот тона практически не было. Но опять же существуют (не знаю точно, насколько были распространены в начале 80-х) алгоритмы и методы автосихронизации при чтении данных. Хотя наверно их реализация в совокупности с коррекцией ошибок была неоправданно сложна и ресурсоемка (например, размеры буфера в ОЗУ). Впрочем, все это только предположения.Цитата:
Сообщение от Paul_ls
В Радио86-РК блоки синхронизируются вообще по 2-м принятым байтам.
Тема имеет продолжение в http://zx.pk.ru/showthread.php?t=720
Оказывается отказоустойчивые решения все же были!
на самом деле должен был начинаться с синхросигнала.
Обычно синхросигнал орагнизуется следующим образом (на кассете):
- Идёт длинная еденичка
- Идёт длинный нолик
- Опять длинная еденица
- Опять длинный ноль
Т.о. образуется чёткая синхросмесь.
Обычно сигнал мерялся с трёх-пяти точках (в SOS это было именно три точки), чтобы увериться в неошибочном чтении. По синхросигналу достаточно просто организовать такую загрузку, чтобы данные однозначно не были потеряны. Паузы при этом рассчитываются так, чтобы замеры текущих состояний приходились приблизительно в центре записанных состояний (еденички или нуля). Это даст некоторый запас прочности при использовании съехавших магнитофонах (с ускоренным или замедленным движением). Если каждый блок оснащать синхросигналами, то это даст колоссальный запас прочности.
Т.о. вот я что я могу сказать - кто бы не разрабатывал процедуру загрузки с ленты - лабасы были те программисты :D
Что-то я есть не понимать. Синхронизация идет ведь по фронтам, а не по уровням, так? Как мы можем делать замеры? Мы же при чтении засекаем время от фронта до фронта, и не важно от 1 к 0 или наоборот. В этом и есть смысл кодирования с самосинхронизацией. И на самом деле это не замеры, а ожидания фронтов. На ленте же нет 0 и 1, там только импульсы (кстати экспоненциальные). И записываются они туда в моменты смена тока в головке, при переходе от 0 к 1 и наоборот. Вот.
Не обязательно по фронтам, можно и по уровням, кстати по фронту весьма можно ошибиться, а вот по уровню вероятность ошибки ниже...Цитата:
Сообщение от Paul_ls
Синхронизация должна идти по последнему фронту синхросигнала...
Что касается Спектрума в плане работы с кассетой, там была автосинхронизация ПО ФРОНТАМ, а не по уровню. Лет 15 назад я даже знал, как назывался алгоритм. И не такой уж плохой он был: по сравнению с ZX80 и ZX81 кассеты читались НА ПОРЯДОК надёжнее (правда, ром от 80/81 я не смотрел - там и железо могло быть кривее). Даже мои извращения с загрузчиками (модификации ромовского лоадера ради анимации, счёткиков загрузки и т.п.) не мешали программам нормально грузиться, правда, сложности могли возникнуть на левоватых клонах типа "Ленинграда".