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

[Patron]

В процессе эмуляции КМД выяснилось, что если режим записи ВП1-128 находится в состоянии NOT A1_WRITTEN ( т.е. до записи 0xA1 или после записи контрольной суммы ) - то чтение регистра данных переводит ВП1-128 в режим предварительного чтения - не выровненного ни на границу байта, ни на границу бита. Поэтому, в данном режиме можно только искать синхрозону. При чтении в районе синхрозоны - слово читаемых данных будет иметь значение 0x0000 или 0xFFFF.

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

[Advertiser]

[Alex_K]

В процессе эмуляции КМД выяснилось, что если режим записи ВП1-128 находится в состоянии NOT A1_WRITTEN ( т.е. до записи 0xA1 или после записи контрольной суммы ) - то чтение регистра данных переводит ВП1-128 в режим предварительного чтения - не выравненного ни на границу байта, ни на границу бита. Поэтому, в данном режиме можно только искать синхрозону. При чтении в районе синхрозоны - слово читаемых данных будет иметь значение 0x0000 или 0xFFFF.

Перевод осуществляется в любом режиме, не зависит от того записали 0xA1 или CRC, или не записали. На дискете в реальности вся дорожка аккуратно выровнена только после форматирования, а стоит записать сектора, то все и пойдет наперекосяк. Потому при поиске синхрозоны и проверяют и на 0x0000, и на 0xFFFF. Но так будет читаться только если контроллер не находится в подрежиме поиска маркера. Если маркер еще не найден, то вся информация с дискеты, проходящая через сдвиговый регистр, не попадает в регистр данных.

[Patron]

Перевод осуществляется в любом режиме, не зависит от того записали 0xA1 или CRC, или не записали.

Немедленно - прекращается запись на текущем бите. .. Далее я ему подсунул маркер, и типа поток данных идет, но требование на чтение не выставляется, сумма не обнуляется, в-общем, читать данные не получится.

Получается, что в режиме предварительного чтения содержимое регистра данных обновляется, но требование не выставляется.

Код прошивки -255 это подтверждает:

; Пропуск не нулей при неактивном ИНДЕКСЕ
6704$:	MOV	#51010,R1	; R1 = длина дорожки в цикле
6710$:	TST	@R4		; Линия ИНДЕКС активна?
	BMI	6762$		; Да
	MOV	@R5,R0		; Считанное слово равно нулю?
	BEQ	7014$		; Да
	INC	R0		; Считанное слово равно 177777?
	BEQ	7014$		; Да
	SOB	R1,6710$		; Цикл по пропуску не нулей
	BR	6666$		; Нет дискеты - ошибка

; Удостоверение в том, что попали на синхрозону
7014$:	MOV	#3,32(R3)	; Счетчик для удостоверения
7022$:	MOV	@R5,R0		; Считанное слово равно нулю?
	BEQ	7032$		; Да
	INC	R0		; Считанное слово равно 177777?
	BNE	7066$		; Нет - не синхрозона
7032$:	DEC	32(R3)		; Уменьшить счетчик
	BNE	7022$		; Продолжаем дальше

[Alex_K]

Получается, что в режиме предварительного чтения содержимое регистра данных обновляется, но требование не выставляется.

А что это за режим предварительного чтения? Есть только режим чтения и его подрежим поиска маркера. Так вот в режиме поиска маркера требование не выставляется, но регистр данных чтения не обновляется, данные идут только через сдвиговый регистр.
А коду прошивки не всегда стоит доверять, авторы прошивки работы с дисководом (и на УКНЦ, и на КМД) судя по всему тоже не все знали. Как можно по такой скудной документации написать код, мне непонятно.

[Patron]

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

Тогда какой режим устанавливается в этом случае:

Немедленно - прекращается запись на текущем бите. Если писались данные, то бросит писать данные. Если писалась CRC, то бросит писать CRC. Как только прошло чтение - то LAST_WR немедленно становится высоким - сразу при чтении процессором 177132. Ну и MODE_nR/W становитс низким (не мгновенно, синхронизируется в какой-то фазе битового интервала). Все, nWRE сразу высокий, даже если бы оно продолжило выдачу данных - дисковод запись блокирует. Далее я ему подсунул маркер, и типа поток данных идет, но требование на чтение не выставляется, сумма не обнуляется, в-общем, читать данные не получится.

Если при чтении регистра данных в режиме записи - устанавливается один и тот же режим чтения, незавивисимо от состояния записи A1_WRITTEN - то в этом режиме чтения данные должны выдаваться, но требование выставляться не должно.

В любом случае устанавливается третий режим чтения, вопрос лишь в том - один и тот же ли этот режим при любом чтении в ходе записи или устанавливающийся режим зависит от фазы прерванной записи по состоянию A1_WRITTEN ( что менее вероятно ).

---------- Post added at 16:43 ---------- Previous post was at 16:04 ----------

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

[Patron]

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

[Patron]

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

[Alex_K]

Посмотрел внимательно схему формирования выходных сигналов DO1, DO2, DO3. Для анализа разложил отдельно по логическим элементам формирование каждого из сигналов. В качестве данных использовал диаграмму, которую выкладывал Vslav в этом сообщении. Также использовал файл для описания диаграммы wave.do. В диаграмме для анализа использовались сигналы DO3, DO2, DO1 (в самом верху), WDATA (бит для записи, соответствует выходу D32 на схеме, а также сигналу WBIT0), WCLK и nWCLK (они перепутаны со схемой, на схеме соответственно nWCLK и WCLK). Далее буду руководствоваться названиями сигналов на схеме.
Сама схема записи состоит из:
-фактически мультиплексора D32, который в зависимости от сигнала LATCH_TR, выбирает или выход с регистра CRC (LATCH_TR=1, пропущенное требование, идет запись CRC), или выход со сдвигового регистра (LATCH_TR=0, запись данных). На выходе получается сигнал WBIT0 (на диаграмме WDATA);
-сдвигового регистра на триггерах D37 (WBIT1), D36 (WBIT2), C37 (WBIT3), C38 (WBIT4), B37 (WBIT5), B36 (WBIT6), A37 (WBIT7), A36 (WBIT8). Хотя разрядов и восемь, но де-факто запоминаются четыре или пять, так как тактируются триггера разными сигналами, нечетные - nWCLK, четные - WCLK. Порядок продвижения битов будет описан чуть ниже;
-собственно целая куча логики для формирования выходных сигналов на DO1, DO2, DO3, в зависимости от значения сигналов WBIT0-WBIT8 и значения бита записи маркера CSR_WM.
Сама схема тактируется двумя сигналами WCLK и nWCLK. Сигналы эти поступают только тогда, когда контроллер находится в режиме записи и дискета не защищена от записи. Также, если нет сигналов WCLK и nWCLK, регистр из триггеров находится все время в режиме сброса (сигнал nWRE). Длительность двоичного бита данных составляет 4 мкс. Сам этот интервал для записи MFM-сигнала делится на два интервала по 2 мкс. В середине этих MFM-интервалов проскакивают импульсы - сначала nWCLK, затем WCLK. Как известно в MFM бит "1" кодируется как "01", бит "0" после "1" как "00" и бит "0" после нуля - "10". Из этого следует, что единичный бит данных надо записывать на импульсе WCLK, а нулевой после нуля - на nWCLK.
Рассмотрим схему продвижения битов по сдвиговому регистру. Они обозначены по порядку, как 1, 2, 3 и т.д.

876543210
---------
000000011 nWCLK
000000111 WCLK
000001122 nWCLK
000011222 WCLK
000112233 nWCLK
001122333 WCLK
011223344 nWCLK
112233444 WCLK
122334455 nWCLK
223344555 WCLK
233445566 nWCLK

Для записи единичного бита используется сигнал WBIT3, для записи нулевого - WBIT4(предыдущий бит данных) и WBIT2(текущий бит данных).
Вот теперь о распределении сигналов по выходам DO1, DO2, DO3. Как описывал Vslav, что это скорее всего разнесенные по времени сигналы. Но анализ схемы этого не подтвердил. Схема распределяет сигнал на соответствующий вывод в зависимости от того, какие были предыдущие биты данных и какие будут последующие. А уже далее эту информацию использует схема внешней прекоррекции. Если прекоррекция не нужна, то сигналы с трех выводов нужно просто сложить. При этом сигнал на выходе будет только на одном выводе.
А теперь о распределении сигналов:
- вывод DO1: "1" - если предыдущий(WBIT5) и следующий(WBIT1) биты данных равны. "0" - если второй слева(WBIT6) и следующий(WBIT0) биты данных равны.
- вывод DO2: "1" - предыдущий(WBIT5)=0 и следующий(WBIT1)=1. "0" - второй слева(WBIT6)=1 и следующий(WBIT0)=0.
- вывод DO3: "1" - предыдущий(WBIT5)=1 и следующий(WBIT1)=0. "0" - второй слева(WBIT6)=0 и следующий(WBIT0)=1.
При установленном бите записи маркера CSR_WM все нулевые биты направляются на вывод DO1.
Ну а теперь самое интересное - как же делаются пропуски синхроимпульсов при записи маркера. По идее бит "0" должен записываться как "00", если предыдущие биты данных равны "100", а следующий - "0". Но разработчики 1801ВП1-128 поступили проще - они анализируют только третий слева бит данных на равенство "1". И то, что хорошо получается при записи маркера 0xA1, может наделать лишних пропусков при записи других данных.
Фрагмент из диаграммы от Vslav:

   !       30      !       31      !       32      !       33      !       62      !       A7      !       00      !       00      !       A1      !       A1      !       A1      !       FE      !
1 0 0 0 1 1 0 0 0 0 0 0 1 1 0 0 0 1 0 0 1 1 0 0 1 0 0 0 1 1 0 0 1 1 0 1 1 0 0 0 1 0 1 0 1 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 1 1 0 1 0 0 0 0 1 1 0 1 0 0 0 0 1 1 1 1 1 1 1 1 0 1 

0100000001010000001010100101000000010010010100000100100001010000010100010100000001000100010010010101000000101010101010101010101010100100010010001001010001001000100101000100100010010101010101010100
    ----      --**            ----            --      --      --            ----                      --**                                    **              **              **
0100101001010010101010100101001010010010010100100100101001010010010100010100101001000100010010010101001010101010101010101010101010100100010010101001010001001010100101000100101010010101010101010100

Сверху указаны шестнадцатеричные данные с границами байтов, ниже двоичный поток. Еще ниже показаны два MFM-потока - с установленным битом маркера CSR_WM и сброшенным битом маркера. Между потоками с помощью "--" указано, что пропуска не должно быть, а он есть, "**" - пропуск нужен и он есть.
Также диаграмма маркера C2:

       4E      !       00      !       00      !       C2      !       C2      !       C2      !       FC      !
0 1 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 0 0 0 1 0 1 1 0 0 0 0 1 0 1 1 0 0 0 0 1 0 1 1 1 1 1 1 0 0

0001001001010100000010101010101010101010101010100101000000100100010100000010010001010000001001000101010101010000
                --**                                  --**            --**            --**                    --
0001001001010100101010101010101010101010101010100101001010100100010100101010010001010010101001000101010101010010

[Patron]

то, что хорошо получается при записи маркера 0xA1, может наделать лишних пропусков при записи других данных

Выходит, что маркер 0xC2 пишется с двумя пропусками синхроимпульсов вместо одного..

[Alex_K]

Выходит, что маркер 0xC2 пишется с двумя пропусками синхроимпульсов вместо одного..

Выходит, что так. Но на чтении это сказаться не должно. ФАПЧ подстраивается под существующие импульсы, а если они исчезают, то держит нужную скорость. В итоге при отсутствии сигнала будут считываться нули.