Вид для печати
CRC_VALID - да, но он не эквивалентен биту в регистре 177130. Читаемый бит в регистре называется CSR_CRC и получается с выхода триггера J36. А триггер защелкивается именно в момент окончания чтения (когда не выполняем требование считывания слова CRC).Цитата:
Сообщение от Patron
Промоделировал чтение - повторное обнаружение маркера не обнуляет регистр CRC, только первый маркер.Цитата:
Сообщение от Patron
Сообщение от Vslav
Похоже, что с моделированием какие-то проблемы. По логике работы контроллера - порядок байтов на диске у слова данных и слова CRC не может быть разным ( в обоих случаях первым должен идти СТАРШИЙ байт ).Цитата:
На выходе записываемых данных получилось:
Код:0x30 (то есть, сначала МЛАДШИЙ байт, старший бит первым)
0x31 (то есть, потом СТАРШИЙ байт, старший бит первым)
0x32
0x33 (после этого байта содержимое регистра CRC = 0x6EE9)
0x91 (инвертированное 0x6E. Сначала пишется СТАРШИЙ байт инвертированной суммы)
0x16 (инвертированное 0xE9. Потом пишется МЛАДШИЙ байт инвертированной суммы)
По результатам моделирования чтения СТАРШИЙ байт слова идет первым. То есть первый прочитанный с диска байт помещается в старший, второй прочитанный помещается в младший байт регистра данных. Получается что при чтении байты в словах надо переставлять. Странная ситуация, порядок байт при чтении/записи отличается, анализ кода драйвера это подтверждает?Цитата:
Сообщение от Patron
Сумма CRC при записи сдвиговый регистр не проходит - данные сдвигаются в самом регистре CRC, поэтому порядок байт там не важен - всегда пишется 16-битное инвертированное слово суммы, начиная со старшего бита. Тасовка же байт данных происходит на уровне мультиплексора 16-битного регистра данных в сдвиговый регистр.
Да, согласен, очень странно. Еще помоделировал, поискал ошибку, вроде нету. Полез в исходники РЕ2-326.Цитата:
Сообщение от Patron
Фрагмент процедуры записи:
Фрагмент процедуры чтения:Код:0DX: TSTB (R4) ;ЖДЕМ ГОТОВНОСТИ
BPL 0DX
MOV (R2)+,(R5) ;ПИШЕМ ДАННЫЕ
0DW: SOB R1,0DX ;ПИШЕМ ПОКА НЕ КОНЧАТСЯ ДАННЫЕ
Мне очень понравился комментарий - "делаем его нормальным" :)Код:BD: MTPS #340
MOV 26(R3),R2 ;ЗАНЕСЕМ АДРЕС БУФЕРА
0BL: TSTB (R4) ;ОЖИДАНИЕ ДАННЫХ
BPL 0BL
MOV (R5),R0 ;ЧИТАЕМ СЛОВО
SWAB R0 ;ДЕЛАЕМ ЕГО НОРМАЛЬНЫМ
MOV R0,(R2)+ ;ЗАНОСИМ В БУФЕР
SOB R1,0BL ;ЧИТАЕМ ОПРЕДЕЛЕННОЕ КОЛ-ВО СЛОВ
Значит ВП1-128 таки ненормальная, ну и текущая модель ее ненормальность отображает нормально :)
Я сейчас пишу эмулятор контроллера MY - там роль драйвера выполняет прошивка -255:Цитата:
Сообщение от Vslav
Похоже что 255-ая точно так же работает, фрагмент чтения:Цитата:
Сообщение от Patron
В процедуре записи команды SWAB нет. В-общем, Цирк уехал, клоуны остались :)Код:; Подпрограмма чтения сектора
7254$: TST R2 ; Перешли за границу "окна"?
BPL 7304$ ; Нет
ROR R2 ; На начало "окна"
ADD #401,@#177102 ; Увеличить адрес старшей части "окна"
BNE 7304$ ; Еще не перешли границу памяти
BIS #4000,0(R3) ; Установить ошибку адреса в РСО
JMP 7500$ ; Завершить операцию с ошибкой
7304$: TSTB @R4 ; Очередное слово сформировано?
BPL 7304$ ; Нет
MOV @R5,R0 ; Прочесть слово
SWAB R0 ; Обменять байты
MOV R0,(R2)+ ; Передать слово в ОЗУ вычислителя
7316$: SOB R1,7254$
А ещё это значит, что требование в регистре статуса ( бит 7 ) выставляется не после пересылки в сдвиговый регистр младшего байта регистра данных ( как это написано в описании ВП1-128 ), а после пересылки СТАРШЕГО байта регистра данных, который пишется на диск следом за младшим.Цитата:
Сообщение от Vslav
Это так ?
Да, иначе ведь и быть не может - требование можно выставить только при условии что 16-битный регистр хранения данных полностью свободен. Последний байт (старший при записи) из регистра переписался в сдвиговый - ставим требование.Цитата:
Сообщение от Patron
По факту требование ставится в последний битовый интервал перед освобождением регистра. Если МПИ быстрая (как было сначала при моделировании), то есть шанс успеть переписать регистр данных и на выходе переписать уже новые данные в сдвиговый регистр. На реальной МПИ такое маловероятно - процессор будет читать коды команд, данные из памяти и прочее - битовый интервал успеет пройти и регистр успеет фактически освободиться.
Выходит, что в течение 4000 нс после выставления требования при записи - содержимое регистра данных находится под угрозой уничтожения. При тактовой частоте 10 МГц - это 40 тактов.Цитата:
Сообщение от Vslav
---------- Post added at 18:50 ---------- Previous post was at 18:43 ----------
Не удивлюсь, если 1801ВМ1 работает в контроллере MY на частоте ВП1-128 ( 4 МГц ).
Я помоделировал - интервал между выставлением требования и перезаписью данных (момент при котором в сдвиговый регистр могут попасть новые свежезаписанные данные) примерно 4 такта частоты 4МГц - то есть порядка 1 мкс. У меня процедуры МПИ вообще не были никак привязаны к тактовой, полностью асинхронные, чтение занимало менее 3 тактов. На МПИ реального процессора такое невозможно, так что проблема условная.Цитата:
Сообщение от Patron