Hard Как считать данные с дискет 5,25" на современном PC?

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

В этот раз не пробовал, только по профилю с секторами. В прошлый раз "бесформатный" образ у меня нигде не прочитался, - может, ещё в следующий раз попробую.
Правда, и этот с секторами тоже нечем сконвертироать. Ни GW, ни HxC, ни FluxEngine не умеют сохранять в ATR/ATX - почему???
Руководство к "Гризвизле" почему-то считает, что "Atari 800" - это IMG. Однако эмуляторы такой формат ожидаемо не понимают.
А та утилита A8RawConv тоже не хочет работать - жалуется, что нет Track42. Он разве бывает?
Ну, это всё вопрос теоретический, - первая сторона благодаря вам успешно сконвертирована
Второй пока нет - и вряд ли будет.

Так а сзади оно разве не одинаковое?

Какая запись? Плохие сектора появляются при уже форматировании, их никак не обойти.

Марку "ИЗОТ" ни разу у нас вживую не видел (только 8" и на картинках). Это что-то болгарское?

Попробовал вчера записать копию защищённого диска из флюксов - не сработало
Флюксы, правда, чужие, но - точно рабочие! А записанная дискета - нет, и её флюксы тоже уже неправильные. Все файлы на месте, но защита на бонусных дорожках типа 40.0 при записи, похоже, портится.
@SanTix, не подскажете, с чем это может быть связано? Не с тем же, что флюксы - от "Криофлюкса", а я пишу "Гризвизлой"?
Нестроек вроде бы тоже особых таких нет для записи... Дискета хорошая - если где попадается плохой сектор, то "Гризвизла" сразу выдаёт ошибку проверки и прекращает запись.

--- добавлено 24 фев 2024, предыдущее сообщение размещено: 24 фев 2024 ---

Разобрался: сконвертировал через HxC из RAW в SCP - и тут уже A8RawConv сразу и справилась!
Правда, мой новый ATX вышел на 100208 байт, тогда как у @SanTix (из моего старого SCP) - 97760 байт. Но работают обе версии одинаково и без проблем! Т.е. до требования перевернуть дискетку.

 

Нет, не бывает на обычных дискетках, хотя дисководы и поддерживали по 42 дорожки, но это последняя дорожка - 41. Но тут дело может быть в том, что образ снят на 42 дорожки, а данных там нет, вот утилитка и ругается. Хотя на том образе первой стороны тоже пара пустых дорог и всё сконвертировалось нормально. Хотя я уже не помню абсолютно точно, возможно я этот образ перед конвертацией обрабатывал.
ИМХО работа с форматом Атари 90 в GW и подобных вещах не для эмулей, а для копирования дискет. С нужными форматами именно A8RawConv и умеет хорошо работать, вроде бы она на сегодня лучшая и она развивается, что тоже неплохо.

Возможно будет, если удастся что-то придумать или найти дисковод, который работает в таком режиме. Можно даже и 80 дорожечный попробовать, т.к. качество записи хорошее. Ни один из ваших флопиков не умеет считывать в этом режиме? Проверено?

Нет, конечно! Спасибо за фото: на 99%, был уверен, что увижу именно такую запайку, тут даже видно саму структуру пластика (чуть более шершавая, чем обычно) и полукруглы торцы Обычно в таких дискетах диски очень хорошего качества, вероятно или 3М или Вербатим или что-то выпущенное под их контролем. Такие диски, обычно, чуть прозрачные - видна спираль лампочки накаливания сквозь диск. Но это именно сборка + диски в сочетании, которое у фирменных распространённых дискет не встречается, вероятно сборочные линии не американские, а делались где-то в Европе. Дискеты с такой запайкой очень часто были в "балках" без этикеток. Но и к нам завозились во времена СССР, например из таких были сделаны "наши" Energo Informatica, путём наклейки этикеток и фасовки по коробочкам. Но эти мы хоть фасовали

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

Формально - да. На деле, что там делали болгары самолично и на каком оборудовании и из каких материалов - на 100% точно неизвестно, но даже конвертики были импортные, явно не сами болгары клеили (особенно из "шелковки", у них и бумаги-то такой не было). ИЗОТ делал всю номенклатуру 8 и 5.25 дискет, даже HD были в 90-х, но это - редкость. Также они были и под разными марками, в т.ч. "ноунеймовские" "Mini Disk" с белыми бумажными этикетками.

Сложно сказать наверняка, но работать должно. А откуда Вы знаете, что флюкс-файлы рабочие 100%? Эмули же с RAW не работают. А если рабочие обработанные образы, то с них и нужно писать, т.к. они дадут лучшую запись - с флюкс-файлов записываются и помехи и несовершенство считанной записи. Это как перезапись музыки по нескольку раз. С флюксов имеет смысл писать, если расшифровки не получаются, а запись с необработанных образов, как раз работает.

Да, я работал через SCP тоже. У автора программки вроде нет CF, формат он добавил по просьбам владельцев оного уже в первых версиях, но, видимо, какие-то образы работают неправильно или нужно вводить ключи в командной строке при конвертации, т.к. RAW потрековый и не содержит никакой информации о числе сторон и треков на сторону.
Разница в байтах - не беда - вероятно различия в конце треков, а там "мусор" при разных считываниях чуть отличался.

 

Да нет, снят как обычно, 0-41. Видимо, у этой утилиты и правда неполная поддержка RAW.

Разве? Она же с 2014 года не обновлялась? По крайней мере, я новее не нашёл.

Проверил только два, как говорил: Chinin и TEAC. Но если этот TEAC не читает, то другие три той же модели тоже вряд ли будут.
Остались только пара Mitsumi/Newtronics и один Safronic - их не проверял, но они и сами плохо работают, почти не читают.
Хорошо читает ещё Y-E DATA - может, его как-нибудь тоже попробую (но он в другом ПК стоит, его оттуда доставать долго).

Понятно

Эти мои - точно из США недавно приехали.

Так ведь GW не будет записывать образ хоть с одним плохим сектором, сразу прекращает запись.

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

Такие вроде бы видел, да.

Так из них же сконвертированы рабочие образы. Плюс специалисты сейчас тоже глянули и проверили.

Не получится: рабочие обработанные образы - это TC. А чтобы его записывать, нужна OptionBoard, которой у меня нет...

 

Версия 0.95 выложена в октябре 2023 - a8rawconv, a new raw disk conversion utility

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

Значит, возможно, линия всё же из США или, напротив, европейская линия была поставлена в США. Специфика вопроса в том, что производители дискет, кроме IBM и 3М, разве что, не обладают, обычно, навыками и наработками по выпуску производственных линий по выпуску чего-либо крупносерийного. Такие компетенции у совсем других фирм, большинству о которых даже ничего не известно. Тут, как раз такой случай. Притом сами магнитные диски делались на других линиях и производителей оных было намного меньше, чем производителей дискет, но одни и те же диски могли устанавливаться в очень разные конверты и напротив некоторые фирмы, которые занимались чисто сборкой дискет могли в принципе закупать диски и не у одного поставщика, а на рыночных условиях. Особенно если дискеты были откровенно бюджетного класса. Отсюда и сильная разница в сохраняемости. Но те же Энергоинформатика - очень хорошие. У меня их разных десятка четыре и подавляющее большинство их них сохранились идеально.

Это не совсем так - можно поставить многократную верификацию. Суть проблемы в том, что запись-то, зачастую, происходит сносно, а вот чтение - гораздо хуже. После трёх верификаций GW прекращает запись образа. Если поставить сотню, то многие дискеты через 10-15 ретрейнов проходят дальше. Причины могут быть разные, но примерно 2/3 дисков с неустойчивой записью после многократных попыток их записать начинают работать лучше. Если сбои вызваны именно повреждениями, то нет, конечно, но если дефектов не видно, то должна быть в чём-то причина неработоспособности, т.к. даже ощутимо царапанные и даже немного мятые дискеты хорошо отстроенным дисководом пишутся на-ура. Я некоторое время экспериментировал с таким нестабильными дискетами и сейчас храню несколько, которые "натренировались" и стали писаться без сбоев. Хочу посмотреть, что будет с ними через пару лет.

Не исключено, что это не плесень. Какие-то продукты гидролиза или, что-то в этом роде. Т.е. это выделяется из диска или внутреннего конверта из нетканного материала. Полиэтиленовые конверты не подвержены распаду в столь краткие сроки.
Ещё я заметил, что если вскрыть некоторые сильно сбойные дискеты с признаками деградации плёнкообразующего магнитного лака, то часто можно видеть желтоваты налёты на белом ворсовом слое, будто бы они слегка закопчены дымом или, что-то в этом роде. Желтизна ближе к краям. Но это, разумеется не дым, т.к. многие такие дискеты были у меня по 25-30 лет и до этого они были или новыми или рабочими и без этого "копчения". Но я встречал и на дискетах, которые хранились не у меня такое. Например в каком0нибудь институте. Притом прокуренными они быть не могли, т.к. и не пахли и коробки были чистыми и вперемежку были дискеты совершенно годные без признаков существенной деградации.

Чем запись с помощью OptionBoard принципиально отличается от записи с помощью GW? Вопрос в том, что flux файлы содержат много лишнего "мусора", реальных импульсов, которые нужны контроллеру FDC, даже с учётом защит на них 1%, а то и меньше. Это похоже на скан текста с разрешением 3000 "диоптрий", где хватит и 200. Такая избыточность нужна для всяких хитрых расшифровщиков, чтобы точно не пропустили нужные данные. Тут имеем уже расшифрованные данные. Запись с такого источника, конечно, будет лучше.
Но т.к. GW не работает напрямую с TC, насколько я понимаю, то нужно преобразовать его в SCP, например, первое же гугление даёт вот такой конвертер - How to convert .tc (Transcopy) or .raw (Kryoflux) to .scp format. Если можно конвертнуть TC в TD0 (вроде схожие форматы), то GW умеет напрямую писать с него. SCP после конвертации из TC будет уже не тот же, что после считывания с дискеты, он будет "идеализированным", так сказать. Копирование через потоковый файл не всегда работает, т.к. последующая запись требует какой-то обработки и непонятно, как софт GW её выполняет (хотя это опенсорс и можно попробовать разобраться, но это нужно получше знать программирование, вроде там софт на Питоне написан, а я имею о нём лишь самые общие представления), если считанный сигнал был далёк от идеала, то копия может и не сработать. Сама по себе физика-электрика работы GW на 99% такая же, как и у других подобных плат. В сущности это не совсем FDC, а скорее аппаратный генератор/считываний импульсов с программным управлением, плюс умеющий работать с сигналами управления флопиком, но тут уж ничего сложного нет.

--- добавлено 24 фев 2024, предыдущее сообщение размещено: 24 фев 2024 ---

Я пока не могу починить свою GW. А так бы мог проверить. Попробую попросить знакомого программиста, чтобы он прошил мне платку и переслал по-почте. Что-то китайцы с очередными платами слегка намудрили или ревизия чипа чуть другая и требует пересборки бинарника. Флоп я к своему ретро-компу, вроде, прикрутил. Можно было бы проверить. Правда это не очень древнее железо - первопень с ММХ., древнее пока нет в собранном виде. В мдеале хочу одноплатники на полу-ISA PC-картах, как этот первопень ещё и на 386 и 486, такие есть, только редкие и дорого Тогда можно по сути иметь один ретро комп в корпусе и менять там процессорные платы по мере надобности.

 

Спасибо!
Пригодится, если вдруг удастся вторую сторону считать

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

А нет какой-либо информации по дисководам: вот, мол, такие-то и такие-то модели точно поддерживают fake-index?

Можно, наверное. Но зачем? Чистые 5,25-дискеты пока ещё не такая редкость, чтобы рисковать записью на потенциально нерабочие. Да и нужно мне их сравнительно немного - скорее для пробы (всё-таки массово заменять дефективные фабричные пока не планирую из-за вопроса с неидеальной переклейкой этикеток), продавать-тиражировать подделки я тем более не собираюсь

Вполне возможно - я не химик и пробы не брал.

Прежде всего - редкостью и стоимостью OptionBoard!
Да и наверняка отличается технология 1980-х от технологии 2020-х.

Так а зачем? Если я эту TC сделал из RAW, зачем мне её обратно перегонять?
Впрочем, один зарубежный эксперт мне сегодня тоже такое посоветовал: мол, пересохранить RAW в XML, а потом XML обратно в RAW. Но - нет, не вышло: TC из нового RAW уже нерабочее оказалось, в отличие от оригинального.

Теоретически можно, да. Но у меня, как правило, всегда получается конвертировать TD0 в TC, а вот обратно - уже очень редко.
Впрочем, у меня есть и другие образы оригинала - тот французский коллекционер, который снимал флюксы, больше по другим платформам специалист, так что помимо обычного RAW он прислал ещё и DSK, IPF+IPX, IMA и один непонятный формат. Расширение тоже RAW - не глянете, вдруг признаете, что это такое?

А что с ней такое?

Ну, у меня на таком YE-DATA отлично работает. Так что может и хватить!

 

Важно понять какие типы дисководов будут корректно работать с fake index. Дискету можно и отдельно для этого теста записать. А уже потом найти такой дисковод, но рабочий или починить имеющийся. Вот, что имелось ввиду. Судя по всему не так много дисководов пригодны для этого, но я пока так подробно этот вопрос не изучал.

Это были просто мои опыты в рамках изучения GW и поведения старых дискет

Наверняка новые платы лучше и считывают больше импульсов, чем более старые. Это чисто технически, софт и расшифровка "сырых" образов в рабочие - другое дело.

А вот это уже интересно. Если RAW конвертируется в ТС и он работает на эмуляторе, а записанная дискета в нативе не работает, то это вопрос, возможно не к железу, а к софту. Но вообще интересно. Нужно побольше, видимо понимать в самой защите, как она работает и почему портится метка при записи.

Можно, но пока без записи - писать-то мне пока не на чем.

В один момент просто перестала инициализироваться. Видимо на этот раз контроллер сдох наглухо. Перепрошить тоже не вышло. Я попросил знакомого купить ещё парочку и прошить, но обстоятельства сложились так, что ему было слегка некогда по семейным делам, да и я не упорствовал. В итоге он эти платы так и не прошил и увёз в Питер. Сам я их прошить не смог, там какие-то отличия и готовые скомпилированные прошивки не всегда встают. Но теперь платы и в Питере, а я в Красноярске У меня GW F1, т.к. платы под них можно купить тут на месте, а с доставкой "оттуда" V4 сейчас сложно, так было проще. Работают они примерно одинаково, вероятно даже можно скомпилировать прошивку от одной версии к другой, но это задачка для программистов, я не осилю. В итоге пока застопорилось. Сам GW у меня сделан в виде переходной платы, куда ставятся прошитая отладочная плата с STM, если она отказывает, то её можно поменять без пайки одну на другую, но на данный момент просто нет у меня рабочих. Т.к. не горит, то я пока и жду, мне всё равно пока некогда плотно этим заниматься. Если время появится, то куплю ещё пару таких платок и попробую ещё разок прошить сам, благо сами эти платки стоят не как GW V4, они совсем дешёвые - около 200-250 рублей оффлайн, а если на Али заказать, так и ещё раза в полтора дешевле.

Да дисковод-то работает. Вопрос в том, как отнесутся игры к моему P1-266 MMX. Например, на нём есть "ошибка 200", как на всех пеньках 200 МГц и выше. Даунклокнуть его не получится, нет ни перемычек ни в биосе настроек - он припаян к материнке. Но я могу попробовать на эту ёлку поставить другую плату CPU и ISA мультикарту и должно тоже работать. Например на Геодах, нет этой ошибки. Но большинство досовских игрушек идут, вроде

 

Парадоксальная ситуация проблемы, о которой все говорят, но которой на самом деле, давно не существует. Это ошибка не железа, определённых версий компилятора софта. Наверное, только на одном лишь old-dos.ru можно найти штук пять удобных в использовании из командной строки утилит для фикса "ошибки 200" в исполняемых файлах раз и навсегда. Это я уж не говорю про зарубежный сегмент интернета. Более того, если нет доверия к готовым утилитам можно самому всё поправить, вооружившись хекс-редактором и терпением.

 

Проверил YE-DATA (пусть и не на атаришной дискетке, а на обычной самописной, какую не жалко) - бесполезно, дорожки не видны

Да, хорошо бы. Но это нужен кто-то с десятками и сотнями моделей в коллекции! Или форум соответствующий с десятками специалистов, - возможно, где-то и собирается такая информация?

Я не уверен, что у карт 1980-х вообще методы работы такие же, как у новых "контроллеров".
А ПО - понятно, что совсем другое дело. OptionBoard только копировала, про эмуляцию тогда и не думали, - да и драйвера у неё разные на каждую версию. Говорят, в зависимости от того, кто из издателей последним выдвигал претензии

Возможно. А возможно, что проблема с конвертацией никак не связана с проблемой записи. Могу только предположить, что проблема в "нестандартности" дорожки с защитой. Её и не считать обычным образом, как мы раньше уже говорили, т.е. принудительно выставить tries не получится. Может, и с записью что-то не то - например, проверка неправильно работает.

Конечно, запись пока не нужна, - просто интересно, что это за формат?

А других аналогов, типа SCP или настоящей KF, у вас нет?

А, ну это зависит от того, какие игры нужны Некоторые древние у меня и на 386 с отключенным Turbo не идут нормально.
Но вообще - конечно, как минимум от начала 1990-х и на "Пентиуме" должны без проблем все идти.

Кстати, уточню, что речь о 5,25 дискетках, - моим самым первым ПК в 1993-1998 гг. был ноутбук со встроенным 3,5-дисководом, так что хотя я и подключал к нему внешний 5,25-дисковод (нынешний TEAC), но пользовался куда чаще 3,5-дискетками. Их у меня намного больше! Где-то около сотни. Хотя статистика выхода из строя примерно такая же: от частого использования и Sony, и Verbatim, и советские "ГМД-90" портятся довольно-таки часто и примерно одинаково.
А есть люди, которые пустые дискетки собирают! В основном - 5,25, и явно ради разных красивых этикеток.

 

Я не видел, правда целенаправленно очень уж тщательно и не искал. У меня такие дисководы есть, но, возможно, ещё какие-то из тех, что не проверял тоже заработают.

Да нет, я думаю, что она точно считывается flux контроллерами, но вот потом нужно бы её обработать, чтобы лишнего не было, особенно если метки на срыв синхронизации. Или есть метки на точный подсчёт импульсов, т.к. FDC считывает иначе, flux контроллеры могут давать сбои. Думаю тут нет совсем уж универсального подхода, но потенциально у них возможности считывания и записи НАМНОГО превышают возможности микросхем FDC, а большинство защит писались таки под них. Я бы начал эксперименитровать с отключения revs., т.е. без дублирования. Но это чтение, а тут запись не работает.

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

Нету. Криофлюкс я хотел купить когда-то, но т.к. там какие-то ограничения на запись, то потом раздумал. Мне ведь не только чтение интересно, мне интересно исследовать и процесс записи.

Был и отечественный контроллер "линк", на ту же тему, но на сегодня GW выглядит привлекательнее всего, т.к. проект открытый и он развивается разными людьми, т.е. меньше риска, что кому-то надоест и он всё бросит. Можно было сделать и fluxengine, но смысла особого нет, т.к. он работает так же, как и GW.

--- добавлено 25 фев 2024, предыдущее сообщение размещено: 25 фев 2024 ---

Слышал о таком, сталкивался когда-то сам на Борландовских компиляторах для Турбо Паскаля (а может и для Си, не помню уже) но факт, что тот же Madspace на пеньке не идёт, если он более 200 МГц, а вот на Geode LX запускается без проблем, даже если там 500 МГц. Почему так? Может всё-таки сочетание ошибки в компиляторе и процессоре?

 

Так а какие это?

Так ведь проблема в записи, не в считывании?
Так, из оригинальных флюксов IMA получается на 373760 байтов - с защитой на "бонусных" дорожках. А из копии - уже стандартные 368640: защита есть, но не в том месте, где нужно!

 

Шугарты, например. Старые Тики. Роботроны сделаны на базе старого комплекта микросхем Тик тоже работают, но они 80-дорожечные.
Это из того, что точно работал. Появится снова у меня GW и я смогу проверить ещё несколько дисководов, которые у меня сейчас под рукой. Но в основном это всё 80-дорожечные. Есть пара советских 40 дорожечных и один односторонний Роботрон, они вероятно, тоже заработают, но я не думаю, что Вы будете с ними связываться, с учётом того, что они, обычно требуют, ремонта или настройки и там даже интерфейсные разъёмы все нестандартные и у каждого они свои.

Но ведь копия тоже проверяется через считывание? Ещё интересный вопрос - запись с флюксов копии, стабильны ли такие копии из других копий (многократное копирование) в итоге, хоть и неправильные? Если стабильны - это проблема, вероятно, в софте. И я не понимаю по поводу 360 кБ - Вы копируете с чего? Я себе представляю это, как запись с RAW на диск (он, как я понял, не работает на нативном железе), потом считывание в RAW/SCP, затем распознавание в TC. Так? Тогда и не будет работать, т.к. второе распознавание точно без гарантии, т.к. и дискета не работала и софт по распознаванию не знает, как правильно распознавать ключевые метки, он распознал в стандартном формате или во всяком случае в понятном ему формате. Вопрос почему не работает копия с рабочего RAW, которой, я так понял, при конвертации в TC работает в эмуляторе? Я бы попробовал сконвертить потом этот рабочий TC в SCP и записать с него, а не RAW, т.к. SCP, как и TC содержит информацию о формате дискеты, где какие секторы расположены подорожечно, а RAW - нет. Поэтому GW и мог записать ключевую метку не там, где нужно даже если скопировал он верно.

Не в том месте - это как? Не на той дорожке или не на том секторе, межсекторном промежутке? Если на другой дорожке, то моё предположение выше.

 

Ну, такой древности у меня нет - и вряд ли получится достать.

Не только - главное же то, что она проверяется через запуск.

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

Что, куда? В данном случае - как я говорил, с точно рабочего RAW, снятого владельцем того самого диска, который у меня повреждён, - на пустую дискету.
Правда, тайванський эксперт считает, что все эти мои проблемы - не от ПО, а от того, что дискету перед записью нужно размагнпитить или хотя бы расформатировать/очистить. Тоже надо будет попробовать...

Так и есть.

Так ведь это уже детали? Как по мне, так сама идея RAW - в том, что из него можно записать копию, с 99,99% вероятности сохраняющую все особенности оригинала, включая защиту. Все известные мне специалисты именно так и делают, проблем практически не должно быть.

Как я говорил - все файлы в порядке, но "экстра" дорожки с защитой не совпадают:

 

Попробовал - не работает Всё то же самое.

Попробовал - не работает
Только SCP я сделал из RAW через HxC - TC же не он, не GW не открывают.
Но, похоже, SCP вообще не сконвертировалась - при его записи просто пустые дорожки.

Насколько я понимаю, проблема в том, чтоб при выборе RAW GW пишет его как обычный формат IBM360 - игнорируя "неожиданные сектора" с защитой на 39.1 и полностью игнорируя дорожки 40/41. Понятно, что выходит дискетка без защиты.
А если писать бесформатно, то и секторов никаких нет...
Непонятно.

@SanTix, и сконвертировать TC в TD0 у меня таки не получается. Может, не так конвертирую? Ибо TD0 в TC как раз всегда работает (как и запись "Теледиском" на реальные дискеты).
(Конвертирую, если что, командой: pri -p encode mfm-dd-300 disk.tc disk.td0)

Кстати, подумалось: возможно, дело ещё и в социальном статусе владельцев
Я с этим сталкивался, когда до игр собирал грампластинки. Т.е. оперная пластинка, которая в 1905 году стоила 5 рублей, в среднем демонстрирует намного лучшую сохранность, чем пластинка эстрадная или танцевальная, которая в том же году стоила 50 коп.
Так и здесь: игры от Infocom покупали богатые американские интеллектуалы, хранившие их бережно в пристойных условиях, тогда как бюджетные аркды покупали люди менее состоятельные и аккуратные, хранившие игры в подвалах и на чердаках.

 

Через запуск образа на эмуляторе?

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

Тут многое зависит от самой структуры ключевой метки, в HEXе может быть и не видно особенностей и сами по себе данные бывают и не являются основой защиты. Есть защиты на хитрых срывах синхронизации. Т.е. если дискета в этом месте в принципе читается и читается одинаково, то метка считается скопированной и защита активируется. Если же метка наоборот считывается нечётко и всё время по-разному, то попробовав её так читать неоднократно защита признаёт метку подлинной. Тут случай похож на такой. Вопрос с том, как это может эмулироваться через ТС? Мне это не совсем понятно. Возможно это делается функциями самого эмулятора и тогда понятно, что он работает, т.е. он по образу понимает, что тут защита и эмулирует её работу. Тогда нужно ещё понять, раз RAW верный, то почему он плохо копируется? Этот RAW сырой, не обработан? Вы его писали в unspecified format, "as is", без обработки и упоминания формата, вроде IBM360 в софте или командной строке GW? Если не as is, т.е. запись "импульс в импульс", то понятно, что он не работает, т.к. синхрометки записываются в межсекторных промежутках, а GW в этом формате просто выкидывает лишнее и пишет только данные из секторов со стандартными межсекторными. А т.к. разметка нестандартная в образе, то он может и не понять где тут данные, а где межсекторные и то, что Вы видите в HEXе может и не иметь никакой практической пользы. Мы возвращаемся на несколько страниц переписки назад, по-сути - успешное воспроизведение работы защиты не гарантируется, если нет понимания, как данная конкретная защита работает. Ведь сама защита это просто кусок кода, который проверяет метку или метки, успешно или нет. Теоретически прямая запись всех импульсов в "сырой" RAW или SCP без всякой обработки и потом такая же запись на дискету должна работать, т.к. частота оцифровки в современных flux контроллерах на порядки превышает возможные времянки, которые могли формироваться дубликатором или дисководом под управлением обычного FDC при записи софта для дистрибуции. Т.е. все эти ухищрения с многократным затиранием и перезаписью секторов с целью вызвать сбои синхронизации GW и им подобным не нужны, они могут записать нужные импульсы за один раз, да по-другому они и не умеют, они в принципе, работают подорожечно в отличии от FDC, посекторная работа которого была основной функцией, т.к. древние компы просто не могли за раз переварить дорожку целиком, это уже в более поздних FDC появилось, когда и защиты были на пике применения, впрочем, но ДОС считывает всё равно посекторно.

В сухом остаке - нужно "под лупой" смотреть не HEX, а в HxC растягивать сектор/межсекторник с защитой и смтреть импульсы.

У Вас нет, случайно, Готека, чтобы проверить этот RAW на нем? Хотя защиты основанные на срыве синхры он, вероятно, пролажает, т.к. он не будет давать разных результатов при многократных обращениях к меткам и защита сочтёт их скопированными. В теории железо Готека это может, но как он узнает, что в этом месте образа метка и нужно её обрабатывать не импульс в импульс а с "дрожанием" потока или, как-то ещё?

Мне кажется, дело может быть в том, что некоторые конвертеры распознают отдельные виды защит и ставят свои метки, которые потом воспроизводит эмулятор. GW не умеет работат с этими метками.

Вопрос ещё и в том, как конвертер рабочих образов определяет по RAW где метка есть, а где нет? Ну, допустим, это возможно. Но вот как он отделяет условно-рабочие диски от сбойных? Ведь Вы копировали в RAW свою дискету, где метки тоже есть, пусть и порченные и уже не работают в нативе, но конвертер-то работает на совершенно иных принципах распознавания меток, если они есть, и он должен был так же распознать в рабочий TC и вашу дискету!

Это вполне возможно.

--- добавлено 27 фев 2024, предыдущее сообщение размещено: 27 фев 2024 ---

Вот в этом и причина - HxC что-то всегда обрабатывает. В GW не пробовали? Или он не хочет конвертировать так без обработки в unspecified format? Любые установки атрибутов попортят защиту. Только перегонка "импульс в импульс". Такая конвертация возможна, хотя ис частота дискретизации не совпадает у CF и SCP, но избыточности хватит с головой. Но всё же непонятно, почему не работают записи "импульс в импульс" с того самого первого RAW? Или Вы их делали в каком-то формае, а не unspecified format? Тогда мы тут зря разводим теории - такие записи работать и не должны.

 

Это уже производное - главное не это, а запуск игры с дискетки.

Да, конечно.

Нет - как я и говорил, в этом, видимо, и проблема.

Нет, такого нет. Зачем Готек, если есть реальные дисководы?

Один специалист сейчас написал, что проверил - вроде бы всё работает через запись просто по команде "gw write --drive 0 track00.0.raw", тогда как FluxMyFluffyFloppy у меня выставляет формат. Попробую...

--- добавлено 27 фев 2024, предыдущее сообщение размещено: 27 фев 2024 ---

@SanTix, кстати, о сохранности дискет от Infocom и о хим. составе клея на этикетках.
Почему-то именно эти дискетки при всей своей надёжности демонстрируют пигментацию наклеек - из моих примерно в половине случаев.

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

 

Так, я запутался: что в итоге не работает? Запись импульс в импульс в unspecified формате? Или так ещё не пробовали?

Мало ли, не всем ведь нравится возня с флопиками. При наличии Готока можно было проверить RAW. Хотя у меня тоже Готека нет и я не уверен, что он нормально такие вещи эмулирует.

Да, да именно об этом я и говорил. Но можно и через GNU к GW c хорьком в шляпе на картинке, он тоже самое должен сделать при выборе верных настроек, что он в командную строку пишет при запуске GW он показывает.

Это зависит от конкретной бумажки и состава клея. Т.е. от партии к партии не приходится. Это не пигментация, в том смысле, что это не окраска, а лишь просачивание адгезива в волокна бумажнойнаклейки. Например на наших ГМД-130 может быть в одной пачке часть наклеек такие "остеклованные", а часть - нет. Хотя обычно или все остеклованные или все нормальные. Пропитывает в основном акриловый клей, каучуковый практически не подвержен этой напасти. Для уменьшения эффекта на этикетки наносился подслой краски под клей, но иногда его нет и такие наклейки 100% с акриловым клеем "остекловываются". Если подслой есть, но он с дырми, плохо накатан, то через них проникает и выходит вот такая пятнистая остекловка - случай с фото (акрил в клее точно есть, часть хороших, возможно чисто каучуковые, но если не отрывать - не узнаешь). Надписи наносятся с другой стороны этикетки - с внешней. На ней тоже покрытие и, обычно, мелованный оверкоат под маркировочную печать. Иногда она потом ещё ламинируется, но это не устраняет "остекловки", т.к. тонкие слои полупрозрачны. Хранение в тёпле первые годы после выпуска дискет способствовали усугублению этого явления, через несколько лет акрил полимеризуется и в наши дни он почти не текуч.

 

Попробовал - работает
Так что это я неправильно выставлял настройки записи. Видимо, привык, что FluxMyFluffyFloppy требует указывать формат при чтении и при конвертации. А при записи его как раз не нужно указывать!

А вот TD0 почему-то не работает Хотя защиту "KBI" оно обычно поддерживает, в отличие от weak bits.

--- добавлено 27 фев 2024, предыдущее сообщение размещено: 27 фев 2024 ---

А он разве поддерживает RAW?

А это как?

Т.е. хуже уже не будет, а если пятен вообще нет (спустя сорок лет), то они уже никогда и не появятся?

 

Не уверен на 100% т.к. у меня его нет, но вроде, впрямую не поддерживает. Да теперь и не столь важно, раз удалось разобраться, почему копии с рабочего RAW не работали, с обработкой они и не должны были работать я постаался выше написать, почему. Даже я почти догадался, что дело было в софтовых неполадках, связанных с конвертацией и запись "импульс в импульс" должна работать, если она способна конверитися в рабочие образы. Вот именно это мне и было непонятно, отчего такая копия вдруг не работала. Т.е. железо GW тут ни при чем и не важно на чем писать копии импульс в импульс, т.к. контроллер просто их передаёт на флопик, а далее уже всё зависит только от него. Есть свои нюансы в формировании импульсов, но тут они не важны.

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

С вероятноостью 99% всё именно так и новых пятен уже не появится. Старые также дальше ползти не должны, но на 1% можно отнести стабильные полимеры-пластификаторы вроде полиизобутеленов или подобное, могут быть в принципе разные соединения, которые теоретически могут ещё диффуднтировать. Но у меня есть пятнистые наклейки, которые были уже такими 15-20 лет назад и за это время если что с ними и изменилось, так некоторые отвалились вовсе, т.к. клей засох, а более пятнистыми они не стали. Но отваливаются и не пятнистые.

 

Ну да, так и делаю, - только это GUI, а не GNU

Это радует, спасибо за информацию!

Я почему-то такие пятна замечаю только у Infocom. Хотя вроде бы у LucasArts тоже попадаются.

 

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