Полигон-2

А вдруг оно таки есть ? Хотелось найти готовый проект желательно бы еще под AVR где по минимум аппаратуры и хорошо написан открытый софт чтобы можно было спокойно прочитать файл с дискеты включая каталоги например и такой файл создать и записать . Само электрическое подключение МК проблем то не вызывает - проблема уже рисуется в декодировании сигнала флоповода без использования допоборудования и ессно раскручивании всей файловой системы ..

ну куда передавать то я как раз найду Выдавать - мне бы только чтобы скажем поблочно в массив складывал . А потому я уже найду куда его переслать тем же контроллером. Запись желательна весьма .. Хм вы говорите о том как будто у вас таки есть ?

Хм на AVRку вполне себе существует проект который с SDшки спокойно файлы читает в FAT16 и никто не умер К тому же AVRбывают РАЗНЫЕ ... Например atmega2560 самая что ни наесть AVRка

Blackbird С СДшки всегда можно перечитать ФАТ и ДИР быстро. С флопом будет очень медленно из-за перечитывания

Blackbird написал:

[q]

Причем учитывая ЧТО сейчас вытворяют на МК на том же AVR скажем - может скорости хватить и на прямое декодирование/кодирование данных дисковода . Мотором то дергать ни разу не проблема а вот все остальное ..

[/q]

Я думаю, точно хватит - на AVR эмулятор Z80 сделали,
Однако задачу реализации проекта можно упростить, если работать
не с "сырыми" данными FDD, а управлять FDC контроллером (NEC765,
i8272 итп)

[q]

Однако задачу реализации проекта можно упростить, если работать
не с "сырыми" данными FDD, а управлять FDC контроллером (NEC765,
i8272 итп)

[/q]

Это понятно - но обычно в "народных" проектах особливо забугорных жестокий испепеляющий минимализм царит . То есть один МК париться за всех и деталей вокруг самый мизер и уж точно никаких дополнений ..

[q]

А зачем на кого-то смотреть? Я считаю, делать надо так, как самому больше
нравиться.

В целом мое мнение такое:

1. Если хочется лучше разобраться с программированием FDC - ставим
внешний контроллер.

2. Если хочется вникнуть в форматы MFM кодирования данных на дискете -
все делаем программнно.

[/q]

как раз именно в эти дебри и влазить неохота - вот было бы все это готовым куском кода а если еще и на сях так вообще класс . Мне бы файл записать и прочитать не вникая вглубь ..

[q]

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

[/q]

там проблема не в динамической индикации а в головах которые никогда нормального частотомера не видели и не осознавали .. когда я вижу демки на AVR где просто сам МК тупо ногами генерит видеосигнал да еще и сразу в PAL и демонстрирует пр этом 3D на экране и музыку играет . Это становиться просто очевидно ..

i8088 написал:

[q]

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

[/q]

Поэтому все нормальные люди пользуют для частотометра PIC микроконтроллер и timer на вход, который может 50 МГц официально по даташиту, еще со времен PIC16 -)

Tronix написал:

[q]

все нормальные люди пользуют для частотометра PIC микроконтроллер и timer на вход

[/q]

Я сам большой поклонник ПИКов, но тут позволю себе не согласится.
Программы надо нормальные писАть, вот и всё.

Blackbird написал:

[q]

Там как раз все очень жестко . Сам видеосигнал жестоко детерминирован а если еще поднесущую PAL генерить то вообще яйца к полу . Но делают ..

[/q]

Многозадачные OS одновременно тоже много всего делают, а вот
задача прецизионного отсчета времени для них тоже весьма сложна

В Вашем случае для точного задания временных интервалов возможно использовали модуль PWM, но временной интервал
1-10s слишком велик для этого.

[q]

Ты записываешь файл/образ диска на SD и МК копирует его на дискету 1:1?

[/q]

Никаких образов вообще !! Хотелось бы чтобы в коде была функция "найти файл с таким то именем" типа существует ли он вообще , дальше фукнция считать блок N из файла когда функция заполняет массив скажем в 256 char и далее я его как то считываю и что то с ним делаю . И так по блокам прочитать весь файл . Аналогично на запись только тут добавляется функция открыть файл . То есть чтобы с образами никакими не работать а работать с файлами непосредственно . Ну что там такого непонятного ? Никакой SDшки или другого носителя не предполагаеться в устройстве

Blackbird написал:

[q]

Хм кстати вот немцы таки ковыряют тему https://www.mikrocontroller.net/topic/458932

[/q]

Интересный проект, но декодирования MFM там не сделано,
это больше тестер дискет/дисководов. ATMega взята довольно продвинутая (8KB SRAM).

А вообще Ваша идея мне понравилась, не исключено, что
будет темой будущих проектов...

upd.
Вообще самым простым решением мне кажется будет ATMega8515
(можно и MCS-51 применить), в прострастве внешней памяти
которой располашается дополнительное RAM и FDC controller
(конкретный кристалл выбирается линиями портов). Методики
работы с FDC можно посмотреть в исходниках BIOS.



