Я думал, там что то новое появилось.. А это уже 12-ого июня было..
Вид для печати
Странно, что уважаемый VSLAV не отписался об этом в своей профильной ветке (цифровая археология). А я и не знал, что F11 уже готов. Теперь можно делать процессорную плату.
Жалко, что я не знал об этом летом. Времени в отпуске свободного было много. Придется выкроить его сейчас, уж больно интересная тема - первый процессор с диспетчером памяти. Настоящий, а не синтетический эмулятор типа pdp2011. На первый взгляд, VSLAV сохранил внешний интерфейс процессора примерно таким же, какой был и у других процессоров, что сильно упрощает задачу. Буду пробовать погонять на нем XXDP-тесты...
По комментариям не понятно (или я не увидел) - сделана она полностью (то есть проходит тесты) или нет
В логе git есть вот это:
То есть какие-то заводские тесты проходят. Если XXDP загрузится, то можно будет погонять уже специализированные тесты, если есть такие. Кстати, я что-то не припомню, существуют ли они вообще. Для J-11 видел, а вот для F-11 навскидку не попадались.Код:- runnable on FPGA, factory tests passed
Наконец нашел время и собрал процессорную плату на отреверсенном F11. Пока, конечно, по упрощенной схеме, без поддержки DMA. Пришлось помучаться с регистром начального пуска FDIN, но, в итоге, плата заработала. Встроенный в микрокод ODT запустился, консоль-загрузчик М9312 тоже. XXDP загрузилась:
Кстати, первый раз вижу, чтобы XXDP спрашивал тип шины. До сих пор он сам мог определить, QBUS или UNIBUS у меня. Видимо, это связано с тем, что на том же F11 существует плата KDF11-U и машина PDP-11/24 с шиной UNIBUS.Код:177777
@165020G
177777 177777 177777 177777
$DX
CHMDXC0 XXDP+ DX MONITOR
BOOTED VIA UNIT 0
28K
DOES THIS SYSTEM HAVE A UNIBUS? (Y/N CR=Y) N
NON-UNIBUS SYSTEM
ENTER DATE (DD-MMM-YY):
RESTART ADDR: 152010
THIS IS XXDP+. TYPE "H" OR "H/L" FOR HELP.
.D
ENTRY# FILNAM.EXT DATE LENGTH START
1 JKDAD1.BIC 3-MAR-83 28 000050
2 JKDBD0.BIC 3-MAR-83 52 000104
3 JKDCB0.BIC 3-MAR-83 52 000170
4 JKDDB0.BIC 3-MAR-83 32 000254
5 JKDEB0.BIN 3-MAR-83 90 000314
6 JKDFA0.BIC 3-MAR-83 25 000446
7 HUDIB0.SYS 3-MAR-83 5 000462
8 UPD2 .BIN 3-MAR-83 25 000467
9 HDDXB0.SYS 3-MAR-83 3 000520
10 JKDIA0.BIC 3-MAR-83 23 000626
.
Тест MMU JKDA работает:
Скрытый текст
Код:.R JKDA??
JKDAD1.BIC
CJKDAD0 KTF11-AA MMU DIAG.
SWR = 000000 NEW =
END PASS # 1 ;TOTAL ERRORS SINCE LAST START AT 200 0
END PASS # 2 ;TOTAL ERRORS SINCE LAST START AT 200 0
[свернуть]
На этом все хорошее заканчивается.
Тест процессорной логики JKDB виснет намертво.
Первая часть теста FPP, JKDC, проходит без ошибок:
Скрытый текст
Код:.R JKDC??
JKDCB0.BIC
CJKDCB, KEF11-A FP DIAGNOSTIC PART 1
SWR = 000000 NEW =
END PASS # 1
END PASS # 2
END PASS # 3
[свернуть]
Но вторая часть, JKDD, также виснет намертво. О загрузке чего-то большего чем XXDP можно только мечтать - даже убогий RT-11 молча виснет.
Тут, конечно, могут быть и мои косяки. Особенно с обработкой прерываний - я это делаю немного не так, как VSLAV в своей референсной схеме. Но, с другой стороны, вся остальная платформа уже протестирована на нескольких разных процессорах, в том числе на очень похожем LSI-11, и на 22-битном PDP2011. И все явные проблемы давно уже выловлены. Хуже, если проблема все же в самом процессорном ядре - тогда придется лезть в его кишки, поскольку сам великий VSLAV тут больше не появляется.
Вообщем, теперь надо брать в зубы листинги тестов, начиная с JKDB, поднимать signaltap и начинать нудное разбирательство. Но радует, что уже хоть что-то заработало.
Все мои эксперименты лежат в экспериментальной ветке F11 репозитория - https://github.com/forth32/dvk-fpga/tree/f11.
Логика там такая - если тип процессора (MFPT) - 3, проверяется наличие регистра переключателей. Если его нет - спрашивается.
- - - Добавлено - - -
Уточнение - зависит от версии XXDP+ - так, как описано - в самой последней. В более ранних - тупо - тип процессора 3 - спрашиваем.
Ну и более хитрая логика (но тоже может спросить), если тип процессора - не 3
Я до этого полагал, что UNIBUS от QBUS можно однозначно отличить по доступности PSW на шине по адресу 177776, ну или по наличию инструкций MTPS/MFPS. Видимо, все не так просто...
Один из признаков - наличие регистра переключателей - но его отсутствие - не говорит о том, что машина QBus. Не могу сказаать наверняка, но вроде на /24, /84 и /94 как его нет, а машины - Unibus
PSW и MTPS/MFPS вроде как вообще не играют роли
F11 запустился на QMTECH и OMDAZZ (есно с аналогичным результатом). Не могли бы вы выложить образ DX-диска с тестами 11/23? Я понятия не имею как создавать загрузочные XXDP диски и где брать драйверы.
Да сколько угодно. Прикладываю к этому сообщению.
Я лично их под simh делал. Загружался с DL-диска с полным XXDP, инициализировал диск DX, и потом копировал то что мне надо с DL на DX.
Интересно, пойдут ли у вас тесты JKDB и JKDD. У меня лично JKDB глухо виснет, так что даже пультовое прерывание HALT перестает работать. Проблема проявляется в тесте 375, проверяющем работу подсистемы контроля нижней границы стека. По адресу 40052 есть инструкция CLR STATUS, очищающая PSW. Это сделано для открытия прерываний. По логке теста, после выполнения этой инструкции процессор должен начать цикл обработки прерывания, поскольку уже имеется активный запрос прерывания от консоли.
Вместо этого процессор убегает на адрес 20400, пытается начать выполнять оттуда код, влетает в прерывание 4 и в процессе его обработки полностью умирает. Пропадает вся активность на внешних шинах. Микрокод продолжает работать, это видно на внутренних шинах, но что он там делает - это только великий VSLAV знает. Он, похоже, пока единственный, кто ковырялся в этом микрокоде, написал доку по микроинструкциям и даже дизассемблер на питоне. Он бы сразу сказал, в чем проблема. А без него как бы не пришлось мне самому стать ковряльщиком микрокода процессора. Ибо по-другому понять суть проблемы не получается.
Для начала я хочу выбрать все же время, прикрутить диск DX к референсной схеме от VSLAV (та, что идет в комплекте с процессорными ядрами), и попробовать погонять тесты там. Ведь сам-то VSLAV гонял все заводские тесты, получается что у него проблем не было. Но он запускал абсолютные бинарники, загружаемые вместе с прошивкой в FPGA, я же использую XXDP - может быть тут есть какая-то разница.
Спасибо, попробовал. Обе платы QMTECH и OMDAZZ ведут себя одинаково:
JKDAD1 MEMORY MANAGEMENT TEST - работает
JKDBD0 BASIC CPU TEST - вис
JKDCB0 KEFlt FLOATING POINT CHIP TEST 1 - работает
JKDDB0 KEFll FLOATING POINT CHIP TEST 2 - вывод SWR = 000000 NEW = --- <Enter> --- вис
То, что поведение однотипное - радует. Может Vslav появится и поможет...
Первая победа. С проблемой непрохождения тестов я разобрался.
Благодаря подсказке от VSLAV, правда дошедшей до меня весьма косвенным путем, я понял в чем дело. Оказалось, что моя схема неправильно формирует протокол входа в прерывание. В отличие от VSLAV, создавшего один универсальный контроллер прерываний, я использую отдельные контроллеры для разных уровней IRQ. Делал я это еще в процессе создания платы PDP2011, и мой набор сигналов несколько отличается от того, что сделал VSLAV. А именно - мой pdp2011 формировал сигнал запроса вектора ISTB для каждого уровня в отдельности - istb[6:4], а VSLAV сделал один-единственный выход ISTB (wbi_stb_o). Потому как у меня каждый сигнал подключается к отдельному контроллеру прерываний и определяет, какой именно из контроллеров отдаст вектор. А у VSLAV контроллер единый и он сам решает, прерывание какого уровня надо обслужить.
Вообщем, теперь все заработало. Пошел тест JKDA:Скрытый текст
Код:015770 000002 001100 000002
$DX
CHMDXC0 XXDP+ DX MONITOR
BOOTED VIA UNIT 0
28K
DOES THIS SYSTEM HAVE A UNIBUS? (Y/N CR=Y) N
NON-UNIBUS SYSTEM
ENTER DATE (DD-MMM-YY):
RESTART ADDR: 152010
THIS IS XXDP+. TYPE "H" OR "H/L" FOR HELP.
.R JKDB??
JKDBD0.BIC
CJKDBD0 DCF11-AA CPU DIAGNOSTIC
END PASS # 1��
END PASS # 15��
END PASS # 29��
END PASS # 43��
END PASS # 57��
[свернуть]
Почему-то номера проходов идут не подряд. Но как оно должно быть на самом деле я не знаю, потому как образцовой машины PDP11/23 у меня нет.
Также пошел FPU-тест JKDD:Скрытый текст
Код:.R JKDD??
JKDDB0.BIC
CJKDDB KEF11-A DIAGNOSTIC PART 2
SWR = 000000 NEW =
END PASS # 1��
END PASS # 2��
END PASS # 3��
END PASS # 4��
END PASS # 5��
[свернуть]
В качестве вишенки на торте, загрузилась RT-11:
Скрытый текст
Код:040000 143060 126064 141300
$DX1
RT-11SJ (S) V05.04 D
.SET TT QUIET
.DIR
DIR .SAV 19 17-Nov-87 RESORC.SAV 26 17-Nov-87
DUMP .SAV 9 17-Nov-87 STARTS.COM 1
RK .SYS 3 03-Jan-99 NL .SYS 2 06-Apr-99
TT .SYS 2 06-Apr-99 VM .SYS 3 06-Apr-99
SWAP .SYS 27 17-Nov-87 PIP .SAV 30 17-Nov-87
DUP .SAV 49 17-Nov-87 RT11FB.SYS 94 06-Apr-99
MY .SYS 3 02-Jan-99 ODT .MAP 1
ODT .SAV 8 DM .SYS 5 12-Jun-99
DW .SYS 15 02-Jan-99 RT11SJ.SYS 84 03-Jan-99
DX .SYS 4 03-Jan-99 SPEED3.SAV 8 29-Oct-88
20 Files, 393 Blocks
93 Free blocks
.SH CONF
RT-11SJ (S) V05.04 D
Booted from DX1:RT11SJ
USR is set SWAP
EXIT is set SWAP
KMON is set NOIND
TT is set QUIET
ERROR is set ERROR
SL is set OFF
EDIT is set KED
KMON nesting depth is 3
PDP 11/23 PLUS Processor
4088KB of memory
FP11 Hardware Floating Point Unit
Extended Instruction Set (EIS)
Memory Management Unit
50 Cycle System Clock
Device I/O time-out support
Error logging support
Multi-terminal support
SJ timer support
[свернуть]
Ну, и на этом пока все. Чтобы загрузить что-то более серьезное, надо собирать схему DMA. Но тут есть одна проблема. Большинство устройств, использующих DMA, умеют работать только с 18-битной адресной шиной. 22 бита из имеющихся у меня дисков умеют только MY и DB. Но MY - мелкая дискетка, а DB не поддерживает RT-11. Для машин с Unibus существует такой замечательный механизм как UBM, позволяющий 18-битным устройствам работать с любыми адресами физической памяти. И у нашего F11 есть выходной сигнал UMAP, включающий этот механизм. Но только вот плата KDF11A, которую мы сейчас собираем, это QBUS-машина, и там этого механизма нет. Следовательно, для работы с любыми дисками кроме DB придется ограничить ОЗУ до 256К. А это грустно, последние версии RSX-11M-PLUS и RSTS/E на такой памяти если и загрузятся, то работать будет практически невозможно.
Интересно, как же люди обходились на реальных 11/23 ?
Всё нормально, тест так устроен
- - - Добавлено - - -
В принципе - можно будет, но нужно сгенерить специально под такую маленькую память
Ну или допилить UMR
RQDX3
- - - Добавлено - - -
Кстати, есть ещё вариант - допилить контроллер RL11 - вариант RLV211, если мне не изменяет память про название, - QBus-ный и поддерживает 22 бита. Но для него тоже надо пилить RSX+, так как все файлы дистра, насколько я помню, на диск не влазят
На OMDAZZ при прогоне теста JKDDB0 часто возникает:
NO INTERRUPT FROM SLU IN ALLOTTED TIME.
FLOATING POINT ERROR, STOPPED AT PC=032622
Тест не "виснет", иногда проходит без ошибок.
RT-11 загружается.
Timer??? Время не "тикает".
- - - Добавлено - - -
.SH CONF
RT-11SJ (S) V05.04 D
Booted from DX1:RT11SJ
***
PDP 11/23 PLUS Processor
4088KB of memory
FP11 Hardware Floating Point Unit
Extended Instruction Set (EIS)
Memory Management Unit
50 Cycle System Clock
Для честной эмуляции RQDX надо ждать реверса Т11 ;)
Честная эмуляция DU-дисков вообще невозможна. Поскольку у нас тут не QBUS и MFM-диск, а Wishbone и SD-карта. То есть и прошивку придется переписывать, и схему в корне переделать. Проще создать контроллер с нуля, но он, гад, сложный, вначале придется дизассемблировать прошивку RQDX и разбираться в ней.
Тут, пожалуй, проще будет сделать PDP11/24 на том же процессоре F11. Это UNIBUS-машина, и там можно реализовать UBM.
На надо путать процессор (F-11), процессорную плату (KDF11-B) и компьютер (PDP-11/23 PDP-11/23+ PDP-11/24)
- - - Добавлено - - -
И кстати, DU (а точнее говоря - MSCP) - это не обязательно MFM диск
- - - Добавлено - - -
Кстати, о птичках. Её не просто дизассемблировали - всплыли исходники
Но на мой взгляд - RQDX, даже третий - так себе. Ну и MFM, конечно, энтузиазма не добавляет
А с чего ты решил, что я их путаю? Наоборот, я пока жестко придерживаюсь плат KDF11A /В и МС1601, и, соответственно, машин 11/23[+] и Э-60-1, отсюда и QBUS, и невозможность UBM.
Но в перспективе, ничто не мешает попробовать сделать и KDF11-U и, соответственно, 11/24.
А где они всплыли?
не знаю - как DEC, а в Воронеже:
"На основе центрального процессора М5 реализована микро-
ЭВМ МС 1213, выполненная в виде автономного блока (подобно
МС 1211.02). В состав блока кроме процессора М5 входят адап-
тер интерфейса, позволяющий подключать к микроЭВМ устройст-
ва с интерфейсом Капала мини-ЭВМ семейства «Электроника»
или «Общая шина» СМ ЭВМ, а также расширить адресное про-
странство до 4 Мбайт при обращении внешних устройств к памя-
ти в режиме НДК; "
Сделать MSCP в FPGA вещь очень заманчивая! (для VAX тоже, чем черт не шутит..) да, задача не тривиальная..
Если есть исходник прошивки RQDX, это должно помочь.
Hunta, поделись пожалуйста ссылкой с нами, я не нашел с ходу..
Мне кажется T11 там не нужен, 1801вм2 его с головой заменит.
Но есть еще альтернативный вариант попробовать сделать его на основе CMD CQD-220, там i8086 (не нативно, и явно будет потребует больше ресурсов в FPGA) но так в качестве идеи.
http://web.archive.org/web/202010181...d-cqd-220-scsi
Я помню только то, что там натыкался, но это было... летом где-то. Так что - искать надо
- - - Добавлено - - -
И вроде я уже писал про это на этом форуме.. Но вот это не точно..
- - - Добавлено - - -
Это было очень тяжело найти - меньше минуты.
http://www.bitsavers.org/pdf/dec/qbus/rqdxx/
Подскажу еще один быстрый способ искать что-то по нашей тематике - к примеру так
https://mirrors.pdp-11.ru/search.php?text=rqdxx
ps: bitsavers туда зеркалируется и соответственно можно быстро искать и в нем тоже
От Гостева сохранились какие-то исходники к нашим портам контроллеров.
я вроде должен был тут выкладывать, но сайтовым поиском ничего не могу найти, приаттачил.
Вторая победа. Дособирал схему DMA, и, как бы мне это было не противно, ограничил ОЗУ до 256К. Иначе пока никак.
В результате все имеющиеся диски заработали вполне нормально. RT-11 и тем более XXDP грузятся откуда угодно.
RSX-11M, RSX-11M+, RSTSv10 пока грузиться не хотят.
Вот так пытается загрузиться RSX-11M, с разных дисков по-разному:
Скрытый текст
Код:040000 140540 123220 136602
$DM2
RSX-11M V4.8 BL70 128.K MAPPED
SAV -- Cannot find home block
145152
@
040000 140540 123220 136602
$DB2
DEVICE TT001: NOT IN CONFIGURATION
SYSTEM CRASH AT LOCATION 000000
SO:003171
XDT>
[свернуть]
Вот так RSX-11M-PLUS:
Скрытый текст
Код:000775 001400 003000 177440
$DB0
OD:022532
XDT>
[свернуть]
А вот так - RSTS/E V10:
Скрытый текст
Код:000160 173620 001000 123220
$DM5
Device TT0: does not interrupt - device disabled.
Priority of RK0: interrupt (PR6) is too high - device disabled.
Priority of RM0: interrupt (PR6) is too high - device disabled.
Priority of RB0: interrupt (PR6) is too high - device disabled.
Priority of RX0: interrupt (PR6) is too high - device disabled.
Device DC0: does not interrupt - device disabled.
Device DC1: does not interrupt - device disabled.
Warning - Booted device is at a non-standard CSR address.
You must use the CSR suboption of the HARDWR option to
set the CSR address before timesharing can be started.
�
RSTS V10.1-L RSTS10 (DM5) INIT V10.1-0L
Today's date? 25-NOV-22
Current time? 20:17
Start timesharing? <Yes>
Timesharing cannot be started due to problems discovered
during the boot/autosizing process.
Option: <Start>
[свернуть]
Конечно, эти системы все генерировались под PDP11/70 и 4М ОЗУ, вполне возможно что они и не обязаны вот так сходу загрузиться на этой конфигурации. Завтра попробую запустить дистрибутивные Baseline и сделать генерацию под 11/23, и там будет видно. Хотя, судя по выхлопу RSTS, могут быть проблемы и с обработкой прерываний. Странно, RT-11 использует те же прерывания без всяких проблем.
Но, вообщем, дело понемногу движется.
Похоже, идёт неправильный DMA в верхнюю память.
В RT, что бы отправить данные в верхнюю память, нужен XM монитор (или что-то похожее) и постараться.
- - - Добавлено - - -
За RSTS/E ничего не скажу - я её не знаю
- - - Добавлено - - -
RSX по идее может загрузиться, RSX+ - зависит от того, что выбиралось при генерации, может и не загрузиться, если я правильно помню, то как раз по v4 вылетало
Верхнюю - это выше 64К? Ну, возможно, хотя я не очень представляю причины такого явления. С точки зрения DMA-устройств вся память - это плоское пространство размером в 256К, 18 бит адреса, и ситуация addr[17:16]==2'b00 не является чем-то особенным.
Другое дело, что я не реализовал DMA в пространство страницы ввода-вывода. Мне казалось что это бессмысленно, но может быть я и ошибался. Завтра проверю.
RT и RSX прописывают во второе слово вектора седьмой приоритет, и с хорошей степенью вероятности (тоже надо постараться, что бы не так было) почти сразу в обработчике они уходят на нулевой приоритет - в этом случае фиолетово - какой приоритет запроса у устройства. Вполне возможно, что у RSTS/E не так и если она в вектор выставляет предполагаемый реальный уровень приоритета - то и получается, что она ожидает 5, а прилетает прерывание (6 приоритет), когда не должно. Так что тут может быть и со схемой прерываний что то не так. Но это предположение.
А XXDP вообще фиолетово на прерывания. Ей главное, что бы DMA в нижнюю память (если устройство DMA) работало - и она на чем угодно загрузиться
- - - Добавлено - - -
Да, когда задействуются биты 17 и 16 адреса
Это и не требуется. Больше того, если проц Unibus и работает UMR (по сути - часть проца), то реализация UMR (вроде как в большинстве вариантов реализации, если не во всех) и не пропустит запрос на страницу в/в
- - - Добавлено - - -
Самый банальный (не говорю, что он) вариант - биты 17 и 16 от устройства не долетают до памяти - и всё на самом деле пишется в нижние 64к
Проблема с незагрузкой 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 через шину недоступно. Следовательно, по этому адресу процессор НИКОГДА штатно не должен лезть через внешнюю шину.
Буду думать дальше. Видимо, пора лезть в схему самого процессора и искать, где там лежат внутренние регистры.
Так всё таки по адресу
Или
?
Ну и именно такой команды
в исходниках 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>/$ /"
.......
Великий и могучий 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
------------------
"Зависание" дисков при работающем таймере устранилось.