БК - типа который вы обзываете LPT-порт в БК называется УП и с МХ справляется запросто при байтовом обмене (порт 16х из них 8-бит данные + упр.сигнлы в старших байтах) - контроллер на 12-15мс мелкой логики 155 ... (спец-коммент для ММ-ме - НИ ОДНОЙ бредятины типа АП2 - нет-НЕТ-НЕТ) ... - спорим на 10000 баксов что такой был и у меня есть моя восстановленная схема и ПО типа загрузка-копирование-обмен...десяток команд... - контроллер был на принципе FM - обычный МХ это элементарно, очень долго его доков не было и потом доки втирали нам в заголовках как МFM (и дальше эту дебильную штуку НА БК никто уже испугавшись не читал - там памяти немеряно нужно) - но... в самом конце доков от руки написано MX0 MX1
и в диаграмме был ОБЫЧНЫЙ FM -...
Последний раз редактировалось Ал-р; 01.06.2016 в 18:17.
Ал-р, не хочу Вас обидеть, но причем тут байтовый обмен? Нет, я допускаю что у Вас наболело за то, что Вам кто-то когда-то что-то втирал, но нам-то про байтовый обмен втирать зачем?
Если бы БК могла отсэмплировать MX - то спрашивается почему Вы это не сделали еще тогда и не изучили какие в MX были заголовки? Как теперь модно писать "вопрос риторический" ;-)
А лично мне интересно, из каких математических размышлений взялась цифра 5МГц для MFM.
Так вроде 5 мбит/с у всех MFM HDD, меньше чем 20 мегасэмплов/с смысла нет.
Последний раз редактировалось dk_spb; 01.06.2016 в 20:15.
Немного о там как это сделано внутри.
В DREM сделан аппаратный encoder - decoder для FM - MFM - RLL работающий, в текущем варианте, до битрейта 7.5 Mbps.
В принципе можно и быстрее, но пока небыло host контроллеров которым это надо.
Каждый из кодеков имеет множество настроек под разные системы кодирования сигнала (например WD и Seagate имеют разные таблицы RLL),
и разные системы синхронизации и т.д. До входа сигнала на декодер есть аппаратное реверсирование предкомпенсации.
В DREM исспользуется MIPS процессор на основе plasma core в который я добавил unalligned instructions, без них процессор не успевает.
Кодеки работают с памятью через DMA. Для ускорение применяется двухуровневый кеш дорожек и CRC.
В режиме RLL скорость поступления байтов такова, что уже DMA работает на пределе. Вопрос решается многоуровневым конвейером.
Ширина импульсов с которыми приходится иметь дело 60 наносекунд и надо уметь определять где они находятся в окне 100 наносекунд.
Никакой raspbery pi с этим несправится. Даже с случае флопи диском реализация на микроконтроллерах проблематична, поэтому
HxC Emulator работает как проигрыватель заранее закодированных в MFM файлов, которые кодируются на PC специальным софтом.
Добавьте большое разнообразие форматов и контрольных сумм, на которые отсутствует документация. Многие полиномы надо искать
при помощи специального крипто софта, а форматы снимать цифровым осцилографом и расшифровывать руками. Естественно для этого надо иметь все
возможняе хост компьютеры и контроллеры в коллекции.
Размер проекта 8000+ строк на С и 3000+ стрк на VHDL не считая библиотек.
------
PS: аппаратно реализовано много чего еще. Многие части интерфейса: счетчики дорожек, дорожка ноль, идентификация типов диска амиги..
Есть контроллер прерывания и три аппаратных таймера. В VGA консоли сделан аппаратный ускоритель скролинга.
В кодеках имеются аппаратные стеки и конвейеры к которым имеет доступ процессор.
Последний раз редактировалось kapitan-u; 01.06.2016 в 20:30.
ну это же интересно :-)
- - - Добавлено - - -
для EC1841 есть два типа контроллеров ЖД
Контроллер Искра-1030 на WD1010-05 => с DREM он будет работать
Контроллер на Z80 совместим с IBM PC XT 5160 (Xebec) - LLF известен добавить его просто, сама плата для проверки у меня скоро будет.
Это Вы так шутите? Что в ЕС-1841 стоит контроллер Искра-1030?
И, если уж на то пошло, вот этот HDC от ЕС1841 Вы к какому типу относите? к "Искра-1030 на WD1010-05" или "Контроллер на Z80"?
- - - Добавлено - - -
А можно Вас попросить хоть одно фото HDC от Искра-1030 с микросхемой WD1010-05?
Вы меня, право слово, пугаете......
вот это самая сложная часть - информация. разберемся :-)
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)