Видак Panasonic NV-MV 20. Как-то внезапно сдох.
Выглядит так: сверху на картинке много мусора, кадры почти не бегут, картинку видно, но она ч/б и нестабильная.
Иногда часть картники закрывается чёрным прямогольником, как будто временно видиосигнал вообще исчезает.
Звук нормальный, не плавает.
Но что самое интересное: OSD меню: когда оно накладывается на картинку с ленты - вместо надписей чёрный прямоугольник.
А если открыть полноэкранное меню - оно нормально выводится, есть цвет, картинка стабильная.
Причем те буквы (бегущая строка рекламы), которые есть в записи, видны без проблем.
Записи, скорее всего, SECAM, но есть кассеты в видеокамеры - они, наверное, PAL. Но проблема общая.

<понемногу занимаюсь оцифровкой и вдруг такой косяк>
С видаками, сложнее замены прижимного ролика, дела не имел, они как-то всегда сами работали :)

Регулятор-понижайка напряжения (DC-DC, 30-50 вольт в 5 вольт, 2 а, flyback, в основе популярная 3842), самопальный, сдох внезапно. Был разработан и изготовлен в 2013 и вот, примерно в прошлом году, сдох. Эксплуатировался на e-bike, выдавал +5 для всяких видеорегистраторов и навиков.
Выгорели защитные зеннеры на выходе, в руках рассыпался силовой дроссель при попытке выпять.

И ещё обнаружился виновник: стабилитрон в feedback регулятора. Он должен держать 3.7v , но сейчас держит около 6v.
Т.е. не оторвался, не спёкся, а именно ушел по уровню. Рабочий ток около 4 ма. Стеклянный корпус, как у диодов д9.
Внутри S-образная пружинка видна. Скорее всего что-то из маломощной КС-серии. Две цветных полоски на корпусе.

Электролиты почти не пострадали, кроме одного, который совсем рядом с дросселем стоял (вспух, но по цифрам вполне живой).
Силовые ключ и диод тоже в порядке. Дроссель собрал новый, лит заменил, стабилитрон тоже.
Вроде всё работает.

Но вот не пойму: какой процесс происходил в этом стабилитроне так, чтобы ушли параметры перехода ?
Он не в обрыве и не замкнут, звонится как диод.

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

Сфотографировал там несколько интересных экспонатов, чтобы в дальнейшем про них почитать.

Сейчас вот разглядываю фотографию телевизора Б-2 с диском Нипкова. Вроде всё просто, но в большинстве упоминаний этого аппарата подробно описывается механическая развёртка и даже упоминаются фотоприёмники. А вот насчёт излучателя пишут мало. Но там же не просто лампа должна быть, а что-то быстродействующее. Поэтому лампа накаливания отпадает сразу.

И вот в википедии наткнулся на такую фразу: "(на практике часто использовались неоновые лампы, а в наше время — сверхъяркие светодиоды)". И очень я заинтересовался этим "нашим временем". Потому что вот сейчас, в наше время, телевизоры, в основном, больше на LED-подсветке с тем или иным ЖК-затвором. Вроде бы диск Нипкова уже и не используется, лет 80 как.

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

Разве что на видеохостинге, канал "История Вятки", есть видосик с таким действующим аппаратом и там изображение мало похожее на неоновое. Скорее как раз на светодиодное.

Почему бы не запрячь нейросеть в какую нибудь не очень точную или, во всяком случае, верифицируемую задачку?
Код какой нибудь неясной проги расковырять или написать что нибудь забавное или даже полезное ?
Ну пусть простенькое для начала.
Deepseek сегодня не работает, полезем в другую:
https://chat.qwen.ai

- Ты можешь написать клевую графическую прогу, которая бы выводила что нибудь динамическое на ассмеблере mos6502 ?

- Потри лампу и я тут же выполню все твои желания. Я прошла три класса и корридор начальной школы и пишу проги на 6502 как школьник-отличник! Уточни, для какой архитектуры будем писать и какой эффект ты хочешь ? Могу очистить экран или нарисовать какой нибудь узор ? А хочешь - запустим волну ? Смотри, какую клёвую прогу для сложения двух чисел я уже тут придумала ? Хочешь объясню подробно ? Вот смотри........ <и ещё несколько экранов текста>.

- Поменьше подробностей.

- А, отлично, давай напишу компактную программу .... <и ещё экран текста>.

- Хорошо! Давай я расскажу тебе сначала, как мы будем использовать видеоозу. Шестнадцатеричные числа я буду писать с префиксом '$'.
<описываю агатовский MGR>. А теперь напиши мне программу для эффекта волна.

- Отличный выбор! <вываливает вполне синтаксически приличную программу, которая что-то делает в видеопамяти, строк на 40>.

Начинаю разбираться: адресация к видеопамяти через индексную команду. И не очень ясно, зачем используются некоторые ячейки.

- Расскажи мне, зачем ты используешь ячейку $FC ?

- О, это древний клёвый способ сохранять регистры в памяти. Чтобы не сломались. Вот смотри: мы используем команду STX чтобы сохранить регистр X и LDX чтобы восстановить значение из ячейки. Это же так клёво и просто. Вот пример......

- Тогда покажи, где в нашей программе ты читаешь эту ячейку ?

- А, сейчас расскажу, конечно ! .... Ой, блин, сорри, реально, запуталась. Нету чтения из неё. Сейчас перепишем программу и будет чтение !  <выкатывает новую версию>.

- Хорошо. Теперь проверь, как ты работаешь с видеопамятью.

- Давай объясню. Я вычисляю адрес.... тут вычисляю... тут формула такая-то, например при значении координат таком-то будет такой-то адрес.... Ой, блин, точно, ошибка. Мы же не можем индексным методом все 8 кб обслуживать. Надо косвенно-индексный ! Сейчас всё перепишем. <прога пухнет ещё строк на 15>.

- А ты можешь её скомпилировать с адреса $3000 и выкатить мне bin-файл ?

- Не, ты чё !!! Я же не компилятор ассемблера ?! Ну ты чё ! Возьми что нибудь, cc65, например, вот ссылка и компилируй, вот команды. Давай я тебе перепишу прогу под этот компилятор <выкатывает ещё вариант>.

Компилятор ругается на то, что после меток нет ":". Исправляю, собираю, пробую в эмуле. Экран заполнен статическими синими полосками. Смотрю работу кода: по всем адресам расписывается в бесконечном цикле $E0. Т.е. что-то она считает, но получается константа.

- Я запустил программу, весь экран в синих полосках. Никакого движения нет.

- Давай проверим. .... О, точно, ошибки. Сейчас исправлю....

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

- Да, не вопрос, есть такая опция, давай я ей поставлю в нашу классную программу.

Пробую ещё раз. Компилятор ругается на неизвестную опцию. Расставляю двоеточия сам. Собираю, пробую.
Теперь весь экран в синих полосках, кроме точки в координатах 0, 0 - она чёрная.
Смотрю работу  кода - теперь проге лень даже адреса перебирать. Она пишет 0 в нулевое смещение, указатель не меняется.

Я час просидел. Кажется, если бы знал алгоритм, то свою версию бы уже закончил :)

Но интересно, конечно :)
Ощущение, что учишь школьника, который очень настроен на победу, но предмет сильно не осваивал.
Уверенность в себе на 100 процентов, ошибки готов признавать, но точно знает, что очередная ошибка будет последней и потом всё получится.

Встретил метки диска "rt60" и "decrt60". Гугление пока ничего не выдало на это.
Но расположение меток очень похоже на таковое для известной всем rt11a.

Есть подозрение, что это какой-то мод rt11.
Может быть, эту метку надо понимать не буквально, а как какой-то ID для определённой версии rt11 ?

Смущает то, что на диске не видно каталога. Даже в radix-50.
А вот какие-то обломки файлов видны,  в т.ч. исходники на ассмеблере с синтаксисом pdp/vax-11.

https://arstechnica.com/gadgets/2024/10 … ppy-disks/

МОНОЛИТНАЯ деталь карбюратора. По сути это шток кран-буксы, только здесь он для грубого дозирования воздуха.

Грани (1) - это для вращения детали ключом на 17. Прорезь (2) - для вращения отверткой.

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

На оригинале есть глубокое отверстие (4) - это не более чем особенности изготовления. На самом деле достаточно 3-4мм в глубину.

Какие вообще могу быть варианты, даже в теории?

