ВГ93 + LPT

[Raven]

Скачал даташит на PIC18F2455/2550/4455/4550... Интересная вешчь, я думаю перепрошиваемый контроллер накопителя на его основе сделать вполне реально. И даже LPT есть! Но, конечно, одним PIC во всех случаях не обойтись. Думаю, некоторые дисководы потребуют согласующих элементов, и кое-какой быстродействующей логики. Также не нашёл асинхронного программируемого последовательного порта - для некоторых старых накопителей потребуется специализированная микра

[Sentenced]

Commodore 1541 к ним есно не относится? Это не контроллер как бы, а дисковод с ЧПУ :-)

Буквально вчера провентилировал этот вопрос, разбираясь попутно со своим дисководом. К 1541 не относится напрямую, потому как декодирование не MFM, плюс к этому - Variable Sector Rate - разное количество секторов на разных дорожках. Амига Вам поможет

[psb]

если амига поможет, значит и обсуждаемый девайс "возьмет". но вот в том и сомнения, поможет ли...

[Sentenced]

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

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

- Между двумя "единицами" может быть только один "ноль"
- Каждый восьмибитный байт должн начинать с "единицы"

Простейшая схема для того, чтобы соблюсти упомянутые требования - дополнительно записать один переход "тактовой" между каждым битом данных. Эта схема называется Частотная Модуляция (FM) или "4 и 4", и позволяет записывать только 10 265 байтные сектора на трек на дискету одинарной ёмкости форм-фактора 5,25.
Возняк понял, что более изощрённая схема декодирования поможет каждому 8 битному байту записывать 5 бит полезной информации вместо 4. Вот поэтому там есть 34 байта, принадлежащие "top bit set" - "верхнему набору бит", в котором отсутствуют два "нулевых" бита. Эта схема декодирования стала известна как 5+3, позволяя записывать 13 секторов на трек. Затем, дизайн дискового контроллера был изменён, чтобы допустить записывание двух "нулей" в байте. Это позволило каждому восьмибитному байту содержать 6 бит полезной информации, и позволяло записывать 16 секторов на трек. Такая схема известна как 6+2. Apple изначально не называл свою схему GCR, это название дано было позже, чтобы подчеркнуть различия между продукцией Apple и IBM.
Независимо от Apple, Commodore Business Machines, разработала GCR алгоритм для своего дисковода 2040, выпущенного в продажу в 1979 году. Важным ограничением этого дисковода было то, что подряд не могут быть записаны более чем два "нуля" без специального внесения условий "оговорок" в первый бит байта. Каждые 4 бита данных на диске транслируются 5 бит, согласно таблице

Nybble Code
0000 01010
0001 01011
0010 10010
0011 10011
0100 01110
0101 01111
0110 10110
0111 10111
Nybble Code
1000 01001
1001 11001
1010 11010
1011 11011
1100 01101
1101 11101
1110 11110
1111 10101

Заметьте, ни один код не начинается с двух нулей и не заканчивается ими. Это даёт уверенность, что независимо от вводных данных поле не будет иметь более, чем два нуля. Также заметьте, что при использовании такой схемы невозможно разместить подряд больше, чем 8 битовых единиц. Кроме того, Commodore использовал последовательности из 10 или более "единиц" как синхронизирующий маркер. Частично благодаря этой эффективной схеме, Commodore был способен записывать 170kb SS/SD, в том время, как Apple добился 140kb 6+2 или 114 kb 5+3, а также FM-Частотная Модуляция, позволявщая записывать только 88kb SS/SD.

За ошибки и опечатки можете пинать, не вопрос.

[Sentenced]

Я вот тут посидел, подумал, после перевода отрывка статьи.
А как это так ,собственно, получилось, что Амига умеет читать всяко-разные диски да ещё и разных форматов ? Помозговав, вспомнил, что Амига читает треками. И также я вспомнил, что на вопрос - А что делает Амига, если диск с помеченными бэдами, ответ был - Начинает по диску елозить. Вот интересно, подумал я ? А чем отличается помеченный бэд от непомеченного ? Только тем, что о нём известно, что он присутствует. Посему рискну предположить (доподлинно не знаю), что елозение начинается из-за того, что операционная система (возможно, ошибаюсь) лазает проверить номер этого пресловутого сектора, это раз , и, два - что дисковод переходит в режим чтения секторов. Недавно прошерстил ещё раз раздел про флоппи на вики (как удачно мне подвернулся хитрый флопик, а то-бы я в статьи и не полез) и нашёл очень интересную фразу - Амига отличалась тем, что контроллер дисковода был ПРОСТЫМ !!! Насколько я могу себе это представить, вполне может быть, что механизм контроллера при чтении секторов сильно тормозит, тем более, что это не его "родной" режим. Итак. Треки. Из чего состоят треки ? Из цилиндров и секторов. Цилиндры нас тут не особо интересуют, нас интересуют сектора.
В переводе отрывка статьи, есть очень любопытное лично для меня замечание об так называемых "минимальных окнах" для записи информации. То есть, присутствует некоторое ограничение, наверняка документированное, на минимальный размер этого "окна" Все мы знаем, что наша многоуважаемая КР 1818ВГ93 страдает, к сожалению, вкупе с нашим не менее уважаемым TR-DOS, одной болезнью, которая называется - невозможно записать диск, используя команду Write Track. К чему это я ? К тому, что, страдает то самое обратное декодирование. То есть, Спектрум работает с дисководом по тем же самым унифицированным законам. Что-же нам мешает беспроблемно читать диски от любых других компьютеров ? Кроме управления дисководом, других кандидатов нет. Моё личное резюме - нужно подумать, как реализовать простейший контроллер, используя какой-нибудь микроконтроллер. И, похоже, разрабатывать придётся с чистого листа.

