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

[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$		; Продолжаем дальше

[Advertiser]

[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 ----------

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

[Alex_K]

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

Ну нету в контроллере никакого режима предварительного чтения. Если уж он начал читать, то читает. Хотя по схеме есть один тонкий момент, что если установился признак LATCH_TR, то сбросить его может только сигнал FIN_STB, а при активном LATCH_TR признак требования не устанавливается. Надо посмотреть повнимательнее схему, проанализировать.
Приеду домой, осмотрю и напишу.

[Patron]

Ну нету в контроллере никакого режима предварительного чтения.

Это режим обычного чтения, при котором не устанавливается требование. Режим этот был обнаружен экспериментально.

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

Но если при невыровненном чтении действовать в соответствии с экспериментально наблюдаемыми результатами и требование НЕ УСТАНАВЛИВАТЬ - то все прошивки полностью сохраняют работоспособность именно потому, что в режиме предварительного чтения никогда не проверяют бит требования.

[Alex_K]

Это режим обычного чтения, при котором не устанавливается требование. Режим этот был обнаружен экспериментально.

В результате каких экспериментов?

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

Не проверяют они его потому, что неизвестно состояние контроллера. Он может находится в режиме поиска маркера, и пока он его не найдет, то и чтение данных не начнется. Есть еще момент - бит требования устанавливается только после чтения двух байтов, а ведь сдвиговый регистр байтовый. Поэтому таким чтением можно прочесть уже следующий байт без установки бита требования. Представим записано на диске 1 2 3 4 5 6 ... Сначала в регистре данных чтения прочтется <1 2> и выставится бит требования, потом будет <3 2>, но бита требования не будет стоять, а уже когда окажется <3 4>, то установится бит требования. Потому в программах поиска синхрозоны и не проверяют бит требования, чтобы не подвиснуть на долгое время.
А если контроллер перешел в режим чтения, то он аккуратно будет нарезать данные каждые 64 мкс, при присутствии сигналов на входе в соответствии с подстройкой ФАПЧ, а если сигнала нет, то будут поступать нули каждые 64 мкс.

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

[Patron]

В результате каких экспериментов?

Вот таких:

требование на чтение не выставляется

Не проверяют они его потому, что неизвестно состояние контроллера. Он может находится в режиме поиска маркера, и пока он его не найдет, то и чтение данных не начнется.

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

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

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

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

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