FLASH-картридж на 29ЕЕ010 для УКНЦ.

[troosh]

MM, в таком видео оно еще менее нужно чем в виде классического картриджа ПЗУ. Только если 512К х 16 туда запихать с полноценной ОС со всеми сервисами, языком, терминалкой на РС и прочим чтобы было не просто "вещью в себе", ну и часами RTC до кучи.
Но тогда больше смысла делать на современных микросхемах чтобы оно еще и позволяло на себя файлы записывать.

Ещё есть симпатичные eeprom-ки M27C322 на 4 Мбайта с 16-ти битной шиной, раз уж 2 Мбайтые флешки не заинтересовали. На Али чуть дороже, но всё ещё меньше бакса штука, если брать десяток. Жаль только 42-х пиновых ZIF сокетов не наблюдается там.

Кстати, а во времена магнитных лент была ли проблема их износа и как это решалось?

[Advertiser]

[svinka]

Кстати, а во времена магнитных лент была ли проблема их износа и как это решалось?

Решалось дополнительными копиями в ВЦ. 3 копии за последние из каждых 3 дней
на субботу и воскресенье все равно делали бекап. тогда до 5-ти дней
на длинные праздники до 10-ти
был регламент. Как я помню одна из трех лент хранилась еще несколько месяцев

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

[troosh]

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

Я не про бэкаппы, а про запись конкретного файла на плёнку... После записи проверяли? Если сбой, то файл переписывали полностью? Учитывали как-то что данный конкретный кусок плёнки столько-то раз считали/записали? Как это поддерживали файловый системы того времени? Можно ли подобные механизмы использовать для потенциально ненадёжныз флешек?

[Hunta]

Я не про бэкаппы, а про запись конкретного файла на плёнку... После записи проверяли? Если сбой, то файл переписывали полностью?

С одной стороны - лентопротяжка вместе с контроллером контролировала качество записи и могла выдать ОшибкаЗаписи.

С другой стороны, при получении данного статуса, ОС могла (через драйвер) выдать команду - точно не помню, как она правильно называлась, поэтому назовём её - ЗаписьСРасширеннымПромежу тком. При записи на ленту между блоками делается небольшой промежуток (ЕМНИП память, порядка 1-2 см) - что бы учитывать старт-стопный основной механизм работы тогдашних лентропротяжек (правда, если программа успевала подогнать очередные данные вовремя - лента могла и не останавливаться - видел неоднократно), соответственно при ЗаписьСРасширеннымПромежу тком контроллер делал бОльший пропуск (который, насколько я помню, зависел от того, сколько было пропущено перед этим - то есть каждая попытка ЗаписьСРасширеннымПромежу тком давала больший промежуток. Так обходились сбойные участки ленты.

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

Учитывали как-то что данный конкретный кусок плёнки столько-то раз считали/записали?

Никакого учёта в известных мне системах на то время - сколько раз данный конкретный участок ленты считывали-записывали не велось.

Как это поддерживали файловый системы того времени?

Опять же, в известных мне системах на то время - никак

Можно ли подобные механизмы использовать для потенциально ненадёжныз флешек?

Вопрос риторический?

[svinka]

После записи проверяли? Если сбой, то файл переписывали полностью?

Структура ленты такая что на ней лежат файлы последовательно. Один за другим. Как на кассете для бытового компьютера. И для распечатывания содержимого ленты нужно считать всю ленту. Хорошие лентотяги делали это с перемоткой или на увеличенной скорости. Если на ленте файлов 10 а вам захочется записать после второго то если размер превысит третий то пропадет и четвертый-и может быть другие

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

Но ленты были очень надежные так как импорт плюс достаточно низкая плотность записи при очень чистой гермозоне

- - - Добавлено - - -

На сбойный кусок можно было попробовать залить фиктивный файл типа бэда. И использовать дальше