Эмуляция 1801ВП1-128 в ПЛИС

[Alex_K]

Если при эмуляции ВП1-128 сделать так, что чтение регистра данных при записи переводит ВП1-128 в режим поиска маркера - дорожка начинает писаться за 10 оборотов вместо одного и программа TESTMY.SAV сообщает, что контроллер неисправен.

Если записываются сплошняком все 10 секторов, то после записи данных, при чтении регистра данных, контроллер переходит именно в режим чтения, т.к. до записи схема чтения находилась не в режиме поиска маркера.
Кстати в УКНЦ, если подряд записываются сектора, то поиск следующей синхрозоны происходит с опросом бита требования. Подпрограмма по адресу 134132.

---------- Post added 28.12.2013 at 00:06 ---------- Previous post was 27.12.2013 at 23:48 ----------

Про триггер написано в этом сообщении.
Диаграмма моделирования чтения регистра данных без пропуска требования в аттаче.

Про это я читал. Просто при моделировании у Вас схема чтения находилась в режиме поиска маркера. Это видно, как только перешли в режим чтения, то сразу же кончились импульсы BCNT_CLK. Для того, чтобы перейти в режим чтения, надо дать маркер 0xA1 именно с пропущенным синхроимпульсом, ну и чтоб он совпал по фазе. А вот схема для сброса CRC останется взведенной и регистры CRC не очистятся, это факт, считаться будет полный бред и в итоге контрольная сумма не сойдется.

[Advertiser]

[Patron]

Кстати в УКНЦ, если подряд записываются сектора, то поиск следующей синхрозоны происходит с опросом бита требования. Подпрограмма по адресу 134132.

Вот программа поиска синхрозоны в ПЗУ УКНЦ:

132656$:MOV     #4,R1
        CMPB    #5,23301        ; Формат 1024 байта в секторе ?
        BNE     132702$         ; Нет
        TST     @R4             ; Присутствует линия индекс ?
        BPL     132702$         ; Нет
        MOV     #36,R1
132702$:MOV     @R5,R0          ; Прочесть слово с дискеты
        BEQ     132730$         ; Это нуль
        INC     R0
        BEQ     132730$         ; Это минус один
        TSTB    @#177710        ; Таймер окончил счет
        BPL     132656$         ; Нет
        CALL    134242$         ; Сбросить готовность таймера
        SOB     R2,132656$
        BR      133002$         ; Ошибка (не найден межсекторный промежуток)

Это практически точная копия программы из прошивки -255 и смысл её именно в том, что в режиме предварительного чтения бит требования не проверяется.

---------- Post added at 23:14 ---------- Previous post was at 23:08 ----------

Интересно найти хотя бы одну прошивку, которая не сможет работать, когда в режиме предварительного чтения ВП1-128 не выставляет требование.

[Vslav]

Кстати, я тут посмотрел внимательно на этот триггер A1W и выяснил что он только CRC_RST генерирует. А вот за запуск чтения другой триггер отвечает - на A30, который PLL_RDY выдает. Я сейчас немного сместил выдачу маркера на чтение - и начало выставляться требование! То есть при предыдущем моделировании просто оно не распознало маркер (попало на противофазу). Но при этом чтении все равно CRC не сбросилась, поэтому результирующая сумма будет неверная.

В-общем, мне кажется все работает так:
- есть два отдельных триггера - A1W и A30(PLL_RDY)
- триггер A1W устанавливается FIN_STB, сбрасывается при обнаружении A1 в сдвиговом регистре, в момент перехода 1->0 вырабатывает nCRC_RST и обнуляет сумму
- триггер A30(PLL_RDY) сбрасывается GOR и взводится по обнаружении полноценного маркера с пропущенным синхроимпульсом
- запись на диск начинается при записи любого значения в регистр данных
- сброс суммы CRC (обнуление) произойдет только при записи первого A1, и только если триггер A1W установлен. При обнулении CRC триггер A1W уже сброшен, следующие записи A1 и сбросы A1W не обнуляют сумму (нет перехода триггера 1->0).
- чтение регистра данных всегда переводит в режим чтения
- чтение всегда сначала ищет маркер, при обнаружении срабатывает триггер A30/PLL_RDY.
- если PLL_RDY установлен то в режиме чтения будет устанавливаться требование
- режим поиcка маркера - только при сброшенном A30. То есть если маркер был найден то новый поиск маркера начнет только после GOR, иначе продолжается чтение, даже при необслуженном требовании. Необслуживание требования при чтении, видимо, имеет одну цель - подсчет суммы и выработку FIN_STB. Потом чтение вполне себе продолжается и даже обнулит сумму если вдруг найдет A1.

---------- Post added at 22:30 ---------- Previous post was at 22:29 ----------

то сразу же кончились импульсы BCNT_CLK. Для того, чтобы перейти в режим чтения, надо дать маркер 0xA1 именно с пропущенным

Ага, я это только сейчас заметил.

[Patron]

Дальнейшая проверка работы прошивок в режиме предварительного чтения.

Прошивка БК-0011:

.SbTtl	Check for Data
20$:	Call	ChkInd
	Bcs	100$
	Beq	20$			;Zero, skip it
	Com	R0
	Beq	20$			;---"----"-----
30$:	Call	ChkInd
	Bcs	100$
	Beq	40$
	Com	R0
	Bne	30$
.SbTtl	Real Adress mark Checking
40$:	MovB	#3,ErrCnt		;Retry Counter
50$:	Mov	@R5,R0			;Data = Zero ?
	Beq	60$			;Yes, 
	Com	R0			;Inverted Zero ?
	Bne	20$			;No
