Надежная загрузка с ленты

[Paul_ls]

НО! Первый блок короткий, а сбои (по теории вероятности) более часты на длинных блоках.

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

Вот если сделать как в CD, т.е. некоторые блоки можно пропускать, то другое дело.

[Conan]

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

Вот если сделать как в CD, т.е. некоторые блоки можно пропускать, то другое дело.

Все верно: «по всей длине программы», то есть если вероятность сбоя на одно чтение одной программы равна 1, то на ее половине? а одной десятой? Природа сбоев носила именно вероятностный характер: выбросы по питанию, механические повреждения ленты и т.д. На коротком кусочке, вероятность сбоя ниже.

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

[GriV]

я могу сделать такой вывод, что отказоустойчивых программ на ленте (как впрочем и на всех остальных носителях на ZX) я не встречал.

Причин здесь несколько:
- Фирменная запись производилась на хорошие кассеты с промышленного оборудования, поэтому вообще то говоря там проблем с качеством не должно быть (заявление где-то в посте про кассету, лежащую 20 лет).
- Пираты делали своё дело - записать на кассету и продать, качество записи их не волновало, единственное что было - желание уместить поболее (что и проявляется в сжатии ПО, даже на кассетах).
- Стоимость оборудования для поддержки нестандартного способа записи соизмерима со стоимостью самого спектрума (если не значительно её превышает), поэтому такое оборудование использовали разве что промышленные производители.

[Conan]

Причин здесь несколько:
- Фирменная запись производилась на хорошие кассеты с промышленного оборудования, поэтому вообще то говоря там проблем с качеством не должно быть (заявление где-то в посте про кассету, лежащую 20 лет).

Природа сбоев при загрузке не всегда связана с качеством записи. Например помехи по питанию, пылинки на ленте, неидеальные контакты. Причем претензии к качеству чтения были и на фирменном железе. Не с проста же появился TAPE TESTER в ZX Spectrum 128

- Пираты делали своё дело - записать на кассету и продать, качество записи их не волновало, единственное что было - желание уместить поболее (что и проявляется в сжатии ПО, даже на кассетах).

Пираты работали на рынок (пусть и черный) поэтому качество считывания играло роль и для них. Иначе просто приносили кассеты взад.

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

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

[[bETA]mEN]

Sinclair Spectrum Hardware Index

Name: Celina Elima-Tapeloader
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

[Conan]

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

[GriV]

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

Конечно счаз правды не "нарыть", но мне так кажется, что ПЗУ SOS для ZX писали сторонние от (С) Sinclair Research ltd программисты, и скорей всего после выпуска первой версии ПЗУ (в которой поддержали аудиокассеты как недорогую альтернативу более надёжным носителям) планировалось в недалёком будущем отходить от касссет и идти на более другие носители (которые кстати и появились лет через 5). Однако потом, после того как практика показала что фирмы разработчики напрямую работают с SOS пришлось отказаться от этой идеи, что скорей всего и подвигло к разработке 128КБ машины с теневым альтернативным ПЗУ с сохранением в целях совместимости старого ПЗУ.

А если тебя всё же интересует, как же её можно реализовать (отказоустойчивость т.е.), то можно использовать уже готовые решения (например алгоритм скрэмблирования 8 бит в 14 для CD дисков).
С другой стороны, компакт диски, в отличие от аудикассет, не могут быть изжёваны, не могут иметь вырезки, поэтому здесь тоже надо думать.

Тогда необходимо все данные представлять следующим образом:

- Каждая программа состоит из нескольких блоков
- Весь файл, записанный на аудиокассете представляется в виде блока
- Блок бьётся на элементы
- Каждый элемент выделяется синхрозаголовком (длинная еденица и длинный ноль, их комбинации), а также сопровождается контрольной суммой
- Каждый элемент имеет уникальный номер
- Обязательно следуют друг за другом два (или более, в зависимости от требований надёжности) элемента с одинаковыми номерами. Если один элемент вдруг запорчен, то другой может быть считан. Уже считанные элементы естественно повторно не считываются.
- Каждый байт представляется в виде 14бит данных.

Подсчитаем:
- 1бит имеет длительность около 1000 тактов обслуживания (эта цифра является определяющей, от неё зависят все остальные выкладки, если её уменьшать, то увеличится скорость загрузки, но уменьшится надёжность и наоборот)
- 1 байт записывается в виде 14 бит, итого около 14*1000=14000 тактов
- В секунду умещается 250 байт "чистыми", при использовании синхрозаголовков и контрольных сумм это число будет на 10-15%% меньше, итого - около 220 байт
- При записи дублирующих блоков эта цифра будет уменьшаться пропорционально количеству дублтирующих блоков (для 2х - 110, для 3х - 70 и т.д.).

А что получается неплохо...
Неразрешимая загадка

[Conan]

Конечно счаз правды не "нарыть", но мне так кажется, что ПЗУ SOS для ZX писали сторонние от (С) Sinclair Research ltd программисты, и скорей всего после выпуска первой версии ПЗУ (в которой поддержали аудиокассеты как недорогую альтернативу более надёжным носителям) планировалось в недалёком будущем отходить от касссет и идти на более другие носители (которые кстати и появились лет через 5). Однако потом, после того как практика показала что фирмы разработчики напрямую работают с SOS пришлось отказаться от этой идеи, что скорей всего и подвигло к разработке 128КБ машины с теневым альтернативным ПЗУ с сохранением в целях совместимости старого ПЗУ.

Очень оригинальный взгляд на историю Speccy.

ROTFL! Честное слово.

Могу лишь сказать, что правду «нарывать» не надо, поскольку есть вполне доступные и достоверные источники, тот же самый WOS и Planet Sinclair. Это к вопросу об авторах и планах при разработке встроенного ПО Speccy.

А если тебя всё же интересует, как же её можно реализовать (отказоустойчивость т.е.), то можно использовать уже готовые решения (например алгоритм скрэмблирования 8 бит в 14 для CD дисков).

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

[Paul_ls]

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

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

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

[Conan]

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

А вот это уже наверно ближе к истинным причинам, рассинхронизация при чтении - еще одна причина сбоев. Кстати длинный пилот тон появился в ZX Spectrum. В его предшественнике (ZX81) пилот тона практически не было. Но опять же существуют (не знаю точно, насколько были распространены в начале 80-х) алгоритмы и методы автосихронизации при чтении данных. Хотя наверно их реализация в совокупности с коррекцией ошибок была неоправданно сложна и ресурсоемка (например, размеры буфера в ОЗУ). Впрочем, все это только предположения.