CodeMaster написал:

[q]

Какой обычный PC сейчас имеет дисковод?

[/q]

PC без дисковода не может считаться полноценным.

i8088 написал:

[q]

А вообще Ваша идея мне понравилась

[/q]

Тогда, если не секрет, можно рассказать всем о чём она?

i8088 написал:

[q]

Ну к примеру имеем самодельный цифровой осциллограф

[/q]

Притянуто "за уши". Зачем с цифрового осла передавать данные на допотопный компьютер? Что с этими данными на спектруме потом делать? Кстати, тогда уж писать сразу на кассету, а то понимаешь, флопы не у всех Commodore 64 были. Или даже нет, первокарты лучше пробивать с данными из цифрового осциллографа. Так оно точно для всех ЭВМ подойдет.

Мне вот идеи svinka показались интересными.

[q]

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

[/q]

Ну как вариант и тоже неплохой и я тоже задумывался

[q]

Ну к примеру имеем самодельный цифровой осциллограф, и для сохранения
осциллограм будем использовать FDD. Если не ошибаюсь, модели с дисководом
и промышленные были.

Те для переноса данных между неким самодельным устройством и PC, когда
соединять COM/LPT кабелем компьютер с устройством неудобно/нежелательно,
и в тоже время требуется "канал" передачи данных, совместимый с самыми
старыми PC.

[/q]

А еще есть старинные музыкальные сэмплеры и драммашины где звуки на дискетах носились . Вот охота сделать такой например ... Да много что можно придумать ..

[q]

А SD чем не устраивает?

[/q]

не те очучения панимаешь ?

svinka написал:

[q]

У меня на пенсию намечено 2 проекта связанных с дисководами

1. Если из дисковода убрать компараторы в каналах чтения-записи и иметь аналоговый доступ к головкам, то на стандартной дискете 1.44 при современных методах кодирования и исправления ошибок сколько на дискету поместится?мегабайт 200?
То есть дисковод прям к DSP подключить. Ведь смогли же в телефонную проволоку честные 33600 втиснуть в 90-х

2. Имея дисковод из П1 читать дорожки со старых нечитаемых дискет на большом битрейте и цифровыми методами вытаскивать полезную информацию которая стандартным контроллером не читается. Может быть даже с предыдущей записи

[/q]

Я подумал над Вашими идеями, мне кажется что:

По пункту 1, применив RLL можно наверно раза в два емкость увеличить, и
компараторы снимать для этого не нужно. Увеличение же плотности записи
жеско ограничено размерами головки и качеством магнитного покрытия.

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

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

svinka написал:

[q]

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

[/q]

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

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

Для сравнения, посмотрите какая весьма сложная система коррекции на CD,
причем записываемые данные там "цифровые" (только два состояния,
прожжен/непрожжен).

Производители HDD давно бы взяли такую идею на вооружение, но запись
всегда двоичная и то без корректирующих кодов никак. Даже одной
индуктивной головкой не удалось обойтись, для чтения в HDD давно уже
отдельная MR головка.


Rio444 написал:

[q]

А SD чем не устраивает?

[/q]

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

Есть и еще один вариант - использовать старый HDD или CF в режиме IDE,
интерфейс программирования значительно проще.

Думаю, можно и без НИОКР, применив готовые микросхемы каналов чтения-записи от старых HDD и запустив их на пониженной частоте.

Занятный, на самом деле, челлендж - сколько информации можно максимально впихнуть на стандартную дискету стандартной головкой. Бесполезный, но занятный.

А ещё, говорят, на MFM винт можно стоп-кадры писать аналоговым способом...

[q]

А ещё, говорят, на MFM винт можно стоп-кадры писать аналоговым способом...

[/q]

Хм

AMPEX HS-100 1966 год но это не винчестер это дисковый видеомагнитофон - использовался обычно для реплея . Мог воспроизводить в замедленном темпе и задом наперед

[q]

То есть дисковод прям к DSP подключить. Ведь смогли же в телефонную проволоку честные 33600 втиснуть в 90-х

[/q]

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

Обратитесь к tnt23
http://www.sensi.org/~tnt23/megadrive/index.html
(эмулятор изначально был для Амиги, но он нормально работает для всех машин)

Оффтоп.
Как вариант, нечто подобное могло бы представлять интерес для замены ГМД7012 для ДВК-1 или ДВК-2, и прямо на дискете 3.5" 1.44, причем с каталогом FAT-12 . Софтовая поддержка, правда, потребовалась бы капитальная ( особенно с фрагментацией ).
Особенно интересно выполнить это на 1816ВЕ35 с навесными СОЗУ ( не менее 32 Кбайт ) и ППЗУ.

MM написал:

[q]

