СМ-1420 – Запуск комплекса

Вид для печати

Показывать 40 сообщений этой темы на одной странице

16.03.2016, 11:53
Patron

.

Учитывая, что все тесты XXDP теперь проходят - можно считать, что ситуация с работой контроллера RK немного прояснилась.

Из не вполне однозначно описанного в документации выяснилось следующее:

1. Номер цилиндра в заголовке сектора пишется в формате RKDA ( со сдвигом влево ), когда цилиндру 001 соответствует номер 040.
2. Номер привода в старших битах RKDS имеет смысл только при установленном бите SCP в RKCS, во всех остальных случаях там нули.
3. Бит SCP в RKCS сохраняется установленным, пока установлены биты 06 и 07 ( разрешение прерываний и готовность контроллера ).
4. Бит SCP устанавливается в RKCS, только когда при прерывании от POLL-системы процессор уже принял от контроллера адрес вектора.
5. Если прерывание SCP от POLL-системы не было принято процессором, маска SCP не очищена и признак SCP у вызвавшего прерывание привода не сброшен - прерывание SCP будет выставлено снова после приёма процессором следующего прерывания готовности.
6. Номер текущего сектора выбранного привода в RKDS циклически инкрементируется непрерывно ( с частотой 300 Гц ) пока крутится диск - движение головки не влияет.
7. Регистры контроллера доступны для байтовой записи.

Не охвачены тестами XXDP и остались неясными следующие вопросы:

1. Как ведёт себя контроллер при передаче ему нечётного адреса буфера в ОЗУ.
2. Как ведёт себя занятый контроллер при записи в регистр RKCS: а) без установки бита GO; б) с установкой бита GO.
3. Какие команды, кроме сброса, может выполнить контроллер при установленном бите HARD ERROR ( бит 14 ) в RKCS.
16.03.2016, 12:09
form

Цитата:

Сообщение от Patron

Номер привода в старших битах RKDS имеет смысл только при установленном бите SCP в RKCS

Я так понимаю имеется в виду после запуска SEEK?

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

Цитата:

Сообщение от Patron

1. Как ведёт себя контроллер при передаче ему нечётного адреса буфера в ОЗУ.

Скорее всего вернет ошибку NXM (2000) в RKER.

Цитата:

Сообщение от Patron

2. Как ведёт себя занятый контроллер при записи в регистр RKCS: а) без установки бита GO; б) с установкой бита GO.

Как и должен. Без установки бита GO записывает и не выполняет. После можно сделать BIS #1 чтобы выполнить (можно делать многократно - именно так делает RSXный загрузчик для чтения следующей порции [регистры адреса диска и буфера после выполнения I/O уже готовы к следующему без дополнительных действий]).

UPD: Пропустил слово "занятый"... Тут не скажу точно. Но во всяком случае не отработает после того как станет готов. А запишет или нет (скорее нет, но мало ли) - легко проверить...
16.03.2016, 12:25
Patron

Цитата:

Сообщение от form

Я так понимаю имеется в виду после запуска SEEK?

После того, как позиционирование завершилось, контроллер выставил прерывание, а процессор его принял.

Цитата:

Сообщение от form

не скажу точно. Но во всяком случае не отработает после того как станет готов.

В документации сказано, что если выполняется команда записи - новая команда не начнёт выполняться, пока не будет полностью записан текущий сектор. У меня это пока не эмулируется - надо тестировать.

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

Также может оказаться, что установленный бит SCP сбрасывается при любой записи в RKCS - это тоже надо тестировать.
16.03.2016, 12:31
Vslav

Ну что, все хорошо, то что запрашивал - то выдали на пару недель на руки :)
Из нового:

3.055.006ТО часть 1, 330 страниц - на СМ2420
3.055.006-01ТО, в двух частях (аналог части 1, на СМ2420), 330 страниц - на СМ2420.01
3.055.006СБ - пакет сборочных чертежей на СМ2420 и СМ2420.01
3.414.00x.xx - толстый сшитый талмуд из таблиц прожига на все РЕ/РТ-шки в 2420/2420.01

Все из цехового архива технологов, КБ-шный тоже частью сохранился, но туда доступ ограничен (закрыто/обесточено/не отапливается все,
надо специально искать кто этот абандом откроет и запустит). Как это отсканю и верну - можно будет дальше спрашивать.
16.03.2016, 12:55
form

Цитата:

Сообщение от Vslav

Ну что, все хорошо, то что запрашивал - то выдали на пару недель на руки

уРА! :v2_dizzy_vodka2:

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

Кстати интересный фрагмент кода в драйвере RK обнаружился:

Код:

MOV #<^B11>,-(SP) ;U-bus controller can handle 18-bit ; transfers MOV @#SYSPTR,R1 ;R1 -> $RMON BIT #<BUS$>,CONFG2(R1) ;Running on qbus? BEQ 47$ ;Nope... CLR (SP) ;Q-bus controller can handle 16-bit ; transfers 47$: BIC (SP)+,R2 ;Strip off allowed hi-order component

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