Когда мы пользовались BIOS-загрузкой, как-то вопрос не возникал о разрядности кода самого BIOS.
Операционка получала проц в реальном режиме и могла переключить его в любой, нужный ей, режим.
Не было проблемы сочетать в мультизагрузке хоть MS-DOS с какой нибудь Win x64.

Но сейчас, когда UEFI окружает со всех сторон, я начал сталкиваться с некоторыми внезапностями.
Например, у меня есть планшет Thinkpad, который грузится в Win10, но не грузится в линухе как бы вообще.
Он был бы классным навигатором, если бы его GPS-модуль видел хотя бы больше 1 спутника.
Пока же он напоминает будущего донора аккумулятора для какого нибудь самодельного powerbank.
Пользоваться интерфейсом Win10 с тачскрином - тест на неконтролируемое бешенство.

Ещё есть брендовый дорогущий ноут от HP, который вообще не ясно, что хочет. У него есть больше десятка AMD-шных ядер и даже режим загрузки из файла (!), т.е. можно просто выбрать на старте EFI-файл и запустить его,
но по какой-то загадочный причине (он не сообщает о какой либо ошибке) несколько подсунутых ему файлов
не запустились (Secure Boot отключен). Едиственный трюк, которому я его успешно обучил - запуск линуксового grub2 с возможностью выбора между win10 x64 и debian x64. У него нет CSM, и вообще весь BIOS SETUP напоминает бюллетень по безопасности. При этом это скотина исхитряется, ИНОГДА, будучи выключенной, выжрать весь аккумулятор (к слову - не съёмный!) за 1-2 недели (починилось встраиванием обычного выключателя, который отключает аккумулятор вообще). Или, например, при выключении забыть отключить какой нибудь светодиод на клавиатуре.
У него классный экран, с регулируемым углом обзора (безопасность же!), но даже на максимальном угле смотреть киношки на нём хуже, чем на обычном TFT-монике 20-летней давности. Кстати, у этого ноута забыли сделать регулировку яркости дисплея без установленных драйверов (т.е. пока не поставишь СПЕЦИАЛЬНЫЕ дрова, яркость не регулируется).

Ещё есть дешевейший китайский ноут, у которого внутри материнка не больше компактного смартфона,
но который запускает очень многое.  Но, кажется, ему сложно запомить, что именно загружалось в последний раз,
и он всякий раз пытается запустить вшитую Win10. Зато у него 4 интеловских ядра, огромная eMMC в целых 32 Гб и небольшой дисплей с разрешением около 1900 x сколько-то там. И - главное - он в работе почти всегда холодный. Там и вентиляторов-то нет, только пластинка меди на проце. И аккумулятор в четверть корпуса (с маркировкой ёмкости, которая всего в два раза меньше, чем обозначено на корпусе ноута).

В общем, у меня возникла первая группа вопросов:
1) Может ли UEFI x32 запустить EFI-файл с x64 разрядностью или UEFI x64 запустить EFI-файл с разрядностью x32 ?
2) Может ли BOOTx64.EFI грузить 32-битную ОС и наоборот ?

В моих ноутах стоят процы Atom и что-то от AMD. Все камни определённо 64-битные.
Но похоже. что UEFI на Atom - x32 (пока я это предполагаю исходя из перерытых тем на разных форумах, где делаются попытка на подобной конфиге запустить 64-битную ОС). Как это надёжно определить ?

Ещё на одном десктопе, похоже что UEFI может грузить как BOOTx64.EFI так и BOOTia32.EFI. Или у меня глюки ?
Но там даже CSM есть, так что эксперименты получаются не совсем достоверными пока что.

{ Когда в последний раз ездил в отпуск, пришлось таскать несколько компов. Один хорошо лазит в интернет, зато другой идеально работает с агатовской темой. Очень хотелось бы объединить всё одной машине, но пока не получается }

Лет 30 назад многие, работавшие с Агатом, думали или мечтали о подключении к Агату жесткого диска.
Я тоже думал об этом. Цель была не столь в объёмах, сколь в надёжности хранения.
На PC уже появились винты по 100 мег и выше и отказывали оно уже довольно редко.

Но позднее, когда я стал узнавать о кодах восстановления данных и прочих интересных штуках,
то стал задумываться о том, можно ли было бы сделать флопики более надёжными, пусть даже ценой некоторой потери объёма ?