60$:	DecB	ErrCnt			;Yes, Wait once more
	Bne	50$
	Call	StrtRd			;Set GoR
	Mov	#20.,R0
70$:	TstB	@R4			;Wait for Data ready
	Bmi	80$			;Ready
	Sob	R0,70$			;Not Ready, Timeout
	Br	20$

Видно, что синхрозона ищется без проверки требования, а сразу после установки GOR - начинается ожидание требования.

[Alex_K]

P.S. Было бы хорошо если кто-нибудь еще поставил Quartus+ModelSim, проект 128-ой для Quartus открыто выложен, разобраться с основами и запустить моделирование помогу. Потому что много нюансов, я могу где-то и ошибиться.

Это отсюда качать?

---------- Post added at 00:43 ---------- Previous post was at 00:37 ----------

- запись на диск начинается при записи любого значения в регистр данных

Вот, как я понял, контроллер переходит в режим записи сразу же. Так как активен режим записи, то импульсы BCNT_CLK идут всегда и счетчик битов всегда работает. Но этот счетчик не сбрасывается, поэтому если он работал ранее в режиме чтения данных, то возможны такие варианты:
- запишется несколько битов из сдвигового регистра (то что было);
- в зависимости от числа счетчика может записаться сначала младший байт, затем старший и выставится требование;
- может записаться только старший байт и выставится требование, младший уже не запишется.

---------- Post added at 00:45 ---------- Previous post was at 00:43 ----------

И ещё небольшой вопрос - чем отличается поведение ВП1-128 при установленном сигнале защиты записи ?

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

[Vslav]

Это отсюда качать?

Нет, надо WEB-edition, он бесплатный.

[Alex_K]

Нет, надо WEB-edition, он бесплатный.

Спасибо! Правда вникать я наверное буду долго. А так надо бы прояснить все временные диаграммы сигналов STB_**, как контроллер переключается в режим чтения, ну и тд и тп.

[Patron]

надо бы прояснить все временные диаграммы сигналов STB_**, как контроллер переключается в режим чтения, ну и тд и тп.

Интереснее всего проверить, что происходит при поиске синхрозоны заголовка следующего сектора после записи блока данных предыдущего сектора.

Последовательность при этом следующая:

1. Прочитать регистр данных
2. Установить и сбросить GOR
3. Ждать требование
4. Записать 0xA1A1
5. Ждать флаг CRC
6. Записать 0x4E4E
7. Ждать требование
8. Прочитать регистр данных

В результате ВП1-128 переходит в такое состояние чтения, в котором ни одна из прошивок не проверяет требование. При этом ( например ) УКНЦ, для определения смены слова в регистре данных, вместо того, чтобы проверять требование - использует таймер УКНЦ.

Какой был бы смысл использовать таймер вместо бита требования, чтобы определить момент смены слова в регистре данных, если бы бит требования в режиме предварительного чтения выставлялся как обычно..

[Alex_K]

В результате ВП1-128 переходит в такое состояние чтения, в котором ни одна из прошивок не проверяет требование. При этом ( например ) УКНЦ, для определения смены слова в регистре данных, вместо того, чтобы проверять требование - использует таймер УКНЦ.

Какой был бы смысл использовать таймер вместо бита требования, чтобы определить момент смены слова в регистре данных, если бы бит требования в режиме предварительного чтения выставлялся как обычно..

Ох, Patron, прицепились вы к этому требованию и придумали какой-то режим предварительного чтения, которого нет. Повторюсь еще раз, что требование не проверяется потому, что неизвестно в каком режиме находится контроллер - поиск маркера (где оно не выставляется до тех пор, пока не будет найден) или режим чтения.
А про использование программируемого таймера в прошивке УКНЦ я Вам сейчас все расскажу. Периферийный процессор в УКНЦ обслуживает кроме дисковода еще эмулятор терминала, который принимает данные по каналу 0, использует сетевой таймер для скроллинга и мигания курсора. Чтобы все это хорошо работало надо чтобы возникали прерывания в нужный момент времени, т.е. нужна система более-менее реального времени. А 1801ВП1-128 как известно не имеет ни режима прерываний, ни ПДП, т.е. чтение данных с дискеты должно идти при полностью запрещенных прерываниях. А вот теперь представьте, что мы прочитали заголовок сектора, а номер сектора не тот, что нам надо. Или прочли маркер данных. Вот здесь, чтобы тупо не читать этот ненужный нам сектор до конца, программа управления дисководом в УКНЦ поступает очень умно. Она программирует таймер на время прохождения сектора, и отдает управление прерванной программе. Когда головка дисковода подходит к концу сектора, то вырабатывается прерывание от программируемого таймера, и программа чтения уже может искать следующий маркер. В КМД ДВК это не надо, и там, если нашли не тот маркер или заголовок, тупо пропускаются все данные.

[Patron]

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

Т.е. при чтении регистра данных в режиме записи - контроллер всегда переходит в тот режим чтения, который был до этого ( поиск маркера или обычное чтение ).

Когда Vslav проводил эксперимент с чтением регистра данных перед записью контрольной суммы - до начала эксперимента у ВП1-128 был режим поиска маркера, поэтому он и установился в момент чтения регистра данных. Если бы перед началом эксперимента уже был режим обычного чтения, то в ходе эксперимента - после чтения регистра данных установился бы режим обычного чтения.