Сабжевый вопрос возник довольно давно.
Те, кто обращал внимание на мои посты, наверное уже догадались, почему.

Возможно, для реализации этой идеи потребуется чуток подправить шлейфы/кабели + софт [как минимум] на одном из компов запустить самописный (для начала - под ДОС).

Скорее всего, с поддержкой подобной схемы на уровне биоса и операционной системы придется распрощаться. Так что отключить "устройства" (но не контроллеры) придется и биосе, и в ОС.

Интересует преже всего совместимость такого решения на электрическом уровне -- не сгорит ли чего ненароком.

Поэтому, предже чем начать изыскания в этом направлении хотел посоветоваться со специалистами.

САТА-кабели и ИДЕ-шлейфы нужной длины для межкомпового соединения думаю найти смогу. По крайней мере, таковые длиной вплоть до 60 см уже имеются.

Можно рассмотреть также варианты соединения кабелюкой:

1) разных каналов одного контроллера;
2) разных контроллеров на одном компе.

Уронить бы на тебя чего тяжелого, чесс слово.

Связать через IDE можно, благо это одна из расширенных разновидностей LPT.
Нужен контроллер для стыковки интерфейсов. Я уже делал нечто подобное из LPT и могу сказть однозначно - в этом контроллере должна быть FIFO (двунаправленная).
Скорость LPT порядка 1Mb/s, скорость моего device порядка стольки, скорость обмена - не выше 100Kb/s. Причина - постоянно ждут готовности друг-друга. Сигнал RDY помогает слабо.
Если абстрагироваться от скорости и перейти к твоих из'ыскам, то - тебе нужен эмулятор CD, так?
Программный не устраивает, как я понимаю?
Бери второй комп, сажай на вторую сторону шлейфа IDE и эмулируй железо ... долго и мучительно.
Тебе надо отвечать на несколько адресов с 8/16-и-битной шиной данных. Проблема в том, что одна запись в порт (как и чтение) занимает 1uS. Примерно с такой-же скоростью работает трансфер в PIO0. Т.е. процессору не составит проблем переварить эти данные, только он не успеет их считать/записать. Значит придется пользовать READY и тормозить протокол. Стандарт ISA позволяет затянуть до 15uS (кажется), т.е. оба процессора легко свяжутся.
Останется вопрос о аппаратном шлюзе, чтоб один из них прикидывался IDE device. Решаемо и не особо сложно.

Про SATA - это не ко мне. Тут уже придется потрошить SATA диск на выдирание его контроллера .... только их не бывает дискретных(!).

По поводу 'сгорит' - ТЩАТЕЛЬНО соединяй корпуса обеих компов и проблем не должно быть. Толстый провод и под винт, качественно.

serj

СПАСИБО за ответ!


За что ?


Это уже радует.

А это огорчает. Если нет схем готовых решений, то тогда идею можно смело

Я не совсем понял, вроде компы по LPT соединяются безо всяких допустройств.
А прерывания использовались ?
Совершенно верно!

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

Не понял, вроде выше говорилось про какое-то сопрягающее доп. устройство.
Распиновку разъема я посмотрел, так там вроде бы сигнал в случае прямого включения приходит с контактов разъема одного контроллера на те же (одноименные) контакты второго контроллера. Если в случае с линиями данных это даже хорошо, то для остальных - не очень, ибо сигналы на большинстве контактов однонаправленные.
Этот кусок я потом перечитаю - пока ничего не понял. Т.е. чем быстрее комп, тем выше шансы на успешную эмуляцию ? Или речь о том, что одну транзакцию придется разбивать на несколько ?

Это радует, но не совсем пока понятно как. Для меня вариант с разработкой с нуля сопягающего "IDE to IDE" устройства отпадает автоматически -- не потяну.

Да уж с ИДЕ бы разобраться сначала.

За предупреждение спасибо ! В случае бескорпусных компов, я так понимаю, достаточно соединить их БП ?

#77
МАКЕТ!

Слева родное, справа симулятор.
Main в 8-битной шине, Simulator - в 16-битной.
Шина данных 0-7 соединяется на прямую, в старшие биты данных вешается спецсигналы и адрес.
U1 - защелка ожидания устройств тот-этот.
В симулятор идет прерывание по каждому обращению, он может выдать прерывание записью 0 в D15.
Еще раз напомню, максимальное время ожидания 15uS. На дольше будет ****ец! Т.е. никаких Windows, чистая DOS задача, причем на обработчик аппаратноего прерывания от IDE надо вешать максимальный приоритет (настраивается в контроллере прерываний).
Резисторы R0-7 'от лукавого', можно не ставить.
В симуляторе ready используетсятолько при записи - он должен дождаться считывания данный в main.

Подробный комментарий, как и уточнение схемы - если такое исполнение устроит.

xKVtor а если не секрет зачем вам это нало ?

serj

У меня просто нет слов! Полная неожиданность! Я в восторге!

СПАСИБО!!!

Теперь можно считать, что дело сдвинулось с мертвой точки.

Хорошо, учту. Но для начала надо будет книжек умных почитать, да людей порасспрашивать.

Устроит. Тем более, требуется всего 2 микросхемы.
От комментов не откажусь.
Надеюсь, во время экспериментов ничего не погорит.

