В СМ1420 было, в версиях с большой памятью.
В СМ1420 было, в версиях с большой памятью.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Для переключения мышления с программирования на синтез поразвлекался немного с UMR.
Дo:
После:Код:Total logic elements 2,296 / 8,256 ( 28 % ) Total combinational functions 2,229 / 8,256 ( 27 % ) Dedicated logic registers 904 / 8,256 ( 11 % ) Total registers 904 Total pins 119 / 138 ( 86 % ) Total virtual pins 0 Total memory bits 1,344 / 165,888 ( < 1 % )
Блоков памяти, конечно, много, но пока не знаю, сколько понадобиться по XU, так что.. На всякий случай и как упражнение для умаКод:Total logic elements 2,226 / 8,256 ( 27 % ) Total combinational functions 2,160 / 8,256 ( 26 % ) Dedicated logic registers 859 / 8,256 ( 10 % ) Total registers 859 Total pins 119 / 138 ( 86 % ) Total virtual pins 0 Total memory bits 672 / 165,888 ( < 1 % )
Занялся Ethernet-ом. Пилить много и долго, пока тупое редактирование исходников.
насчет 18 и 22 разрядов.
Достоверно известно (официально продавался), что работает в ПРОС на Электронике-85 через специальный переходник на Q-bus И17(контроллер лент),
а он 18-ти разрядный с ПДП.
Это факт, а мне не понятно - как это получается ?
Это контроллер лент для Э60, значит он, априори - QBus, значит переходник для него был банальным.Сообщение от ra3qdp
То, что контроллер для QBus 18-ти разрядный, не значит, что он не будет работать в корзине на 22 бита. Будет.
Дальше возникает вопрос - старшие 4 бита адреса будут висеть в воздухе - что увидят устройства на шине? Судя по некоторым соображениям - логическую единицу, то есть при попытке использовать ПДП контроллер будет шарашить данные в верхние 256 кб (248 кб потенциального ОЗУ и 8 кб страница в/в). И вот тут становится понятным окно в 256 кб в верхней памяти при использовании UMR - через него можно отлично писать куда угодно в памяти, естественно, правильно настроив UMR. Возможно (мои догадки) 18-ти разрядные контроллеры Unibus так и работали - через это окно, без прямого заведения шины адреса в UMR.
Так что можно предположить, что на этой плате были и UMR.
Дальше можно пойти гадать в другом месте. А лучше найти документацию или саму плату-переходник и посмотреть - как оно.
У меня (пока) контроллер RK (и будущий контроллер XU) адресную шину напрямую заводят в UMR, так что теоретически (надо посмотреть, как на это будут реагировать ОС) можно использовать память выше 3840 кб.
Ни разу такого не видел, значит скорее всего было в небольших количествах, но вариантов может быть много:
1. Использовалась система не использующая ДП(например - мониторы RT11 SJ/FB)
2. Специально написанные драйвера.(То есть отводится буфер в нижних 256 Кбайтах памяти и чтение/запись идёт оттуда, потом данные процессор разносит куда надо.) Я такое в руководстве по RSX-11 читал когда-то(но точные детали не упомню). Я полагаю, что возможно программисты в те давние времена, когда не было понятно как аппаратно будет решаться проблема с 18-разрядными устройствами при шине 22 бита подстелили соломки
В RT11XM вопрос можно решить аналогично, сам драйвер находится в нижних 56 Кбайтах. И при неиспользовании виртуальных заданий - драйвер даже переписывать не надо. Всё и так в нижней памяти. Вот при использовании виртуального задания(виртуального оверлейщика, виртуальных массивов фортрана) возможны проблемы...
Что касается остальных ОС, то скорее всего - правильные драйвера.
МС 1601.02 плата М-6 и МС 1213 плата М-5 должны иметь почти те же решения, что для Электроники-85.
- - - Добавлено - - -
По-хорошему да, смотреть схему переходника и схему диспетчера памяти/контроллера памяти внимательно и сделать выводы... Или попробовать на практике. Сгореть ничего не должно
Только вот где бы это всё взять сейчас Электронику-85(реально), переходник(маловероятно), контроллер(среде-вероятно), магнитофон (реально)... Эх...
Последний раз редактировалось Alex; 28.04.2020 в 14:19.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Напрямую RT11-XM вроде как не поддерживает UMR, а в 5.7 (может быть уже и в 5.6) есть драйвер UBX.SYS - UMR PSEUDO HANDLER
И я не помню ни в драйверах для RT ни в драйверах RSX что бы использовался такой буфер, кроме драйверов для DU и MU в RSX - так создаётся какой то PUCOM. Но вот для чего он - не скажу, может быть это и не связано с проблемой 18-ти бит...
На F-11 вроде как UMR нет...
Буфер в нижней памяти возможно изначально предназначался для решения проблемы 18-22, а ведь его можно использовать для малого кэширования накопителя... Если на десяток хотя бы блоков - то прирост скорости на некоторых задачах ..
Исходно, они предназначен для процов Unibus и, насколько я знаю, ни в одном проце для QBus от DEC их нет. Но если в проце 22-ух битный ДП, по идее должен быть выход бита UMap Enabling. Как, например, на 1801ВМ3.
Технически, UMR входят в состав ДП, но практически - они как вроде практически полностью работают самостоятельно (кроме бита разрешения)
Так что ни на F-11 ни на J-11 их нет в принципе.
Насчёт кэширования - насколько я в курсе - ни один драйвер DEC кэширования не реализует. В RSX+ есть независимый от драйверов механизм кэширования, причём в достаточной степени на уровне файловой системы, а не тупо - блоков.
На J-11 регистров куча в процессоре, причём на последних версиях J-11 их стало ещё более(в основном диагностика)... На первых PDP-11 вообще было только PSW. Потом добавили MMU. Я читал по диагонали, чисто из интереса... Ведь увы, от DEC J-11 мне не светит. И что там навтыкали... Вроде на последних было, что вся память работает со скоростью кэша.
У меня была идея сделать псевдодрайвер кэша дисковых устройств на RT11, но далеко не продвинулся
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
