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

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

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

28.12.2013, 00:06
Alex_K

Цитата:

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

Если при эмуляции ВП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 ----------

Цитата:

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

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

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

Цитата:

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

Кстати в УКНЦ, если подряд записываются сектора, то поиск следующей синхрозоны происходит с опросом бита требования. Подпрограмма по адресу 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 не выставляет требование.
28.12.2013, 00:30
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 ----------

Цитата:

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

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

Ага, я это только сейчас заметил.
28.12.2013, 00:36
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 - начинается ожидание требования.
28.12.2013, 00:45
Alex_K

Цитата:

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

Нет, надо WEB-edition, он бесплатный.
28.12.2013, 00:53
Alex_K

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

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