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

[Patron]

По поводу комментариев, они не всегда могут быть верные

Дело не в комментариях.

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

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

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

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

[Alex_K]

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

Бит 14 устанавливается в начале записи CRC. Пишется два байта из регистров CRC, из регистра записываемых данных ничего не копируется. При установке бита 14 начинается запись CRC, бит 7 также установлен, т.к. требование было выполнено, но не удовлетворено. Сразу же после установки бита 14 в регистр данных записи надо скопировать новые данные. Они во время записи CRC никуда не уходят, бит 7 сбрасывается при записи новых данных. Сбросится и бит 14, т.к. сбросился бит 7 и должен сняться сигнал LATCH_TR, но об этом лучше скажет Vslav. После того как CRC записалась, записывается младший байт данных, а потом, при копировании старшего байта в сдвиговый регистр, устанавливается бит 7, приглашая записать новые данные.

Кроме того - если после записи заголовка сектора генератор CRC не перезапустится на маркере данных - у блока данных неоткуда взяться корректной CRC.
Ведь блок данных при форматировании пишется в одной операции записи с заголовком сектора. Пропускается одно требование, чтобы записать CRC заголовка - и запись байтов формата дорожки немедленно продолжается.

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

Получается, что если установлен бит CRCw и в сдвиговом регистре находится байт 0xA1 - бит CRCw сбрасывается, а генератор CRC перезапускается.

Во время записи бит 14 должен сбрасываться после сброса бита 7.

[Patron]

Почему не перезапустится - перезапустится

А какие условия перезапуска генератора CRC при записи..

Почему генератор CRC не перезапускается при записи второго и третьго байтов заголовка ?

[Vslav]

Извиняюсь, меня тут работой привалило...

Насколько немедленно:

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

В описании КМД этот бит называют GOR:

У меня текстовый файлик .txt, я по нему работал, там Gdr, видимо человек набирал с плохой копии.

И сигнал IND никак на это не влияет ?

Элементы N21, N22, N23 представляют собой синхронный D-триггер (вход D - LAST_WR), который записывает сигнал с этого входа по ниспадающему фронту тактового сигнала (выход H15 4-9), и общий асинхронный сброс INIT_073. Поэтому сигнал IND - он максимум может сформировать лишний фронт записи в этот триггер, но повлиять на режим R/W - никак. Я долго не мог поверить что IND никуда больше не идет, тщательно изучал фото, всю цепь перепроверил. В итоге полагаю фактическое НЕ обрабатывание сигнала индекса - косяк 128-ой. Ну или индекс просто банально блокирует смену режима. При высоком уровне на ноге IND микросхема работает, при низком - смена режима блокирована. В-общем, про сигнал индекса можно забыть.

А если не обращаясь к регистру данных - установить в CSR бит GOR, что-нибудь в такой ситуации изменится ?

К регистру данных надо обращаться обязательно - иначе LAST_WR/MODE_R/W правильно не перекинется. Ну или INIT внешний дать.

Программа форматирования пишет на диск четыре байта: 0xA1,0xA1,0xA1,0xFE с установленным в CSR битом WM. В каких байтах при этом происходит пропуск "синхробита":

Во всех байтах маркера A1. Ессно, при чтении пропущенный импульс никак не повлияет на читаемое значение (потому что 128-ая анализирует середину интервала - был имульс в середине - бит данных 1, не было - бит данных 0), Байт FE пишется нормально, без пропусков, потому что все его биты единичные и кодируются имульсом в середине МФМ интервала. Кстати, после FE я начал писать 0x30 - там тоже импульс выкушен, но в 5-ой позиции - не там где в A1. Но на читаемые данные это не повлияет - 128-ая прочтет все правильно, даже несмотря на пропущенный импульс.

По логике работы программы форматирования

Сначала пишем первую порцию, потом игнорим требование записи - начинает записываться CRC, при этом в регистр суммы вдвигаются единицы, сигнал CRC_IN0 - активен. После записи всей CRC регистр приобретет значение 0xFFFF и поэтому после окончания записи CRC будет активен признак CRC_VALID и мы увидим этот флаг в CSR при чтении 177130. Если мы запишем маркер в 177132, то начнется процесс записи нового сектора.

Записав заголовок сектора - программа форматирования ждёт установки бита 14, чтобы была выполнена запись CRC, потом без единого перехода в режим чтения - пишет промежуток, маркер данных, данные и затем повторно ожидает записи CRC:

Именно так.

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

Бит WM на перезапуск не влияет - он управляет только работой МФМ-кодировщика.

---------- Post added at 19:55 ---------- Previous post was at 19:49 ----------

Бит 14 устанавливается в начале записи CRC.

