Верхнюю - это выше 64К? Ну, возможно, хотя я не очень представляю причины такого явления. С точки зрения DMA-устройств вся память - это плоское пространство размером в 256К, 18 бит адреса, и ситуация addr[17:16]==2'b00 не является чем-то особенным.
Другое дело, что я не реализовал DMA в пространство страницы ввода-вывода. Мне казалось что это бессмысленно, но может быть я и ошибался. Завтра проверю.
RT и RSX прописывают во второе слово вектора седьмой приоритет, и с хорошей степенью вероятности (тоже надо постараться, что бы не так было) почти сразу в обработчике они уходят на нулевой приоритет - в этом случае фиолетово - какой приоритет запроса у устройства. Вполне возможно, что у RSTS/E не так и если она в вектор выставляет предполагаемый реальный уровень приоритета - то и получается, что она ожидает 5, а прилетает прерывание (6 приоритет), когда не должно. Так что тут может быть и со схемой прерываний что то не так. Но это предположение.Сообщение от forth32
А XXDP вообще фиолетово на прерывания. Ей главное, что бы DMA в нижнюю память (если устройство DMA) работало - и она на чем угодно загрузиться
- - - Добавлено - - -
Да, когда задействуются биты 17 и 16 адреса
Это и не требуется. Больше того, если проц Unibus и работает UMR (по сути - часть проца), то реализация UMR (вроде как в большинстве вариантов реализации, если не во всех) и не пропустит запрос на страницу в/в
- - - Добавлено - - -
Самый банальный (не говорю, что он) вариант - биты 17 и 16 от устройства не долетают до памяти - и всё на самом деле пишется в нижние 64к
Последний раз редактировалось Hunta; 25.11.2022 в 23:25.
Проблема с незагрузкой RSX11M немного локализовалась.
Оказалось, что возникает она в ситуации, когда программа обращается к PSW по адресу 177777. Как следует из описания процессора, при этом сигналы на внешней шине не формируются, вся обработка происходит внутри процессора. И обычно так оно и бывает, особенно после недавнего патча от VSLAV. Но иногда, вместо того чтобы тихо обработать команду внутри себя, процессор генерирует внешний цикл обращения к странице ввода-вывода с адресом 777776.
Вот осциллограмма, поясняющая ситуацию: https://disk.yandex.ru/i/mgKlqKVvWC92tg
Это кусок начального загрузчика RSX-11M (одна из частей SAV.TSK), выполняющий раннюю инициализацию устройств в процессе загрузки системы.
По адресу 110600-110602 расположена команда CLRB @#177776. После ее выборки процессор почему-то поднимает сигнал обращения к странице ввода вывода (wbm_ios, последняя строка), а затем и строб wbm_stb (предпоследняя строка). Подождав для приличия, процессор констатирует таймаут шины и уходит выбирать вектор 4. Дальше уже неинтересно, ибо этого быть не должно.
Конечно, прежде чем пытаться обратиться к первоисточнику VSLAV, надо как-то локализовать условия, при которых проблема проявляется. Надо как-то вытащить из процессора в сигналтап как минимум PSW и регистр SR0, чтобы понять текущий режим работы процессора. И найти в исходниках SAV этот фрагмент. Но в любом случае, какой бы режим не был в данный момент активен, ситуация эта ненормальная. Раз процессор поднял сигнал IOS, значит он целенаправленно лезет на страницу ввода-вывода. А на этой странице по адресу 177776 ничего нет и быть не может, ибо PSW через шину недоступно. Следовательно, по этому адресу процессор НИКОГДА штатно не должен лезть через внешнюю шину.
Буду думать дальше. Видимо, пора лезть в схему самого процессора и искать, где там лежат внутренние регистры.
Последний раз редактировалось forth32; 27.11.2022 в 16:35.
Так всё таки по адресу
Или
?
Ну и именно такой команды
в исходниках SAV с ходу не нашлось
- - - Добавлено - - -
Ну и команды CLRB (005037) я на диаграмме не вижу. Картинка, конечно, так себе, но всё, что я увидел, это 207 по адресу 110600 (на запись? если wbm_stb это сигнал записи), а потом 6666 по адресу 110602 (то же на запись?)
Ну, ошибся малость. 177776, конечно. Я вообще не знаю,возможна ли к PSW байтовая адресация. Никогда не пробовал.
SAV от RSX-11M v4.8? Ну, я сам еще не смотрел, так быстро ведь команду не найдешь, я думаю что там немало команд CLRB.
Может быть конечно это и не SAV, но кто еще может заниматься инициализацией системы? Хотя, конечно, это может быть и кусок драйвера какого-нибудь - большинство драйверов резидентны в сохраненном образе системы. Раньше я как-то не особо интересовался тонкостями процесса начальной загрузки. Тут плотно копать надо, может быть даже трассировать процесс загрузки системы...
Но все это не отменяет того факта, что по команде CLRB @#177776 процессор полез на внешнюю шину.
Возможна
Да, именно там. 20 раз встретилсь CLRB. Сейчас ещё другой вариант проверю
- - - Добавлено - - -
Да, скрывает оно под макросом. Вот этот кусок
Ничего необычного в нём не вижуКод:; ; FIND CLOCK AND ALL DEVICES ON SYSTEM ; CLOCK: BIS #<PMODE+CMODE>,@#PS ;;; GET BACK INTO USER MODE .ENDC CALL $STCLK ;;; SELECT CLOCK AND INITIALIZE ;;; CLOCK AND FPP VECTORS CALL $TSTDV ;;; LOOK FOR NONEXISTENT DEVICES, ;;; SIZE DISKS, SET UP PARITY ;;; REGISTERS, DETERMINE SIZE OF ;;; MAIN MEMORY MTPS #0 ;;; ENABLE INTERRUPTS ; ; CONVERT PHYSICAL UNIT NUMBER TO LOGICAL DEVICE NUMBER ;
- - - Добавлено - - -
Если что, макрос MTPS раскрывается в CLRB @#177776
- - - Добавлено - - -
Единственное из занимательного - (судя по BIS #<PMODE+CMODE> и по тому, что я увидел в $STCLK и $TSTDV) CRLB отрабатывает из пользовательского режима. Может в этом и причина неправильного поведения CRLB?
Я так понимаю, что если в адресное пространство входит страница ввода-вывода и она R/W, то команда должна отработать независимо от режима пользователь-супервизор. Если страница не входит в адресное пространоство, или она R/O - будет трап MMU. Если на месте 177776 в адресном пространстве лежит просто память, то отработает обычный цикл шины.
Или я не прав, и процессор защищает PSW от записи в режиме пользователя? Но если и защищает, то только старший байт, а не оба. А тут именно поднялся флаг IOS, то есть процессор явно полез на страницу ввода-вывода. Никаких трапов.
Вообще говоря, такая проблема имела место быть, и VSLAV последним коммитом пытался ее устранить. Но он это сделал чисто косметически, просто подавив сигнал wb_stb при обращении к внутренним регистрам. Может быть причина и глубже....
А в младшем байте ещё и приоритет. И вот с ним дела мутноватое. Например - а работает ли приоритет процессора в пользовательском режиме вообще? Если да, то он тоже должен защищаться. И вроде так оно и есть - память царапает, что вроде где то в тестах я видел проверку - SPL в пользовательском режиме не меняет приоритет процессора.
Хотя в принципе это всё на реальных процессорах проверяется быстро - написать такие спец тесты - дело 5-15 минут
Или схема восстановлена не совсем правильно. Или где-то времянка (в синхронном дизайне) пролетает. На реальном то F11 это всё вроде не наблюдается. Сейчас попробую грузануть на KDF11, но, насколько я помню - уже грузил
- - - Добавлено - - -
Начал проверять. И кстати, вспомнилось ещё одно. Если образ RSX по размеру больше 494 (примерно) блоков - он вполне может и не загрузиться (но как свезёт) на PDP с размером памяти 256 кб или меньше - если SAV сидела в памяти (по крайне мере её хвост) выше 256 кб
- - - Добавлено - - -
Хотя, наверное, правильный размер 514 блоков, просто SYSGEN, когда проц не 22-битный, создаёт образ такого (494) размера, насколько я помню
- - - Добавлено - - -
Ну как и ожидалось
Да и врят ли DEC допустила бы такой ляпсусКод:@10000G HX 2.2 RT-11 Cold boot.. HX DSK/TTY multiplexer v3.3 2016 RT-11SB (S) V05.07 .R MSCPCK .BOO ZB1:RT11SB RT-11SB (S) V05.07 .R MSCPCK .BOO C40:/FOR RSX-11M-PLUS V4.6 BL87 2044.KW System:"KXX002" >RED ZC1:=SY: >RED ZC1:=LB: >RED ZC1:=SP: >MOU ZC1:"RSX11MPBL87" >@ZC1:[1,2]STARTUP >; PLEASE NOTE >; >; If you have not yet read the system release notes, please do so >; now before attempting to perform a SYSGEN or to utilize the new >; features of this system. >; c; SET -- Inquire cannot determine terminal type >; >; Please ignore any random characters that may have printed on your >; terminal just now. They came from a SET /INQUIRE=TI: command. >; Evidently your terminal does not recognize escape sequences. >; This will not affect the running of this command file. >; >* Please enter time and date (HH:MM DD-MMM-YYYY) [S]: 20:23 27-nov-2022 >TIME 20:23 27-nov-2022 >ACS SY:/BLKS=1024. >CON ONLINE ALL >ELI /LOG/LIM >CLI /INIT=DCL/CTRLC/DPR="<15><12>/$ /" .......
Последний раз редактировалось Hunta; 28.11.2022 в 09:31.
Великий и могучий VSLAV разобрался наконец с проблемой CLRB PSW, и сделал фикс. После фикса все заработало!
Вот RSX-11M:Скрытый текст
Код:$DB DEVICE DU000: NOT IN CONFIGURATION DEVICE DU001: NOT IN CONFIGURATION RSX-11M V4.8 BL70 124.K MAPPED (BASELINE) >RED DB:=SY: >RED DB:=LB: >MOU DB:RSXM70 >@DB:[1,2]STARTUP >* Please enter time and date (HH:MM DD-MMM-YY) [S]: 6:37 05-dec-22 >TIME 6:37 05-dec-22 >* ENTER LINE WIDTH OF THIS TERMINAL [D D:132.]: 80. >SET /BUF=TI:80. >ACS SY:/BLKS=1024. >@ <EOF> >@sysgen >; >; RSX-11M V4.8 BL70 System Generation PHASE I -- Version 06.03 >; >; 05-DEC-22 06:37:08 >; Big disk distribution kit >; >* 1. Autoconfigure the host system hardware? [Y/N]: y >INS $ACF.BSL >INS $ACO �F >ACO SHOW Processor Type: 11/23 Memory Size: 2044. Kw Options: Floating Point Processor (FP11) Extended Instruction Set (EIS) Extended (22-Bit) Addressing Parity Memory Name Vector CSR Unit Type Remark RHA 254 176700 0 RP06 1 RP06 2 RP06 3 RP06 4 RP06 5 RP06 6 RP06 7 RP06 DXA 264 177170 YLA 060 177560 >ACO SYSGEN >REM ACF >REM ACO >* 2. Do you want to override Autoconfigure results? [Y/N]: ^Z[свернуть]
А вот RSTS/E v10:
Скрытый текст
Код:141703 000001 000550 000000 $DB4 RSTS V10.1-L RSTS (DB4) INIT V10.1-0L Today's date? 5-DEC-22 Current time? 6:39 Start timesharing? <Yes> Disk is being rebuilt - wait ... Cannot use extra 12K of buffers. Reduced to 1K. Size of monitor has changed from 70K to 58K. Default memory allocation table shows LESS memory than INIT detects on this machine. Adjusting memory table. Memory allocation table: 0K: 00000000 - 00347777 ( 58K) : EXEC 58K: 00350000 - 15523777 (1691K) : USER 1749K: 15524000 - 17757777 ( 295K) : XBUF Memory available to RSTS/E is 2044K words. 22.12.05 06:39 3 devices disabled Proceed with system startup? <YES> Beginning RSTS/E system startup... 22.12.05 06:39 Installing monitor overlays 22.12.05 06:39 Installing Virtual Disk 22.12.05 06:39 Mounting disks 22.12.05 06:39 Assigning logical names 22.12.05 06:39 Starting error logging 22.12.05 06:39 Setting system characteristics 05-Dec-22 06:39 Installing run-time systems and libraries 05-Dec-22 06:39 Starting Operator/Message Services >>>>>>>>>>>>>>> OMS V10.1-A 05-Dec-22 06:39 <<<<<<<<<<<<<<< Message 1 from OMS, user [1,2], Detached, job 3 Starting Operator/Message Services 05-Dec-22 06:39 Setting terminal characteristics 05-Dec-22 06:39 Defining system commands 05-Dec-22 06:39 Setting printer characteristics 05-Dec-22 06:39 Starting spoolers *** From [1,2] "[ 1, 2]" on KB0: at 06:39 05-Dec-22 ** RSTS/E is on the air... >>>>>>>>>>>>>>> OMS V10.1-A 05-Dec-22 06:39 <<<<<<<<<<<<<<< Message 2 from user [1,2] on _KB0:, job 2 The system startup is complete $[свернуть]
Все отлично. Я добавил в схему регистр управления прерываниями от таймера, теперь можно и XXDP грузить не выключая таймер вручную.
Теперь надо еще ограничить память до 256К, включить остальные устройства и попробовать RSX в этих условиях. Кому интересно, могут сами это проделать. Все изменения уже лежат в репозитории, за ограничение памяти отвечает флаг RAM256 в config.v, в секции процессора F11.
$DM2
RSX-11M V4.8 BL70 128.K MAPPED
SAV -- Cannot find home block
145152
------------------
RSTS --- OK
------------------
$DB
OD:064524
XDT>
------------------
TSX 6.01 --- OK
------------------
"Зависание" дисков при работающем таймере устранилось.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием