Сабжевый вопрос возник довольно давно.
Те, кто обращал внимание на мои посты, наверное уже догадались, почему. :)
Возможно, для реализации этой идеи потребуется чуток подправить шлейфы/кабели + софт [как минимум] на одном из компов запустить самописный (для начала - под ДОС).
Скорее всего, с поддержкой подобной схемы на уровне биоса и операционной системы придется распрощаться. Так что отключить "устройства" (но не контроллеры) придется и биосе, и в ОС.
Интересует преже всего совместимость такого решения на электрическом уровне -- не сгорит ли чего ненароком. :lol: :roll:
Поэтому, предже чем начать изыскания в этом направлении хотел посоветоваться со специалистами. :)
САТА-кабели и ИДЕ-шлейфы нужной длины для межкомпового соединения думаю найти смогу. По крайней мере, таковые длиной вплоть до 60 см уже имеются.
Можно рассмотреть также варианты соединения кабелюкой:
1) разных каналов одного контроллера;
2) разных контроллеров на одном компе.
[list=1][*] Есть подозрения, что напраямую обычным или переделанным шлейфом два IDE-контроллера соединить нельзя. Ибо кол-во сигналов, использующихся "на выход", не соответствует количеству сигналов "на вход". (надо еще почитать, более внимательно)
[*] Если первый пункт верен, то скорее всего для соединения компов по ИДЕ придется паять (как и для соединения по ЮСБ) промежуточный девайс, что резко снижает привлекательность этого решения.
[*] Как тут уже заметили, необходимо установить однозначное соответствие между подаваемыми АТА-командами/значениями регистров и сигналами на выходах (и наоборот).[/list:o]В случае с LPT данные вопросы решались гораздо проще и прозаичнее. Кстати, насколько я помню, первые варианты LPT также не были заточены на использование для связи компьютеров (и вообще для полноценной двунаправленной работы). В случае с ИДЕ на лучшее расчитывать уже не приходится. :(
Поясню еще немного, зачем мне это нужно.
Нужно подобное решение не просто для связи двух компов, а для эмуляции одним из двух компов накопителя на жестких дисках/привода оптических дисков.
Соответственно, спец софт должен стоять только на одном из компов (эмулирующем). А второй комп должен для "связи" использовать стандартные драйвера операционной системы (именно поэтому способ с ипользованием части линий данных для управления не подходит).
При помощи такой связки можно было бы например отслеживать протокол обмена сервисных утилит и накопителей на жестких дисках. Для этого на компе-эмуляторе можно было бы запустить прожку, которая просто-напросто транслировала бы команды/данные, полученные через соединение с контроллера от другого компа, на реальный жесткий диск, попутно записывая их в лог. Я в курсе, что для этой цели уже существуют другие устройства, но в магазине их не купишь и самому спаять не всегда возможно.
Кстати, вариант переходника на LPT (да и на другие, более быстрые, интерфейсы) также подошел бы, но нужно, чтобы переходник работал не с оконечным IDE-устройством, а с IDE-контроллером. Сомневаюсь, что представленное по ссылке устройство способно на это. :(
Спасибо всем откликнувшимся. Может из этой идеи еще что-нибудь да выгорит. ;)
Даже если нельзя 1-к-1, то можно 1-к-2, зачем ещё нам на старых матплатах 2 иде контроллера нужно:-)
хотя, в этом случае придётся паять хотя бы кабель, если получится без микросхем.
Возьмите тот же SCSI - там почему-то нормально можно связать два компа по этому интерфейсу. Правда, с кучей issues, но тем не менее, конструкция получается работоспособная. А тут огород городить - ну, его нафиг.
сразу бы и ссылки в студию:-)
Даже если и получиться сделать такую штуку(очень хотелось бы увидеть), то лучше pio4 вряд ли что-то получиться. В южном мосте есть 48МГц, возможно, они и идут на ИДЕ. Поэтому, синхронизацию удерживать будет очень трудно, а это грозит обработкой "реального времени". Хотя, если не под виндовс...
Так Вам нужен обыкновеннейший IDE-Snooper? См., например, http://www.arl.wustl.edu/~lockwood/class/cs535/project/ide/index.html
Не могу не согласиться с
Спасибо за ссылку, надо будет изучить подробнее.
Если эта штука умеет не только подслушивать, но и изменять поток двнных м/у контроллером и накопителем, то это то, что надо. А конечный интерфейс (NIC|USB|FW) значения особого не имеет, если есть готовое решение. :)
Скорее всего так и есть. :(
Baza
"Полистал" я вчера про SATA до 5 утра. :)
Там очень хитрая начальная инициализация/калибровка скорости на физическом уровне. Хост не может выступать в качестве оконечного устройства и наоборот. Хотя, может и существуют в природе такие хитрые SATA-контроллеры, которые могут прикидываться конечными устройствами, но рассчитывать на это не приходится. :)
Хотя поначалу, когда читал про AHCI, закралась надежда -- уж больно его программная модель работы с контроллером похожа на "равноправный" FireWare.
Добавлено спустя 14 минут 3 секунды:
NortonC
Идея с 2-мя каналами интересная. Но боюсь, тут основная проблема в пункте №3: поиск соответствия сигналов на пинах и команд.
Уже давненько встречал проект человека с ником NAZYura - название "IDE Grabber" или "IDE-BUS SIGNAL ANALYZER". Лично мне идея понравилась, но из-за своей занятости так и не попробовал это устройство в работе...
С уважением, Владимир.
здесь люди разрабатывают всякие устройства для параллельных шин, в .т.ч. и для ide, вот с ними бы пообщаться...
Нужно понять общий принцип, как на пинах выставляются значения и тогда не нужен будет "поиск соответствия сигналов на пинах и команд", интерфейс-то цифровой и все команды, видимо, выставляются одинаково. Главная сложность должна быть в большом количестве разноформатных команд разных винчестеров и контроллеров, но никак не в соответствии пины-команды, мне так кажется
по поводу команд, думаю, можно спросить создателя uni_ata, а лучше привлечь его к дискуссии:-)
PS кстати, зачем нужен именно железный эмулятор? почему не подойдёт просто это? так проще и паять ничего не придётся