CRC_VALID - да, но он не эквивалентен биту в регистре 177130. Читаемый бит в регистре называется CSR_CRC и получается с выхода триггера J36. А триггер защелкивается именно в момент окончания чтения (когда не выполняем требование считывания слова CRC).Сообщение от Patron
Промоделировал чтение - повторное обнаружение маркера не обнуляет регистр CRC, только первый маркер.
Сообщение от Vslav
Похоже, что с моделированием какие-то проблемы. По логике работы контроллера - порядок байтов на диске у слова данных и слова CRC не может быть разным ( в обоих случаях первым должен идти СТАРШИЙ байт ).На выходе записываемых данных получилось:
Код:0x30 (то есть, сначала МЛАДШИЙ байт, старший бит первым) 0x31 (то есть, потом СТАРШИЙ байт, старший бит первым) 0x32 0x33 (после этого байта содержимое регистра CRC = 0x6EE9) 0x91 (инвертированное 0x6E. Сначала пишется СТАРШИЙ байт инвертированной суммы) 0x16 (инвертированное 0xE9. Потом пишется МЛАДШИЙ байт инвертированной суммы)
Последний раз редактировалось Patron; 13.12.2013 в 16:29.
По результатам моделирования чтения СТАРШИЙ байт слова идет первым. То есть первый прочитанный с диска байт помещается в старший, второй прочитанный помещается в младший байт регистра данных. Получается что при чтении байты в словах надо переставлять. Странная ситуация, порядок байт при чтении/записи отличается, анализ кода драйвера это подтверждает?
Сумма CRC при записи сдвиговый регистр не проходит - данные сдвигаются в самом регистре CRC, поэтому порядок байт там не важен - всегда пишется 16-битное инвертированное слово суммы, начиная со старшего бита. Тасовка же байт данных происходит на уровне мультиплексора 16-битного регистра данных в сдвиговый регистр.
Да, согласен, очень странно. Еще помоделировал, поискал ошибку, вроде нету. Полез в исходники РЕ2-326.
Фрагмент процедуры записи:
Фрагмент процедуры чтения:Код: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:
Похоже что 255-ая точно так же работает, фрагмент чтения:
В процедуре записи команды 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 ), а после пересылки СТАРШЕГО байта регистра данных, который пишется на диск следом за младшим.
Это так ?
Последний раз редактировалось Patron; 13.12.2013 в 17:31.
Да, иначе ведь и быть не может - требование можно выставить только при условии что 16-битный регистр хранения данных полностью свободен. Последний байт (старший при записи) из регистра переписался в сдвиговый - ставим требование.
По факту требование ставится в последний битовый интервал перед освобождением регистра. Если МПИ быстрая (как было сначала при моделировании), то есть шанс успеть переписать регистр данных и на выходе переписать уже новые данные в сдвиговый регистр. На реальной МПИ такое маловероятно - процессор будет читать коды команд, данные из памяти и прочее - битовый интервал успеет пройти и регистр успеет фактически освободиться.
Выходит, что в течение 4000 нс после выставления требования при записи - содержимое регистра данных находится под угрозой уничтожения. При тактовой частоте 10 МГц - это 40 тактов.
---------- Post added at 18:50 ---------- Previous post was at 18:43 ----------
Не удивлюсь, если 1801ВМ1 работает в контроллере MY на частоте ВП1-128 ( 4 МГц ).
Я помоделировал - интервал между выставлением требования и перезаписью данных (момент при котором в сдвиговый регистр могут попасть новые свежезаписанные данные) примерно 4 такта частоты 4МГц - то есть порядка 1 мкс. У меня процедуры МПИ вообще не были никак привязаны к тактовой, полностью асинхронные, чтение занимало менее 3 тактов. На МПИ реального процессора такое невозможно, так что проблема условная.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием