УКНЦ загрузка через стык С2

[form]

Попутно заглянул в драйвер, заполнение остатка блока нулями делается драйвером, что криво и накладно. Это задача контроллера (сервера).

[Patron]

Специально перенёс заполнение нулями из сервера в драйвер, чтобы протокол стал более однозначным - при запросе у сервера чтения одного байта - читается один байт, при запросе записи одного байта - пишется один байт.

[form]

Специально перенёс заполнение нулями из сервера в драйвер, чтобы протокол стал более однозначным - при запросе у сервера чтения одного байта - читается один байт, при запросе записи одного байта - пишется один байт.

А оно так и получается в любом случае: передается столько сколько указано. Зануление конца блока - не передача данных, а документированное требование к блочным устройствам, актуальное по сей день.
Обращаю внимание: к устройствам, не к драйверу.

[Patron]

А полноценный драйвер для УКНЦа появился уже? Всмысле чтобы функционал системы не ломал - там этого вроде не требуется

В смысле, чтобы номер загружаемого привода принимался в R0 ?

[form]

В смысле, чтобы номер загружаемого привода принимался в R0 ?

Всмысле чтобы .READ и .READC работали.
В случае когда делается смешивание консоли с диском такое потребует вмешательства в систему или написание драйвера хукающегося по принципу PI. Для отдельного порта таких трудностей нет.

[Patron]

Всмысле чтобы .READ и .READC работали.

А как .READ и .READC реализованы у VM.SYS и как они работают у MX.SYS ( MX.SYS при работе вообще запрещает прерывания ) ?

[Advertiser]

[form]

А как .READ и .READC реализованы у VM.SYS и как они работают у MX.SYS ( MX.SYS при работе вообще запрещает прерывания ) ?

VM.SYS - драйвер мгновенного действия (и то он как раз из-за этого имеет проблемы в SJ), а что касается MX - у нас полно драйверов криво писали. Но это же не повод перенимать глупости
Ладно бы были трудности, так ведь их нет.
А так, согласись, драйвер который ломает функционал системы - драйвером называться не имеет права

---------- Post added at 14:39 ---------- Previous post was at 14:25 ----------

Наглядный пример потери функционала из-за нерабочести .READ/.READC. Это тупой тест, а я видел достаточно много программ которые выполняли реальную работу во время I/O.

Прога тупо читает 20. блоков с SY: и пока они читаются занимается своими делами (инкрементит счетчик).

        .TITLE  TIO -- I/O TEST
        .IDENT  /V01.00/

        .MCALL  .LOOKUP,.READC,.EXIT,.PRINT

START:: .LOOKUP #AREA,#0,#DBLK
        BCC     20$
        .PRINT  #ERR1
10$:    CLR     R0
        .EXIT

20$:    .READC  #AREA,#0,#BUFF,#WCNT,#CRTN,#0
        BCC     30$
        .PRINT  #ERR2
        BR      10$

30$:    CMP     FLAG,#1
        BCC     40$
        ADC     COUNT+2
        ADC     COUNT
        BR      30$

40$:    MOV     #VALUE,R0
        MOV     COUNT,R1
        MOV     PC,R2
        CALL    $CBOMG
        MOVB    #<',>,(R0)+
        MOV     COUNT+2,R1
        MOV     PC,R2
        CALL    $CBOMG
        .PRINT  #VALUE
        BR      10$

CRTN::  INC     FLAG
        RETURN

COUNT:: .WORD   0,0

FLAG::  .WORD   0

BUFF::  .BLKW   256.*20.
WCNT    ==      <.-BUFF>/2

DBLK::  .RAD50  /SY/
        .WORD   0,0,0
AREA::  .BLKW   7

VALUE:  .ASCIZ  /XXXXXX,XXXXXX/

ERR1:   .ASCIZ  /LOOKUP FAILED/
ERR2:   .ASCIZ  /READ FAILED/

        .END    START

На достаточно быстром SCSI на 11/83 имеем (время меньше секунды):

.RU TIO
000000,002275

.

На УКНЦ (MZ по прерываниям [что не несет никаких проблем программам, работающим с ПП несмотря на мифы об этом]) получается 167000 с чем-то, время около секунды. А на HX примерно за пол минуты имеем ноль сделанного

[Alex_K]

На УКНЦ (MZ по прерываниям [что не несет никаких проблем программам, работающим с ПП несмотря на мифы об этом])

Небольшой оффтоп - хотелось бы поподробнее узнать про мифы насчет этого.

[form]

Небольшой оффтоп - хотелось бы поподробнее узнать про мифы насчет этого.

Мифы читал у Арсения на сайте - там выложена подборка каких-то статей, среди прочего была статья с исходниками драйвера MZ без прерываний и обоснование - мол поскольку работают через одну дырку, драйвер может мешать - глотает прерывания (и соответственно портит содержимое CSR или что-то в этом роде). Теоретически такое возможно например в случае запуска чтения с MZ вышеупомянутыми .READ/.READC и параллельной загрузки кода в ПП. Ну или в случае кривого драйвера (что по-видимому имело место с автором статьй) который не выключает прерывания по завершению I/O.

[Alex_K]

Мифы читал у Арсения на сайте - там выложена подборка каких-то статей, среди прочего была статья с исходниками драйвера MZ без прерываний и обоснование - мол поскольку работают через одну дырку, драйвер может мешать - глотает прерывания (и соответственно портит содержимое CSR или что-то в этом роде). Теоретически такое возможно например в случае запуска чтения с MZ вышеупомянутыми .READ/.READC и параллельной загрузки кода в ПП. Ну или в случае кривого драйвера (что по-видимому имело место с автором статьй) который не выключает прерывания по завершению I/O.

А-а-а-а!!!!! Теперь понял. Смысл состоит в том, что если программа через канал 2 передает блок (а это четыре байта), и в это время произойдет прерывание от драйвера MZ, и он тоже начнет что-то передавать по каналу К2, то собьется синхронизация счетчика драйвера канала 2 в системном ПЗУ ПП. Но вообще-то это невозможно, т.к. последний четвертый байт не читается из К2 со стороны ПП, пока не будет завершена операция. Т.е. если по .READ/.READC что-то запросить и сразу же попробовать работать с К2, то у него не будет установлен бит готовности. Как-то вот так ...