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