Люди, к чему этот экстремизм? 6 шт. шинных драйверов (или 3 8-разрядных), 3-4 м/с - селектор адреса, одна - фиксатор младших битов адреса, штуки три - прерывание и DMA, остальное - в контроллер, любой современный, хоть в АТМегу. 32-й, по беглым прикидкам, хватит. Я, конечно, понимаю, хотелось бы запихнуть в контроллер всё, но занимать контроллер прямым обслуживанием Q-BUS - это и 200 МГц не хватит...
Присутствующий здесь SuperMax к АТМегам даже Ethernet прикручвал...
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Вот тут что называется "задел за живое"! Об этом самом мечтают чутли не все pdp-шники мира, а воз и ныне ТАМ! Что интересно что уже были сделанны ide контроллеры работающие в PIO режиме и доки на них есть, но не устраивает общественность такой вот вариант: http://forum.maxiol.com/index.php?showtopic=4919Сообщение от AFZ
или http://forum.maxiol.com/index.php?showtopic=4920
вероятно суть в том что:
1. устройства если изготовить то цена будет около $100 за штуку (в лучшем случае), что примерно равно усилиям по прикручиванию rqdx3 + st251;
2. нету DMA (это очень многих расстраивает - значит не pdp11 стиль...);
3. нужен 100% MSCP стандартный контроллер, так как многим нужно именно для культовой связки 512Kw+kdj11+2.11BSD; (поэтому цена на qbus scsi стартует с $225);
КАК ПО МНЕ ДАК, идеал современного storage для pdp11 достигнут в pdp2011: http://pdp2011.sytse.net/wordpress/pdp-11/, там есть реализация на MMC/SD карточке:
- RK11(диски RK-05)
- RH11/RH70 (RP/RM диски такие жЫрные как RP06, при одной озвучке названия которых form смеялся а я по неопытности не понимал почему)
- RL11(диски RL02)
это как по мне дак вообще улет, так как может тянуть все старые системы, даже 2.9BSD в которой нету MSCP.
p.s. Правда не ясно как переделать из UNIBUS-a...? И еще, могут ли драйверы оказавшись на q-bus продолжать работать с этими же контроллерами которые в реальной жизни бывают только на unibus?
Последний раз редактировалось bigral; 16.03.2015 в 22:09.
Да оно и понятно - клепать такое на "рассыпухе" - ужасно,сделать всё на FPGA - это надо владеть навыками высшего пилотажа в этой области, потому -сложно очень, все-таки винчестеры, SD-карты и пр. заточены для работы с нормальным процессором - компа или микроконтроллера - неважно; городить эти протоколы на FPGA - та еще работка. А отрабатывать на МК Q-Bus - даже 72-МГц Cortex-M4 не справится. А вот промежуточное решение, ИМХО, подъемно и для лиц, не владеющих навыками высшего пилотажа. Связь с Q-Bus, регистры, которые должны быть видны со стороны Q-Bus, контроллер DMA и управление прерываниями делаем на FPGA, с другой стороны какой-нибудь простенький интерфейс с МК, и это всё содержимое FPGA, ничего военного. А к МК можно будет прицепить что угодно - хоть Ethernet, хоть SD-карты, хоть IDE-винчестер, хоть писюшный переходник SATA-IDE и SATA-винт... Если очень хочется, можно попробовать впихнуть в FPGA что-то, прикидывающееся DEC-овскими устройствами, но лучше, ИМХО, склепать что-то своё - драйвера мы писать умеем, а городить аналоги DEC - значит усложнять начинку FPGA, можем и не справиться.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Вопрос спорный. "умеем писать" в данном контексте скорее всего означает "умеем только для RT-11, да и то не мощнее SJ". Ну с RSX/TSX все не так плохо, а если захочется другие системы запускать?
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
Да оно и понятно - клепать такое на "рассыпухе" - ужасно,сделать всё на FPGA - это надо владеть навыками высшего пилотажа в этой области, потому -сложно очень, все-таки винчестеры, SD-карты и пр. заточены для работы с нормальным процессором - компа или микроконтроллера - неважно; городить эти протоколы на FPGA - та еще работка. А отрабатывать на МК Q-Bus - даже 72-МГц Cortex-M4 не справится. А вот промежуточное решение, ИМХО, подъемно и для лиц, не владеющих навыками высшего пилотажа. Связь с Q-Bus, регистры, которые должны быть видны со стороны Q-Bus, контроллер DMA и управление прерываниями делаем на FPGA, с другой стороны какой-нибудь простенький интерфейс с МК, и это всё содержимое FPGA, ничего военного. А к МК можно будет прицепить что угодно - хоть Ethernet, хоть SD-карты, хоть IDE-винчестер, хоть писюшный переходник SATA-IDE и SATA-винт... Если очень хочется, можно попробовать впихнуть в FPGA что-то, прикидывающееся DEC-овскими устройствами, но лучше, ИМХО, склепать что-то своё - драйвера мы писать умеем, а городить аналоги DEC - значит усложнять начинку FPGA, можем и не справиться.
Я еще для ДИАМСа умею.
Что-то форум расколбасило - я просто сделал быстрый ответ, а тут вон что вылезло...
Последний раз редактировалось AFZ; 19.03.2015 в 12:05.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Ну хочется как минимум RSTS/E, ULTRIX-11, 2.11BSD, XXDP... Про экзотику вроде UNIX, 2.9BSD уж не говорю - ладно, ее и так без доработки у меня например не запустить
В идеале хотелось бы получить возможность с минимальными телодвижениями (при наличии готового железа) иметь под рукой максимум всегда готового к работе
И тут часто даже более-менее стандартные возможности требуется ограничивать до еще более стандартных. В частности RSTS/E попросту рушится если на один MSCP контроллер повесить больше 4 дисков
---------- Post added at 15:16 ---------- Previous post was at 15:12 ----------
Попутно, поскольку у народа уже набирается достаточно их, замечу, что правила требуют, чтобы физические номера устройств были все разными (на всех контроллерах). Связано ли это с чем-то кроме особенностей стандартных KDJ11-B/E (на них иначе не получится) не знаю
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Ну, как вариант, можно разработать некий стандартный девайс с FPGA и МК на борту, остальные вопросы решаются софтово. Залей в FPGA отработку MSCP - будет MSCP, залей RK05 - будет RK05. При нужде, таких девайсов можно воткнуть и несколько... Но первично, ИМХО, стоит склепать что-то простенькое своё, интерфейс с Q-Bus сделать по типу MY, т.е. два регистра на Q-Bus, в них передается адрес таблички в памяти, а там уже расписано все, что нужно сделать. Остальное - через DMA. Ну, и, при таком простом интерфейсе нового устройства, найти и дизассемблировать драйвер какого-нибудь простого в управлении диска и сделать из него прямым патчем бинарника новый драйвер - сложно, но можно.
---------- Post added at 15:43 ---------- Previous post was at 15:28 ----------
Кстати, тут уже несколько раз проскакивало, что буржуйские корзины с Q-Bus и наши Э-60/ДВК несовместимы. Что, Э-60 не цельнотянутая? Или, как всегда, дюймы-миллиметры? А то я из "больших" -11 только дохлую СМ 1420 потрошил на детали.
Последний раз редактировалось AFZ; 19.03.2015 в 12:46.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
На мой взгляд, это не самый правильный подход. Полагаю, что гораздо правильнее возложить на FPGA простую взаимную конвертацию родного протокола Q-Bus ( передающегося по линиям шины ) и пакетного протокола, передающего все транзакции Q-Bus в последовательной форме.
Тогда можно без больших проблем эмулировать хоть всё железо одновременно, потому что на пакет DIN будет отвечать пакетом RPLY только тот эмулятор, который обнаружил "свой" адрес Q-Bus в пакете SYNC.
При таком подходе разные устройства могут одновременно эмулироваться на разном железе. Что-то можно эмулировать сразу в FPGA, что-то в микроконтроллере адаптера, а разрабатываемые, отлаживаемые и просто временно запускаемые эмуляторы различных устройств - на любом компьютере, общающемся с микроконтроллером такого адаптера через Ethernet, Wi-Fi или USB.
...
Последний раз редактировалось Patron; 19.03.2015 в 14:01.
Тоже, конечно, вариант. Очень хороший, но в реализации сложновато будет. Я не очень представляю себе, что такое "пакетный протокол", но, по-любому, передача в МК должна быть в виде "байт, слово или слово с несколькими битами сопровождения, плюс сигнал прерывания (не поллить же из МК адаптер Q-Bus?), а назад - слово с несколькими битами типа RPLY, требование прерывания и т.п. При этом FPGA должен отслеживать адрес Q-Bus, чтобы отвлекать МК только на запросы к нему, а не на весь трафик по Q-Bus. Ну, допустим, получили мы обращение по адресу 177440, прерываемся. Возьмем один из лучших недорогих МК - 72-МГц Кортекс М4. Частота транзакций Q-Bus, вроде-бы, 2 МГц, итого на обслуживание цикла Q-Bus можно потратить до 36 тактов, иначе придется тормозить RPLY. А у Кортекса только прервыание занимает 12 тактов, еще 12 тактов - возврат из прерывания, осталось 12 тактов, за которые надо успеть считать , чего от нас хотят, выставить соответствующий регистр на шину связи и дать ответ. Дай Бог уложиться в оставшиеся 12 тактов. И, если с той стороны программа вдруг займется "прополкой" этого регистра, то 30-50% производительноси этого Кортекса окажется занятой. А мы в это время, допустим, что-то по Ethernet'у получали...
Да и по-любому. сложно это.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
А что делать с тайм-аутом на RPLY в 64 такта процессора, характерное время 10 мкс? Пинг в 10мкс у меня даже в прямом гигабитном проводном эзернете не обеспечивается, не говоря про WiFi. Поэтому на уровне адресов и транзакций шины эмуляция на удаленном хосте не получится.
Эту тему просматривают: 2 (пользователей: 0 , гостей: 2)
Ваши права
Ответить с цитированием