Ну и как результат на Q-Bus проце:

Код:

.DIR RK: 16-Mar-2016 0 Files, 0 Blocks 4762 Free blocks .V DIR RK: ?DIR-F-Error reading directory .
16.03.2016, 13:17
AFZ

Цитата:

Сообщение от form

Кстати интересный фрагмент кода в драйвере RK обнаружился:

Хм... А у меня RK с новосибирским контроллером работал на ВМ3. Или RT-11 не опознает ВМ3, как Q-bus'ный? Я на нем еще тестил работу с верхней памятью. Результат, помню, был неудовлетворительный - что-то там путалось, из-за чего слово или два из сектора могли лечь не туда - сбой в старших битах адреса.
16.03.2016, 13:25
Patron

Цитата:

Сообщение от AFZ

Или RT-11 не опознает ВМ3, как Q-bus'ный?

Опознаёт как PDP-11/34.
16.03.2016, 13:29
form

Цитата:

Сообщение от AFZ

Хм... А у меня RK с новосибирским контроллером работал на ВМ3. Или RT-11 не опознает ВМ3, как Q-bus'ный?

Опознает или нет - надо проверить. Но работать он и так работает, только следит, чтобы в результате операции конечный адрес вписался в 16 bit. А в RT-11 это условие как правило выполняется даже для XM/ZM.

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

Цитата:

Сообщение от Patron

Опознаёт как PDP-11/34

Биты шины отдельно надо посмотреть на всякий случай.

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

Это в принципе может и ошибкой быть ибо никто не мешает на Q-Bus быть RK контроллеру 18-битным. Причем у DEC вроде в принципе не было RK для Q-Bus. Одну по крайней мере ошибку в драйвере я уже заметил: он не запрещает прерывания в принципе никогда. То есть загрузил по .FETCH, потом он выгрузился, а прерывания остались разрешенными.
16.03.2016, 13:47
AFZ

Цитата:

Сообщение от Patron

Опознаёт как PDP-11/34.

Это-то понятно, а откуда тогда память >248K?

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

Цитата:

Сообщение от form

Это в принципе может и ошибкой быть ибо никто не мешает на Q-Bus быть RK контроллеру 18-битным.

А еще, вроде-бы, был адаптер QUnibus, который вставлялся в Q-bus, а к нему можно было подключать Unibus-устройства.
16.03.2016, 18:00
form

Цитата:

Сообщение от AFZ

Это-то понятно, а откуда тогда память >248K?

Память он в явном виде тестирует в BSTRAP.

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

Цитата:

Сообщение от AFZ

А еще, вроде-бы, был адаптер QUnibus, который вставлялся в Q-bus, а к нему можно было подключать Unibus-устройства.

Были такие. По идее к 18 бит должен доступ давать.

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

Цитата:

Сообщение от form

Биты шины отдельно надо посмотреть на всякий случай.

В эмуляторе определяется как UNIBUS система.

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

Еще инфа по RK05

Код:

RK11/RKV11 cartridge disk (RK05) controller (RK) This simulation only simulates the RK05 disk drive. After 1973, you couldn't have an RK02 in a system. Except for an early version of DOS11, no PDP11 operating system supported it. DEC did two versions of the RK11 controller for the PDP11: the RK11-C and the RK11-D (There's also a -E for the PDP-15.). The -C is described in the 1972 PDP11 Peripherals handbook. In that controller, RKDS<11> distinguishes an RK02 (low density, 128 words/sector) drive from an RK03 (high density, 256 words/drive). By 1973, the RK11-C had been superseded by the RK11-D. The RK11-D only supports high density drives: the RK03 Diablo drive, and the RK05 DEC drive. In the RK11-D, RKDS<11> distinguishes between an RK03 (Diablo) and an RK05 (DEC) drive. From the point of view of software, the RK03/RK05 distinction is cosmetic. At the hardware level, RK05s had to be daisy-chained in front of RK03s, because RK03s did not receive/propagate the power fail signals. Daisy-chain order is different than unit-number order and cannot be detected from software. There is no known way to test an RK11-C, as none of the existing software sets support it. RT, RSTS/E, and M/M+ were all released after the RK11-D and do not support the RK11-C.

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

Кстати код, проверяющий конечный адрес перед запуском I/O появился в RK не сразу. В 5.0 проверки еще нет и драйвер полагается на то, что вернет конроллер. В 5.4G проверка уже есть. Одно из двух - или DEC действительно делал для Q-Bus 16-bit контроллер (выше текст из SimH - упоминается некий RKV11), а потом на RK забили; либо проверка должна была проверять 22-bit адрес который на Q-Bus по определению не будет работать (только в этом случае не ясно зачем вообще шины различать - проверка будет одинаковой).

Показывать 40 сообщений этой темы на одной странице