Значит ошибку сделали авторы ПЗУ.Цитата:
Сообщение от Titus
Значит ошибку сделали авторы ПЗУ.Цитата:
Сообщение от Titus
Тут уж ничего не могу сказать. Знаю, что когда на УКНЦ выбираешь режим 15ИЭ, то забой в RT-11 не стирает символ, а перескакивает в верхний левый угол экрана.Цитата:
Сообщение от Patron
Тогда всё понятно - это просто переключение в 1-ю ( 15ИЭ ) и 2-ю ( VT52 ) системы команд 15ИЭ.Цитата:
Сообщение от Titus
---------- Post added at 00:26 ---------- Previous post was at 00:24 ----------
Т.е. 15ИЭ эмулируется в УКНЦ в обоих этих режимах (и режимы в обоих случаях могут переключаться программно).
Режим 2 более правильный?Цитата:
Сообщение от Patron
Цитата:
Сообщение от Titus
http://felixl.com/Uknc_RAM_description_appЦитата:
Сообщение от Patron
Именно такой начальный режим рассчитывают иметь большинство программ для 15ИЭ ( хотя после включения устанавливается 1-й режим - в нём SL работать не будет, поэтому все и всегда переключались во 2-й режим ещё до загрузки RT-11 ).Цитата:
Сообщение от Titus
А многие, включая меня, еще спичку в ВР втыкали :)Цитата:
Сообщение от Patron
---------- Post added at 04:34 ---------- Previous post was at 04:32 ----------
Кстати помню был у нас какой-то редактор под RT-11, экранный, с командами в стиле TECO как раз для 15ИЭ.
А буржуйские программы в каком режиме работают? С чем он наиболее совместим?Цитата:
Сообщение от Patron
VT52 и VT100 в основном.Цитата:
Сообщение от Titus
Некоторые и то и другое умеют одновременно.
А КСМ, 15ИЭ 1, 2, КЦГД1, 2 как классифицировать по-буржуйски?Цитата:
Сообщение от form
Как VT52 при установке соответствующего режима.Цитата:
Сообщение от Titus
На дисках от anasana нашлась одна копия легендарного экранного редактора SCREEN.SAV, который поставлялся в комплекте ДВК и работал в 1-й системе команд, но он похоже битый - передаёт управление внутрь команды и вылетает по Trap_To_10.Цитата:
Сообщение от form
...
Тот про который я говорю был когда ДВК еще не было :)Цитата:
Сообщение от Patron
Да, похоже битый.
MFPT - не самая обычная команда для редактора :)
На самом деле там MOV #7,R0 и управление передаётся на второе слово команды. Явно при каком-то из копирований была ошибка чтения и содержимое одного блока заменилось содержимым другого.Цитата:
Сообщение от form
Ох, не надо о грустном :)Цитата:
Сообщение от Patron
Большая часть образов лент на сервере simh убита таким образом - блоки/eofы переставлены местами. С BRU лентами особых проблем нет, там легко автоматизировать восстановление, а вот со всякими DOS-11 хреново. Я уже давно бьюсь, пытаясь восстановить BP2 V2.7 :)
Последствия чтения программой в режиме чтения кучи блоков за раз.
Исправил работу команд вертикальной прокрутки изображения в 1-й системе команд терминала 15ИЭ-00-013 - теперь по этим командам циклически прокручиваются последние 48 строк в буфере вывода.
Новый вариант дистрибутива "эмулятора ДВК" ЗДЕСЬ.
Теперь тест 15IE.BAS даёт такой результат:
http://emulator.pdp-11.org.ru/misc/15IE_test2.png
Для более вдумчивого тестирования мега-глюка ВМ2 - можно запустить MOVPCY.SAVЦитата:
Сообщение от hobot
задав вручную параметры:Код:.RU MOVPCY
MovPCy - v1.1
Mem Top: 137564
Max Row: 11000
CPU KHz: 5300 >
MTPS : 000000 >
Command: 011700 >
Row Len: 1000 >
Grow : 0 >
R1 : 000000 >
R2 : 000000 >
R3 : 000000 >
Addons : 3 >
W1 : 000240 >
W2 : 000240 >
W3 : 000240 >
Loops : 106 >
Код:Row Len: 1000 > 100
Grow : 0 > 100
принято - сейчас прогоню )Цитата:
Сообщение от Patron
---------- Post added at 10:00 ---------- Previous post was at 08:43 ----------
Получилось как-то так?
Скрытый текст
Какую всё таки герцовку для ВМ2 вбивать в тестах где требуется.
Сегодня тогда начну гнать все тесты по соседней теме наверное?
Если что то в первую очередь интересней пишите же )
Если в этом надо параметры изменить на "правильные" прогоню ещё раз.
---------- Post added at 10:15 ---------- Previous post was at 10:00 ----------
уже вижу - проглядел ( Критично?Цитата:
Сообщение от Patron
---------- Post added at 10:39 ---------- Previous post was at 10:15 ----------
Поправил герцовку на 8013 и вбил Loop=106
Row Len: 1000 > 100
Grow : 0 > 100
результаты 1 в 1 даже не стал делать снимок.
Изучаю соседнюю тему, буду уже в ней выкладывать.
Любопытно, что тест ни разу не вылетел.Цитата:
Сообщение от hobot
Возможно, играет роль блок питания.
Чтобы проверить более тщательно - можно задать такие параметры:
Код:Row Len: 100 > 9000
Grow : 100 > 1
Не знаю что подразумевается под вылетом, но после прогрева выдал совершенно другие данные в результатах! А именно :Цитата:
Сообщение от Patron
Скрытый текст
это при
Поправил герцовку на 8013 и вбил Loop=106
Row Len: 1000 > 100
Grow : 0 > 100
---------- Post added at 13:16 ---------- Previous post was at 13:15 ----------
Начинаю в другую тему выкладывать по тестовой плате№1 (она же на снимках тут)
Какой бы хитрый тест для DJ11 придумать :)Цитата:
Сообщение от hobot
---------- Post added at 16:23 ---------- Previous post was at 16:23 ----------
Одна мысль правда есть - опробовать режим голого кэша - когда память совсем отключается, но пока не готов.
Когда плата прогрелась - вылет произошёл при длине цепочки последовательных команд MOV (PC),R0 = 7700.Цитата:
Сообщение от hobot
Когда до прогрева не вылетает, а после прогрева вылетает - "питательная" теория получает ещё одно подтверждение.
параметр Loops рассчитывается автоматически на основе заданной частоты процессора, а в режиме Grow - вообще не используется.Цитата:
вбил Loop=106
Режим Grow нужен для того, чтобы более точно определить, начиная с какого количества команд MOV (PC),R0 подряд - начинаются вылеты. При этом Row Len задаёт начальное значение, а Grow - приращение длины цепочки команд.
Подбирая Row Len и уменьшая Grow - нужно ( в смысле - надо бы ) в результате серии последовательных прогонов теста максимально точно определить ту длину цепочки команд, начиная с которой появляются вылеты.
Да не может влиять питание)Цитата:
Сообщение от Patron
В крайнем случае, смена характеристик какой-либо части схемы при ее разогреве.
Ну БП в УКНЦ как раз очень сильно разогревается под нагрузкой :)Цитата:
Сообщение от Titus
Единственное, что зависит от длины цепочки одинаковых команд - профиль энергопотребления.Цитата:
Сообщение от Titus
Если частота вылетов зависит от температуры, но не зависит от профиля энергопотребления - вероятность вылета для цепочки команд должна быть прямо пропорциональна её длине ( и отличаться от нуля даже для "цепочки" из одной единственной команды ).
Если же выяснится, что при любой температуре есть такая длина цепочки команд, при которой вылет не происходит вообще - решающая роль профиля потребления будет доказана.
Не докажете)Цитата:
Сообщение от Patron
Команда, скачкообразно потребляющая в несколько раз больше тока, чем все остальные, вряд ли может существовать, если только выходы не нагружаются на выходы, и не идет сквозной ток.
И то, это у КМОП-структур, а проц по другой технологии сделан, на сколько я помню.
ага! уже меньше чувствую себя просто мартышкой тыкающей кнопки (Цитата:
Сообщение от Patron
В принципе ничто не мешает погонять этот тест в процессе эксплуатации УК_НЦ )
По моей личной практике - может влиять. По поводу конкретного питанияЦитата:
Сообщение от Patron
вот нагрузка: системная плата №1 (у неё СА висит на проводках) + КГМД + КЖМД
с флеш-драйвом.
А вот блок питания
http://savepic.org/3156751.jpg
Критерий истины - практика.Цитата:
Сообщение от Titus
Если при любой температуре платы всегда будет существовать такая длина цепочки команд, что при меньшем или равном значении вылет не происходит - будет доказано, что температура не является причиной вылета.
Но так как единственный физический параметр, зависящий от длины цепочки команд - это профиль энергопотребления, то значит он и влияет.
Какое ещё физическое влияние на плату может иметь ДЛИНА цепочки команд ?
Уважаемые господа! Глюк с вылетом, а точнее с непредсказуемым выполнением команд, существует если после MOV @PC,R0 в цепочке команд, не нарушающих предвыборку, встречаются команды установки/снятия признаков (коды с 240 по 277). При исполнении других команд поведение предсказуемо (двойное исполнение или пропуск), никаких левых вылетов не наблюдается.
P.S. Извиняюсь! Пока забросил тестирование, т.к. нет времени. Появится, продолжу. А так про особенности исполнения я уже писал.
Он стабильный? - всмысле что срабатывает с первого раза всегда или надо помучить?Цитата:
Сообщение от Alex_K
Критерий истины - четкое понимание вопроса. А у тут гадание на кофейной гуще. Раз кроме разогрева никаких параметров не известно, то пусть это будет... ПРОФИЛЬ ПИТАНИЯ! Ничего, что ни на каких других программах, режимах работы и т.д. он не сказывается. Но пусть будет.Цитата:
Сообщение от Patron
Мы не знаем структуры процессора изнутри, и процессы, происходящие в нем могут быть какими угодно сложными и непонятными (и в частности нестабильными с точки зрения известных данных). Но к профилю питания это явно не относится никаким боком.
Питательной теории это не противоречит.Цитата:
Сообщение от Alex_K
Если бы была принципиально важна лишь "несовместимость" двух типов команд - ДЛИНА предшествующей цепочки никакой роли не играла бы.
Допустим ( т.к. тесты ещё не завершены и как обстоят дела можно лишь гадать ), что при длине цепочки 100 - не вылетает никогда, при длине 700 - тоже никогда, а при длине 800 - всегда.
У микропрограммы ВМ2 слишком маленькое пространство состояний, чтобы после выполнения 700 команд иметь какое-то другое внутреннее состояние, чем после выполнения 800 команд.
Если бы при одной команде никогда не вылетало, а при двух всегда - я бы первый сказал, что проблема в микропрограмме. Но когда задействованы СОТНИ команд - причина явно в другом.
---------- Post added at 13:59 ---------- Previous post was at 13:56 ----------
Вот и не надо гадать на кофейной гуще.Цитата:
Сообщение от Titus
Вопрос элементарно прост - какое физическое влияние оказывает на плату ДЛИНА цепочки одинаковых команд ( кроме влияния на профиль питания, которое очевидно ).
1. Влияние прерываний. (надо запрещать все)Цитата:
Сообщение от Patron
2. Влияние несинхронности шины данных. (так же необходимо останавливать ПП)
Такая настройка в тесте есть.Цитата:
Сообщение от Titus
Ничто из этого не может иметь чёткой зависимости от длины цепочки команд.Цитата:
Сообщение от Titus
Если 700 ( и меньше ) команд никогда не вылетают, а 800 ( и больше ) всегда вылетают - несинхронность шины данных, ПП и все остальные нефизические причины очевидно непричём.
Начало выполнения цепочки команд с чем-нибудь да синхронно, с таймером или с чем-то еще. Следовательно вполне возможно, что через какой-то промежуток времени на последовательность выполнение команд влияют дополнительно появившиеся условия.Цитата:
Сообщение от Patron
При включенном таймере (т.е. при разрешённых прерываниях) начало выполнения цепочки команд синхронно с таймером, при выключенном - только с тактовой частотой ( каждая команда начинает выполняться в начале такта ) и эта синхронность одинакова для каждой команды в цепочке.Цитата:
Сообщение от Titus
Большие никаких синхронностей быть не может.
Ради интереса померял время компиляции KMON для RT-11ZM в обычном варианте и с выключенным кэшем...
Код:.TIM
10:00:31
.MAC/OB:OBJ:KMZM SRC:(ZM+FORMZX.CND+EDTG+KMON+KMOVLY)
.TIM
10:09:58
Код:.TIM
10:10:16
.MAC/OB:OBJ:KMZM SRC:(ZM+FORMZX.CND+EDTG+KMON+KMOVLY)
.TIM
10:34:32
да существенно! А кэш - это дисковая память или ОЗУ?Цитата:
Сообщение от form
Кэш ОЗУ.Цитата:
Сообщение от hobot