Всегда хотел узнать - для чего нужен PIN-40, на который подаётся 12 вольт ?
Вид для печати
Всегда хотел узнать - для чего нужен PIN-40, на который подаётся 12 вольт ?
Судя по дукументации, это не более, чем "вход" для "дополнительного" питания.. издержка технологии, т.с.з. ;)
Robus, Не поверите, Для питания микросхемы.
У 8080 и его аналогов, и у К573РФ1 с аналогами, например, три разных питания.
А тут всего-то два.....
То есть все остальные выходы 5-вольтовые ? И 12 вольт никак не влияют на уровни сигналов !?
---------- Post added at 21:15 ---------- Previous post was at 21:12 ----------
А можно как-то получить документацию ? Желательно максимально детальную.Цитата:
Сообщение от null_device
И ещё ... Как я понимаю на PIN-24 подаётся тактовая частота. Какая она в TR-DOS адаптерах ?
Стандартно (в BDI), 1МГц, в схемах "турбирования" контролера во время команд "чтения" на вход подается удвоенная частота..Цитата:
Сообщение от Robus
---------- Post added at 03:10 ---------- Previous post was at 02:49 ----------
Блок-схема функционирования "сердца" BDI (1818вг93) мне ниразу на глаза не попадалась. Отдельная информация была в книге Родионова\Ларченко про tr-dos, журнале ZX-Ревю и т.п. литературе..Цитата:
Сообщение от Robus
Когда наши его сдирали, делалось это послойным копированием. А т.к. сам по себе чип древний, то и технологии задействованные в нём тож древние. Но при послойном копировании возможно токо клонирование оригинала. А чтоб убрать +12В - это пришлось бы весь кристалл перепроектировать заново. Украсть было проще и дешевле :)Цитата:
Сообщение от Robus
wikipedia rulezzzzzzzz http://en.wikipedia.org/wiki/Western_Digital_FD1771Цитата:
Сообщение от null_device
http://bitsavers.org/pdf/westernDigi...eets_May80.pdf
Robus,
Можно. Вот те фирменный ДатаЩщиииит и его Русский собратец:Цитата:
А можно как-то получить документацию ? Желательно максимально детальную.
Если наши скопировали один к одному, откуда в наших чипах появился глюк сбоя синхронизации при чтении дорожки целиком? Если только заподозрить то, что наши ошиблись где-то и не проверили.Цитата:
Сообщение от БК-0010
Это ошибки присущие такому методу копирования, когда копируется всё вслепую, т.е. без понимания логики работы. Если бы наши понимали бы логику работы - они бы и сами спроектировали этот чип. Помнишь советский фильм про Хоттабыча, эпизод, где он сделал телефонную будку с мраморным телефоном, который был всем хорош, кроме того, что не работал :) Вот так и мы копировали чипы - по внешнему виду слоёв, без понимания что там за схема (я утрирую конечно). Потом по этим слоям рисовалась схема, но как видно не всегда всё удавалось понять правильно, или повторить точно.Цитата:
Сообщение от Titus
Интересно бы узнать, чем еще отличалась наша вгшка от буржуйского аналога, кроме потери синхронизации на чтении трека.Цитата:
Сообщение от БК-0010
Вроде как этот глюк присущ и оригиналу (WD1793/FD1793), так что немудрено что глюк сохранился.Цитата:
Сообщение от Titus
Не во время чтения/записи, а во время команд позиционирования. Или чтения с установленным битом проверки положения МГ. Причем, если подать на ВГ93, скажем 2Мгц, то в режиме чтения все работает прекрасно. Но записанные диски таким образом портятся на нормальных контроллерах. Т.е. при записи нужно подавать строго 1Мгц.Цитата:
Сообщение от null_device
Vadim, если не ошибаюсь, то для работы с дисками 1.44Мб на ВГ также и при чтении/записи подают удвоенную частоту.
А что за ошибка ?Цитата:
Сообщение от spensor
Что-то я совсем запутался !!! Как я понимаю, изменение частоты влияет на временные диаграммы.Цитата:
Сообщение от Vadim
Спасибо всем за помощь.
---------- Post added at 12:11 ---------- Previous post was at 11:54 ----------
Вот что я нашёл в описании ...
Тактовая частота: 2 МГц для 8″, 1 МГц для 5¼″
Из этого вывод, что вряд-ли кто-то будет юзать 8″ ??? Однако если это было запланировано в TR-DOS'е ...
А можно поподробнее про другую частоту для 3.5" ?Цитата:
Сообщение от Дмитрий
Все верно. Дискеты 1.44М имеют удвоенную плотность, по сравнению с 720КБ, но мы ведь говорим про trdos. В tr-dos же нет поддержки такого формата, а так, вообще верно.Цитата:
Сообщение от Дмитрий
Не про 3,5", а про плотность HD. Т.е. если мы юзаем дисковод в режиме DD, то на ВГ93 идет 1Мгц, если на неё подаем 2Мгц и меняем схему выделения данных, то можем юзать HD. Это сделано в спринтере (больше не знаю где и есть ещё разработка от PSW). Т.е. при использвании дисковода 3.5" в режиме DD (заклеиваем окошко плотности на дискете) частота на ВГ стандартная. Со стороны контроллера дисковод выглядит как обычный 5.25".Цитата:
Сообщение от dk_spb
---------- Post added at 15:42 ---------- Previous post was at 15:36 ----------
Влияет, но в контроллере бетадиска чаще всего схема выделения данных из битового потока с дисковода тактируется не тем сигналом что идет на ВГ93. Для ВГ93 отдельно формируется 1Мгц, а для выделения данных вроде 1/16Мгц (вернее я не помню сколько там, давно не видел схемы). Таким образом, если мы подаем на ВГ93 2 Мгц, то ничего страшного не происходит, данные читаются верно. Но вот при записи возникают проблемы. Суть их может рассказать psb или БК0010, может ещё кто, я не разбираюсь в тонкостях кодирования данных в дисководе (хотя читал не раз) и какие там происходят метаморфозы при изменении частоты на ВГ93 в 2 раза. Про 8" диски читал, что для ВГ нужна частота 2Мгц. Но это связано по моему со стандартом записи. И как помню там вообще применяется FM метод кодирования, при 2Мгц. Т.е. бит синхры потом бит данных, потому и 2 Мгц.Цитата:
Сообщение от Robus
А, Тогда понятно. Спасибо за разъяснения.Цитата:
Сообщение от Vadim
Команда Read Track по документации должна считывать всю дорожку от индексного импульса до индексного, при этом процедура-обработчик в принципе могла бы сдампить порядка 6 Кбайт в память и дальше можно было бы выделить данные секторов и служебные байты. Но в BDI это сделать не получится - происходит сбой синхронизации (бит-поток то единый) и вместо структурированных данных формируется дамп мусора в котором только начальная часть соответствует достоверным данным. Почему так происходит понять не удалось, вроде как причина в "кривости" ВГ93, но возможно микра требует хитрого внешнего сепаратора данных. Подробнее разбиралось тут: http://zx.pk.ru/showthread.php?t=859Цитата:
Сообщение от Robus
В e-zine DejaVu была схема переделки BDI в составе Пентагона под дискеты высокой плотности HD, для работы с применением процедур TR-DOS требовалось турбировать ВГ93 до 2Мгц и Z80 до 7Мгц, т.к. процедуры чтения/записи байт на 3,5МГц и даже на турбе с плохим коэффициентом турбирования не укладывались в отведенный промежуток времени.Цитата:
Сообщение от Vadim
Когда-то с этим разбирался на Спекки, но сейчас уже подробностей не помню. Помню, что делал в обход этого глюка защиту для Софтстаровской версии Street Fighter'а, где как раз использовалось чтение всей дорожки целиком. Т.е. информация на диске была записана не в виде секторов, а в виде единого сплошного потока бит. Но, чтобы сбоя не было, я исключал из потока данных комбинацию, приводящую к сбою. Сейчас уже не помню, какую )Цитата:
Сообщение от spensor
А как насчет программной поддержки? Аппаратно то, ясен пень сделать несложно, а вот будут ли работать программы? Если добавить кол-во секторов на треке (это как бы самый правильный вариант), то очень много программ не запустятся, они считают что секторов то 16, на трек. Если попробовать сделать пересчет и увеличить кол-во треков, то тогда может что и получится.Цитата:
Сообщение от spensor
Когда я писал первые процедуры для работы с диском на Профи, в ЦПМ, то начинал сначала разбираться с командами имея на руках скудное описание. Доступ к ВГ93 на профи полный, порты открыты. Делал и чтение дорожки. Дорожка читается, вся. Вероятность рассихнронизации выше чем хуже читается дискета, и чем хуже дисковод. Если мы только что отформатили дискету на FD-55 то команда чтение дорожки с вероятностью 70-80% прочитает весь трек верно. Если дискета писана другим дисководом то вероятность падает до 5-10%. Причем сбой синхры может начаться где угодно, в любом месте диска.Цитата:
Сообщение от spensor
На профи многие программы которые продавал Кондор (в режиме ЦПМ) имели защиту. Сделана была именно таким вышеописанным способом. Читался весь трек командой "чтение дорожки", потом в определенном месте, в межсекторном промежутке, искалась определенная сигнатура, скажем:Цитата:
Сообщение от Titus
+0 A
+1 B
+5 C
+7 D
Если сигнатура не найдена, то производится несколько попыток, после чего программа говорит что копия нелиц. Ни один копировщик на спектруме не преодолел эту защиту. Пробовал я копировать и на ПЦ через FDA - эффект аналогичный, межсекторные данные все копировщики откидывали, заменяя их стандартными пробелами.
если мы на дорожку записали определенные байты, то 100% именно в этом месте будет рассинхронизация. на любом дисководе, на любой дискете. перепроверено в свое время 100500 тыщ млн. раз.Цитата:
Сообщение от Vadim
Ну насчет пня и несложно вопрос зыбкий, переделка там основательная и не на всякий клон нахлобучишь, но в целом задача решаемая. А насчет программной поддержки это действительно сложно - для использования таких дискет требуется загрузить коммандер с обычной дискетки (ну или HDD и тому побобного) и уже в коммандере пользоваться, в нынешних реалиях как минимум глупо. И второй вариант патчить TR-DOS, причем там совсем не все гладко, как минимум загрузчики программ не должны иметь оторжения ситуаций когда номер сектора >16. А если принять во внимание что от правила "16 секторов" прыгают все процедуры в TR-DOS, те же FORMAT, MOVE то пределка совсем нетривиальная получается.Цитата:
Сообщение от Vadim
Именно так, в теме которую я указывал выше, Lion17 дал исчерпывающий ответ по этой проблеме http://zx.pk.ru/showpost.php?p=16970. Вопрос только остался за тем почему так, и можно ли побороть схемной обвязкой.Цитата:
Сообщение от psb
Поискал в старых тетрадках и нашел комбинацию из 9 бит, которая гарантированно дает сбой при чтении трека на ВГ, и при отсутствие которой, трек читается гарантированно правильно. И эта комбинация000101001, что в просторечии можно представить, как 0x029. Но еще раз замечу, что эта комбинация не из 8 бит, а из 9.Цитата:
Сообщение от spensor
Подробности механизма сбоя не помню, но очень так на вскидку мне кажется, что есть два режима чтения MFM-последовательности. Первый - это внутри блоков данных и заголовков, когда контроллер уже правильно синхронизирован на MFM-данные, и просто их читает. Второй режим, это когда контроллер может правильно синхронизирован, может нет, но готов синхронизироваться по первой последовательности 0100010010001001 (MFM). В режиме чтения дорожки целиком, контроллер всегда находится во втором режиме, в результате чего не только правильно синхронизируется в нужных местах, но в том числе и сбивает синхронизацию о комбинации 000101001, если они встречаются внутри блоков данных. Причем, если сбился, то перепутывает тактовые биты MFM кода и собственно биты данных, в результате чего на выходе MFM-декодера имеем абакадабру. Ну это так, чисто теоретически на вскидку.
эту? (cм.аттачмент)Цитата:
Сообщение от Titus
с этой защитой интересная ситуация вышла, когда писал эмулятор ВГ93 для первого ZXMAK (в нем используется довольно глубокая эмуляция для ВГ93).
Деталей сейчас точно не помню, но суть примерно следующая.
Игрушка почемуто не хотела работать если сектор читался с неправильным CRC (а именно с неправильным CRC она и была записана на дискете), но читалась и работала если ВГ сигналила о правильном CRC.
Такая парадоксальная ситуация привела меня в замешательство. Так и не понял почему игра работает с правильным сигналом CRC, хотя реально записана с неправильным. А с неправильным при этом работать отказывается...
В итоге я временно залочил эмулятор ВГ93 так, чтобы он всегда правильное CRC давал. Таким образом эта игрушка грузится нормально, но эмуляция ВГ93 некорректная :) Так все и осталось.
В Unreal к сожалению эмуляция ВГ не такая детальная. Там до таких деталей не доходит - проскакивает т.к. эмулятор не анализирует реальные CRC.
Эмуляцию ВГ93 для дотнет версии ZXMAK я писал на основе кода Unreal, т.к. эмуляция первого ZXMAK получилась слишком сложная, лень было столько кода переводить :)
может где-то сохранились исходники или описание защиты этого загрузчика? :v2_wink2:
Конечно эта, раз там написано Титус )Цитата:
Сообщение от Alexander Makeev
Поищу исходники.
Кстати, Спектакулятор этот образ прочитал хорошо и запустил игру.
Вот нашел какие-то исходники.
Судя по всему там копировщик для стритфайтера и форматтировщик.
Не обязательно.Цитата:
Сообщение от spensor
А это зачем?????Цитата:
Сообщение от spensor
Всего лишь научить контроллер обращаться к первой половине секторов 1-16 как к дисководу "А", а вторую 32-64 как "В" и всё. Форматировщик есть, в виде плагина к реалкому, даже реформатит.
Схема такого бди тож есть и 10(десять) лет успешно используется до сих пор.
Получается на одной дискете два дика, типа "А" и "В".
Вот, с ПИСИ не пробовал состыковать...
И какой в этом резон? Идея ноухавная, но вещь в себе.Цитата:
Сообщение от lisica
Две дискеты умещаются на одной. И с ними работаешь как с обычными дискетами даже перевтыкать не надо. Всё на одном дисководе.Цитата:
Сообщение от spensor
Извиняюсь, поправлю "А" и "С". "В" всегда 720кбЦитата:
Сообщение от lisica
Ну, а в данном случае "А" и "С" будут какого объёма?Цитата:
Сообщение от lisica
"А"-720
"С"-720
И это с одной дискетой и одним дисководом.
Если заклеить отверстие на дискете, то всё работает как обычно, в обычном контроллере, только "С" будит = "А".