Тухлые яйца, гнилые помидоры - рад всему

[Anykey]

Из чего состоят треки ? Из цилиндров и секторов.

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

Все мы знаем, что наша многоуважаемая КР 1818ВГ93 страдает, к сожалению, вкупе с нашим не менее уважаемым TR-DOS, одной болезнью, которая называется - невозможно записать диск, используя команду Write Track.

Как раз Write Track работает нормально, ведь с помощью этой команды
форматируются диски. А вот при команде Read Track происходит потеря синхронизации и данные считываются не корректно.
синхронизации

[Advertiser]

[psb]

Как раз Write Track работает нормально

ну как бы только этой командой трек с данными записать не получится.

а амига, на сколько мне известно, позволяет считать/записать сырые данные без интерпретации, т.е. просто битовый поток.

вопрос-то был не об этом в плане дисковода C64. как он физически записывает на диск, так же как обычный дисковод или нет, а не о кодировании информации.

[Sentenced]

ну как бы только этой командой трек с данными записать не получится.

а амига, на сколько мне известно, позволяет считать/записать сырые данные без интерпретации, т.е. просто битовый поток.

вопрос-то был не об этом в плане дисковода C64. как он физически записывает на диск, так же как обычный дисковод или нет, а не о кодировании информации.

Я именно это и пытался донести до многоуважаемого All - Commodore записывает в соответствии с приведённой мною таблицей. Но ! Это "сырые" данные. Далее, эти сырые данные нужно разобрать с помощью интерпретации сырых данных в сектора, а, затем, с помощью ещё более "высокого уровня" преобразовать сектора в файловую систему с файлами. Подозреваю, что на Амиге именно так и сделано. Когда подсовываешь дискету с ПС Амиге, оператор обязан сказать, что это дискета с ФАТ, используя КроссДос. И, насколько я помню логику работы, Амига сначала преобразует этот битовый поток в диск с ФАТ, а уже потом, при открытии дискеты, включается механизм трансляции содержимого диска согласно ФАТ. То есть, происходит "двухуровневое" преобразование. Сначала мы получаем информацию о том, что это за файлсистема, а уже потом, другим механизмом, транслируем файлы.
Для тех, кто не выпал из танка по поводу глюков ВГ, предлагаю перечитать соответствующую тему, чтобы закрыть вопрос.
Признаюсь честно, для меня это тоже был сначала абсолютно тёмный лес с этим перекодированием, но, почитав статьи на эту тему, начал понимать что к чему.
Резюмируя. Чтобы Копировать абсолютно любые диски, нужно знать хардварные ограничения на размер бита. Чтобы разбирать информацию на дискетах в виде файлов, нужно знать, как конкретно декодируется диск конкретного устройства, как он разбивается на сектора, и какая у него структура файловой системы. В итоге по поводу Commodore ответ - Да, там самые обычные нули и единицы, а вот дальше начинаются танцы с бубном.

[psb]

если самые обычные 0 и 1, значит можно работать с этими дискетами через обыкновенный дисковод (+контроллер). кто-нибудь это реально делал (с С64)?

[Anykey]

Все таки по мойму нет в команде WriteTrack ВГ93 глюков,
и данные в поле данных можно записывать любые, кроме
специальных #F5-#FB, т.к. эти коды приводят к генерации
заголовков и контрольных сумм. (Я в курсе как работает ВГ,
работал с ней и на Спектруме и на MCS51.)


Что касается дисков Амиги -
драйвер Fdrawcmd.sys позволяет читать сырые данные с
дискет под Win XP.
На странице автора драйвера
http://simonowen.com/fdrawcmd/
Есть несколько ссылок на програмки для ПС, работающие
с дисками Амиги при помощи стандартного контроллера FDC.

Единственное условие для чтения RAW данных с диска это наличие
2-х дисководов, по второму происходит калибровка первого.
Автор утверждал что по другому не подучится читать диски амиги.