Нет, бит 14 устанавливается ПОСЛЕ того как СRC физически выведена на выходы DOx, то есть записана на диск. Микросхема остается в режиме записи и продолжает писать нули (инвертированный регистр суммы, в котором FF-ы). Если записать маркер в регистр данных - начнется запись новой последовательности, бит WM на этот процесс не влияет, только на кодировщик МФМ. Да, и запись нового маркера сбрасывает бит 14, не мгновенно, а как начнется запись маркера на диск.

[Patron]

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

Значит, любое чтение регистра данных после записи и до установки 8-го бита - блокирует чтение.

А повторная запись в регистр данных приведёт к восстановлению нормальной работы или последующая запись также блокируется ?

[Alex_K]

Нет, бит 14 устанавливается ПОСЛЕ того как СRC физически выведена на выходы DOx, то есть записана на диск. Микросхема остается в режиме записи и продолжает писать нули (инвертированный регистр суммы, в котором FF-ы). Если записать маркер в регистр данных - начнется запись новой последовательности, бит WM на этот процесс не влияет, только на кодировщик МФМ. Да, и запись нового маркера сбрасывает бит 14, не мгновенно, а как начнется запись маркера на диск.

А вот здесь я не согласен. При записи сигнал CSR_CRC формируется из сигналов MODE_nR/W и nLATCH_TR. Если бы бит 14 выставлялся бы после физической записи CRC на диск, то был бы разрыв между CRC и последующими данными. А ведь данные в регистр записи заносятся после установки этого бита, а там исполняется несколько команд.
А вот сигнал MODE_R/nW и защелкнутый CRC_VALID формируют бит 14 при чтении, соответственно он формируется уже после физического чтения CRC с диска.

[Advertiser]

[Vslav]

А вот здесь я не согласен. При записи сигнал CSR_CRC формируется из сигналов MODE_nR/W и nLATCH_TR. Если бы бит 14

Да, я ошибся - перепутал на диаграмме при моделировании CSR_CRC и CRC_VALID (не туда посмотрел когда писал пост). CSR_CRC устанавливается в момент начала записи контрольной суммы на диск.

[Patron]

К регистру данных надо обращаться обязательно - иначе LAST_WR/MODE_R/W правильно не перекинется. Ну или INIT внешний дать.

Просто интересно, как идёт запись после того как в CSR:

1. Установлен и не сброшен 8-й бит
2. Установлен и сброшен 8-й бит

в случаях, когда:

1. дальнейшая запись в регистр данных после установки 8-го бита не производится
2. дальнейшая запись в регистр данных после установки 8-го бита продолжается по тебованию

После записи всей CRC регистр приобретет значение 0xFFFF и поэтому после окончания записи CRC будет активен признак CRC_VALID и мы увидим этот флаг в CSR при чтении 177130. Если мы запишем маркер в 177132, то начнется процесс записи нового сектора.

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

У генератора CRC есть только один шанс отличить первый байт маркера от второго - если бит CRCw сбрасывается только при записи байта маркера. Тогда запись маркера при установленном бите CRCw должна перезапускать генератор CRC.

Но тогда по INIT бит CRCw должен устанавливаться, а не сбрасываться - как иначе определить, что первый байт первого записываемого маркера не является его вторым байтом..

[Vslav]

Исправленое описание процесса записи:

- старт записи начинается записью данных в регистр 177132, при этом записываемые данные пишутся на диск, по новому требованию можно записывать произвольное количество слов данных
- при первой записи A1 в регистр данных 177132 и начале вывода этого A1 сбрасывается регистр CRC
- при необслуживании требования записи начинается вывод вычисленной CRC на диск
- при начале записи CRC на диск выставляется бит CSR_CRC (14-ый)
- после выставленного CSR_CRC можно обслужить требование записи
- можно писать в 177132 любые данные и они будут выводится на диск, но только при обнаружении записи первого нового маркера A1 опять сбросится CRC
- цикл можно повторить нужное число раз

Просто интересно, как идёт запись после того как в CSR:
1. Установлен и не сброшен 8-й бит
2. Установлен и сброшен 8-й бит

Как повезет - сигнал nGDR стробируется на триггере G35 импульсами входных данных, если импульсов нет, то бит GOR никак не влияет - запись промоделировалась штатно. А вот если сработает - то все встанет - будут активны RDINIT0 и RDINIT1 - остановится счетчик битов, не будет выставлятся требование и прочее - запись просто не пойдет

[Patron]

Исправленое описание процесса записи:

- при первой записи A1 в регистр данных 177132 и начале вывода этого A1 сбрасывается регистр CRC
- можно писать в 177132 любые данные и они будут выводится на диск, но только при обнаружении записи первого нового маркера A1 опять сбросится CRC

Но из этого прямо следует, что бит CRCw должен устанавливаться по INIT - иначе невозможно отличить запись первого байта 0xA1 самого первого маркера от записи второго байта 0xA1 того же маркера.