Например, на дорожках 840ки обычно есть 21 сектор, но нередко попадаются защищенные диски с 22 секторами на каких нибудь дорожках. Поздние драйвера, поддерживающие ленивое чтение, имеют буфер для полной дорожки. Если этот буфер чуть расширить и форматировать 22 сектора на каждую дорожку, то можно в лишний сектор запихнуть XOR'ку от остальных байт на остальных секторах.
Имея такой сектор, можно будет, при ошибке чтения одного любого сектора (но только одного!), восстановить этот сектор из оставшихся 21.

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

--

Но недавно мне подумалось ещё вот о чём: а как бы сделать возможность высокой надёжности загрузки операционки с флопика ?
Ведь первой работает прога в ПЗУ, там и так места мало, да можно ли обойтись там без модификаций ?

--

История развивается по спирали. Флопики были не надёжны, жесткие диски стали получше, EEPROM стали ещё получше, потом Flash-память, достигшая рессурса едва ли не в миллион перезаписей. Но потом, в погоне за объёмами, история вернулась к ненадёжными накопителям: современная многоуровневая флеш имеет рессурс всего около 3000 перезаписей. Вроде бы много - если сравнить с флопиком, но мало, если много прог пишут что-то одновременно, часто и, при этом, постоянно перезаписываются системные области.
Тогда возникла идея о FTL (не, она раньше возникла, просто о ней меньше говорили).  Flash Translation Layer - слой управления флеш-памятью, который пытается обеспечить равномерный износ ячеек памяти. Может быть организован как часть накопителя (свой контроллер внутри USB-флешки, SD-карты и т.д.) либо являться частью операционной системы (в этом случае используется т.н. RAW NAND - флеш-памяти без своего FTL).

Как работает FTL если совсем по простому: операционке нужно сохранить сектор номер 2. Она отправляет его на накопитель, там логика FTL решает: пишем в блок 12354, он сейчас свободен и отметит в своих таблицах, что сектор 2 сейчас сохранён в блоке 12354. А также увеличит счётчик износа этого блока. Если операционка снова запросит запись в сектор 2, FTL запишет данные уже в блок 12355 и отметит, что теперь сектор 2 сохранён в блоке 12355.

И вот именно этот вариант - когда используется FTL в операционке и RAW NAND в качестве накопителя - я как раз вспомнил в связи с Агатом. В чём интересное: как загрузить операционку с RAW NAND, если без операционки невозможно понять, где у тебя какой блок данных ? Т.е., например: операционка имеет начальный загрузчик в секторе 0, но в каком блоке RAW NAND находится этот сектор ?

Как это решается, например, в процессоре FreeScale imx6: ROM loader сперва читает блок RAW NAND номером 16 (точную цифру не помню, её можно уточнить в доках на проц). После этого он проверяет, что контрольная сумма блока верна и что блок имеет определённую сигнатуру. Если блок не прочитался (а реальная RAW NAND вполне может иметь несколько нечитающихся блоков даже при выходе с производства), ROM loader читает следующий блок и повторяет для него все те же операции.
Первый же блок, который будет иметь правильную CRC и сигнатуры, будет считаться загрузчиком.

В теле этого загрузчика уже будет находится что-то вроде "таблицы разделов" - это список регионов блоков RAW NAND, который будет передан ядру ОС. В соответствии с этой таблицей ядро уже будет настраивать свою подсистему FTL. Естесно, блоки, где хранится начальный загрузчик, не включаются в эту таблицу.

Как записывается начальный загрузчик ? Утилита записи, зная о ненадёжности RAW NAND, после записи каждого блока проверяет его чтением. Если блок не почитался (CRC не совпала), она повторяет запись той же информации в следующий блок.
Точно также пишется и ядро операционки, а также DTB-файл (описатель оборудования).
Всё остальное хранится уже поверх FTL, как правило, с использованием файловой системы UBIFS.

--

Возвращаясь к Агату:
ROM loader Агата работает похоже: он читает сектор 0/0, проверяет его CRC, если есть ошибка, он снова пытается найти и прочитать сектор 0/0. Поэтому, если создать примерно такой трек:
0 1 2 3 4 5 6 0 7 8 9 10 11 12 0 13 14 15 16 17 18 19
мы получим трек с трехкратным повтором сектора 0.
Так как ROM loader ищет подходящий сектор постоянно, он переберёт все сектора и те, которые будут иметь номер 0, попробует прочитать. Наверняка хотя бы одна из копий прочитается.

