Это уже вопросы к самой организации эмулятора, они выходят за рамки вопроса поправки C2 :)
Вид для печати
Хорошо если так.
Для устройств, имеющих разные векторы прерываний передачи и приёма, в реальном оборудовании (как правило) задан жёсткий порядок обсуживания этих прерываний при одновременном поступлении.
Является ли "правильной" эмуляция, при которой данный порядок не соблюдается и требует ли такая ситуация учёта и "поправки" - вопрос абстрактный.
Ну это все отдельная тема по организации самого эмулятора.
Для этой темы думаю нашлось бы много полезного материала.
Мне же пока нужно просто чтобы С2 в эмуляторе заработал - тогда я успокоюсь даже без починки С2 в своем УКНЦ и буду его плавно готовить к тому, чтобы сплавить нахрен :)
В исходники эмулятора не полезу принципиально :)
В тему правильной эмуляции прерываний PDP-11 глубже всего проник Боб Супник: PDP-11 Interrupts: Variations On A Theme.
В описании E11 есть глава, посвященная эмуляции прерываний в условиях эмулируемого же железа. В двух словах кроме уже упомянутых rank, level, нужен еще параметр сколько команд cpu пропустить прежде чем приерывание сработает. Это особенно критично для DECовского софта в котором часто обработчики прерывания надеются не на приоритет процессора, а на то, что хватит времени обработать прерывание раньше чем возникнет следующее :)
Тамже кстати примеры есть из реальной жизни.
---------- Post added at 18:16 ---------- Previous post was at 17:53 ----------
Кстати о Супнике... Ни у кого случайно нет с ним связи? :)
У них там в эмуляторе RK06/07 криво запись делает. Пробовал написать на адрес на который "пишите" - это оказался список рассылки на который еще надо подписаться. Попробовал подписаться - молчание. На том и кончилась добрая инициатива по отправке им патча :)
Так приходится поступать (например, буферизовать принимаемые через порт символы и передавать их процессору только тогда, когда после передачи предыдущего символа процессор успел выполнить не менее 100 команд ), но это уже относится не к корректной, а к комфортной эмуляции.
В ядре монитора RT11SJ есть забавный баг, который приводит к тому, что если очередной символ поступает на вход порта терминала раньше, чем процессор успел выполнить 100 команд - символы заносятся в кольцевой буфер ввода в обратном порядке. Причём, это происходит (если не ошибаюсь) даже в том случае, когда при генерации монитора заказан High Speed Ring Buffer :)Цитата:
Это особенно критично для DECовского софта в котором часто обработчики прерывания надеются не на приоритет процессора, а на то, что хватит времени обработать прерывание раньше чем возникнет следующее
Во всех остальных мониторах, кроме SJ - такого бага нет.
Кстати насчет клавиатуры в SJ. На SB не распространяется - проверил :)
(клавиша выдает "1234567890")
Баг проявляется, когда терминал может запоминать последовательности символов и передавать их (в нужный момент) компьютеру со скоростью порта терминала.
При скорости порта 9600 bps процессор должен выполнять менее 100'000 команд в секунду (т.е. иметь быстродействие меньше 0.1 MIPS), чтобы этот баг проявился.
При скорости порта 57600 bps - баг проявится при быстродействии процессора менее 0.6 MIPS.
Учитывая, что минимальная тактовая частота процессора 1801ВМ1 примерно 100 КГц, а при тактовой частоте 5 МГц быстродействие 1801ВМ1 составляет примерно 0.2 MIPS - вполне можно собрать реальную конфигурацию, в которой данный баг проявится.
Между можно собрать и тем, что выпускалось разница огромная :)
знакомы строчки? :)Код:; DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS
; SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL.
DEC частенько даже в коментариях писал замечания вроде "не менять команды местами", "не убирать вот эти команды" итд. RT-11 правда в этом отношении бедновата на коментарии вообще - более-менее детально коментировать его начал уже Mentec.
Это не относится к устройствам, подключаемым к стандартным портам DEC - подключать к портам допустимо любые устройства, соответствующие стандарту порта.
Учитывая, что быстродействие стандартной LSI-11 при выполнении кода ядра RT11SJ составляет (если не ошибаюсь) около 0.1 MIPS - обсуждаемый баг вполне может проявиться. Нужно лишь подключить достаточно продвинутый терминал.
Есть еще такой список - железо которое поддерживается системой, в котором в том числе терминалы упоминаются...
Кстати, сейчас попробую организовать глюк в SJ на живом 11/83 :)
---------- Post added at 19:33 ---------- Previous post was at 19:28 ----------
RT-11 V05.04... Ждемс...Код:Testing in progress - Please wait
Memory Size is 2048 K Bytes
9 Step memory test
Step 1 2 3 4 5 6 7 8 9
Message 04 Entering Dialog mode
Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key: B MU
Trying MU0
Starting system from MU0
MSBOOT V05.04
*MDUP.AI
MDUP V05.30
?MDUP-I-No bad blocks detected VM0:
Глюк будет с любым терминалом, у которого есть клавиши, генерящие при одном нажатии более одного кода.
Так я на этот глюк и наткнулся. При установке в эмуляторе малых скоростей процессора и больших скоростей порта - клавиши доп.клавиатуры переставали нормально отрабатываться.
Сильно подозреваю, что не будет ни с каким.
Просто будут потери символов, а прерывания не станут чаще чем задумано.
Впрочем осталось недолго - каких-нибудь минут 20 еще и система поставится :)
Ну а в эмуляторе или стороннем железе (не терминале) вероятность конечно большая.
---------- Post added at 20:41 ---------- Previous post was at 20:25 ----------
Добиться не удалось ни потерь ни переворота в буфере на 38400.
Надо проц послабее.
На этом дело остановилось - поскольку таймер управляемый да еще и от внутреннего генератора процессорной платы. Сейчас попробую повесить в память драйвер который по нажатии на клавишу запретит через CSR.Код:.RU DU4:SPEED
tEST BYSTRODEJSTWIQ.
bYSTRODEJSTWIE (TYS.OP./SEK)
kOMANDA SLOVENIQ REGISTR-REGISTR: 1632
kOMANDA SLOVENIQ REGISTR-PAMQTX: 948
kOMANDA UMNOVENIQ REGISTR-REGISTR: 188
kOMANDA DELENIQ REGISTR-REGISTR: 668
wYKL@^ITE TAJMER...
Это версия SPEED.SAV из комплекта TMOS. Она требует включить таймер перед началом работы (иначе не сможет определить быстродействие процессора) и выключить таймер перед завершением работы (иначе не смогут работать тесты TMOS).
Быстродействие ~1.0 MIPS обычных команд - слишком большое для "глюка SJ" - нужно замедлить процессор минимум в 10 раз :)
У меня таймер управляемый, поэтому даже мысли не было о том, чтобы реализовать внешнее отключение тем более что BEVNT не используется для него :)
Сейчас допилю драйвер чтобы отключать со второго терминала :)
А что до глюка - сильно подозреваю, что ни одна DECовская DL11 железка просто не даст прерываний больше чем DEC ожидал :)
---------- Post added at 22:03 ---------- Previous post was at 21:55 ----------
Не вышло ничего - видимо он приоритет проца задирает в этом месте - второй терминал перестает отзываться :)
Попробовал вывалить в пульт, запретить таймер и запустить дальше - прога просто вышла :)
---------- Post added at 22:03 ---------- Previous post was at 22:03 ----------
Надо в XXDP порыться - там поди есть.
Гы. Ну и фиг с ним :)
---------- Post added at 23:14 ---------- Previous post was at 22:05 ----------
Немно зверства :)
А вообще пора наверное тему заводить специально по вопросам диагностики :)Код:.RU ODT
ODT V05.08
*177520/003007 7007
*^C
.RU DU4:SPEED
+EST BYSTRODEJSTWIQ.
bYSTRODEJSTWIE (TYS.OP./SEK)
+OMANDA SLOVENIQ REGISTR-REGISTR: 100
+OMANDA SLOVENIQ REGISTR-PAMQTX: 60
+OMANDA UMNOVENIQ REGISTR-REGISTR: 12
+OMANDA DELENIQ REGISTR-REGISTR: 40
+YKL@^ITE TAJMER...
Благодаря собранной информации, смог загрузить через стык С2 операционную систему.
Огромная благодарность form и Andrey_Ak за предоставленные программу TU58 и процесс загрузки на ДВК, ну и текст загрузчика.
Также огромная благодарность nzeemin за программу UkncComSender.
Программу UkncComSender пришлось немного модифицировать, т.к. для связи я использую кабель с контролем передачи (задействованы линии CTS и RTS), модификация состоит в присвоении в блоке DCB переменным fDtrControl и fRtsControl значений DTR_CONTROL_ENABLE и RTS_CONTROL_ENABLE соответственно. Также в архиве пример образа для загрузки (в образе нет драйверов MZ и WD), на основе этого образа можно собрать свой.
Сам процесс загрузки начинается с посылки загрузчика TU58 на УКНЦ (TU58.SAV) с помощью программы UkncComSender. Далее загруженная программа ожидает нажатия пробела, и потом начинается загрузка с образа.
Alex_K, ссылка "текст загрузчика" прокисла -- может сюда этот текст выложить?
Господа! Ткните носом - где можно посмотреть формат команд/пакетов для сетевого диска? Грубо говоря - что творится на Стык2 после загрузки в УКНЦ RT-11 и монтирования Стык2, как сетевого диска?
тогда какой формат наиболее прост? есть мысль реализовать файл-сервер на какой-нить простенькой Меге с SD-картой и RS232 портом.
даже так - где взять инфу по трем вышеперечисленным дискам/драйверам?
Я это уже сделал. Мультиплексор HX как раз и работает с файл-сервером на PC через RS-232, позволяя одновременно использовать тот же самый порт ещё и в качестве системного терминала ( для УКНЦ это не очень актуально, а для запуска "на столе" голых процессорных плат ДВК / PDP-11 - самое то ).
В РАФОСе был драйверок и несколько программок. Там сервер был под TSX (РАФОС/TS), а клиентами была кучка RT-11. И через линию тоже можно было терминалом подключаться или диски монтировать. Руки не дошли поковырять, софт этот у меня валяется среди рафосов.
на мой взгляд РС здесь лишний:) где почитать про протокол НХ? только прошу не предлагайте покурить листинги:)
Описание протокола HX существует только на языках MACRO-11 ( описание протокола с точки зрения клиента ) и C++ ( описание протокола с точки зрения сервера ).
Ведь адекватно описать фазовую машину протокола без использования алгоритмических конструкций невозможно - поэтому листинг реализации фазовой машины и является её единственно адекватным описанием.
я думал - все гораздо проще:) команда-отклик:) считать блок-записать блок.
режим терминала реализовываться не будет. только файл-сервер и только для УКНЦ.
Там ведь по одному каналу идут и пакеты дискового обмена, и обычный байтовый обмен с терминалом.
Фильтр протокола HX на стороне сервера, получая эту кашу - опознаёт в ней пакеты и извлекает их, а всё остальное пропускает на сокет подключения терминала.
Если на любой стадии разборки пакета тот отклоняется от стандарта HX - все принятые в процессе разборки байты возвращаются в терминальный обмен и отправляются терминалу.
Лучше, чем уже сделано - сделать вряд ли получится.
А какой смысл делать хуже, если можно просто запустить "Эмулятор VT52" в режиме HX-сервера и пользоваться.
да блин. в том-то и дело, что хочу реализовать файл-сервер без ББ, автономно. и я не собираюсь делать лучше, собираюсь по другому.
в мегах немного рублю, в RT-11 - не очень, потому и прошу помощи.
Вот, например, как драйвер HX.SYS для RT-11 реализует вызов чтения массива слов с диска ( с поддержкой режима сжатия на стороне сервера ):
Код:HX.Read:
.IF NE MMG$T
Mov HXCQE, R4
.EndC
BiC #100, @#TPS
Mov #1, R0 ; Send SOH
Call ChOu
;; MovB #375, R0 ; Short packet
;; Call ChOu
;; Mov #7, R0 ; Packet size.
;; Call ChOu
Mov #176407, R0 ; Short packet ; Packet size = 7
Call WOu
;; Mov #'C, R0 ; Packet type = COMMAND
;; Call ChOs
;; Mov #'R, R0 ; Command = Cmd_READ_RAW
;; Call ChOs
;; Mov #"RC, R0 ; Packet type = COMMAND ; Command = Cmd_READ_RAW
Mov #"rC, R0 ; Packet type = COMMAND ; Command = Cmd_READ_PACKED_STREAM
Call WOs
Mov R3, R0 ; Unit
Call ChOs
Mov R2, R0 ; Block
Call WOs
Mov R1, R0 ; WordCount
Call WOs
Call TTKPrep
Mov ChSum, R0
Call WOu ; CheckSumm
................
Clr ChSum
1$:
Call ChIn
CmpB R0, #374 ; PACKED_STREAM ?
BEq GetPackedStream
CmpB R0, #376 ; Long packet == Data
BEq GetData
CmpB R0, #3 ; Ctrl_C ?
BEq ERR
CmpB R0, #375
BNE 1$
; Short packet == Error
Call ChIn
Mov R0, R3 ; R3 == Packet Size;
BEq ERR ; Packet Size == 0 ?
Skip:
CmpB (R3)+, (R3)+ ; R3 += 2;
Call ChIn
SOB R3, .-4. ; Get packet bytes.
Br ERR
GetData:
Call WInR3 ; R3 == Packet Size;
BEq ERR ; Packet Size == 0 ?
Call ChIn
CmpB R0, #'R ; Pcket type == REPLY ?
BNE Skip
Dec R3
BLE ERR
Add R0, ChSum
Call ChIn
CmpB R0, #'D ; Reply type == RAW DATA ?
BNE Skip
Dec R3
BLE ERR
Add R0, ChSum
ASL R1 ; R1 == Byte Count
2$:
Call ChIn
Add R0, ChSum
.IF EQ MMG$T
MovB R0, (R5)+
.IFF
Mov R0, -(SP)
Call @$PTBYT
.EndC
Dec R3
BEq 3$
SOB R1, 2$
3$:
Tst R3
BGt Skip
Call WInR3 ; R3 == CheckSumm
Dec R1
BNE ERR
CmpR3:
Cmp R3, ChSum
BNE ERR
OK: Tst (PC)+
ERR: SeC
Return
................
GetPackedStream:
NextPackedBlock:
Call ChIn ; R0 == PackedBlock Header
Add R0, ChSum
Dec R0 ;
BMi EndOfStream ; = 0 - End Of Stream
BEq GetRptBlock ; = 1 - RPT_Block
Inc R0 ; > 1 - RAW_Block
; Get RAW_Block
Mov R0, R2 ; R2 == RAW Bytes Count
1$:
Call ChIn
Add R0, ChSum
.IF EQ MMG$T
MovB R0, (R5)+
.IFF
Mov R0, -(SP)
Call @$PTBYT
.EndC
SOB R2, 1$
Br NextPackedBlock
EndOfStream:
Call WInR3 ; R3 == CheckSumm
Br CmpR3
GetRptBlock:
Call ChIn ;
Add R0, ChSum
Mov R0, R2 ; R2 == RPT Count
Call ChIn ; R0 == Byte to repeat.
Add R0, ChSum
1$:
.IF EQ MMG$T
MovB R0, (R5)+
.IFF
Mov R0, -(SP)
Call @$PTBYT
.EndC
DecB R2
BNE 1$
Br NextPackedBlock
---------- Post added at 16:36 ---------- Previous post was at 16:35 ----------
Это как?
я же писал - Мега с SD-картой и портом RS232. Мега обрабатывает пакеты, читает-пишет SD-карту. если тяму хватит - будет поддержка FAT16 на SD-карте. если нет - просто массив блоков. Мега - всмысле ATmega8,16,32 и т.д. конструктив очень простой - мега, МАХ232, стабилизаторы 5В и 3.3В,цепь сброса, согласователь на резисторах для карты. разъем карты, разъем подключения. все вроде.
по идее протокол не может быть очень сложным?
диск с последовательным доступом вобщем.
сорри, не доступом, а интерфейсом:)
---------- Post added at 17:55 ---------- Previous post was at 17:46 ----------
у мну есть и КНГД и КНЖД, но они вместе с дисками довольно громоздки и не всегда удобны. а тут коробка с пол-пачки сигарет, грубо говоря. а если реализую поддержку FAT, так инфу с-на-карту будет ваще просто переносить:) (это я пока мечтаю) :)
Там ( см. приложение ) всё элементарно. Из обработчика можно смело выкинуть запоминание входного потока для отправки терминалу в случае ошибочного опознавания, а всё остальное должно уложиться в несколько килобайт.
...
Описание и исходники протокола HX v2.2
...
Мои попытки подключить С2 к rs232:
1.Косичку спаял по схеме "минимальный"
2.На писюке проверил ком порт обычной ком-мышкой -все работает.
3.запустил гипертерминал на winXP SP3 ,настроил COM1.На УКНЦ запустил загрузку стык2 .На в окне терминала появился символ @
4.Запустить программу UkncComSender.exe - ошибка
http://i.piccy_.info/i7/2d95a675f3af...iannyi_240.jpghttp://i.piccy_.info/a3/2013-01-05-1...240x55-r/i.gif
Ага,запускается из этого поста http://zx.pk.ru/showpost.php?p=391152&postcount=23 Значит в 1 посте не актуальные версии программ?
http://piccy_.info/code2/3939397/9ac...cd10f9cfd95e0/
можно по пунктам что включить где скачать и что нажать?А пока пойду тему еще раз перечитывать - с первого раза что то не дочитал :)
На контупере не нашлось подходящего runtime для той версии MSVC под которой собиралось.
Соберите из исходников: http://code.google.com/p/ukncbtl/sou...FUkncComSender
---------- Post added at 17:20 ---------- Previous post was at 17:16 ----------
UkncComSender.exe ожидает два параметра. Первый -- имя ком-порта, второй -- имя .SAV-файла. Судя по скриншоту, у вас что-то со вторым параметром -- например указан несуществующий файл.
UkncComSender писался как утилита для проверки Стык С2, контроль ошибок не на высоте.
получилось,дело в том что нужно распаковать папку с программкой из первого поста и заменить в этой папке EXE скаченный из поста №23 .
Было бы не плохо в 1 посте обновить файлы до актуальных версий и если нужно дополнить описание .А то сразу не въехал.
http://i.piccy_.info/i7/63b860fa4566...41_375_240.jpg[IMG]http://i.piccy_.info/a3/2013-01-05-13-21/i7-3939411/240x180-
r/i.gif[/IMG]
По варианту из этого поста http://zx.pk.ru/showpost.php?p=469503&postcount=101 дохожу до нажатия пробела на УКНЦ - нажимаю и дальше нечего не происходит.Ждал мин 15 -может дольше нужно ждать?
http://i.piccy_.info/i7/3b1f7793a52d.../55555_240.jpghttp://i.piccy_.info/a3/2013-01-05-1...40x150-r/i.gif