Оффтоп.
Как вариант, нечто подобное могло бы представлять интерес для замены ГМД7012 для ДВК-1 или ДВК-2, и прямо на дискете 3.5" 1.44, причем с каталогом FAT-12 . Софтовая поддержка, правда, потребовалась бы капитальная ( особенно с фрагментацией ).
Особенно интересно выполнить это на 1816ВЕ35 с навесными СОЗУ ( не менее 32 Кбайт ) и ППЗУ.

[/q]

Сомневаюсь, что представляет интерес (кроме, может, академического) замена ГМД7012 именно на 3.5" дискету, получится замена одной более древней древности на другую, менее древнюю, но тоже уже древность, от которой большинство остальных в это же время пытаются уйти с помощью эмуляторов. Гораздо проще как раз заменить ГМД7012 сразу на SD карту или на USB флэшку, а не на 3.5" дискету. И это ещё более справедливо для отдельно взятого ВЕ3x (без внешнего чипа контроллера FDD), поскольку для работы с дискетой 3.5" точная субмикросекундная тактовка гораздо важнее, чем для той же SD, которая просто снаружи тактируется с доступной МК скоростью.

Думаю, эмулятор ГМД-7012 на SD карте вызвал бы немалый интерес и спрос.

[q]

Товарищъ хочет создать некоторое цифровое устройство (какое он ещё не придумал сам), но которому однозначно нужны некоторые переменные данные которые он хочет скармливать ему с дискет (с каких 3.5", 5.25" или 8" он пока не конкретизировал, сейчас речь уже зашла о IDE HDD, может IDE магнитооптика или сменные HDD типа Jazz подойдут, он пока тоже не определился). При этом для своего НЦУ он не хочет использовать классические схемы контроллеров, а заюзать нечто минималистское (по корпусам) на современном МК.

[/q]

Я как понял увы из хотелок нема ничего на даный момент не растет.. Мда .. Тогда можно слепить нечто более другое тоже не особо большое . Но без использования специализированного контроллера флопа . Кстати и сделает девайс более универсальным и форматонезависимым . Да еще и к контроллеру не будет особых требований по быстродействию . Дорожки дрыгать шагами и индекс ловить может практически любой мк . А дальше дорожка скидывается в сыром виде в ОЗУ с помощью аппаратного счетчика и там уже микроконтроллер ее и декодирует софтом - тут уже неважно быстродействие . На запись в общем то та же шняга - в озу сосдаеться образ дорожки и кидаеться через "ускоритель" на флоп. прикинуть бы объем потребного ОЗУ исходя из того что писать все таки будем байтами через сдвиговый регистр чтобы однобитовое ОЗУ не юзать . В общем из моего опыта чтобы нормально ловить нужно по такты записи тикать раз в пять быстрее чем минимальная ширина импульса с флоповода - отуда можно прикинуть и объем . Главное схема получается не особо какой то грандиозной то ..

Blackbird написал:

[q]

Дорожки дрыгать шагами и индекс ловить может практически любой мк

[/q]

Не знаю, в KryoFlux почему-то ARM используется.

Blackbird написал:

[q]

На запись в общем то та же шняга - в озу сосдаеться образ дорожки и кидаеться через "ускоритель" на флоп. прикинуть бы объем потребного ОЗУ исходя из того что писать все таки будем байтами через сдвиговый регистр чтобы однобитовое ОЗУ не юзать . В общем из моего опыта чтобы нормально ловить нужно по такты записи тикать раз в пять быстрее чем минимальная ширина импульса с флоповода - отуда можно прикинуть и объем . Главное схема получается не особо какой то грандиозной то ..

[/q]

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

Я бы все же поставил внешний FDC, да и устройство симпатичнее будет (не люблю когда все
устройство из одного MK и нескольких пассивных деталей).


Blackbird написал:

[q]

Это где ? Если ARM там реально больше ничего не делает .. То блин в общем ARMоводы люди особенные .. Там где на обычном МК нужно три строки кода эти уникумы впендюрят линуха и 10 сторонних глючных библиотек подключат .. Что называется "я не могу иначе" Так что опуститься до нормальных МК они не могут он им непонятен (там все сложно не то что ARM где все просто)- шутка

[/q]

Я эти ARM тоже как-то просто подсознательно стороной обхожу и вдаваться в них не хочется...

svinka написал:

[q]

FDC - это микропрограммный автомат. Я бы даже сказал микроконтроллер. Трудится на частоте 4 или 8Мгц (для 1.44)
И все его функции можно реализовать на современном микроконтроллере с фиксированными таймингами исполнения команд

[/q]

Так я же не говорю что нельзя! Мне просто решение с внешним FDC больше
нравиться (хотя можно и полностью программную реализацию расссмотреть
тоже конечно), тем более что дискеты предполагается читать самые обычные.


svinka написал:

[q]

Ищите микроконтроллер 5-ти вольтовый с памятью минимум под 1 а лучше 2 трека 1.44

[/q]

Для удешевления проекта и использования микросхем в нормальных
приятных DIP корпусах предлагаю ATMega8515 с внешним SRAM от
кеша 486 материнок.