Можно также продублировать остальные сектора.

Интересно, что мне не встречалось в коллекциях агатовскго софта каких либо попыток повысить надёжность хранения данных на дисках программным путём, хотя, IMHO, это было вполне возможно. (Причем, например, для волковского архиватора 140кб дисков на 840ку - ввести какой-то подобный алгоритм было бы и не сложно и весьма полезно.)

Хотя эта тема на магнитофонах Спектрумов, вроде бы (поправьте, если я ошибаюсь!), вполне развивалась.

Описание: край пленки со стороны перфорации очень ровный (заводского изготовления). Второй край пленки получен в результате ее разрезания на ручном резаке, который НЕ обеспечивал достаточную точность резки. Поэтому там всегда, гарантированно, получалась "волна" с размахом в несколько долей миллиметра (примерно от 0,1 до 0,3 - в среднем 0,2 мм). Толщина пленки около 0,2 мм. При прокрутке такой пленки на советских киноаппаратах проблема не замечается, поскольку их фильм-канал и сам не очень точный, или сделан с заранее заданным дополнительным расширением.
При прокрутке такой пленки на японском аппарате для автоматизированного покадрового сканирования наблюдается повышенное трение пленки о стенки фильм-канала, вплоть до ее заклинивания в нем. Ширина импортного фильм-канала точно соответствует стандарту и (примерно) равна 8 мм (точные измерения требуют частичной разборки аппарата, поэтому не проводились).

Требуется: придумать метод и изготовить приспособление для ручной/ полуручной/ автоматизированной подрезки неровного края пленки.

Хотелки:
1. Сам аппарат (сканер) разбирать и модифицировать нельзя (по "политическим" соображениям).
2. Пленка не должна получать дополнительные царапины и загрязнения (все поверхности соприкосновения должны быть отполированы или использовать другие методы; пыль и стружка должны куда-то отводиться и не мешать дальнейшей подрезки "волн").
3. На пленке могут быть места склейки, места разрывов, места с нарушениями перфорации (трещины, надрывы, порывы и проч.) В таких местах при подрезке пленка не должна рваться.
4. Предпочтительным видится ручной метод протяжки пленки через приспособление. Мотивация: повышенное внимание к процессу, возможность остановить его при проблемах, без порчи пленки.
5. Хочется иметь возможность точной юстировки ширины канала подрезки (получаемой ширины пленки).
6. Хочется иметь возможность дополнительной заточки/ замены ножей, которые будут постепенно тупиться при больших масштабах работ.

Примечание: пленки имеют архивную ценность, им более 60 лет. Основа пленки пока достаточно эластичная, сама по себе не лопается, проверено механической протяжкой через два разных типа аппаратов с электродвигателями.
Всего пленок несколько десятков, каждая - от 5 до 20 минут записи. Это несколько сотен метров (5 мин = 15,84 м, всего в архиве около 1000 м пленки)

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

Хоть там в названии "цифровой телевизор", но это как раз для аналогового телека.
Видел обзор этой платы с примером переделки NTSC телека в мультистандартный: https://www.youtube.com/watch?v=MoqflFfvkR0

Прикольно, что в 2023 году такие штуки еще производятся

Если кто хорошо разбирается в шимках:
iru3037 - мелкий корпус soic-8, 400 КГц, синхронный PWM, управляет двумя внешними ключами.
Хитрое питание: отдельно на управление верхним ключом и отдельное на всё остальное.
В моём случае у неё на входе 12 вольт и питания объединены.

Сдохла на старом компе, ему лет 20 всего. Нашел её только на Али.

Немного удивлён: шимки, даже и синхронные, вполне в ходу и сейчас, чем она была плоха, что сейчас никто о ней не знает?
Или у неё имя сейчас сменилось и есть куча аналогов пин-2-пин ?

Прерыл свои заначки, но такого номера не нашел, хотя мои заначки включают больше 10 разобранных старых материнок и видях.

https://www.avito.ru/sankt-peterburg/or … 2429908560

Окошко индекса сдвинуто, окно для головы тоже непропорциональное какое-то...
Нет указания плотности.

Кто знает, что это за чудо ? может 8 дюймов ?