ЗЫ: А какая максимальная скорость на этом деайсе возможна ? Большой ли выигрыш будет по сравнению с девайсами, управляемыми по LPT ?

Возможно ли дальнейшее совершенствование устройства (пусть даже за счет усложнения) для повышения скорости обмена, задействования ДМА ? (желательно без использования каких-либо микроконтроллеров/плисов и прочих подобных наворотов)
Добавлено спустя 4 минуты, 5 секунд
Daemon Имеешь в виду SMM и процессорную виртуализацию ? Кому проще, тот почему-то в этом не заинтересован. Может займешься на досуге ?

DeDaL_OC

Зачем ? Ответ во втором и третьем постах.
Добавлено спустя 14 минут, 59 секунд
serj

Кстати, обсуждение этой темы на ROM.BY:

http://forum.rom.by/viewtopic.php?t=15192

Скорость PIO, т.к. main контроллер не сможет работать в (u)dma в принципе - не используется его сигнализация.
Т.е. ~1MB/s (и меньше).
В симуляторе можно не сидеть в откровенном PIO и сделать передачу данных через DMA. Из-за вынужденого преобразования 8-16 перед этим придется сформировать данные специальным образом, байт-word с старшим=80h. При чтении аналогично, наоборот.
Вместо второго IDE можно использовать LPT, практически так-же и практически с теми-же характеристиками. Дело в том, что IDE (PIO mode), LPT (EPP mode) и ISA - это одно и то-же.

Учти, компов с IDE (особенно двумя) и/или LPT становится все меньше и меньше.

По схеме - задавай вопросы.

add: определись с интерфейсом. IDE или LPT.

serj

Это радует. На перспективу.
Еще бы на авторскую схему взглянуть. Она не усложнится ? В некоторых версиях LPT вроде также есть возможность использовать DMA.
Это я уже слышал.

Ну, это не проблема. Можно в крайнем случае использовать PCI-варианты (хоть это и посложнее должно быть в программировании).

Начсет LPT -- он есть на подавляющем большинстве компов и исчезать не собирается. Максимум, на что производители решились пойти -- убрать сам 25-ти пиновый разъем с задней панели. Но его всегда можно докупить на барахолке.


Пока только аналоги микросхем интересуют.


Это сложный вопрос. Была бы схема LPT-варианта -- было бы легче решить.
Критериев немного: простота схемы, безопасность эксплуатации, сложность программирования, перспективность (в плане ускорения, перевода на ДМА).

ЗЫ: Кстати, вопросец хотел задать еще один.

На ромбе высказали идею подключения шлейфа на комп-эмулятор не к одному иде-разъему, а сразу к двум.

Точнее, поскольку проблема заключается в несоответствии количества IN и OUT контактов, то "недостающие" предлагается взять с другого IDE-разъема.

Хочется услышать комментарий специалиста по поводу данного решения.

(U)DMA, наверное, все равно не удастся организовать ?

#77

Режим доступа: EPP 1.9
В этом варианте меньше ошибок, чем в верхнем.

serj

Спасибо большое! Поразбираюсь на досуге.
Я правда, не понял, куда D8..D15 делись ? Или ИДЕ в 8-ми битном режиме будет работать ?

Да, сигнал интерфейса '16 бит' = High

xKVtor кстати, обрати внимание на контроллер
http://www.jmicron.com/Product_JM20337.htm

Не подойдет ли?

Daemon

Вряд ли. Если бы эта микросхема умела работать в обоих направлениях, то тогда да, возможно подошла бы. Но об этом в описании нигде не говорится, что не удивительно. А более полной документации нет.

К тому же, сомневаюсь, что разработчики могли себе представить вариант подключения USB-девайса к SATA/IDE контроллеру. В первую очередь потому, что чистокровных USB-приводов и накопителей в природе пока что не встречается. Ну, разве что кроме юсбовых флэшек. Но они не в счет, т.к. их стоимость наверняка меньше стомости контроллера на предлагаемой микросхеме.

Хотя, такой переходник с юсб-накопителей на sata/ide контроллеры предоставил бы потребителям дополнительные возможности. Например, возможность установить не только ДОС, но и любую винду (9x/nt/xp/...) на юсбовый девайс. Но подобные приятные для потребителей мелочи вряд ли подстегут производителей к выпуску таких двунаправленных переходников.

Хватает и других "НО".
Так что все как обычно очень мрачно и безысходно.

есть у меня USB->Ide кабель. при загрузке компа устройства определяются сразу как усб девайсы. проблем с работой нету. единственное что ограничивает это скорость усб2.0

по теме. было бы понятно если бы тема всплыла лет 10 назад когда локальные сети еле работали на 10мбит. но сейчас чуть ли не в каждой маме гигабитная сетевуха. и кабель 5р. за метр. даже если сетевухи отдельно покупать то затраты на соединение будут не больше 1к р.

MaStEr-Xmoder Ты о чём речь идёт понял? Здесь задача не инфу передать, а сделать это по IDE интерфейсу. Не суди о книге по обложке
Что по теме
xKVtor Не думаю, что двунаправленные контроллеры так распространены, потому не стоит на них ориентироваться.