Просмотр полной версии : Чтение дисков без АГАТа
LeoN65816
25.08.2016, 19:25
Здесь (http://zx-pk.ru/threads/26887-dopozu-dlya-agat-9-novodel.html?p=883161&viewfull=1#post883161) Игорь озвучил мысль о реальной необходимости современного и мобильного средства снятия образов АГАТовских дисков.
Почитал о FM-, MFM-кодировании - "перевариваю".
"Нарисовался" такой вариант: флоппик без контроллера цепляем к девайсу на МК, читаем 4-5 раз каждую дорожку в сыром виде (RAW-битпоток) с привязкой к индексу и "выплевываем" через UART на COM-USB в PC. А можно извратиться и писать сразу на SD. Уже на PC анализ синхросбоев, бит-байт преобразование, анализ достоверности.
Советы/хотелки/критика/подсказки/обмен опытом приветствуются.
GARNIZON
25.08.2016, 19:47
О! Сейчашние мосты читают в EIM, обработка потом, это жутко удобно.
EIM-файлы - поток сырых данных, получаемых из регистра чтения реального дисковода. В поток органично вплетаются символы синхросбоя, метки индекса (сигнал от датчика индексного отверстия) и все байты, которые контроллер возвращает через регистр чтения. EIM создаётся только программами обслуживания моста, а читается только программой RawEdit. Размеры этих образов не фиксированы и составляют 1-10 Мб, причем могут содержать несколько экземпляров (проходов) чтения каждой дорожки (обычно от 2 до 6 вариантов). Каждая копия каждой дорожки читается 220 мс, т.е. содержит примерно 110 % данных (десятая часть повторяется дважды для возможности точной склейки кольца, если таковая потребуется). Размер дорожек не фиксирован.
Если новое устрйство будет создавать такой же формат, то куча софта для работы с ним уже есть.
У Володи не получилось зарегится здесь, тогда бы он уточнил хотелки. Что-то я запутался как тут зарегится. Сейчас попробую спросить "смотрящих".
Очень хотелось бы, если будут варианты такого устройства, понимать сколько это (каждый из вариантов) будет стоить. Т.е. я скорее в хотелки запишу SD, но затяну пояса.
LeoN65816
25.08.2016, 20:23
Очень хотелось бы, если будут варианты такого устройства, понимать сколько это (каждый из вариантов) будет стоить.
Навскидку: PIC24EP256GP204, LCD 20x4, SD-shield, кварц, стабилизатор, кнопки, разъемы.
Не-не-не. Читать в сырые данные, а обработка потом - это совсем плохо. Проходили.
Надо сразу анализировать формат, считать контрольные суммы, и, если есть сбои - пробовать читать еще раз.
Пробовал на том же KryoFlux - читаем диск в сырое, а потом этом же программой переводим в условно .dsk - программа даёт полно ошибок, образ кривой.
Делаем то же сразу на лету - видно и слышно как некоторые дорожки перечитываются - получаем годный образ без ошибок.
У нас же не идеальные дискеты.....
Ну и надо определиться какой формат - если 140, то надо предусмотреть возможность читать и на "обычном" дисководе, и на 140-вом, причем с возможностью "подвигать" головку на полшага на 140-вом.
Сдается мне что при чтении дискет 140 в "обычном" дисководе могут быть физические непопадания на дорожку. Но это только гипотеза, которую я пока обосновать не могу и не уверен что такая проблема есть.
GARNIZON
25.08.2016, 21:26
Навскидку: PIC24EP256GP204, LCD 20x4, SD-shield, кварц, стабилизатор, кнопки, разъемы.
Это само собой, я про работу имел в виду. Или сперва надо определится с хотелками?
Мне вот что пока приходит в голову (целиком все мысли попробую оформить через пару дней):
Пишу только про свои хотелки, надеюсь заинтересованные включатся в обсуждение:
1) Когда я еду дампить диски, ноут всегда со мной, на нем вероятней удобней наблюдать за процессом чем на
автономке с СД картой. Видимо с СД я погорячился, а может и нет.... пока запутался.
2) 99 процентов дисков - 840, и если 140 не будет вписываться в проект то можно вероятно и пережить.
3) Очень важно: больше всего доставляет проблем, особенно когда в другом городе или на коленке дампиш,
сортировка! Т.е. многие агатовцы свои диски частично переформатили на PC, или как чаше бывает просто кучей от
разных компов отдают - типа разбирайтесь сами. Т.е. необязательно чтоб и другие MFM форматы умела читать -
достаточно подать знак типа такого "с большой долей вероятности этот диск не от агата".
Надеюсь, форумчане напишут свое видение ситуации.
Если делать "автономное", хватит ли 32К и на "сырое" и на "готовое"?
Если неавтономное - там проще - считали дорожку, отдали "сырое" на комп, там проанализировали и при необходимости попробовали считать еще раз. При этом должен быть механизм "сбора" дорожки из разных кусков с разных попыток (например, первый раз не считался первый сектор, второй раз -3; уже за эти две попытки можно собрать годную дорожку).
GARNIZON
25.08.2016, 21:42
Не-не-не. Читать в сырые данные, а обработка потом - это совсем плохо. Проходили.
И мы проходили http://agatcomp.ru/Soft/agat.shtml
И поэтому Володя написал прекрасный софт для изучения RAW и работы с RAW.
И вот уже 12 лет именно в сырье.
KryoFlux не показатель. И как он там dsk из сырья делает тоже вопрос.
Ручной анализ EIM-файлов позволяет в некоторых случаях восстановить сбойные блоки дискет, в том числе обнаруживать и исправлять довольно неприятную ошибку "двойных" секторов (в случае неуверенного чтения поля адреса стандартный драйвер иногда "путает" поля данных разных секторов, не имея эффективной возможности обнаружить ошибку). Програмное обеспечение работает под MS-DOS-совместимой системой, за исключением полноэкранного редактора EIM-файлов - он сделан под FreeBSD с использованием библиотеки ncurses.
- - - Добавлено - - -
При этом должен быть механизм "сбора" дорожки из разных кусков с разных попыток (например, первый раз не считался первый сектор, второй раз -3; уже за эти две попытки можно собрать годную дорожку).
Это все есть и даже больше в сейчашних мостах, которыми я пользуюсь - въедливый когда надо, ожидает всяких подлянок и т.д.
Но они LPT и так далее про неудобства.
Как скажете. Если есть уверенность что в raw с первого раза прочиталось без ошибок (не попала никакая пылинка, микрокусочек покрытия дискеты и т.д.) - можно сразу однократно в raw.
А потом дома кусать локти если после долгого изучения raw потвердилось что пылинка таки была, да еще и протащилась на пару секторов....
и потом, мы под raw понимаем абсолютно разное: то что Вы называете raw (байты из регистра контроллера, то есть видимо уже засинхронизированный поток записанных битов) - это совсем не raw. raw - это либо семплирование с частотой минимум в 4 раза больше реального потока битов, или хранение таймингов "перепадов" (типа на такой-то наносекунде после сигнала индекс произошел первый перепад из 0 в 1, следующий - на такой-то, следующий - на такой-то). Или я неправ?
- - - Добавлено - - -
Это все есть и даже больше в сейчашних мостах
А это тут причем? Мы вроде будущий продукт обсуждаем и какие в нем фичи нужны. Или я спутал тему? Если обсуждаем что где УЖЕ есть - беру свои слова назад ;-)
GARNIZON
25.08.2016, 21:56
можно сразу однократно в raw.
Поечему однократно? вот пример про 140, прошу прочитать со всей внимательностью (там в конце видео есть интересное):
http://agatcomp.ru/Reading/fl140k_selfmade.shtml
- - - Добавлено - - -
А это тут причем?
Этими наработками можно воспользоваться
Еще раз - мы разные raw обсуждаем.
>Этими наработками можно воспользоваться
Я бы не мешал всё в одну кучу. Сначала, обычно, обсуждают желаемый функционал, а уже потом смотрят есть ли под этот функционал наработки.
А то для меня непонятно: я пишу "надо бы такую вот фичу", а мне "да это уже там-то и там-то есть". Может показаться что мне возражают и эта фича в конкретно обсуждаемом новом продукте не нужна, раз она уже где-то есть.
- - - Добавлено - - -
Я Вас совсем перестал понимать.
Вот по ссылке "(на плохих дискетах приходится перечитывать до 800 раз)"
То есть Вы предалагаете 800 раз записать на SD "сырье" без всякого анализа? А потом (когда дискета уже недоступна) выбирать из этого годные сектора?
Или сразу проанализировать "сырье" (то есть получить из него битовый поток данных, проверить нет ли сбоев кодирования, посчитать CRC) выбрать правильные куски и сохранить битовый поток данных?
GARNIZON
25.08.2016, 22:11
Я же пишу "но они LPT". Т.е. есть хорошие наработки но не всегда удобно LPT, с этого все и началось еще в другой теме, ссылка туда в первом сообщении.
LeoN65816
25.08.2016, 22:14
Сдается мне что при чтении дискет 140 в "обычном" дисководе могут быть физические непопадания на дорожку. Но это только гипотеза, которую я пока обосновать не могу и не уверен что такая проблема есть.
Однозначно не выйдет.
я про работу имел в виду.
Думаю, сумеем договориться о взаимовыгодном сотрудничестве.
1) Когда я еду дампить диски, ноут всегда со мной, на нем вероятней удобней наблюдать за процессом чем на автономке с СД картой.
Это да, информативней. Тогда на PC прога "на лету"/подорожечно должна анализировать, принимать решение и давать команду девайсу на чтение следующей дорожки.
Зато с SD мобильность и автономность.
2) 99 процентов дисков - 840, и если 140 не будет вписываться в проект то можно вероятно и пережить.
Плюс, честно говоря, FM мне совершенно не интересен...
Т.е. необязательно чтоб и другие MFM форматы умела читать
Может, я неправильно "всосал" теорию, но других MFM не бывает... Да, скорость битпотока бывает разной (250 Кбит/с у ВГ93/i8272, 255.357 Кбит/с у АГАТа), но это важно при аппаратном декодировании (даже с ФАПЧ x16). Это самосинхронизирующийся метод, и при программном декодировании эта скорость "по-барабану". Не исключаю, что заблуждаюсь.
А вот какой синхросбой прочитан и где (ВГ93 или АГАТ), это уже на PC прога может определить и принять решение.
Если делать "автономное", хватит ли 32К и на "сырое" и на "готовое"?
Если неавтономное - там проще - считали дорожку, отдали "сырое" на комп, там проанализировали и при необходимости попробовали считать еще раз. При этом должен быть механизм "сбора" дорожки из разных кусков с разных попыток (например, первый раз не считался первый сектор, второй раз -3; уже за эти две попытки можно собрать годную дорожку).
Потому и 32К, чтобы от индекса 4-5 оборота сырого битпотока считать и записать на SD или отдать на хост, а уже на PC с этих 4-5 копий (как бы автоматически склееных) после анализа принять решение.
>Однозначно не выйдет.
Что не выйдет и куда?
>Потому и 32К, чтобы от индекса 4-5 оборота сырого битпотока считать и записать на SD
И сколько это займет из 32K. И, если в автономе делать анализ, сколько памяти останется?
И, если именно бит поток с дисковода (а не переходы), как планируете (с какой частотой) сэмплировать?
Как бы 250 кбит/с это 50 кбит/оборот, а это 6,25 килобайт/оборот чистых данных. Если сэмплировать хотя бы в 4 раза чаще (чтобы потом программно делать фапч и прочее), это уже 25 килобайт. Если локальный анализ - нужно еще место как минимум для данных (10 секторов по 512 байт) - это уже впритык. То есть даже промежуточные данные (MFM поток) уже не сохранить.
GARNIZON
25.08.2016, 22:57
Может, я неправильно "всосал" теорию, но других MFM не бывает...
Я конечно же имел в виду что агатовский от скажем спектрума мог отличить, ну типа они оба MFM. Просто выражаюсь сегодня криво. MFM - модифицированная частотная модуляция, но это ж не законченный формат записи, а только намёк на имеющиеся ограничения. Вроде того, сколько нулевых бит может приходится на один единичный бит. А такие вопросы, как, например, порядок бит в байте, размеры синхрополей (и вообще их конструкция) - отданы на усмотрение разработчика конкретного контроллера.
Просто по всей видимости я сегодня плохой собеседник и выражаюсь криво. Сижу переживаю что Агат-4 сорвался, прям места себе не найду. Я попросил Володю что бы присоединился к нашему разговору, надеюсь у него получится зарегится. Завтра возьму себя в руки и продолжим тогда.
LeoN65816
25.08.2016, 23:11
Эх, как же плохо, что не можем за кружечкой пива "вживую" понять друг друга... ;)
GARNIZON
26.08.2016, 17:34
Попробую обобщить мысли, в том числе, разъяснить за что меня вчера Денис наругал :) При чем тут уже имеющиеся разработки и вообще про все.
Я буду писать только о своих хотелках и необходимостях, на мне свет клином не сошелся, но раз уж эту идею начал я, то простите за некоторую однобокость в рассуждениях.
Сразу отмечу, какой-то суперуниверсальности я от устройства не жду, мои интересы нацелены только на одно - сохранение информации с АГАТовских дисков.
Снятие образов дисков в домашних условиях.
Т.е. когда диски для съема оказываются у меня дома и в спокойной обстановке.
Как это все происходит у меня сейчас:
специально для этого имеется отдельный комп на базе Р1 (АТ корпус, LPT, DOS).
К нему без проблем подрубаются оба устройства (мост140 и мост840)
http://agatcomp.ru/Hard/bridge.shtml
Сами устройства разработаны Володей и меня полностью устраивают по своему функционалу.
Остановлюсь чуть-чуть подробнее на них (дальше по тексту поймете зачем).
Мост 140:
http://agatcomp.ru/Hard/bridge/br_fin.jpg
Представляет из себя небольшую плату. С одной стороны LPT, с другой стороны кабель для Агатовского дисковода 140.
Очень компактное устройство на ATmega16. Обязательно должен отметить что с помощью этого устройства я дважды выигрывал спор у Американцев и трижды у Болгар. Т.е. мне присылали дискеты от Apple/Правец, по их мнению сильно битые и разрушенные с уверениями что я лучше чем они все равно не вычитаю. Помню что вычитал без ошибок (совсем без ошибок) диск с какой-то игрой про гоночку, которая считалась безвозвратно утерянной даже на asimov.net.
пИсали кипятком но пометить что диск был вычитан именно в России отметить на сайте отказались - фиг с ними.
В след раз деньги буду брать :)
А ведь они, в попытках прочитать эти гоночки, пользовались тоже неплохим устройством: http://www.willegal.net/appleii/appleii-disk-int.htm
Как-то на сайт пришло письмо, от человека который пожелал переделать это устройство под USB вместо LPT.
По его словам надо было только использовать другую модель ATmega, и практически не трогать софт как встроенный в устройство, так и с стороны РС. Не знаю правду он сказал или нет, но он внезапно пропал, да и мне это показалось не особенно важным на тот момент.
Мост 840:
http://agatcomp.ru/Hard/bridge/bridge.jpg
Представляет из себя небольшую плату. С одной стороны LPT, с другой стороны обычная агатовская слота (видно на фото), в которую надо вставлять стандартный агатовский контроллер840, а уж к нему кабелем флоп.
Тоже прекрасные возможности (которых мне хватает с головой)по вычитыванию убитых и разрушенных дисков.
Однако необходимость использовать с составе устройства контроллер840 делает эту спарку весьма громоздкой и контроллер 840 склонен к деградированию (им лет-то сколько) - так что частенько приходится поперетыкать\позаменять платы. Т.е. даже для домашнего использования хотелось бы что-то более компактное.
Я могу что-то путать, но Володя сказал что на данном этапе он не может сделать мост840 без использования контроллера840, это связано с «недоизученностью» данного контроллера вроде в разделе Кодер/декодер записи/чтения.
http://agatcomp.ru/Reading/fl800k.shtml . Как только он появится на форуме, я попрошу его объяснить этот момент подробнее и с примерами (т.е. почему именно не получилось без использования контроллера).
Так же отмечу, что в том же Р1 у меня стоит пара дисководов подключенный к стандартному порту FDD. Их я использую для чтения "неагатовских дисков", применяя кучу всяких прог: Floppy Disk Analyser, Teledisk, DCP, SN_114 для спектрума и т.д. Т.е. если мне попадаются "неагатовские" диски я тоже их читаю - коллег по увлечению (даже если они увлекаются другими компами) надо уважать. В моих сообщениях по форуму можно без труда найти сколько я всего выкладывал для Искара, ЕС, корвет, спектрум, БК и прочее.
Снятие образов дисков в походных условиях.
Мост140
В принципе, он вполне подходит для походных условий (компактный), но приходится с собой таскать ноут с LPT.
Причем в последнюю поездку я брал два таких ноута (второй спецом прикупил на полигоне призраков) - очень боялся что с одним что-то случится от тряски в дороге (старенькие же все таки). Но это все фигня... численность дисков 140 которые мне предлагают несравнимо меньше чем 840. Так что про 140 я не переживаю - пусть будет все так как есть, может кто-то в будущем действительно переделает его под УСБ.
Кроме того, DK_SPB частично решил эту проблему, и я теперь смогу посылать владельцам дисков 140 небольшое устройство (правда требующее живого компа). Денису еще раз спасибо, в который раз меня выручает.
Итак, про 140 никакой острой необходимости нет, и далее речи о нем вести не буду.
Мост840
Вот тут проблемы. Громоздкость системы, о чем я писал выше, это только одно из зол. Так же приходится брать два ноута с LPT и кучку запасных контроллеров 840. ДА и не пошлешь его ни кому - по тем же причинам.
Как бы было здорово иметь коробочку с одной стороны стандартный соединитель 34пин для FDD, с другой УСБ (все такие не SD, и даже вероятно не важно напрямую будет работать с УСБ или через эмуляцию компорта).
Если потребуется, могу подключить профессиональных программистов (бывших агатовцев) - скажем для написания программ (в том числе под виндовс) с стороны РС.
Но тут вот очень важное обстоятельство: у нас с Володей сложилась (более 10 лет) отработанная схема обработки образов. Успешная схема!
Я добываю диски, снимаю и отправляю ему на обработку в виде EIM файлов (про них писал выше).
Мост конечно умеет и въедливое чтение в DSK, именно так как писал dk_spb, но мы предпочитаем именно в EIM.
На это есть свои причины, Володя как только появится объяснит почему (я специально его об этом попрошу).
Т.е. в идеале, чтоб новое устройство умело создавать именно такие же EIM, т.е чтоб для Володи было все равно чем я снимаю. И он все обрабатывал как обычно. Таким образом цепочка работы с образами не будет нарушена, важно это.
Ведь у него написано много классного софта для работы с EIM, и даже конверторы, которые самостоятельно много решений принимают создавая из EIM в DSK. Всякие там анализаторы EIM и прочие прелести. Для нас EIM уже стал стандартом и отказавшись от него - это застопорить всю работу и переписывать софт под что-то другое.
Где бы про этот EIM почитать подробней?
GARNIZON
27.08.2016, 22:27
Немного тут про него: http://agatcomp.ru/Soft/agat.shtml
Подробного описания формата (ведь оно нужно?) на сайте нет,ведь мы только вдвоем его используем, правда очень давно. Володя появится на форуме и все предоставит.
Wierzbowsky
29.08.2016, 19:15
У моего приятеля на работе затопило подвал, где были все его ретро компы и диски. В общем армагеддец, диски не читаются, дисководы сдохли все. Вот он сейчас восстанавливает диски путём переноса магнитных носителей в другие конверты. Читает их вот этим устройством:
http://www.kryoflux.com/?page=kf_features
Это USBшный аналог вашего граббера битстрима с флопов. Стоит конечно прилично, но как говорит мой приятель это стоит тех денег, которые за него заплачены. К тому же он очень компактный, поддерживает кучу форматов.
Не стоит. Ибо закрытый сильно коммерческий проект с кучей нарочно придуманных ограничений.
У меня уже давно такой.
Sergei Frolov
29.08.2016, 20:03
Это USBшный аналог вашего граббера битстрима с флопов.
АГАТовский формат уникальный. Вряд ли его можно как-то прочитать считывалкой для обычных дисков.
Можно. Как и любой другой формат (Apple 140, C64 и т.д.).
Необычной читалкой для обычных (5.25") дисков.
Kryoflux как раз необычная читалка.
Можно. Как и любой другой формат (Apple 140, C64 и т.д.).
Необычной читалкой для обычных (5.25") дисков.
Kryoflux как раз необычная читалка.
Именно так, вот описание того как я декодировал данные дискеты по дампу логического анализатора.
https://github.com/sintech/AGAT/blob/master/docs/agat-840-analysis.md (По тексту возможны ошибки, не так давно работаю с Агатом.)
В принципе никто не мешает написать программу для микроконтроллера, которая будет читать по очереди все дорожки, программно декодировать адреса и данные, проверять контрольные суммы и т.д.
Перечитывать дорожку, если она не читается с первого раза, а результаты в т.ч. промежуточные сохранять на SD карту.
Если не делать декодирование после считывания, а просто сохранять битовый поток нескольких проходов дискеты, для последующей обработки на PC, то задача сильно упрощается.
>то задача сильно упрощается.
Только итоговый результат ухудшается на пару порядков больше, чем упрощается задача. Причину выше я описывал.
GARNIZON
30.08.2016, 00:19
Скажем вот у нас МОСТ вообще-то не даёт EIM, он даёт сырой поток, а как именно его обрабатывать - решают дампирующие проги на стороне PC. У нас есть версии и get_dsk и get_eim и прочее. Т.е. в результате работы дампируюшей программы получается например EIM со всеми нужными проходами подозрительных мест, которые например прочитались но не сразу - для ручного анализа. Снимать в DSK - плохо, у меня было так что КС сходилась по стечению обстоятельств при том что данные прочитались неверно.
Я же давал ссылку сюда (http://agatcomp.ru/Reading/fl140k_selfmade.shtml)
в результате многократных попыток иногда возникают ситуации, когда "шум" (т.е. неуверенное чтения отдельных байт и бит) приводит к такой модификации данных, которая подходит к имеющейся контрольной сумме, но не является верной. Напомню, что формат предполагает один байт контрольной суммы, вычисляемый как "исключающее ИЛИ", для $156 байт данных.
Т.е. если устройство будет удовлетворено только тем, что КС сошлась – на агате может не прокатить. Лучше когда устройство посылает до РС сырое а «умная» дампирующая прога принимает решение что еще перечитать прям во время съема и дает задание устройству. Но все попытки оставит в файле. И алгоритмы чтения проще модифицировать в проге чем в прошивке устройства.
решение что еще перечитать прям во время съема
Вот, я именно про это. Прямо во время съема. То есть анализ пофиг как и чем делать, главное делать его в тот момент пока дискета еще доступна.
А уж в чём хранить результат - для данного вопроса дело десятое.
GARNIZON
30.08.2016, 09:36
А уж в чём хранить результат - для данного вопроса дело десятое.
Нет, не десятое а первое, я писал почему. И на видео это хорошо видно.
- - - Добавлено - - -
Именно так, вот описание того как я декодировал данные дискеты по дампу логического анализатора.
https://github.com/sintech/AGAT/blob...40-analysis.md (По тексту возможны ошибки, не так давно работаю с Агатом.)
ага, суперски написано, четко и с точностью в деталях
Нет, не десятое а первое, я писал почему
Я, пожалуй, помолчу. А то мы как слепой с глухим....
Я пишу что для вопроса когда делать анализ не важно в чем потом хранить. А мне опять какое-то видео....
GARNIZON
30.08.2016, 10:32
Важно в чем хранить! Если долго-долго на агате читать в DSK хреновую дорожку - полюбому потом КС сойдется но данные будут неверные. Поэтому в случае с агатом только ручной анализ. А его можно сделать только если в файле есть все проходы искомой дорожки.
Кроме того формат DSK не содержит столько подробностей для анализа сколько скажем EIM "поток сырых данных, получаемых из регистра чтения реального дисковода. В поток органично вплетаются символы синхросбоя, метки индекса (сигнал от датчика индексного отверстия) и все байты, которые контроллер возвращает через регистр чтения."
Теперь по опыту (несколько тысяч агатовских дисков): перечитывать одну дорожку более 5-6 раз смысла нет (для дисков PC есть, для агат нет), поэтому
просто сохранять битовый поток нескольких проходов дискеты, для последующей обработки на PC,
Вполне годный (набезрыбье). И не надо про соринки говорить. У меня еще ни байта не пропало. Твои теории хороши, но я практик.
И как сказал кто-то на полигоне "второй раз я его буду читать только при острой необходимости, иначе развалится". Ведь вычитывая DSK с многократным чтением, голова ерзает по диску весьма усиленно и долго, на диске это сказывается не лучшим образом. Самый лучший вариант - это прочитать диск простой и быстрой читалкой, а потом плохие области (если они есть) перечитать отдельно в сыром виде, возможно не один раз, разными флопами и потом свести все в один образ диска. Ну собственно я так и делаю всегда. И имею результат даже с таких:
http://agatcomp.ru/Common/disks.jpg
Все эти обстоятельства, в идеале, учитываются с самого начала, при разработке программно-аппаратного комплекса и
поэтому очень важно сразу определится в чего читать и как хранить.
И не надо про соринки говорить. У меня еще ни байта не пропало. Твои теории хороши, но я практик.
А, так тут все практики, а я-то куда в этот калашный ряд...... Точно помолчу.
GARNIZON
30.08.2016, 11:18
А, так тут все практики, а я-то куда в этот калашный ряд
Денис, ну зачем ты так! я же лучше других знаю сколько (дикое кол-во образов которых без тебя просто никогда бы не было в инете) ты всего снял от разных ЭВМ. И твой способ вероятно оправдан для ДВК, ЕС и прочих, тут тебе лучше знать, в них ты практик а я только теоретик. Я же именно про агатовские говорю, и тут я собаку то скушал.
Мысль которую ты хочешь донести понятна: «мне дали на пол часа диски, и надо вычитать так чтоб КС сошлись, иначе если я этого не дождусь в дампах может не оказаться нормального прохода а диски уже тю-тю». А я тебе говорю, что с агатовскими дисками это дохлый номер, проходили, Кс сошлась а в дампе мусор. А вот 5-6 проходов полных в сырье дадут возможность анализа (на это есть софт классный) . Акцентирую внимание (статистика) : Больше 5-6 проходов смысла нет делать на агатовских дисках.
На РС у меня такой номер почти каждый раз срабатывает (бывало на 25 попытку как подменили - взял и прочитался), на агате ни разу.
Ты забываешь что кроме Агата есть еще другие системы. И делать железку ТОЛЬКО под Агатовские диски - неинтересно. Как минимум должна быть возможность потом добавлять форматы.
Относительно твоей мысли про 5-6 проходов для Агата достаточно: мне кажется ты упускаешь из виду тот факт, что ты читаешь мостом диски через "родной" контроллер, которые берёт на себя многие задачи (в том числе по синхронизации и выделению из читаемых данных) битового потока. Или я неправ?
В обсуждаемой же железке этого "препроцессора" не будет, поэтому твоя статистика может не соответствовать. Поэтому обязательно нужна минимальная верификация что мы хоть что-то нормально прочитали ДО того как диски "ушли".
И пусть у нас будет дорожка с какими-то ошибками. Да, можно её прочитать несколько раз, чтобы небольшие ошибки устранить анализом нескольких копий. Но без начальной верификации ты несколько раз можешь прочитать и сохранить мусор, где не только КС данных не сошлись, но даже КС заголовков ни у одного сектора не совпали или даже синхробайты не находятся. И что тебе даст анализ этого мусора?
- - - Добавлено - - -
Денис, ну зачем ты так!
Просто пытаюсь свести переходы "что может сказать теоретик об искусстве Герберта фон Караяна " в шутку ;-)
Wierzbowsky
30.08.2016, 13:53
Ппц, и что, мятую как из жопы дискету тоже реально прочитать!?
Мужики, вы неконструктивны. Хорошо, что Агатовские темы вновь ожили, но не стоит тут начинать холивар по поводу опыта. У каждого он свой и неповторимый.
LeoN65816
30.08.2016, 13:57
ага, суперски написано, четко и с точностью в деталях
А мне так не показалось, особенно с точностью в деталях...
Начиная с логических уровней и активного состояния сигналов.
Затем правило MFM-кодирования, где каждый бит данных кодируется в два полуинтервала (смена направления тока в головке, именно при смене тока дисковод выдает импульсы). Посмотрите здесь (https://ru.wikipedia.org/wiki/MFM-кодирование), здесь (http://www.pcguide.com/ref/hdd/geom/dataMFM-c.html) и в "хорошей статье на эту тему от инженеров компании Shugart Associates" (https://github.com/sintech/AGAT/blob/master/docs/agat-840-files/cd-8002-1.pdf). Затем посмотрите в его доке на пример, как байт данных $C5 кодируется в MFM-последовательность, и опять взгляните на мои ссылки... Может я и ошибаюсь, но это не "по-фэншую".
Затем пресловутый (в ВГ93) $A1 - это и есть уже MFM-последовательность полуинтервалов, в которых идут подряд 4 одинаковых полуинтервала (4 нуля), что есть невалидная MFM-последовательсть, то есть синхросбой. Но в АГАТе нет "desync 0xA1" (как указано у него), тем более не MFM, а именно "desync 0xA1-данных". Здесь (4.7.2) (http://agatcomp.ru/Reading/serkov/hainfo/023-01to.shtml), здесь (пункт 16) (http://agatcomp.ru/Reading/docs/es5323.txt) и здесь (http://www.agat-legacy.narod.ru/docs/teac.rar) говорится об этом. Последний (младший) бит от $A4 (бит данных равный 0) дает два одинаковых полуинтервала, затем задержка на один полуинтервал в 2 мкс, затем один такой же полуинтервал от старшего бита следующего байта $FF (бит данных равный 1), итого 4 одинаковых полуинтервала - синхросбой.
Не исключаю, быть может это я неправильно "вкурил" про MFM-кодирование...
GARNIZON
30.08.2016, 14:15
От Володи письмо: "
> Плюс, честно говоря, FM мне совершенно не интересен...
Неверно. Контроллер 140ки вообще не занимается модуляцией-демодуляцией.
При записи он только сдвигает полученный от ЦП байт в дисковод.
Формат записи может быть, таким образом, различный. Можно даже MFM замутить,
если сильно надо. Стандартный же формат следующий: GAP вообще не кодируется
(просто константа АА, которую при сбое синхро можно прочитать как 55),
прологи-эпилогий полей - тоже константы, адресное поле - FM, поле данных
- GRC.
GRC - групповое кодирование. Решает ту же задачу, что и MFM, только с бОльшими
затратами рессурсов (ОЗУ и ЦП). И примерно так же эффективно по плотности.
Принципиальное отличие тут только в том, что в 140ке частичная синхронизация происходит
на каждом байте (байт записывается как 10 бит, два последних - нули), а в MFM
- только на поле синхросбоя.
Из-за этих двух нулевых бит дорожка 140ки - всего 16 секторов против 21 у 840ки.
Если бы было FM - там бы, наверное, секторов 10 поместилось, не больше.
А разница в объёмах дисков идёт из-за ширины и количества дорожек
- 35 против 160.
-=-=-
RAW-споры:
Давайте называть поток бит от дисковода до контроллера RAW-bit, а поток байт
от контроллера к ЦП - RAW-byte. Чтобы однозначно.
AIM и EIM - это RAW-byte.
Поток, который наши мосты гоняют по LPT - это RAW-byte + служебка (состояния контроллера).
Почему не RAW-bit ?
1) Исторически, RAW-bit просто был не нужен для эмуляторов.
Проги обмениваются данными с контроллером, а не дисководом. Таким образом, больше
информации, чем может прочитать контроллер, нам уже просто не нужно.
2) Потому что битрейт (если, действительно, семплировать каждый импульс от флопаря
с частотой раза в 4-8 большей, чем длительность импульса) будет велик. Но бессмысленнен.
Чтобы обработать такой битрейт проц уже должен быть заметно более мощным.
Контроллеры, что 140, что 840 - уже имеют на борту соответствующий аппаратный анализатор.
Он же есть и в мосту-140. Я не вижу возможности его как-то улучшить за счёт программной
обработке на PC или в каком-то современном контроллере, поэтому пусть он сразу и
конвертирует RAW-bit в RAW-byte.
3) В сущности, конвертация RAW-bit в RAW-byte в 140 очень проста: очередной байт
начинает читаться после прохождения последовательности "001". Собственно, секвенсор
её ищет, это является синхронизацией и все последующие биты просто собираются в
байт, с некоторой фазовой автоподстройкой. Так что глядя на RAW-byte легко представить
и как выглядел RAW-bit.
4) Копаться в RAW-bit, как и в RAW-byte, вручную на практике почти нет смысла.
Например, я могу найти в GCR-последовательности сбойный байт, где явно затесался лишний
ноль. И что дальше ? Мне его заменить на единицу или просто удалить?
И есть уверенность, что последовательность затем соберётся без ошибок?
Это маловероятно. Ведь повреждение записи - это проблемы поверхности. Они вряд ли
будут размером с 1 бит. Пару секторов - да, это бывает. А чтобы стабильный 1-бит - почти нет.
5) Гораздо чётче работают две другие схемы восстановления: найти такой же файл на другом диске и объединить
две копии посекторно. И переснять другим дисководом этот же диск. 3-4 разных дисковода
и больше половины проблемных дисков читаются.
Зачем же тогда нужен RAW-byte?
1) Ключи защиты от копирования. И всякие хитромудрые форматы, типа один сектор
размером во всю дорожку. Этого добра на 840ке хватает...
2) Всё таки восстановление чего-то очень интересного. В RAW-byte несложно нарисовать
запорченное адресное поле или проигнорировать CRC. Или расчитать его по особому алгоритму.
Но подгонять каждый бит на всех непрочитавшихся дискетах - это перебор.
3) А откуда я знаю, что Игорь накопает в очередной раз... ?
Не забывайте о том, что мы работаем вдвоём, но разделены приличным расстоянием.
Так же будет и если устройство для чтения будет выпущено серией: железка отправится
по разным пользователям, но глубокий анализ вряд ли кто-то из них возьмётся сделать.
Так что проще вытащить весь поток и потом уже, если он окажется чем -то странен -
копать уровень RAW-byte.
-=-=-
Спор насчёт EIM vs DSK
Не совсем понял, почему вы их противопоставляете?
Что, собственно, мешает, контролировать CRC и перечитывать вопросные зоны сразу,
но в файл сохранять именно RAW-byte? У нас именно так работают оба моста.
Да, RawEdit потом заного всё анализирует, по более замороченным алгоритмам, кой где.
Однако он пока не жаловался, что его заставляют второй раз делать уже выполненную работу.
У нас и для dsk есть две разные проги - одна быстрая, другая - въедливая. Есть и прямо
прога, которая выводит каталог диска, вообще ничего никуда не сохраняя.
Вообще, при чем тут формат ?... EIM или DSK - это вообще дело не аппаратуры, а
софта. Коего можно понаписать позднее просто сколько угодно.
Мне кажется, его сейчас очень рано обсуждать. Если только:
> Ты забываешь что кроме Агата есть еще другие системы. И делать железку ТОЛЬКО под Агатовские диски - неинтересно. Как минимум должна быть возможность потом добавлять форматы.
Потому что тема начиналась вот этой фразой:
> Здесь Игорь озвучил мысль о реальной необходимости современного и мобильного средства снятия образов АГАТовских дисков.
Так надо решить: вы (не знаю кто, но кто-то) делает строго железку под агат,
пусть даже это будет коммерческой разработкой или вся работа - "на интерес"?
/Озвучивайте суммы, не стесняйтесь - если работа будет хорошая, можно и оплатить её/
Потому что до сего момента я считал, что речь идёт именно и только об агате.
Если нет - то это надо ясно обозначить.
Если это универсальный девайс - то я пасс, я могу только рассказывать,
что и как и почему делалось у нас, но вряд ли возьмусь что-то обсуждать о том,
как это нужно делать теперь.
-=-=-
Как я вижу конечное устройство для 840ки, работу над ним и вопросы:
1) Сейчас уже два человека расковыряли формат 840ки. Один из них даже опубликовал
на гитхабе. Статья классная (!), сегодня читал (ну может есть какие-то ошибки, но то что я знаю - похоже).
Проблема только в том, что оба они анализировали битовый поток, а не схемотехнику
контроллера. В результате оба не описали поведение секвенсора при генерации
и анализе синхросбоя. А это не такая простая штука. Как минимум, насколько я понимаю,
поведение контроллера будет менятся в зависимости от предшествующего синхросбою байта
(при записи) и не знаю чему - при чтении.
До тех пор, пока вы работаете со стандартным форматом, это всё не существенно.
Но когда начнутся игры с защитой от копирования, особенно с MouseGraf 4.4 - могут быть сюрпризы.
2) С другой стороны - анализ контроллера мог бы способствовать воссозданию
секвенсора для будущей железки. Как это было сделано для 140ки. ATmega16 просто
бы не вывезла такой семпл-рейт, который там молотят 4-5 копеечных микросхем.
Наверное, это же можно сделать на простой ПЛИСКЕ-ПЛМке. Но я не умею.
3) Почему USB-интерфейс? Я бы, наравне с ним, использовал и синий зуб.
Сейчас андроидов полно, бывает что у чела и ноута -то может не быть, а
планшет у детей занять можно.
А может быть предусмотреть Ethernet ? Вроде сейчас есть готовые платы
с контроллером, который - с одной стороны - смотрит в витуху, а другой -
в любую 8-битку?
4) Для питания предусмотреть на плате несколько разных разъёмов от БП распространённых
ноутов. И с него уже конвертировать в +12 +5 и что ещё надо. Для особой электромагнитной
эстетики можно даже конвертировать линейными регуляторами.
5) Экран и флешки точно не надо. Это компактно, но всё таки проще отлаживать бОльшую
часть кода на PC чем в контроллере. И экран ноута заметно удобнее, и клавиатура.
А главное - можно напрограммить много разных управляющих прог для разных задач.
У нас мосты, например, кроме прочего, могут измерять скорость дисководов, вручную
можно управлять головками (при ремонте удобно), выводят статус датчика нуля,
самотестирование, тестирование интерфейса с компом...
6) Минимум кабелей. Пусть будет только какой нибудь стандартый miniusb с одной стороны
и флоп-разъём с другой. И посередине питание.
7) Запись данных вторична, в первую очередь обкатать чтение.
8) USB-порт на контроллере или USB-конвертор, что нибудь вроде cp2102 ? У него скорость высокая,
стоит вроде не дорого? Не знаю.
9) Насколько сложно сделать буфер дорожки (внешнее озу), чтобы не зависеть
от сбоев PC ? Именно мало памяти на ATmega вынудило на заморочки с DOS и LPT - чтобы
иметь со стороны PC быстрый отклик без задержек.
"
Ну как-то всё сильно в "терминах" Агатовского железа.
На самом деле raw-bit нужен как раз для того, чтобы "вытягивать" raw_byte. В том числе программной ФАПЧ.
Видел сорцы как раз конвертилки raw-bit в raw-byte от kryoflux - так там даже методы ФАПЧ можно менять.
Про противопоставление EIM-DSK вообще ничего не понял. Железка+софт должны уметь писать все (raw-bit; raw-byte=EIM; dsk).
И мне лично крайне не нравятся все эти дискуссии про всякие atmeg'и. Ну давайте еще на 155 серии сделаем ;-)
Я думал сделать такой проект (не только для Агата) в виде дочки к BBB, точнее к BBG (BareBone Black Green). При этом от дочки нужны практически только разъемы и пару м/c "адаптеров" сигналов логики 3,5V-5V. И тогда получается чисто софтовый проект. Сейчас у меня такое железо (не моей разработки софт и "дочка") работает универсальной читалкой HDD MFM. То есть нужно, в некотором роде, "задаунгрейдить" софт и добавить анализатор агатовского формата. За 35 евро на борту и SD и USB и Ethernet. Внутри Linux с компилятором C. Для realtime обработки данных с дисковода- встроенный спецпроцессор. Дискетный битрейт - почти из пушки по воробьям. Но времени совсем нет :-(
- - - Добавлено - - -
Принципиальное отличие тут только в том, что в 140ке частичная синхронизация происходит на каждом байте (байт записывается как 10 бит, два последних - нули), а в MFM- только на поле синхросбоя.
Я не специалист в кодировании и передаче информации, но, насколько я понимаю, синхросбой нужен для синхронизации начала потока информации. Грубо для того чтобы в MFM потоке типа 10101010 понять с какого бита начинается байт. То есть в предлагаемых терминах это уже работа с raw_byte.
Еще нужно получить поток MFM типа 101010 из такого сигнала ----____----____----___, который по факту может быть и ------__----__-_----___ . И вот именно для этого и нужен raw-bit, который обрабатывается программно.
- - - Добавлено - - -
Контроллеры, что 140, что 840 - уже имеют на борту соответствующий аппаратный анализатор.
Он же есть и в мосту-140. Я не вижу возможности его как-то улучшить за счёт программной
обработке на PC или
В том-то и дело что в железке, которую планируется сделать, его нет (хотя бы потому что желзки еще нет). И тут и возникает вопрос: делать "соответствующий аппаратный анализатор" или делать это программно. Для меня в данном случае программно - значит с большими вариантами и возможностями спасти плохочитаемую информацию.
Хотя опять же была мысль сделать два канала: читать чистый сигнал с дисковода и, параллельно уже после какого-нибудь сепаратора с ФАПЧ (например, WD92C32). А потом сравнить. Но аппаратные сепараторы я видел только для FM/MFM. Для GRC не видел.
- - - Добавлено - - -
Ведь повреждение записи - это проблемы поверхности.
А вот тут уже категорически нет. Есть еще куча причин, например, размагничивание от времени, неточная юстировка головки при записи и т.д.
LeoN65816
30.08.2016, 15:42
http://yadi.sk/d/e46aIhNZ8qFTQ - что то я совсем запутался...
(По тексту возможны ошибки, не так давно работаю с Агатом.)
Цитата из статьи:
2.2 Address field:
0x95, 0x6A (2 byte address field mark),
volume number (1 byte, default 0xFE),
Track number (1 byte 0x00 - 0x14),
Sector number (1 byte),
Который из них номер сектора, а который -дорожки? Если верить тексту "Track number (1 byte 0x00 - 0x14)" получается что максимум 0x14=21 дорожка? Или 21 сектор?
Цитата из статьи:
2.2 Address field:
0x95, 0x6A (2 byte address field mark),
volume number (1 byte, default 0xFE),
Track number (1 byte 0x00 - 0x14),
Sector number (1 byte),
Который из них номер сектора, а который -дорожки? Если верить тексту "Track number (1 byte 0x00 - 0x14)" получается что максимум 0x14=21 дорожка? Или 21 сектор?
Конечно Track 0x0-0x9F (159), а Sector 0x00-0x14 (21). Опечатка в спецификации kapitan-u.
Наверное я сделаю свою, обновленную версию спецификации, с правильным Desync и диапазонами значений дорожки и сектора.
GARNIZON
31.08.2016, 05:55
Володя:
"
Ну как-то всё сильно в "терминах" Агатовского железа.
На самом деле raw-bit нужен как раз для того, чтобы "вытягивать" raw_byte. В том числе программной ФАПЧ.
Видел сорцы как раз конвертилки raw-bit в raw-byte от kryoflux - так там даже методы ФАПЧ можно менять.
А польза от чередования разных алгоритмов есть?
Есть ли алгоритмы, использующие, например, статистический анализ дорожки или сектора? Или всё сводится только к состоянию последних 2-4 бит?
Про противопоставление EIM-DSK вообще ничего не понял. Железка+софт должны уметь писать все (raw-bit; raw-byte=EIM; dsk).
Был выше спор о том, кто что проходил и что надо сразу писать в DSK (при считывании диска).
И мне лично крайне не нравятся все эти дискуссии про всякие atmeg'и. Ну давайте еще на 155 серии сделаем ;-)
Я больше скажу - у нас ещё и 531 серия используется на мостах. А в чём проблема -то?
Задачу они решают, стоят копейки.
Но времени совсем нет :-(
Так если нет времени - зачем мы тогда здесь собрались?
Игорь сказал, что тут есть те, кто хочет сейчас и здесь сделать реальное устройство, но не имеет некоторых данных, по форматам и ещё чему-то.
Для меня в данном случае программно - значит с большими вариантами и возможностями спасти плохочитаемую информацию.
Программно надо делать либо если есть избыточные вычислительные мощности либо если есть идеи по модификации этой программы во время отладки.
У меня нет ни того ни другого. Я разбирал логику 140го секвенсора и экспериментировал с прогой от разработчиков агата и от Возняка - разница есть, но не очень значительная.
Поэтому, возможно, если разобрав логику 840го секвенсора я увижу в ней какие-то возможности для расширения, тогда сделаю так же как сделано в 140ке: несколько
разных программ в ПЗУ секвенсора и чередование их в случае неуспеха. Но сохранять в файлы RAW-bit мне кажется уже перебором. Просто из практики работы с агатовскими дисками.
Если найдется какой-то явно лучший способ RAW-bit -> RAW-byte конвертации, чем анализ последних пары бит - я им заинтересуюсь.
А вот тут уже категорически нет. Есть еще куча причин, например, размагничивание от времени, неточная юстировка головки при записи и т.д.
Я под повреждениями имел ввиду не только физические, но любые. Независимо от своей природы они вряд ли коснутся единственного бита.
"
Так если нет времени - зачем мы тогда здесь собрались?
Хороший и своевременный вопрос.
У меня вот один из ответов такой "для того чтобы поспорить есть ли польза от ФАПЧ при чтении дисков". Хотя, насколько я себе представляю этот вопрос уже давно решен гораздо более светлыми умами, чем наши.
LeoN65816
09.09.2016, 14:42
Про пресловутый "desync A1" - http://vak.ru/doku.php/proj/megadrive/mfm?do=export_raw.
Леонид, я согласен, что написаное мной не верно с точки зрения документации и возможно неграмотно технически.
Но разбираясь с форматом 840кб я рассматривал контроллер и сам Агат как черный ящик, на вход которого нужно подать определенный битовый поток. Который будет воспринят как дискета.
На самом деле конечно используется последовательность A4 FF разделенная 2 мкс интервалом нулевого уровня. Но для меня это выглядело как 12 FF. Минус один бит с начала, плюс один в конце первого байта, т.к. 2 мкс пауза декодировалась у меня в дополнительный 0.
Для целей эмуляции использование последовательности 12FF даже удобнее т.к. не требуется вставлять эту паузу между битами в функции стриминга битового потока.
P.S. Статью исправлю. Добавлю картинку с логического анализатора с десинк последовательностью.
Спасибо за конструктивную критику.
LeoN65816
09.09.2016, 18:20
Дык, я сам учусь. Пока что очень много нестыковок в понимании вопроса:
1. Импульсы с привода идут в инверсной логике (нам важен передний фронт, он же отрицательный фронт, он же переход с единицы на ноль, он же изменение напряжения с 5В до 0В, а вот длительность активного состояния [логический ноль] импульса может варьироваться, зависит от начинки дисковода и номинала подтягивающего резистора перед триггером Шмитта в контроллере) с одинарным, полуторным, и двойным периодом. С одинарным периодом кодируются последовательные одинаковые биты данных (...111... или ...000...), причем определить до самосинхронизации, что это, единицы или нули, то есть фронт поймали в середине единицы или в начале нуля - невозможно. Еще раз обращаю внимание, что я говорю о битах данных. С полуторным периодом кодируется изменение битов данных (...100... или ...001...), здесь тоже нельзя определить, что именно пришло. А вот с двойным периодом кодируется единственная возможная комбинация данных (...101...), вот здесь у нас и происходит самосинхронизация. И далее мы уже можем определять, где приходит следующий фронт, в середине или в начале битового интервала. Но с какого из битов в любой восьмерке последовательных бит начинается байт???
2. Последний бит от 0xA4 (младший, равный нулю) после предпоследнего (тоже равного нулю), затем пауза в полинтервала 2 мкс, затем первый бит от 0xFF (старший, равный единице) будут закодированы с двойным периодом, что декодируется как ...101... Как мы определим синхросбой???
3. По ссылке выше, применительно к ВГ93/i8272:
При записи маркеров байты C2 и A1 кодируются специальным образом, с нарушением обычных правил MFM:
^ ^ C ^ 2 ^ A ^ 1 ^
^ Биты | _1 _1 _0 _0 | _0 _0 _1 _0 | _1 _0 _1 _0 | _0 _0 _0 _1 |
^ MFM с нарушением | 01 01 00 10 | 10 **00** 01 00 | 01 00 01 00 | 10 **00** 10 01 |
Биты b3..b1=001 от маркера 0xC2 закодируются с периодом в два с половиной! :confused: Невалидная кодировка, как реагировать?
Биты b3..b1=000 от маркера 0xA1 закодируются с двойным периодом, и декодируются как 101! :confused: Как фиксировать синхросбой???
Описываю, то что я вижу: импульсы логической единицы (0В) имеют длину примерно 1 мкс, длительность логического нуля (5В) различна (от 3 до 7 мкс в среднем).
Когда я проигрываю закодированный в MFM образ диска на вход контроллера, каждый 1 бит я выдаю как: "0В, пауза 1 мкс, 5В, пауза 1 мкс". Каждый 0 как: "пауза 2 мкс". Биты естественно передаются в обратном порядке от старшего к младшему.
Соответственно, А4 FF выглядит в закодированном виде как: 01000100100100100101010101010101, при использовании в качестве синхропоследовательности в агат эти байты передаются как 0100010010010010, пауза 2 мкс,0101010101010101 или 010001001001001000101010101010101.
http://s017.radikal.ru/i420/1609/45/0f387a4b9a99t.jpg (http://radikal.ru/fp/08a9yyi727s16)
Таким образом, если использовать в эмуляторе дисковода в качестве desync, последовательность "10001001001001000101010101010101" которую я назвал 12FF, то не нужно дополнительно вставлять между определенными байтами паузу, а можно просто передать битовый поток по алгоритму описанному выше.
LeoN65816
14.09.2016, 11:17
Фуф, еле осилил вот это (http://zx-pk.ru/threads/20406-emulyatsiya-1801vp1-128-v-plis.html), тоже есть интересное.
Wierzbowsky
28.09.2016, 23:56
Ночку провёл с Орлом и в итоге появился прототип реплики линка номер два для 840кб контроллера дисковода.
http://podrezov.com/agatlink/render.jpg
Плату планируется вставлять в параллельный порт лэптопа, ставить в слот контроллер и писать образы дисков на 3.5 дюймовый дисковод. Буду заказывать 5 платок, если кому-то интересно - отпишитесь. Тогда можем заказ увеличить.
Но с какого из битов в любой восьмерке последовательных бит начинается байт???
Биты данных чередуются с синхробитами. Синхробиты должны быть всегда. Отсутствие синхробита и есть синхросбой.
После обнаружения синхросбоя байт начинает читаться заново, при этом сначала идёт поиск еденичного бита. Синхросбой обычно делается не на последнем бите, данные маркера должны быть таковы, чтобы после синхросбоя гарантированно произшёл ещё один синхросбой на последнем бите, при чём в нужном месте, т.е. чтобы не было смещения, когда вместо битов данных читаются синхробиты.
(неинтересная практическая часть поскипана).
Мда, как я погляжу, описание практической реализации железки для чтения любых FM/MFM дисков вызвало большой интерес и бурные обсуждения.
Ладно, разговоры о теории тоже важны.
LeoN65816
04.10.2016, 12:43
Биты данных чередуются с синхробитами. Синхробиты должны быть всегда.
Это в FM-потоке (http://www.pcguide.com/ref/hdd/geom/dataFM-c.html) термин "синхробит" применим: в начале первого полуинтервала каждого бита данных (хоть 1, хоть 0) идет синхроимпульс (первый R - кратковременный логический ноль с выхода nReadData дисковерта, говорящий о смене направления тока [верхние и нижние "черточки" на рисунке]), а затем в начале второго полуинтервала бита данных для 1 вторым идет еще один R, а для 0 вторым идет N - отсутствие импульса. Итак, если за единичный интервал бита данных поймали два импульса, то это однозначно бит данных 1, если же за единичный интервал поймали только один импульс, то это однозначно бит данных 0. То есть в любом бите данных есть хотя бы один импульс (синхроимпульс, синхробит).
А в MFM-потоке (http://www.pcguide.com/ref/hdd/geom/dataMFM-c.html) несколько по-другому... Там может быть 1 импульс на 1 бит (для ...111... будет ...NRNRNR..., для ...000... будет ...?NRNRN...), 1 импульс на 2 бита (для ...10... будет ...NRNN...), 2 импульса на 2 бита (для ...001... будет ...?NRNNR...), 2 импульса на 3 бита (для ...101... будет ...NRNNNR...). То есть не всегда на каждый бит данных приходится хотя бы по одному импульсу (синхроимпульсу, синхробиту)...
Правильно?
А в MFM-потоке несколько по-другому..
Отличие только в том, что в FM синхробит ВСЕГДА равен 1, а в MFM он может быть 0 или 1 в зависимости от соседних бит данных.
Считать это дело в импульсах - верный путь в тупик, потому как первая задача - превратить импульсы в поток бит, вторая - засинхронизироваться по этому потоку (по синхросбою ли или по маркеру в данных - неважно), а уже потом смотреть FM там или MFM.
Вот хорошая поясняющая картинка:
http://www.pcguide.com/ref/hdd/geom/z_rll.gif
Только надо учесть, что это реально записано на дискете (или блине жёсткого диска), а с дисковода приходят короткие импульсы на каждое изменение 0->1 или 1->0.
а с дисковода приходят короткие импульсы на каждое изменение 0->1 или 1->0.
Это не так. С дисковода как раз приходит поток бит. Например, если данные 10, то FM 1110, и с дисковода физически придет три импульса.
Если бы это было так как изложено, то при данных 512 * 0xff для FM получался бы поток 1024 единиц и ни одного импульса с дисковода ;-)
LeoN65816
04.10.2016, 13:39
Денис, при всем моем уважении к тебе:
а в MFM он может быть 0 или 1 в зависимости от соседних бит данных.
Как это? На то он и синхро, что четко определен по значению, и четко определен по положению во времени. В SPI для приема/передачи можно выбрать как положительный фронт SCLK, а так и отрицательный. Но в самой передаче тип фронта синхроимпульсов не может меняться, на то он и синхро. Правильно ?
Покажи, пожалуйста, на рисунке MFM-потока как ты эти синхроимпульсы "видишь".
Считать это дело в импульсах - верный путь в тупик
Я считаю, что как раз-таки наоборот. По импульсам получаем пары полуинтервалов RR(11), RN(10), NR(01), NN(00). По ним определяем FM или MFM. Затем синхронизируемся на битовом уровне (эти пары полуинтервалов переводим в биты данных). Затем синхронизируемся на байтовом уровне (пока не "вкуриваю" как...).
Если бы это было так как изложено, то при данных 512 * 0xff для FM получался бы поток 1024 единиц и ни одного импульса с дисковода ;-)
при данных 512 * 0xff для FM получишь 512(байт)*8(бит)*2(перехода)=8192 импульса с частотой, равной удвоенной частоте синхроимпульсов
>при данных 512 * 0xff для FM получишь 512(байт)*8(бит)*2(перехода)=8192 импульса с частотой
и
>короткие импульсы на каждое изменение 0->1 или 1->0
у меня никак не складываются. Если у меня только единицы, откуда у меня "изменение 0->1 или 1->0" и соответствующие импульсы?
Вот смотри:
http://www.pcguide.com/ref/hdd/geom/z_encoding.gif
Сигнал записи, поступающий на дисковод - это тактовые сигналы, по которым происходит смена полярности записываемого на дискету сигнала.
С дисковода приходит считанный сигнал, усиленный и с нормализованной полярностью (т.е. не вверх-вниз-вверх, а обычные тактовые сигналы).
На то он и синхро, что четко определен по значению
Откуда эта аксиома?
По ним определяем FM или MFM. Затем синхронизируемся на битовом уровне
Зачем, простите, нам знать FM или MFM до синхронизации на битовом уровне?
Вы всё путаете. Синхронизация "на битовом" уровне нужна только для преобразования потока импульсов (например, для FM 125килобит в секунду) в поток нулей и единиц. Что в этих битах - нем не важно, важно что мы делаем выборку входного сигнала в нужное время. Например, для FM 10 мы сделаем выборку первого бита строго в положительный период сигнала, а для второго - в отрицательный. Это важно так как периоды по длительности могут плавать и заметно. Именно для этого и сущуствует FM и MFM и другие.
А потом этот поток бит мы уже декодируем, засинхронизировавшись по маркеру или по синхросбою.
Предыдущая картинка поясняла, как записываются еденицы.
b2m, Стоп! Мы начали с сигналов с дисковода. Причем тут магнитые домены. Если мы обсуждаем физику магнитной записи - там да, есть переходы 0->1 и 1->0.
Если мы говорим про получаемый с дисковода сигнал "read data" - никаких импульсов при переходах там нет. Там идет поток закодированных (FM или MFM) данных, стого как указано на твоей картинке FM/MFM/RLL
LeoN65816
04.10.2016, 14:03
а с дисковода приходят короткие импульсы на каждое изменение 0->1 или 1->0.
Совершенно верно! Причем на каждое изменение тока, а не данных! И где на этой картинке синхроимпульсы в MFM-потоке?
Это не так. С дисковода как раз приходит поток бит.
Найн!!!
Если бы это было так как изложено, то при данных 512 * 0xff для FM получался бы поток 1024 единиц и ни одного импульса с дисковода ;-)
Нет. В этом случае с дисковерта придут 512*8*2=8192 коротких импульса отрицательной полярности (логический 0) с периодом в половину бита данных (512*8 пар RR). В случае 512 * 0x00 для FM с дисковерта придут 512*8*1=4096 коротких импульсов отрицательной полярности (логический 0) с периодом в 1 бит данных (512*8 пар RN).
Совершенно верно! Причем на каждое изменение тока, а не данных! И где на этой картинке синхроимпульсы в MFM-потоке?
Ммм... отсутствующий синхроимпульс на картинке виден как голубая вертикальная чёрточка, розовая - соответственно бит данных.
Ну Вы меня совсем хотите запутать.
Вот Вам из практики: вот такой сигнал мы получаем с 30-го пина дисковода при чтении (на рисунке - RAWD). Анализатор сэмплирует на 100 Мгц. Это FM
http://oldpc.su/3/ttt.jpg
Я Вам гарантирую что между двумя синими полосками записан байт данных 0xff, а между синей и голубой - байт 0x00.
Где Вы тут видите какие-то переходы из 0->1 и обратно? Причем тут в каком виде это намагничено?
- - - Добавлено - - -
коротких импульса отрицательной полярности (логический 0) с периодом в половину бита данных
Вот покажите мне на выложенной картинке с анализатора "импульса отрицательной полярности (логический 0) с периодом в половину бита данных".
Я только замечу что длительность этого отрицательного импулься регламентируется документацией на дисковод и для советских дисководов составляет 1 мкс независимо от скорости записи (125 или 250 кбит/с)
LeoN65816
04.10.2016, 14:58
Если мы говорим про получаемый с дисковода сигнал "read data" - никаких импульсов при переходах там нет.
Как раз-таки дисковерт и выдает короткий импульс отрицательной полярности при чтении участка, на котором при записи была смена направления тока записи. Смотри в аттаче, это из даташита на флоп FD55 (показан MFM-поток).
Ммм... отсутствующий синхроимпульс на картинке виден как голубая вертикальная чёрточка, розовая - соответственно бит данных.
Хм. Хорошо. Ключевое слово "отсутствующий", а ведь у нас не синхросбой, а обычные данные! В случае FM-потока - да, мы указанные тобой синхробиты с дисковода получим. А в случае MFM-потока (указанные тобой "отсутствующие") синхробиты мы получим только на последовательных нулях (...000000000....), во всех остальных случаях (например, ...111111111... или ...10101010101...) мы синхробиты не получим! Верно? Это я к этому (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=886561&viewfull=1#post886561).
Я Вам гарантирую что между двумя синими полосками записан байт данных 0xff, а между синей и голубой - байт 0x00.
Совершенно верно!!!
Вот покажите мне на выложенной картинке с анализатора "импульса отрицательной полярности (логический 0) с периодом в половину бита данных".
Пожалуйста! Красным, 8 пар RR при записи байта 0xFF. А белым - с периодом в 1 бит данных, то есть 8 синхроимпульсов (8 пар RN) при записи байта 0x00.
Я только замечу что длительность этого отрицательного импулься регламентируется документацией на дисковод и для советских дисководов составляет 1 мкс независимо от скорости записи (125 или 250 кбит/с)
Ты же не путаешь "длительность" и "период", верно?
Как раз-таки дисковерт и выдает короткий импульс отрицательной полярности при чтении участка, на котором при записи была смена направления тока записи.
Еще раз - мне пофиг как оно там унутри дисковода магнитится. С дисковода идёт поток бит. Причем в нашем случае FM или MFM, никаких там "импульсов при переходе из 0 в 1 и обратно". Это я к тому, что FM/MFM у нас именно на выходе из дисковода, а не
Только надо учесть, что это реально записано на дискете (или блине жёсткого диска), а с дисковода приходят короткие импульсы на каждое изменение 0->1 или 1->0.
>А в случае MFM-потока синхробиты мы получим только на последовательных нулях
Да нет же, опять сначала. С дисковода (в линии связи) идёт поток бит. и при FM и при MFM мы ВСЕГДА получим синхробиты, только при MFM они иногда будут нулевые.
Вот наглядно: два бита данных и два единичных синхробита - в линии 1111, два бита данных и два нулевых синхробита - в линии 0101, два бита данных и ОДИН единичный синхробит - в линии 111. Улавливаете разницу?
- - - Добавлено - - -
Ты же не путаешь "длительность" и "период", верно?
Путаю ;-) Горячусь от Вашей упертости и нежелания видеть поток битов.
LeoN65816
04.10.2016, 15:57
С дисковода идёт поток бит.
Еще раз нет! Контроллер кодирует данные по FM- или MFM-закону в пары RR, RN, NR, NN. Дисковерт при записи их сглатывает, как только получает R-импульс, то меняет направление тока в головке, а при N ничего не делает (только проворачивает диск). При чтении в этом же самом месте дисковерт выдает R-импульс (1 мкс логический 0). Контроллер сэмплирует на своей частоте этот FM- или MFM-поток (эти пары) и декодирует в биты данных.
Я же привел картинки из даташита. Ну качни даташиты на другие дисководы, почитай, посмотри про nReadData, nWriteData, ну подумай.
Горячусь от Вашей упертости и нежелания видеть поток битов.
:) Эта, может наоборот? ;)
Ок, дальше спорить смысла нет. Уже пошли какие-то пары.
На вопрос "зачем Вы пристали к току в головке" вообще ответа нет. А если у меня вместо дисковода эмулятор, то что уже не FM/MFM получается?
А если у меня и не дисковод и не эмулятор, а просто канал данных с MFM кодированием, то что мне делать с даташитом на дисковод? ;-)
>Ну качни даташиты на другие дисководы, почитай, посмотри про nReadData
Ну дай мне ссылку на любую документацию с такими терминами "MFM-закон" и "кодирование данных по MFM-закону в пары RR, RN, NR, NN".
Пара у меня всегда одна, и это не пара, это синхробит и бит данных, которые образуют поток битов.
>Контроллер сэмплирует на своей частоте этот FM- или MFM-поток (эти пары)
Это вообще жесть. Особенно про "свою частоту". А как же синхронизация, а как же самосинхронизирующиеся методы кодирования. А как же data separator, который умеет эту "свою частоту" делать +-20% в зависимости от приходящих данных.....
Может, всё-таки, правильней, не "со своей частотой", а с частотой поступления синхробитов!?!?!?! Они, синхробиты, как ни странно, именно для этого существуют.....
И что значит "сэмплирует пары"? Делает не выборку бит, а выборку пар не бит? Жжёте.
Вопрос что же по Вашему есть "этот FM- или MFM-поток" Вы тоже постоянно разное говорите. Вот например,
>Контроллер кодирует данные по FM- или MFM-закону в пары RR, RN, NR, NN
что же такое эти "пары"? Если это пары бит, то по Вашей же логике FM/MFM поток - это поток пар бит, то есть поток бит.
LeoN65816
04.10.2016, 20:36
Денис, ты как практик бесспорно очень и очень много сохранил, сделал и исследовал по всяческой отечественной и буржуйской технике, и не одну "собаку съел" в этом деле. Как говорится, респект тебе и уважуха! ;)
Обрати внимание, я не оспариваю правильность заграбленных тобой на практике данных (#64 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887301&viewfull=1#post887301)), а указываю, что твоя практика прекрасно согласуется с теорией, завязанной на токах в головке (#51 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887279&viewfull=1#post887279), #53 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887285&viewfull=1#post887285), #58 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887292&viewfull=1#post887292)), на которую я и Дмитрий тебе указываем (и не мы эту теорию придумали).
В #64 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887301&viewfull=1#post887301) ты попросил меня указать - я указал (#65 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887307&viewfull=1#post887307)). В #55 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887288&viewfull=1#post887288) я попросил тебя показать эти синхробиты - ты так и не показал... Покажи, пожалуйста. Все ссылки (о которых ты просишь) в теме есть, тем более за сегодня. И еще раз прошу - подумай, пожалуйста, спокойно и размеренно.
P.S. Не кипятись, Денис. Тем более так, некрасиво это, не подобает тебе, тем более ты сам в других темах некоторых товарищей пытаешься образумить.
Да я и тут пытался образумить. Нет в MFM никаких пар, кроме пары синхробит и датабит.
Бесспортно, MFM заменил FM только для того, чтобы при намагничивании уменьшить число переходов.
Но мне, когда нужно поставить аккумулятор в машину, важно клемму "+" накинуть на контакт "+", а течет ток от + к - или от - к + не важно. Как и не важны электрохимические процессы в аккумуляторе.
Так и здесь, для меня (и для моих читалок HDD и FDD) все эти магнитные переходы и как оно там записано на диск - не важно. Важно что флоп/винт выдают мне битовый поток, который что в FM что в MFM состоит с последовательно идущих синхробита и датабита. И синхробит есть всегда, хотя, в MFM может быть, как и датабит, как "0" так и "1".
И нет там никаких пар, потому как это шаг в тупик (эта, якобы, пара, в MFM зависит от предыдущего бита, а это уже не пара, а триада или тетрада или какой там был еще более предыдущий датабит ;-) )
Дмитрий же вообще сказал что MFM - это физические данные на диске, а от флопа идут только переходы 0 в 1 и обратно.
Для меня что FM что MFM - это "синхронные" методы передачи данных, то есть биты идут всегда. И могут быть нулевыми, единичными, но за 40мкс с для FM мы получаем поток из 10 бит, а импульсов может быть и 5 и 8 и 9 и 10. И в этом потоке за 40мкс будет ровно 5 синхробитов и ровно 5 датабитов, которые я аппаратно выделяю и разбираю. Как бы кому-то не хотелось увидеть что синхробитов там не 5. И для MFM ровно также, только 10 бит "набегут" не за 40 мкс, а за 20 (для скорости 250 кбит/c).
И еще раз, количество переходов на диске, сократившееся при переходе с FM на MFM, никак не уменьшило количество синхробит в потоке между дисководом и контроллером: для 5 датабит синхробитов будет тоже ровно 5.
>и не мы эту теорию придумали
Такого "особого" видения этой простой теории, как у Вас, я даже в страшном сне не мог предположить.
В общем спор я закончил, ибо он бессмысленный. Я лучше пойду еще один формат добавлю в мою HDD MFM читалку. Чем пытаться понять откуда вдруг в достаточно простой теории нашлись какие-то пары и куда, оказывается, пропали синхробиты, хотя я их "вижу" программно ;-)
LeoN65816
04.10.2016, 22:58
Важно что флоп/винт выдают мне битовый поток
но за 40мкс с для FM мы получаем поток из 10 бит
Я уже в третий раз прошу тебя - покажи на своих и моих картинках этот "битовый поток".
а импульсов может быть и 5 и 8 и 9 и 10.
От 5 до 10.
И в этом потоке за 40мкс будет ровно 5 синхробитов и ровно 5 датабитов
Совершенно верно! Именно эти от 5 до 10 импульсов за 40 мкс и дадут ровно 5 синхробит и ровно 5 датабит!
Как бы кому-то не хотелось увидеть что синхробитов там не 5.
Ткни меня "мордой в г....": где я такое утверждал?
И для MFM ровно также, только 10 бит "набегут" не за 40 мкс, а за 20 (для скорости 250 кбит/c).
И еще раз, количество переходов на диске, сократившееся при переходе с FM на MFM, никак не уменьшило количество синхробит в потоке между дисководом и контроллером: для 5 датабит синхробитов будет тоже ровно 5.
Ну покажи на картинках синхробиты MFM.
В общем спор я закончил, ибо он бессмысленный. Я лучше пойду еще один формат добавлю в мою HDD MFM читалку. Чем пытаться понять откуда вдруг в достаточно простой теории нашлись какие-то пары и куда, оказывается, пропали синхробиты, хотя я их "вижу" программно ;-)
А как же это (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887271&viewfull=1#post887271)?
>Я уже в третий раз прошу тебя - покажи на своих и моих картинках этот "битовый поток".
Так я же показал для FM? Или надо еще для MFM сигнализатором снять?
>>Как бы кому-то не хотелось увидеть что синхробитов там не 5.
>Ткни меня "мордой в г....": где я такое утверждал?
"То есть не всегда на каждый бит данных приходится хотя бы по одному импульсу (синхроимпульсу, синхробиту)..."
Вот я и говорю что ВСЕГДА (если мы про битовый поток с 30-го пина) на датабит есть свой синхробит, что в FM, что в MFM.
Дальше цитаты не искал.
>Ну покажи на картинках синхробиты MFM.
Когда будет время - воткну анализатор и для MFM.
Но честно скажу: в HDD MFM читалке после определения начала потока я даже не проверяю правильность синхробит. я просто с нужного месте из потока беру только четные биты и из них собираю байты данных.
То есть все нечётные биты - синхробиты. Никуда они не пропадают.
То есть я бы эти синхробиты вообще всегда бы пропускал аппаратно, НО, тогда не увидеть синхросбой и сепаратор не всегда цепляется как "четный=датабит", но по синхросбою (или по маркеру) всегда выставляю начало потока на первый синхробит, чтобы синхробиты были нечётными.
А то что на Ваших последних рисунках (код Миллера) - так это Вы опять про то как это на магнитном диске. В нашей задаче это совсем неинтересно. Из этого дисковод за нас делает битовый поток. В котором всё не так, например, первый рисунок 4-я клетка слева на красном сигнале низкий уровень, а во второй клетке слева - высокий. А это датабиты первых двух _единиц_ "двоичного сигнала". На 30-м пине дисковода датабиты всегда РАВНЫ передаваемым данным.
LeoN65816
05.10.2016, 07:49
>Я уже в третий раз прошу тебя - покажи на своих и моих картинках этот "битовый поток".
Так я же показал для FM? Или надо еще для MFM сигнализатором снять?
Три раза я просил (точнее, четыре) - нет результата... На твоей единственной картинке из #64 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887301&viewfull=1#post887301) - последовательность импульсов, но не бит! Причем для FM-потока.
Пятый раз прошу - покажи где там биты ("битовый поток"). И для MFM, пожалуйста.
В оригинале (#51 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887279&viewfull=1#post887279)) "черным по белому" сказано и про FM, и про MFM:
Это в FM-потоке (http://www.pcguide.com/ref/hdd/geom/dataFM-c.html) термин "синхробит" применим: в начале первого полуинтервала каждого бита данных (хоть 1, хоть 0) идет синхроимпульс (первый R - кратковременный логический ноль с выхода nReadData дисковерта, говорящий о смене направления тока [верхние и нижние "черточки" на рисунке]), а затем в начале второго полуинтервала бита данных для 1 вторым идет еще один R, а для 0 вторым идет N - отсутствие импульса. Итак, если за единичный интервал бита данных поймали два импульса, то это однозначно бит данных 1, если же за единичный интервал поймали только один импульс, то это однозначно бит данных 0. То есть в любом бите данных есть хотя бы один импульс (синхроимпульс, синхробит).
А в MFM-потоке (http://www.pcguide.com/ref/hdd/geom/dataMFM-c.html) несколько по-другому... Там может быть 1 импульс на 1 бит (для ...111... будет ...NRNRNR..., для ...000... будет ...?NRNRN...), 1 импульс на 2 бита (для ...10... будет ...NRNN...), 2 импульса на 2 бита (для ...001... будет ...?NRNNR...), 2 импульса на 3 бита (для ...101... будет ...NRNNNR...). То есть не всегда на каждый бит данных приходится хотя бы по одному импульсу (синхроимпульсу, синхробиту)...
но за 40мкс с для FM мы получаем поток из 10 бит, а импульсов может быть и 5 и 8 и 9 и 10. И в этом потоке за 40мкс будет ровно 5 синхробитов и ровно 5 датабитов, которые я аппаратно выделяю и разбираю. Как бы кому-то не хотелось увидеть что синхробитов там не 5.
>>Как бы кому-то не хотелось увидеть что синхробитов там не 5.
>Ткни меня "мордой в г....": где я такое утверждал?
"То есть не всегда на каждый бит данных приходится хотя бы по одному импульсу (синхроимпульсу, синхробиту)..."
Вот я и говорю что ВСЕГДА (если мы про битовый поток с 30-го пина) на датабит есть свой синхробит, что в FM, что в MFM.
Дальше цитаты не искал.
Мое утверждение про MFM ты "приплеташь" к FM. Подтасовка фактов - нехорошо, Денис... :(
>Ну покажи на картинках синхробиты MFM.
Когда будет время - воткну анализатор и для MFM.
Но честно скажу: в HDD MFM читалке после определения начала потока я даже не проверяю правильность синхробит. я просто с нужного месте из потока беру только четные биты и из них собираю байты данных.
То есть все нечётные биты - синхробиты. Никуда они не пропадают.
То есть я бы эти синхробиты вообще всегда бы пропускал аппаратно, НО, тогда не увидеть синхросбой и сепаратор не всегда цепляется как "четный=датабит", но по синхросбою (или по маркеру) всегда выставляю начало потока на первый синхробит, чтобы синхробиты были нечётными.
Так все-таки, ты с выхода FDD/HDD получаешь "синхробиты MFM", или с выхода сепаратора?
Шестой раз прошу - покажи это на картинке.
А то что на Ваших последних рисунках (код Миллера) - так это Вы опять про то как это на магнитном диске. В нашей задаче это совсем неинтересно. Из этого дисковод за нас делает битовый поток. В котором всё не так, например, первый рисунок 4-я клетка слева на красном сигнале низкий уровень, а во второй клетке слева - высокий. А это датабиты первых двух _единиц_ "двоичного сигнала". На 30-м пине дисковода датабиты всегда РАВНЫ передаваемым данным.
Битовый поток, черный "график", длительность/ширина бита 2 клетки, слева направо: 11100010011000111101101101.
MFM-поток, красный "график", длительность полуинтервала R/N 1 клетка, слева направо: NRNRNNRNRNNRNNRNNRNRNNRNRNNRNRNRNRNNNRNRNNNRNRNNNR .
При чтении 250 кбит/с MFM: R состоит из 1 мкс логический ноль (тот самый импульс в даташите) и 1 мкс логическая единица, N состоит из 2 мкс логическая единица, т.е. битовый интервал NR=NN=RN=4 мкс.
При чтении 500 кбит/с MFM: R состоит из 0.5 мкс логический ноль (тот самый импульс в даташите) и 0.5 мкс логическая единица, N состоит из 1 мкс логическая единица, т.е. битовый интервал NR=NN=RN=2 мкс.
Сходится с даташитом на флоп?
До свидания. Думаю дискуссию имеет смысл приостановить до того момента, как Вы попытаетесь Вашу "теорию" применить на практике ;-)
LeoN65816
05.10.2016, 09:02
Глупо красное называть зеленым, верно? Вот где "упрямство и нежелание принимать"... :(
Думаю дискуссию имеет смысл приостановить до того момента, как Вы попытаетесь Вашу "теорию" применить на практике ;-)
Хорошо.
Хехе. Некрасиво сливаться вместо того, чтобы признать, что облажался. Хотя и признать не всем просто :)
Да дело Ваше как и что считать.
У меня есть две рабочие железки: одна читает флопики (пока только FM), вторая - MFM HDD.
Как учили нас философы - лучший способо проверить чьи-то предположения - практика. Я свои проверил. Железки работают. Если такой результат называется "облажался", то меня он всё-равно устроит ;-)
И потом, дискуссия она ведь нужна для поиска истины. Я вроде как уже что-то нашел. Может это и не истина, может я и облажался, но, тем не менее, я своё видение вопроса неоднократно подтвердил практически (в части наличия битового потока с дисковода и наличия в этом потоке синхробита для каждого датабита). Что для меня вполне достаточно и дальше в этом вопросе я ничего не ищу ;-)
Мой основной оппонент пока оперирует только картинками из разных мало имеющих к практической части нашего вопроса источников. Неаргументированные реплики зрителей, которые сделали эмулятор дисковода, но в этой теме не сочли возможным хоть что-то сказать по существу, мне интересны ровно настолько, насколько интересны реплики зевак-наблюдателей в принципе ;-)
И опять же, по началу темы я был уверен что здесь речь идет о практической реализации читалки дисков без LPT. Пока получается что я один здесь "облажался", в смысле получил положительный практический результат? Не вопрос, свалю-ка я из этой темы. Видимо у остальных участников темы какие-то другие интересы. ;-)
Я Вам гарантирую что между двумя синими полосками записан байт данных 0xff, а между синей и голубой - байт 0x00.
Абсолютно верно. Я когда поясняющую картинку вставил, поэтому и добавил, что с дисковода идут короткие импульсы на каждое изменение сигнала, показанное на картинке. Просто если представить 8 едениц подряд, то по картинке это будет 8 импульсов со скважностью 50%, а на самом деле приходят 16 импульсов (как у тебя на картинке) и скважность там далеко не 50%.
avivanov76
05.10.2016, 15:57
Бросайте спорить, лучше проверьте, правильно ли я понимаю :):
Когда мы пишем один бит, равный единице, то на дисковод (не на головку записи!) подается один импульс. Когда этот же единичный бит дисководом читается, мы с дисковода получаем один импульс. Если бит равен нулю - импульсов нет.
В исходном виде данные на дисковод не подаются. Они предварительно кодируются, а при чтении декодируются. При кодировании данные объединяются с синхросигналом.
Кодирование FM и MFM схоже. Есть интервал времени, отводимый на запись одного бита исходных данных. Этот интервал делится на две части. В первой пишется синхробит, во второй - бит данных.
Если метод записи FM, то синхробит всегда равен 1. Соответственно, бит данных, равный 1, записывается как два импульса, нулевой - как один.
Если метод записи MFM, то значение синхробита считается как x NOR y, где x и y - два подряд идущих бита данных. Соответственно, единичный синхробит получается только если идут подряд два нуля. Во всех остальных случаях синхробит есть, но он равен 0.
Чтобы определить начало блока данных используется некорректно сформированный синхробит (он же синхросбой). Например, пишется 0, хотя по правилам должен быть 1. Если вычисленный синхробит равен 0, и с дисковода получен 0, то это не синхросбой.
Правильно?
Я бы возразил по 6-му пункту. Используется не только синхросбой, а определённая последовательность бит данных, при кодировании которой один из синхробитов изменяется (синхросбой). Сам по себе синхросбой (вне нужной последовательности) может быть просто ошибкой записи/чтения.
А по 3-му пункту опять сейчас будут спорить. Вы написали как передается на /с дисковода. Пишется (магнитится) оно не совсем так.
- - - Добавлено - - -
Я когда поясняющую картинку вставил, поэтому и добавил, что с дисковода идут короткие импульсы на каждое изменение сигнала, показанное на картинке.
Да, там на картинке сигнал именно как пишется на диске, а не то что идёт с дисковода.
правильно ли я понимаю
1. в общем случае - зависит от метода кодирования
2. верно для FM
3. понятие "схоже" довольно растяжимое. MFM при (грубо говоря) практически одинаковой частоте смены магнитного направления на носителе даёт вдвое большую плотность записи, но требует, однако, более точного соблюдения интервалов
4. да, но не забываем про интервалы между импульсами
5. вообще неправильно
6. про синхросбой - верно, это когда обязательно должен быть импульс, но его (в течение заданного интервала) нет. Про "вычисленный синхробит" - не слышал такого.
2. верно для FM
Это как это? То есть для MFM clocking не "подмешивается"?
- - - Добавлено - - -
И что же в 5 неправильного?
Вас послушать так при записи байта 0x00 биты данных не передаются. Или, по Вашему, биты данных могут быть равны 0, а синхробиты не могут?
Как кодируется MFM.
Обозначим как R присутствующий импульс, а как N - отсутствующий. Каждый бит записываемых данных будет кодироваться двумя буквами:
еденица - всегда NR
нуль после еденицы - NN
нуль после нуля - RN
Таким образом, максимальная длина отсутствущих импульсов, т.е. N-ок - при кодировании бит данных 101, получим NRNNNR. Больше 3-х N - это уже синхросбой.
Если кодировать 10000 получим NRNNRNRNRN.
Интересно, что одни нули или одни еденицы выглядят одинаково. Важно, в какой момент мы начали анализировать.
Вы уходите от прямых вопросов:
1) Вы написали что пункт 2 ("При кодировании данные объединяются с синхросигналом") неверен для MFM. Следует ли понимать что Вы утверждаете что в MFM clocking не "подмешивается"?
2) что неправильно в пункте 5.
Поверьте, прочитать "Как кодируется MFM" можно в массе более достоверных источников. Но раз Вы утверждаете что пункт 5 неверен, хотелось бы понять что Вы считаете неверным.
>Обозначим как R присутствующий импульс, а как N - отсутствующий.
У меня есть другое предложение. Давайте поступим проще: присутствующий импульс, как и полагается в бинарной логике, назовем 1, а отсутствующий - 0.
И не будем придумывать совсем непонятное "бит записываемых данных будет кодироваться двумя буквами", или геометрическими фигурами, а скажем то же самое общепринято: "бит записываемых данных будет кодироваться двумя битами"
- - - Добавлено - - -
крайне не люблю ссылаться на википедию, но все-таки там (https://en.wikipedia.org/wiki/Modified_Frequency_Modulation) есть умная фраза:
"As is standard when discussing hard drive encoding schemes, FM and MFM encodings produce a bit stream which is NRZI encoded when written to disk. A 1 bit represents a magnetic transition, and a 0 bit no transition."
Заметьте, что FM что MFM дают нам "a bit stream". Можно я буду использовать перевод "поток битов" или "битовый поток"?
Который при записи на диск "is NRZI encoded" (те самые записываемые током магнитной головки переходы/transition при получении бита=1).
Ну и предлагаю в дальнейшем в данном контексте переходы, токи головки и прочее (то что после NRZI encoded) не рассматривать, так как внутрь дисковода вроде никто подключаться не планирует. И нас, соответственно, интересует только битовый поток, который мы получаем с 30-го пина дисковода.
avivanov76
06.10.2016, 01:47
Я бы возразил по 6-му пункту. Используется не только синхросбой, а определённая последовательность бит данных, при кодировании которой один из синхробитов изменяется (синхросбой).
Да, точно, это я упустил.
А по 3-му пункту опять сейчас будут спорить. Вы написали как передается на /с дисковода.
Ну да, имелось в виду кодирование перед подачей сигнала на дисковод.
2. верно для FM
Почему только FM? Данные в любом случае должны быть объединены с синхросигналом, потому что нужно как-то синхронизироваться при чтении - это раз, и нужно чем-то "разбавлять" данные чтобы уменьшить полосу сигнала при записи - это два. Головка записи это индуктивность. Чем выше частота сигнала, тем выше импеданс этой индуктивности и, соответственно, меньше ток записи (если считать напряжение на выходе усилителя записи постоянным). Если писать данные прямо как есть, полоса сигнала получится от почти 0 (длинная последовательность одинаковых бит) до половины частоты записи (101010...). Одинаково хорошо записать низкочастотные и высокочастотные составляющие просто не удастся и прочитать тоже.
3. понятие "схоже" довольно растяжимое
Я имел в виду схожесть в способе объединения синхробитов и битов данных.
5. вообще неправильно
Вы возьмите свой же пример: 1 0 1
Вычислим синхробиты. Чтобы вычислить самый первый, нужно знать предыдущий бит данных (который был перед единицей). Будем считать, что это был 0. Тогда первый синхробит 0 NOR 1 = 0, второй 1 NOR 0 = 0, третий 0 NOR 1 = 0. Теперь запишем перед каждым битом данных соответствующий ему синхробит: 01 00 01. Или можно записать буквами: NRNNNR. Так что здесь неправильно?
6. про синхросбой - верно, это когда обязательно должен быть импульс, но его (в течение заданного интервала) нет
А чем это отличается от ситуации, когда синхробита быть не должно, но он есть?
Ладно. Оба убедили в своей правоте. Умываю руки.
CodeMaster
06.10.2016, 16:31
Да, точно, это я упустил.
Оба убедили в своей правоте.
avivanov76, выложи список в последней редакции.
выложи список в последней редакции.
Пока ты не был модератором, звучало красивее, типа "если не трудно - выложи...". Или даже, не побоюсь этого слова, "Пожалуйста, выложи..." ;-)
Ничего личного....
- - - Добавлено - - -
А чем это отличается от ситуации, когда синхробита быть не должно, но он есть?
Я бы всё-таки отнёс этот случай к теоретически допустимым, но неизвестным на практике.
LeoN65816
06.10.2016, 18:05
Вот сигнал с 30 ноги дисковерта Teac FD-55GFR на АГАТе (напомню, что это MFM, 255.357 Кбит/с). На картинках вся нужная инфа есть.
Денис, в 7-ой раз прошу, как практик практика:
1. Покажи на своей и моих картинках "битовый поток".
2. Покажи на моих картинках "синхроимпульсы", особенно то одной полярности, то другой (здесь нет вводящего в соблазн сепаратора).
3. Что ты вообще на них видишь? :)
CodeMaster
06.10.2016, 18:33
Пока ты не был модератором, звучало красивее, типа "если не трудно - выложи...". Или даже, не побоюсь этого слова, "Пожалуйста, выложи..." ;-)
Ничего личного....
Я в этом разделе не модератор, можете и личную предъяву выкатить: "Ты меня уважаешь?"
Просто показалось консенсус найден и хотел застолбить этот момент.
Денис, в 7-ой раз прошу, как практик практика:
Но, видимо нет, понаблюдаем дальше...
>Вот сигнал с 30 ноги дисковерта Teac FD-55GFR на АГАТе (напомню, что это MFM, 255.357 Кбит/с). На картинках вся нужная инфа есть.
Да я почему-то вообще картинки не вижу.
>1. Покажи на своей и моих картинках "битовый поток".
На моей картинке я же показывал: в 64-ом сообщении темы видет поток бит -RAWD. Между двумя синими черточками в этом потоке 16 единиц, между синей и голубой поток бит 1010101010101010.
>2. Покажи на моих картинках "синхроимпульсы", особенно то одной полярности, то другой (здесь нет вводящего в соблазн сепаратора).
А уж не знаю чем тебя соблазняет сепаратор, но как в цифровом двоичном сигнале могут быть разные полярности!?!?!?! Вроде на троичную систему мы пока не перешли.....
>3. Что ты вообще на них видишь?
Ну что я вижу на своей картинке я описывать не буду, получится много букав. А вот на твоей картинке я не вижу ничего, ибо не вижу самой картинки
- - - Добавлено - - -
можете и личную предъяву выкатить: "Ты меня уважаешь?"
А смысл? Чтобы прочитать в ответ "Уважаю, но пить не буду" из-за удалённости? ;-)
Другие варианты ответа мне неинтересны даже более, чем этот ;-)
Можно я скажу, что вижу?
1010101001000100101010100100010010101
Могу ошибиться в пару бит (пишу с телефона), но смысл думаю понятен.
Декодировать это из mfm мы сможем только когда будем точно знать начало последовательности. Но учитывая, что по правилам кодирования после 01 не может быть 10 то я бы декодировал это так:
111000011110000111.
Не знаю, но я бы декодировал так (жирное - датабиты).
1010101001000100101010100100010010101
Но как уже правильно сказали нельзя достоверно декодировать без определения начала потока.
LeoN65816
06.10.2016, 20:03
Константин, а ты видишь "битовый поток" (с фиксированной длительностью/шириной битов) или последовательность импульсов? И про "синхроимпульсы" ответь, пожалуйста.
Денис, у всех .png является стандартом в любом браузере, и лишь у тебя очередное (просто смешное) увиливание...
но как в цифровом двоичном сигнале могут быть разные полярности!?!?!?! Вроде на троичную систему мы пока не перешли.....
Вот и я не вижу ни двуполярного сигнала, ни RZ. А кто-то на куче страниц "впаривает" про меняющий полярность синхро...
и лишь у тебя очередное (просто смешное) увиливание...
Да ты у меня вообще в списке игнорирования. Может поэтому картинки и не показывает. Это я так, от скуки, нажимаю иногда "Посмотреть сообщение"
- - - Добавлено - - -
А кто-то на куче страниц "впаривает" про меняющий полярность синхро...
Вранье это откровенное, ссылочку можно увидеть? Голословно-то любой может....
Константин, а ты видишь "битовый поток" (с фиксированной длительностью/шириной битов) или последовательность импульсов? И про "синхроимпульсы" ответь, пожалуйста.
Каждый импульс это 1, пауза между ними в зависимости от длительности 1, 2 или три нуля.
Насчет синхроимпульсов, в детали не вдавался, т.к. с точки зрения практики они никакого смысла не несут.
Синхропоследовательность для меня это особая последовательность бит, которая не может быть декодирована обычным способом.
Как ее находить? Использовать скользящее окно пропускающее через себя битовый поток, как только паттерн совпадает - это оно. Дальше пошли данные которые можно декодировать.
Я рассматриваю все алгоритмы кодирования как черный ящик с детерминированной связью между входом и выходом.
Использовать скользящее окно набивающееся битовым потоком
Как, и Вы, Брут!?!?!?! И Вы про "битовый поток"?!?!?! ;-):v2_dizzy_roll:
>Дальше пошли данные которые можно декодировать.
Причем, что характерно, дальше нечётные биты (синхробиты) можно просто игнорировать, не вникая что в них.
Да, это снижает устойчивость к сбойной записи, но на нормальной записи никаких проблем не будет.
с фиксированной длительностью/шириной битов
Не совсем так. фиксированная длительность (и очень короткая) как раз у импульса. У битов - окно (временной промежуток). Сначала окно синхробита, потом окно датабита. Так вот если в это окно есть импульс - значит этот бит (синхро или дата, в зависимости от того в чье окно) равен 1, если нет импульса - бит равен 0.
И поскольку поток окон непрерывен (как только закончилось окно синхробита, сразу начинается окно датабита, а как только закончилось окно датабита - сразу начинается окно следующего синхробита) - получаем непрерывный битовый поток.
При этом из-за сложностей физики у нас длина окна при чтении может "плавать"
Но как уже правильно сказали нельзя достоверно декодировать без определения начала потока.
По-моему, если встретились три нуля, то можно уже однозначно декодировать. Нуль после нуля не может кодироваться как 00.
01 00 01 возможная комбинация, декодируется как 101
.0 10 00 1. что по вашему означает 10 00?
Вот начало байта нельзя найти. Нужно синхросбой искать.
>По-моему, если встретились три нуля, то можно уже однозначно декодировать.
Это так кажется теоретически. А если эти три нуля образовались по нулю от каждой записи? то есть сначала мы записали что-то, оканчивающееся на 0. Потом писали что-то другое, тоже на 0, но получилось физически на диске чуть короче, а потом и третий раз. Тут хоть синхросбой может быть, хоть три нуля подряд.
>Нужно синхросбой искать.
Не синхросбой, а паттерн (определённый байт данных с синхросбоем). По причине, изложенной в начале этого поста.
- - - Добавлено - - -
.0 10 00 1. что по вашему означает 10 00?
Синхросбой? ;-)
И как Вы определите что это именно "Нуль после нуля не может кодироваться как 00", а не банальный синхросбой?
Да, и потом, даже без этого (мной в этом посте изложенного) есть ЕСЛИ, которое всё портит. ЕСЛИ встретились три нуля.
А на многих MFM дисках паттерн с сихнросбоем свой и на заголовок каждого сектора и на тело. А длина того заголовка всего ой, там Вы эти три нуля можете и не поймать никогда.
А еще ведь у нас намагничивание и фазовые сдвиги. У нас три нуля могут еще и таким способом возникнуть. Не говоря уже о дергании питания и т.д.
LeoN65816
06.10.2016, 21:19
Не совсем так. фиксированная длительность (и очень короткая) как раз у импульса. У битов - окно (временной промежуток). Сначала окно синхробита, потом окно датабита. Так вот если в это окно есть импульс - значит этот бит (синхро или дата, в зависимости от того в чье окно) равен 1, если нет импульса - бит равен 0.
И поскольку поток окон непрерывен (как только закончилось окно синхробита, сразу начинается окно датабита, а как только закончилось окно датабита - сразу начинается окно следующего синхробита) - получаем непрерывный битовый поток.
При этом из-за сложностей физики у нас длина окна при чтении может "плавать"
Угу, именно сепаратор с ФАПЧ именно это и делает, и на выходе у него битовый поток, каждый бит равной фиксированной длины. А на входе у него, равно как и на выходе дисковода битовый поток (каждый бит равной фиксированной длины) или последовательность импульсов?
Подрисуй на моей осциллограмме (у 2-4 масштаб получше) битовый поток (длина каждого бита фиксирована, и длины всех бит равны).
>и на выходе у него битовый поток, каждый бит равной фиксированной длины.
В корне не понимаете. ФАПЧ в сепараторе играет длиной окна (периодом SEPCLK).
Некоторые реализации выдают бит в SEPD (наличие или отсутствие импульса в нужный момент) строго с определённым зазором до фронта SEPCLK. Некоторые нет.
То есть если у нас бит "плавает" внутри своего окна с определённым зазором до границ окна - никто (и ФАПЧ) даже не парятся.
Соответсвенно никакой фиксированной длины бита нет, что верно как для размера окна, так и для интервала между импульсами при единичных битах (например, в 101001 интервал между первыми двумя импульсами не факт что будет строго в полтора раза меньше чем между 2 и 3, даже после сепаратора). И длина бита (размер окна) для каждого из этих пяти бит может быть как равной, так и заметно не равной.
Причем корректировка ФАПЧем (в сепараторе) длины окна чуть ли не под +-30%. Какая тут фиксированная длина чего-либо.
LeoN65816
06.10.2016, 21:48
Соответсвенно никакой фиксированной длины бита нет
Угу, оказывается при 250Кбит/с 4мкс бит (на том же выходе сепаратора) по указанию Дениса просто нет! А также на последовательных входах/выходах UART при 9600 бод 104.1(6) мкс бит тоже не существует! И т.д.
>А также на последовательных входах/выходах UART при 9600 бод 1.041(6) мкс бит тоже не существует!
Ну Вы совсем не практик, как я погляжу.
И в UART на _выходе_ передатчика и на _выходе_ записи контроллера дисковода всё есть, все интервалы соблюдаются (пока не берем предкомпенсацию), но после намагничивания и считывания этой намагниченности, или, для UART, например, при передаче через спутниковый канал, все эти мкс начинают "плавать". Иначе бы всё было просто и никаких ФАПЧ и прочее никто бы не придумывал...
LeoN65816 В общем я в очередной раз устал Вам объяснять что дважды два равно четыре. А от Ваших почти переходов на личности ("по указанию Дениса", "у тебя очередное (просто смешное) увиливание...") я уже не устал, а запарился. Поэтому, даже если висящий в теме tnt23 снова скажет что я "облажался и слился" - я закончил. Уже все, кроме Вас, в этой ветке, на википедии и еще чёрт знает где согласились на битовый поток, а Вы всё упираетесь. Может Вам надо практиковаться не на мне, а на читалке дисков?
- - - Добавлено - - -
Кстати, еще в тему Агатов (сорри за оффтопик).
Думаю всем будет полезно перечитать 2-3 страницы начиная с конца вот этой http://zx-pk.ru/threads/26990-aaa-i-rindex-i-vladeltsy-foruma/page3.html.
До упоминания разработчиков Агата.
avivanov76
07.10.2016, 14:26
Я бы всё-таки отнёс этот случай к теоретически допустимым, но неизвестным на практике.
В M2FM такой способ использовался практически (https://en.wikipedia.org/wiki/Modified_Frequency_Modulation, http://openpreservation.org/blog/2016/09/28/counting-ones-and-zeros/).
выложи список в последней редакции.
Это приказ? :v2_dizzy_army:
Но, видимо нет, понаблюдаем дальше...
Да тут, похоже, долго ждать придется. Ладно, попробую еще раз поискать консенсус.
Насколько я понимаю, сейчас всё уперлось в терминологию: с 30 ноги дисковода идет битовый поток или поток импульсов?
Предлагаю смотреть так: с точки зрения осциллографа по любому проводу передается сигнал, будь то выход UART, дисковода или телефонного модема. А битовый поток это вещь абстрактная: по проводам не передаются нули и единицы в чистом виде. По проводам передаются уровни напряжения, импульсы, или вообще колебания, фаза и амплитуда которых что-то означает. На осциллографе мы "видим" нули и единицы потому что мы знаем правила преобразования уровней, импульсов, интервалов между ними или чего-то еще в нули и единицы. Для UART и дисковода эти правила разные. И действия, которые нужно предпринять, чтобы выделить биты и заполнить ими сдвиговый регистр - разные. Поэтому в проводе не битовый поток, в проводе сигнал, содержащий битовый поток.
Понятно, что не хочется упоминать физический уровень, поскольку и так все понятно, но от этого физический уровень никуда не девается.
В M2FM такой способ использовался практически (https://en.wikipedia.org/wiki/Modifi...ncy_Modulation, http://openpreservation.org/blog/201...nes-and-zeros/).
Может быть, но это как-то совсем без ссылок на конкретную систему. Плюс там какой-то вообще замороченный формат.
Но вполне может быть.
с 30 ноги дисковода идет битовый поток или поток импульсов?
когда прожектором семафорят, то что там передают, азбуку Морзе или вспышки?
А так, конечно, всё дело в терминологии. VCC +3,3V то батарейки тоже можно считать импульсом. Вполне себе конечный. И вполне себе кратковременный, по сравнению со временем жизни человека ;-)
А так, конечно, всё дело в терминологии. VCC +3,3V то батарейки тоже можно считать импульсом. Вполне себе конечный. И вполне себе кратковременный, по сравнению со временем жизни человека ;-)
Можно ещё Дирака с Хевисайдом вспомнить... :D
висящий в теме tnt23 - не понял, что тебя так встревожило?
avivanov76
08.10.2016, 00:34
Может быть, но это как-то совсем без ссылок на конкретную систему.
Виноват, вот нормальные ссылки. Машина HP 9845 (http://www.hp9845.net/9845/), диск HP 9895A (http://www.hpmuseum.net/display_item.php?hw=262), обе ссылки с этой страницы http://openpreservation.org/blog/2016/09/29/8-inch-disks-hp9845-endeavour-success-at-last/ Еще, говорят, использовалось в Intel MDS 800
когда прожектором семафорят, то что там передают, азбуку Морзе или вспышки?
Глаза то видят вспышки. В точки и тире они уже в мозгу складываются. А по одиночной вспышке вообще не поймешь - это тире, переданное на большой скорости или точка на маленькой.
- не понял, что тебя так встревожило?
Да всё ждал каких-то слов по существу, кроме вброса на вентилятор
- - - Добавлено - - -
Глаза то видят вспышки. В точки и тире они уже в мозгу складываются.
Ну вот я и про то же. Мы про глазки или про анализ.
Да всё ждал каких-то слов по существу, кроме вброса на вентилятор
Бедняга. Я всего-то забыл вкладку в браузере закрыть, а ты вон как извелся.
Ну ничего, впредь постарайся просто не сливаться вместо признания своей неправоты.
Да с неправотой разобрались, забывчивый ты наш. И я так и знал что про вброс возражений не будет ;-)
avivanov76
08.10.2016, 16:32
Ну вот я и про то же. Мы про глазки или про анализ.
Мы про анализ. Того что нам дали глазки. Ведь если бы прожектор семафорил непосредственно точками и тире, мы бы по одиночной посылке могли судить что это - точка или тире.
И если бы то, что приходит с дисковода было непосредственно битовым потоком, то зачем понадобились бы все эти пляски с сепаратором и ФАПЧ?
А так у нас приходит с дисковода последовательность импульсов, положение которых из-за свойств материала диска, неравномерности вращения и еще кучи причин "плавает" по времени. Мало того, что нужно какое-то железо, чтобы выделять из нее битовый поток, мы ведь в результате можем или получить синхросбой или выделить из нее совсем не тот битовый поток, который был записан. Так правильно ли эту последовательность импульсов называть битовым потоком?
(Кстати по каналу чтения и сепараторам неплохой цикл статей в журнале "Радиолюбитель Ваш компьютер" за 1999 год, номера с 4 по 8. И там считается, что на выходе дисковода "сигнал MFM").
>И если бы то, что приходит с дисковода было непосредственно битовым потоком, то зачем понадобились бы все эти пляски с сепаратором и ФАПЧ?
Существует много схем без сепаратора и без ФАПЧ.
Или Вы хотите сказать что поток синхро и дата битов с дисковода - это не битовый поток, а этот же электрический сигнал после сепаратора с ФАПЧ - уже битовый поток?
>Так правильно ли эту последовательность импульсов называть битовым потоком?
Несомненно правильно. Логика предельно проста: мы пишем/читаем "FM/MFM encoded data", которые образуют "data stream". поэтому, как мне кажется слово "поток" вполне уместно.
Поскольку мы передаем в этом потоке биты (синхро- и дата-), про данный поток вполне правильно сказать битовый поток. И именно как битовый поток мы его анализируем, когда ищем "desync" по паттерну (набору битов).
А то, что "в физике" этот битовый поток выражен импульсами, наличием или отсутствием тока - не изменяет сущности этого битового потока.
И даже если мы перейдём на уровень ниже и начнём называть то что идет с дисковода "потоком электронов" или "движением заряженных частиц" или даже, если угодно, "электрическим отражением намагниченности диска", то на определённом, более высоком уровне (на котором мы и будем работать с этим потоком, с этими данными) это всё-равно так и будет битовый поток (bitstream).
- - - Добавлено - - -
Ведь если бы прожектор семафорил непосредственно точками и тире, мы бы по одиночной посылке могли судить что это - точка или тире.
А Вы утверждаете что при наличии определённого навыка принимающий по длительности одиночной посылки не справится отличить точку от тире?
CodeMaster
08.10.2016, 18:10
А Вы утверждаете что при наличии определённого навыка принимающий по длительности одиночной посылки не справится отличить точку от тире?
Это при некоторой стандартизации. А если передаёт эстонский моряк, то точку легко перепутать с тире ;-)
avivanov76
09.10.2016, 02:22
Да, смешно получилось. Оказывается, "серьёзные инженеры из Shugart" как ни в чем не бывало называют поток импульсов - битовым потоком (ftp://ftp.eskimo.com/home/mzenier/cd-8002-1.pdf) ;)
The bit stream transferred from the disc to the controller consists of composite clock and data bits.
И не парятся ;) И в описании сепаратора данных контроллера DP8473 (http://info-coach.fr/atari/hardware/_fd-hard/AN-505.pdf) тоже не парятся и пишут
incoming data stream
И хотя едва ли дисковый контроллер переварит битовый поток с выхода UART, пусть и сформированный по правилам MFM, (они все же заметно отличаются), я тоже решил не париться :)
Потому что импульсы нас волнуют только на уровне их обнаружения и попадания/непопадания в окно детектирования. Если мы этот уровень прошли, то нас действительно уже интересуют нули и единицы и не будет большим преступлением назвать входной поток битовым.
Я этих "серьёзных инженеров из Shugart" побаиваюсь. У них на Fig 1 для FM на каждый бит 2 мкс (4 на пару синхро+дата). У меня же получается 4 мкс на каждый бит (8 на пару).
Ну и датарейт везде для FM пишется 125, а у этих товарищей 250....
>не будет большим преступлением назвать входной поток битовым.
В конце концов наличие или отсутствие импулься - это всего лишь 1 или 0 значение бита. А я лично не вижу особой разницы между "стакан наполовину пуст" и "стакан наполовину полон".
avivanov76
09.10.2016, 13:24
Инженеры Shugart пишут про 8-дюймовые диски. Там даже при FM влезает 26 секторов по 128 байт на дорожку. А если посмотреть документацию на контроллеры FD197x или, например, статью про КР1818ВГ93 в МПСиС 1986 №3, то там будет указано две тактовых частоты и для 2МГц в FM будет 4 мкс на пару "синхробит + бит", а в MFM - 2 мкс.
Инженеры Shugart пишут про 8-дюймовые диски.
Тады ой, я это просмотрел :-(
- - - Добавлено - - -
И хотя едва ли дисковый контроллер переварит битовый поток с выхода UART,
Кто-то где-то упоминал КНГМД на основе 8251... то есть они вроде как выход с UART подавали на дисковод. И что-то даже у них при этом работало....
avivanov76
09.10.2016, 14:40
Кто-то где-то упоминал КНГМД на основе 8251...
Видимо, контроллер для "Специалиста"
http://publ.lib.ru/ARCHIVES/M/''Modelist-konstruktor''/''Modelist-konstruktor'',1989,N10.%5bdjv-fax%5d.zip
Но там пара одновибраторов выделяет из FM тактовые импульсы и формирует битовый поток, требующийся для КР580ВВ51. А я говорил про то, что хотя на выходе дисковода "битовый поток" и на выходе UART "битовый поток", попытка подменить одно другим скорее всего не прокатит, потому что "единицы" шириной во всю битовую позицию с выхода UART обычным дисковым контроллером детектироваться не должны. ;)
Ну вот мы так плавненько и подошли к сути ;-)
То есть, если, конечно, я Вас правильно понял, настоящим битовым потоком Вы считаете только то, в чем "единицы" шириной во всю битовую позицию.
А если единица короче, чем битовое окно, то это уже не битовый поток. Правильно я Вас понял?
avivanov76
09.10.2016, 19:57
А если единица короче, чем битовое окно, то это уже не битовый поток. Правильно я Вас понял?
Я прям чувствую какой-то подвох. Вы небось сейчас скажете что-нибудь вроде: "так нет же никакой разницы в длительности единицы; определение значения сигнала происходит по фронту тактового импульса"?:v2_blink:
Ну в нашем случае вроде не по фронту.
Мне просто интересно почему Вы делаете разницу: вот это - битовый поток, а вот это (хотя многие и его так называют) - совсем не битовый. Именно об этом, как мне кажется, не смог сказать LeoN65816.
А тут мне показалось что Вы сформулировали критерий, определили разницу.
Просто в возражениях "это не битовый поток" я-то всё ждал продолжения "потому что ..."
А тут вроде почти дождался и хотел конкретно определиться с этим "потому что", чтобы дальше было что _предметно_ обсуждать. Пока же получалось что-то из серии "я не знаю как надо, но Вы делаете (называете) это неправильно". Или "уж мы-то знаем что ты облажался, но в чем не скажем, надо же тему читать". Оба варианта не от Вас, но это всё-равно огорчало, несмотря на поддержку википедии и инженеров из Шугарта ;-)
avivanov76
09.10.2016, 21:18
Мне просто интересно почему Вы делаете разницу: вот это - битовый поток, а вот это (хотя многие и его так называют) - совсем не битовый.
Ну, хотя бы потому, что если единица короче битового окна, то в пределах окна у нас получается два состояния: и 0 и 1. Возникает неопределенность - а в какой, собственно, момент времени железо должно определять текущее значение. Особенно, как в случае с сигналом с дисковода, если импульс узкий и "гуляет" по битовому окну. В случае с UART ситуация выглядит проще - можно защелкнуть в какой-нибудь триггер значение в середине битового окна и дело в шляпе. Поступать так с сигналом с дисковода мы не можем, мы очень быстро защелкнем не то состояние. Значит, схема должна быть построена иначе. Мы должны ловить именно факт присутствия импульса в окне, то есть определить его передний и задний фронты, убедиться что расстояние между ними какое-то разумное (то есть это не случайная "иголка") и что оба фронта находятся внутри окна.
Собственно из-за того, что детектятся вроде бы одинаковые битовые потоки по разному, и хочется их считать разными :)
Мне кажется Вы преувеличиваете разницу. Вот на что я бы обратил внимание: в обоих случаях для нам критически важно определить размеры окна. В случае UART при определенных особенностях канала и реализации окно тоже может плавать как по длине, так и смещаться. Да, при старт-стопной реализации UART и жесткой фиксации скорости передачи это незаметно . При длительной же передаче никто не гарантирует что наша выборка в середине окна со временем не может оказаться на границе окна.
В КНГМД при условии четкого понимания границы окна нам тоже достаточно защелкнуть тригером импульс в течении этого окна и считать выход этого тригера на заднем фронте окна. С учетом того что этот импульс формируется одновибратором в дисководе вероятностью иголки можно в большинстве случаев пренебречь. В отличии от UART тут у нас и скорость передачи может плавать.
И, опять же, разница схем обуславливается еще и тем, что в случае UART у нас асинхронная передача, а в нашем случае - синхронная. Соответственно совсем по разному определяется и момент времени, в который железо должно определять текущее значение. Так что асинхронный битовый поток и синхронный битовый поток - они уже разные.
Поэтому я целиком с Вами согласен что потоки в нашем случае и в случае UART - разные. Но почему в одном случае у Вас не вызывает возражение "битовый", а в другом - вызывает, я пока не понял.
avivanov76
11.10.2016, 03:20
Но почему в одном случае у Вас не вызывает возражение "битовый", а в другом - вызывает, я пока не понял.
Знаете, рационального объяснения не нашлось :) Я почти не встречался с импульсной логикой, поэтому в голове прочно засела потенциальная :) И при словах "битовый поток" сам собой всплывает NRZ-L поток. Хотя безусловно и NRZ и импульсный поток - это битовые потоки, хотя и кодирующиеся по-разному. Возможно, попадись мне в начале 90-х картинка с 9 разными кодировками одного битового потока как здесь (https://en.wikipedia.org/wiki/Line_code), у меня бы сейчас не было этого возражения.
При чтении 250 кбит/с MFM: R состоит из 1 мкс логический ноль (тот самый импульс в даташите) и 1 мкс логическая единица, N состоит из 2 мкс логическая единица, т.е. битовый интервал NR=NN=RN=4 мкс.
При чтении 500 кбит/с MFM: R состоит из 0.5 мкс логический ноль (тот самый импульс в даташите) и 0.5 мкс логическая единица, N состоит из 1 мкс логическая единица, т.е. битовый интервал NR=NN=RN=2 мкс.
Сходится с даташитом на флоп?
Мне кажется, Вас цифры FD-55 ввели в заблуждение. У какой-нибудь "Электроники МС5305" максимальная длительность импульса 1,5 мкс, так что уже не будет соотношения 1:1.
Угу, именно сепаратор с ФАПЧ именно это и делает, и на выходе у него битовый поток, каждый бит равной фиксированной длины.
В некоторых сепараторах длительность импульса старались искусственно уменьшить. Поскольку "наползание" импульса правым фронтом на границу окна детектирования у некоторых контроллеров считается ошибкой чтения, выгодно иметь этот импульс максимально коротким, чтобы расширить диапазон, в котором этот импульс может "гулять". И сепаратор вовсе не обязан "выравнивать" длительность импульсов. Важен только факт наличия или отсутствия импульса внутри окна детектирования.
Угу, оказывается при 250Кбит/с 4мкс бит (на том же выходе сепаратора) по указанию Дениса просто нет!
Если диск крутился на 10% быстрее чем надо, не в силах сепаратора растянуть время и вернуть битовой позиции длительность 4 мкс. Но у сепаратора есть функция восстановления тактовой частоты. Частота будет пропорционально повышена, окна детектирования уменьшены, и чтение бита пройдет на 10% быстрее, как и запись данных в сдвиговый регистр.
Знаете, рационального объяснения не нашлось
Понял. Спасибо. тогда за консенсус! ;-)
LeoN65816
02.11.2016, 13:41
О синхроимпульсах (#65 (http://zx-pk.ru/threads/26895-chtenie-diskov-bez-agata.html?p=887307&viewfull=1#post887307)) - в аттаче (отсюда (http://www.pk8020.narod.ru/docs/techref.htm) и отсюда (http://www.pk8020.narod.ru/docs/mics/pics.html)).
avivanov76
03.11.2016, 14:43
Давайте я тогда к этому рисунку добавлю окна данных и синхронизации, чтобы было видно, что в каждом битовом элементе есть две части и каждый импульс кодирует определенный бит - бит данных или бит синхронизации. Причем, наличие импульса это 1, а отсутствие - 0. То есть, битовый поток будет 0101000100101001.
58668
LeoN65816
31.12.2016, 22:31
http://zx-pk.ru/threads/26328-planiruyu-sdelat-fdd-emulyator-na-atmega8.html?p=863911&viewfull=1#post863911
http://info-coach.fr/atari/hardware/FD-Hard.php
LeoN65816
18.01.2017, 06:32
Интересный момент (http://zx-pk.ru/threads/27312-tysyacha-plastinok.html).
shattered
24.01.2017, 02:01
Кстати, некоторые диски из той "тысячи" -- с Агата. Экспериментирую с a8rawconv, вроде что-то распознает.
A8 raw disk conversion utility v0.92
Copyright (C) 2014-2016 Avery Lee, All Rights Reserved.
Licensed under GNU General Public License, version 2 or later.
Reading SuperCard Pro image: work/A7-02x5.scp
0 (16) | 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8
1 (16) | 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11
2 (16) | 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3
3 (16) | 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13
4 (16) | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
5 (16) | 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13
6 (16) | 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6
7 (16) | 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9
8 (16) | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0
9 (16) | 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11
10 (16) | 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2
11 (16) | 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7
12 (16) | 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11
13 (16) | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0
14 (16) | 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4
15 (16) | 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9
16 (16) | 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
17 (16) | 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3
18 (16) | 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8
19 (16) | 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2
20 (16) | 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
21 (16) | 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5
22 (16) | 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
23 (16) | 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9
24 (16) | 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4
25 (16) | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
26 (16) | 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11
27 (16) | 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5
28 (16) | 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1
29 (16) | 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
30 (16) | 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10
31 (16) | 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5
32 (16) | 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1
33 (16) | 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5
34 (15) | 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9
Writing Apple II disk image (DOS 3.3 ordering): work/a7-02.do
WARNING: Missing sectors not supported by DSK/DO format. Writing out null data.
WARNING: Track 34: missing sectors: 11
1 missing sector, 0 sectors with errors
% ./a2ls work/a7-02.do
Disk Volume 254, Free Blocks: 244
B 092 EVOLUTION
A 079 DINO
59520
LeoN65816
25.01.2017, 11:30
http://firmware.altervista.org/Data%20Encoding%20and%20Decoding.htm
shattered
25.01.2017, 23:47
Первый попавшийся 840K диск более или менее успешно прочитался SAMdisk. Действительно ли там есть address mark 0x6B90 -- это вопрос...
80 Cyls 2 Heads:
250Kbps MFM, 21 sectors, 256 bytes/sector:
0.0 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
1.0 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10
2.0 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6
3.0 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Warning: unknown MFM address mark (6B90) at offset 2 on cyl 4 head 0
4.0 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10
5.0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
6.0 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
7.0 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2
8.0 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
9.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0
10.0 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12
11.0 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4
12.0 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
13.0 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8
14.0 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
15.0 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
16.0 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6
17.0 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
18.0 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
19.0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
20.0 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
21.0 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
22.0 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
23.0 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
24.0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0
25.0 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12
26.0 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4
27.0 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
28.0 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7
29.0 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
30.0 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Warning: unknown MFM address mark (9533) at offset 4 on cyl 31 head 0
31.0 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6
32.0 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
33.0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
250Kbps MFM, 31 sectors, 256 bytes/sector:
34.0 11 12 13 14 15 16 17 18 19 1[r] 20 2[r] 0 3[r] 1[r] 4[r] 2[r] 5[r] 3[r] 6[r] 4[r] 7[r] 5[r] 8[r] 6[r] 9[r] 7[r] 10[r] 8[r] 9[r] 10[dc,r]
250Kbps MFM, 21 sectors, 256 bytes/sector:
35.0 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
36.0 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8
37.0 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
38.0 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7
39.0 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15[nd]
40.0 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2
41.0 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11
42.0 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
43.0 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7
44.0 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
45.0 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
46.0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
47.0 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10
48.0 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
49.0 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6
50.0 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
51.0 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4
52.0 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12
53.0 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7
54.0 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
55.0 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2
56.0 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11
57.0 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
58.0 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6
59.0 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
60.0 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
61.0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
62.0 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4
63.0 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8
64.0 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
65.0 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
66.0 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
67.0 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11
68.0 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
69.0 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
70.0 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
71.0 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
72.0 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
73.0 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
74.0 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
75.0 17 18 19 20 0 1 2[+320] 3[nd] 4 5 6 7 8 9 10 11 12 13 14 15 16
76.0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
250Kbps MFM, 40 sectors, 256 bytes/sector:
77.0 4 5 6[r] 6[r] 7[r] 7[r] 8[r] 8[r] 9[r] 9[r] 10[r] 10[r] 11[r] 11[r] 12[r] 12[r] 13[r] 13[r] 14[r] 14[r] 15[r] 15[r] 16[r] 16[r] 17[r] 17[r] 18[r] 18[r] 19[r] 19[r] 20[r] 20[r] 0[r] 0[r] 1[r] 1[r] 2[r] 2[r,+810] 3[r] 3[nd,r]
250Kbps MFM, 21 sectors, 256 bytes/sector:
78.0 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3[dc] 4 5 6 7 8
79.0 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12
250Kbps MFM, 19 sectors, 256 bytes/sector:
0.1 14 15 16[m2,dc] 17 18 19 20 0 1 2[m2,dc] 4 5[m2,dc] 6[m2,dc] 7 8 9 10[m2,dc] 12 13
diff (16): =92 -16 =148
diff (2): =5 -251
diff (5): =69 -187
diff (6): =69 -187
diff (10): =37 -219
250Kbps MFM, 21 sectors, 256 bytes/sector:
1.1 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
2.1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3
3.1 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
4.1 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6
5.1 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
6.1 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7
7.1 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
250Kbps MFM, 22 sectors, 256 bytes/sector:
8.1 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5[r] 6 5[nd,r]
250Kbps MFM, 21 sectors, 256 bytes/sector:
9.1 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
10.1 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
11.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
12.1 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
13.1 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
14.1 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
15.1 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11
16.1 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2
17.1 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
18.1 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6
19.1 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
20.1 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10
21.1 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
22.1 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
23.1 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
24.1 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
25.1 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
250Kbps MFM, 41 sectors, 256 bytes/sector:
26.1 2 3[r] 3[r] 4[r] 4[r] 5[r] 5[r] 6[r] 6[r] 7[r] 7[r] 8[r] 8[r] 9[r] 9[r] 10[r] 10[r] 11[r] 11[r] 12[r] 12[r] 13[r] 13[r] 14[r] 14[r] 15[r] 15[r] 16[r] 16[r] 17[r] 17[r] 18[r] 18[r] 19[r] 19[r] 20[r] 20[r] 0[r] 0[r] 1 24[nd]
250Kbps MFM, 21 sectors, 256 bytes/sector:
27.1 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
28.1 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
29.1 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
30.1 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11
31.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0
32.1 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
33.1 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
250Kbps MFM, 34 sectors, 256 bytes/sector:
34.1 6 7 8 9 10 11 14[r] 12 15[r] 13 16[r] 14[r] 17[r] 15[r] 18[r] 16[r] 19[r] 17[r] 20[r] 18[r] 0[r] 19[r] 1[r] 20[r] 2[r] 0[r] 3[r] 1[r] 4[r] 2[r] 5[r] 3[r] 4[r] 5[nd,r]
250Kbps MFM, 21 sectors, 256 bytes/sector:
35.1 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
36.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
37.1 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
38.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
39.1 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10
40.1 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
41.1 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6
42.1 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
43.1 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4
44.1 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12
45.1 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
46.1 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
47.1 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
48.1 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
49.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0
50.1 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
51.1 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
52.1 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
53.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
54.1 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10
55.1 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
56.1 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
57.1 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
58.1 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4
59.1 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11
60.1 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
61.1 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
62.1 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
63.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
64.1 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
65.1 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10
66.1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
67.1 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
250Kbps MFM, 22 sectors, 256 bytes/sector:
68.1 20 0 1 2 3 4 5 6 7 8 231 9 10 11 12 13 14 15 16 17 18 19
250Kbps MFM, 21 sectors, 256 bytes/sector:
69.1 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2
70.1 7 8 9 10 11 12 13 14 15 16[m2,dc] 17 18 19 20 0 1 2 3 4 5 6
diff (16): =150 -106
71.1 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11
72.1 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14[+317] 15[nd]
73.1 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3
74.1 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
75.1 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9
76.1 14 15 16 17 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13
77.1 18 19 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
78.1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1
79.1 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0 1 2 3 4 5
shattered
06.07.2017, 01:43
Улучшил код чтения формата 840K -- теперь читаются образы .hfe, сконвертированные из .aim инструментом agath-aim-to-hfe.pl (http://www.torlus.com/floppy/forum/viewtopic.php?f=19&t=1385).
Причешу и отправлю автору SAMdisk.
GARNIZON
08.07.2017, 00:08
Кстати, некоторые диски из той "тысячи" -- с Агата. Экспериментирую с a8rawconv, вроде что-то распознает.
вот это да..... я несколько лет разыскивал игру evolution. Так как автор игры вот тут её вспоминал :
http://agatcomp.ru/Gamez/Shamus.shtml
Цитата:
Одним из первых, более или менее «профессиональных продуктов» была переделка PCшного Evolution - игра из пяти уровней, амеба должна была поедать корм увеличиваясь в размерах, мышь - собирать сыр, бобер - проплыть между крокодилов, обезьяна - сбивать бананы, а человек отстреливался от пришельцев. На этой игре отработали технику работы со спрайтами, заодно «изобрели» алгоритм проверки натыкания на препятствия на черно-белом экране: вывести спрайт на черный фон через XOR а потом сравнить то что на экране с оригиналом. Если не совпадает - значит натолкнулись на что-то белое )) Ну и родилось название AKM GameSoft.
И тут такая удача, на вашем диске она есть, спасибо!
А еще что-то удалось вытянуть из агатовских дисков?
shattered
09.07.2017, 01:10
есть немного из той же пачки, что и диск с evolution - те, что прочлись без ошибок: 61577.
a7-01.do Disk Volume 254, Free Blocks: 108 0 errors
*B 32831 bejsik-a7
*A 32772 AUTOEXEC
*B 125 STAR BLASER
*A 020 dino-3
*B 036 SNAKE.EXE
*A 002 rekl.(d)
*A 082 dino-2
*A 016 dino-2(|kz)
a7-04.do Disk Volume 254, Free Blocks: 30 [WARNING: Track 32, sector 15: 3/4 bad sector reads discarded at position 0.96.]
*A 002 MENU
*B 081 BOLO1
*B 044 PUSHER
*B 036 SNAKE.EXE
A 080 DINO
*A 011 PITON
*A 063 KLARNON
*A 028 morskoj boj
*A 033 piton
*A 007 slowa
a7-07.do Disk Volume 254, Free Blocks: 133 0 errors
A 002 HELLO
B 045 G(1)
B 088 G(2)
*B 139 CANNONBALL BLITZ
*B 081 SNAKE BYTE
*B 011 MENU
=
for pravetz?
a7-09.do Disk Volume 254, Free Blocks: 0
B 010 TEST.OBJ
*B 011 MENU
*B 086 SPY'S DEMISE
A 003 START1
A 007 U1
B 010 FEX
*B 101 PANIC
*B 053 TETRIS'
*B 087 CUBIT
T 002 START
A 051 KLAV1
A 042 KLAV2
A 025 TEST.FEX
T 001 sa{a
GARNIZON
10.07.2017, 11:59
А нельзя ли заполучить и плохо прочитавшиеся образы 140?
840 как я понимаю тоже есть несколько?
И еще, а не сможем договорится после окончательной сортировки, о передаче мне на время агатовских дисков, я бы их вычитал с гарантией своей читалкой:
http://agatcomp.ru/Hard/bridge.shtml
shattered
13.07.2017, 11:04
Заполучить можно, но на форум они не влезут -- один образ в сыром виде .scp - 11-12 мб (5 проходов чтения каждой дорожки). Что-нибудь придумаю. 840K диск нашелся пока только один.
Одолжить тоже можно, не знаю только - когда :)
shattered
14.07.2017, 11:06
Кстати, a7-02.do частично битый:
WARNING: Missing sectors not supported by DSK/DO format. Writing out null data.
WARNING: Track 34: missing sectors: 11
a7-07.do и a7-09.do -- для Apple (а скорее, для Правца).
GARNIZON
26.07.2017, 23:05
Одолжить тоже можно, не знаю только - когда
Да без разницы, главное чтобы это когда-то случилось.
Кстати, a7-02.do частично битый:
Я бы не стал с ходу обвинять диск, скорее всего просто дорожка в сторону уехала.
Такое бывает на 140Кб. Даже проги типа "корректор смещения" существовали.
Просто не знаю чем вы читаете, кстати расскажите каким инструментарием пользуетесь - очень интересно, на форуме не нашел информации.
Скажем если чем-то типа KryoFlux или SuperCard Pro, то уже неоднократно был опыт что
вроде как диск битый при чтении ими - а я потом настоящем приводом 140 перечитываю все без единой ошибочки.
shattered
27.07.2017, 00:35
железо -- SuperCard Pro + Panasonic JU-475-5 (есть и другие дисководы, но этот основной)
софт -- Aufit (для сортировки "PC" - "не PC" и красивых картинок), a8rawconv (для перегона в формат .do), samdisk, HxC. в samdisk потихоньку дописываю поддержку формата 840к (пока не уверен в ней до конца)
ссылки на софт
http://info-coach.fr/atari/software/pc-projects/Aufit.php
http://atariage.com/forums/topic/231835-a8rawconv-a-new-raw-disk-conversion-utility/
https://bitbucket.org/whizzosoftware/a8rawconv
http://simonowen.com/samdisk/
https://github.com/simonowen/samdisk
LeoN65816
05.10.2017, 01:19
http://www.fpga-cpld.ru/miler.html
GARNIZON
11.12.2017, 08:37
Улучшил код чтения формата 840K -- теперь читаются образы .hfe, сконвертированные из .aim инструментом agath-aim-to-hfe.pl (http://www.torlus.com/floppy/forum/viewtopic.php?f=19&t=1385).
Причешу и отправлю автору SAMdisk.
Можно про это подробнее? Удалось ли причесать, как сейчас чтение, добавлено ли в SAMdisk? Ну и вообще как с этим сейчас дела обстоят...
shattered
11.12.2017, 22:11
да никак. ждет своего года, месяца, дня и часа, а тем временем я в https://vk.com/yebenya залез :)
GARNIZON
11.12.2017, 23:39
Ясно, я то думал ей и вправду можно 840 агатовские прочитать хоть как-то
http://forum.agatcomp.ru//viewtopic.php?id=126
shattered
12.12.2017, 00:02
как-то -- можно, если не лень собрать samdisk с патчем: https://github.com/shattered/samdisk/commit/e4a1ef315779a698be38597b158b3a30929369c7
за результат не отвечаю
LeoN65816
04.02.2018, 23:20
https://www.techtravels.org/wp-content/uploads/pefiles/SAMSUNG-SFD321B-070103.pdf
Про импульсы чтения/записи расписано в п.5.3.6 на стр.18 и в п.5.4.4 (все сказано "русским языком") на стр.20.
shattered
11.02.2018, 11:20
https://wiki.reactivemicro.com/Applesauce -- мега-проект для чтения дисков без Apple :)
результаты работы этого изделия можно увидеть в https://twitter.com/A2_Canada, https://twitter.com/DiskBlitz, https://twitter.com/a2_4am
shattered, Ага, только релиз обещан в марте 2018 года. То есть пока у них тихий междусобойчик.
И да, заявленный ценник радует. Плюс, если я правильно понял, для полноты ощущений нужен родной дисковод с аппаратной модификацией (замена MC3470)
shattered
11.02.2018, 13:15
Как-то так, да. Простым смертным остается покупать SCP/Kryoflux и страдать от невозможности дампить half/quarter tracks и подобные фокусы.
Простые смертные б давно уже взяли ардуину и сделали все сами.
дампить half/quarter tracks и подобные фокусы.
Вроде GARNIZON говорил что он своим МОСТом это умеет.
shattered
11.02.2018, 17:38
И это прекрасно, а пока у меня надобности в подобной колбасе нет :)
GARNIZON
17.02.2018, 21:07
Вроде GARNIZON говорил что он своим МОСТом это умеет.
Да, давно уже. Кстати это Володино устройство получилось настолько удачным, что нам удалось помочь в снятии образов болгарским и американским коллегам. Имеющиеся у них средства не смогли прочесть некоторые, исторически важные, но заковыристые диски.
http://agatcomp.ru/Hard/pcad-new/link2-140s.jpg
Wierzbowsky
21.02.2018, 21:07
Одно такое устройство для 140кб дисководов есть в продаже на барахолке форума Agatcomp.ru. Также есть платки для сборки обоих линков и одно собранное устройство для 840кб дисководов.
shattered
16.03.2018, 22:47
Немного софта для работы с образами дисков
DiskBrowser
https://github.com/dmolony/DiskBrowser
CiderPress
http://a2ciderpress.com/
http://github.com/fadden/ciderpress/
AppleCommander
https://applecommander.github.io/
https://github.com/AppleCommander/AppleCommander
dos33fsprogs
http://www.deater.net/weave/vmwprod/apple/dos33fs.html
https://github.com/deater/dos33fsprogs
специфику Агата (840K, кириллица в бейсике) не учитывают, разумеется.
GARNIZON
01.04.2018, 15:36
Да оно и не нужно вроде, есть свои не менее развитые: http://agatcomp.ru/Soft/dos33c2.shtml
Там на специфику агата слишком много приходится, это и имена в каталогах и файловые системы и подкаталоги ос и тексты\картинки других режимов, в общем более 100 мелких и крупных особенностей
shattered
01.04.2018, 18:35
Как скажете, но DiskBrowser весьма хорош для разглядывания дисков (удобная карта &c), например
LeoN65816
15.02.2020, 22:53
FM и MFM в картинках (http://publ.lib.ru/ARCHIVES/N/%27%27Novoe_v_jizni,_nauke,_tehnike%27%27/''NJNT._Vychislitel'naya_tehnika_i_ee_primenenie'' ,1988,N11.[djv-fax].zip), страница 20.
shattered
26.10.2020, 00:39
Итоги чтения дисков после сортировки и ремонта.
Игры для Apple, 10 дисков. Почти не пострадали.
73781
Софт для Правца (СП Вариант и ХИЦ Волна), 8 дисков. "Знакомство" пострадало сильнее прочих, есть битые сектора. Остальные отремонтированы, но насколько хорошо -- непонятно, в эмуляторе Олега О некоторые ведут себя странно.
73782
1- Алгоритм
2- Информатика
3- База данных «Рок-группы», редакторы
4- Клавиатурный тренажер
5- Знакомство с ЭВМ
6- Редактор текстов (ХИЦ Волна)
7- Курс обучения программированию на Бейсике
8- Знакомство с ЭВМ ч.2
Софт для Агата (уже известный, насколько я понимаю), 4 диска.
73783
1- Агат-Автор и немного текстов втч. чудесные предсказания П. Глоба :). На дорожке 25 сильно плывет скорость, часть секторов не прочлась.
2- диск с надписью "сервис+RESSI"
3- диск с "графическим ДОС"
4- диск с меткой К.Ц. ЭЛЬФ-1П
Игры для Агата (бейсик и ассемблер), 7 дисков.
73784
Sergei Frolov
26.10.2020, 08:43
[QUOTE=shattered;1086245]
2- диск с надписью "сервис+RESSI"
Здесь оригинальный загрузчик Бейсика и COMP - комплексный тест, и с этого загрузчика можно запускать игрухи из a140-agat-games.zip
4- диск с меткой К.Ц. ЭЛЬФ-1П
Там тоже игрухи
GARNIZON
01.11.2020, 18:19
можно договорится о пересыле мне на время дисков поврежденных и плохо прочитавшихся - вычитаю всё по максимуму.
electroscat
26.06.2021, 15:13
Ночку провёл с Орлом и в итоге появился прототип реплики линка номер два для 840кб контроллера дисковода.
http://podrezov.com/agatlink/render.jpg
Плату планируется вставлять в параллельный порт лэптопа, ставить в слот контроллер и писать образы дисков на 3.5 дюймовый дисковод. Буду заказывать 5 платок, если кому-то интересно - отпишитесь. Тогда можем заказ увеличить.
Доброго времени!!! Есть у кого нибудь лишняя - свободная платка для моста 840? Куплю !!!
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot