Дискуссии вокруг УКНЦ и прочее.

[Alex_K]

Хороший пример - это Тетрис Пажитного, он там лез в эти порты, но похоже документация у них в конторе была кривая и от этого лазанья никакого проку не было.

Он там лез не для вывода, а для реализации задержки. Вывод там сделан через операторы WRITE/WRITELN, а библиотека Паскаля использует стандартные функции системы для вывода.

[Advertiser]

[litwr]

Он там лез не для вывода, а для реализации задержки. Вывод там сделан через операторы WRITE/WRITELN, а библиотека Паскаля использует стандартные функции системы для вывода.

А у вас есть исходники? Задержка там в другом месте, могу даже адрес сообщить ячейки, где задержка лежит. А o почти полной бесполезности обращения к портам мне сообщал @form, он патчил Тетрис для RTEM.

- - - Добавлено - - -

Для УКНЦ - нет. Хотя такое было если читать те старые журналы, но это уже было а-ля в 94 году когда собственно сами IBM расплодились настолько что уже их девать стало некуда.

Именно для УКНЦ и действительно примерно с 1994, но именно с тех времен про УКНЦ стали писать-вспоминать как про нормальный компик, с которым можно работать.


Помню в конце 80-х и начале 90-х все вокруг использовали именно ДЕМОС на ДВК и даже в нулевые люди вспоминали как тупили си под Юникс, не зная, что работают в самой перспективной системе и с самым перспективным языком. Там только был фокус, не было форматера дискет и форматировали вроде через RT-11, делая запросы в смежные организации. Но тут почему-то Юникс явно не в фаворе.

- - - Добавлено - - -

Интересно, что в Википедии написано, что советские клоны PDP-11 были бинарно несовместимы с настоящими PDP-11! О чем это могло быть? Цитата "As happened with ES EVM mainframes based on the System/360 architecture, the Russians and their allies sometimes significantly modified Western designs, and therefore many SM EVM machines were binary-incompatible with DEC offerings at the time".

[Alex_K]

Задержка там в другом месте, могу даже адрес сообщить ячейки, где задержка лежит. А o почти полной бесполезности обращения к портам мне сообщал @form, он патчил Тетрис для RTEM.

003044  024646                  CMP        -(SP), -(SP)
003046  012701  177564          MOV        #177564, R1
003052  032711  000100          BIT        #000100, (R1)
003056  001375                  BNE        003052
003060  017603  000006          MOV        @000006(SP), R3
003064  017600  000010          MOV        @000010(SP), R0
003070  005711                  TST        (R1)
003072  100000                  BPL        003074
003074  077003                  SOB        R0, 003070
003076  077306                  SOB        R3, 003064
003100  016666  000004  000010  MOV        000004(SP), 000010(SP)
003106  062706  000010          ADD        #000010, SP
003112  000207                  RETURN

По адресам 3046-3056 ожидается сброс бита разрешения прерывания в регистре 177564. При начале вывода RT-11 его устанавливает, как только вывод окончился - сбрасывает. Это значит, что RT-11 закончила вывод на терминал. А вот в адресах 3060-3076 уже сделаны два цикла задержки. В качестве команды исполнения используется TST (R1), при R1=177564, и BPL 003074. Т.е. также тестируется регистр терминала. Смысла в этом особого нет, только команда вносит задержку. Осуществлять можно тест и ячейки памяти, разное может быть только время исполнения команды.

[litwr]

003044  024646                  CMP        -(SP), -(SP)
003046  012701  177564          MOV        #177564, R1
003052  032711  000100          BIT        #000100, (R1)
003056  001375                  BNE        003052
003060  017603  000006          MOV        @000006(SP), R3
003064  017600  000010          MOV        @000010(SP), R0
003070  005711                  TST        (R1)
003072  100000                  BPL        003074
003074  077003                  SOB        R0, 003070
003076  077306                  SOB        R3, 003064
003100  016666  000004  000010  MOV        000004(SP), 000010(SP)
003106  062706  000010          ADD        #000010, SP
003112  000207                  RETURN

По адресам 3046-3056 ожидается сброс бита разрешения прерывания в регистре 177564. При начале вывода RT-11 его устанавливает, как только вывод окончился - сбрасывает. Это значит, что RT-11 закончила вывод на терминал. А вот в адресах 3060-3076 уже сделаны два цикла задержки. В качестве команды исполнения используется TST (R1), при R1=177564, и BPL 003074. Т.е. также тестируется регистр терминала. Смысла в этом особого нет, только команда вносит задержку. Осуществлять можно тест и ячейки памяти, разное может быть только время исполнения команды.

Это Вам к form, но вроде вы и сами подтвердили, что смысла особого нет. Знаю только, что народ меняет константу по адресу 016642 и это регулирует задержку. И, главное, исходники есть?

[Alex_K]

Это Вам к form, но вроде вы и сами подтвердили, что смысла особого нет. Знаю только, что народ меняет константу по адресу 016642 и это регулирует задержку.

Вот собственно и команда по этому адресу:

016640  012765  000160  001256    MOV        #000160, 001256(R5)

Задержка может быть разной, в зависимости от быстродействия. В оригинале она была поменьше.
А вот и вызов п/п задержки:

016722  010500                MOV        R5, R0
016724  062700  001256        ADD        #001256, R0
016730  010046                MOV        R0, -(SP)
016732  010500                MOV        R5, R0
016734  062700  001240        ADD        #001240, R0
016740  010046                MOV        R0, -(SP)
016742  004767  164076        CALL       003044

Этой п/п передаются два параметра по ссылке. Т.е. п/п задежки при описании на Паскале будет как procedure L03044(var DEL1,DEL2:integer);.

А по поводу смысла. В первых командах ожидается, что RT-11 освободила свои внутренние буферы при выводе на экран. Ввод идёт по прерываниям, скорость 9600 бод. И чтобы узнать, что вывод закончился, пользовались вот таким методом.