Контроллер псевдо КМД+дисковод для УКНЦ (на SD карте)

[ZPilot]

Нуууу.... а почему 4E начинается не с 260?..

А потому что CRC там. Глюк на этой картинке в том, что нет контрольной суммы после номера трека, стороны, сектора и его типа, сразу 4Е начинались. Подправил еще, вроде ошибок нет, вот файл целиком: https://cloud.mail.ru/public/4Nub/zpns2dVFg

- - - Добавлено - - -

ZPilot, это от начала индекса?

Да.. и все тут вроде правильно, тк GAP1 должен быть всего длинной 38 байт, только он разбит на куска GAP1 и GAP3, вернее GAP3 состоит из 36 (34) байта GAP1 и 2(4) байта GAP3. Как то так..
Начало и конец сектора всегда 0х4Е, по этому сдвинуть можно.

Да, какой длинны должна быть индексная метка?

[Advertiser]

[nzeemin]

Как я вижу по коду из эмулятора - см. m_writemarker, m_shiftmarker, m_crccalculus, m_writing - https://github.com/nzeemin/ukncbtl/b...ase/Floppy.cpp
При записи адресного маркера данных, УКНЦ должна собственно записать маркер - она выставляет бит 9 в 177130. С этого момента начинается подсчёт контрольной суммы. После завершения записи сектора - конрольная сумма помещается в сдвиговый регистр, и соответственно записывается на диск - это два байта сразу после данных сектора.
Т.е. вам не нужно ждать что УКНЦ передаст контрольную сумму - её считает и записывает сам контроллер, т.е. в вашем случае - ваш контроллер.
Alex_K конечно лучше объяснит, я тут мимокрокодил.

- - - Updated - - -

Да, какой длинны должна быть индексная метка?

Думаю это не особенно важно, ловится же начало отверстия. У меня стоит константа в 150 байт:
#define FLOPPY_INDEXLENGTH 150 ///< Length of index hole, in bytes of raw track image

[Hunta]

её считает и записывает сам контроллер

Память подсказывает, что таки да и самое главное - это выглядит логичней

[ZPilot]

При записи адресного маркера данных, УКНЦ должна собственно записать маркер - она выставляет бит 9 в 177130. С этого момента начинается подсчёт контрольной суммы. После завершения записи сектора - конрольная сумма помещается в сдвиговый регистр, и соответственно записывается на диск

Тут вы не совсем правы, да она выставляет 9 бит, но УКНЦ четко отлавливает когда контроллер выставил бит CRC, те начало подсчета контрольной суммы. По записи УКНЦ ждет от контроллера 2 вещи, это бит индекса и бит начала подсчета контрольной суммы, они должны выставляться в правильное время, по ним УКНЦ синхронизирует вывод данных. Да, других бит, кроме бита готовности принять данные, контроллер во время записи выставлять не должен.

- - - Добавлено - - -

Думаю это не особенно важно, ловится же начало отверстия. У меня стоит константа в 150 байт:

У меня всего 10 байт.

- - - Добавлено - - -

Кстати, я переписал чтение под 36 байтный заголовок 4Е, читает нормально.

- - - Добавлено - - -

А еще, на моей УКНЦ почему-то зависает вот этот образ: mz80_UKNC_pafcom.dsk
Прямо на запуске аналога Нортон Коммандера, печально, а на эмуляторе ув. nzeemin, запускается, печаль

[Alex_K]

ZPilot, собственно я вижу, что вы приводили куски кода из моего труда о контроллере дисковода УКНЦ. Вроде там всё написано, как производится запись CRC. Во-первых сперва обратите на описание битов 7 и 14. Они разные для режимов чтения и записи. Т.е. существует два бита готовности и два бита CRC, одни для режима чтения, вторые для режима записи.
Обратите внимание, что существует регистр записи РДЗ (0177132) и сдвиговый регистр. Во время записи информация из РДЗ копируется в сдвиговый регистр, и собственно со сдвигового регистра она и уходит на линии DO для дисковода. Расчет CRC начинается с установки бита WM (9). При записи в РДЗ сбрасывается бит готовности TR (7). Как только сдвиговый регистр становится свободным, то в него копируется информация из РДЗ и снова устанавливается бит готовности для получения новых данных. Но информация с РДЗ копируется в сдвиговый только при сброшенном бите готовности. Если же в РДЗ ничего за 64 мкс не записали, т.е. бит готовности остался установленным, то тогда в сдвиговый регистр копируется не РДЗ, а рассчитанная CRC. После этого расчет CRC прекращается и контроллер устанавливает бит CRC (14), который говорит о том, что в данное время производится запись CRC. Но её прерывать нельзя. Для этого в РДЗ записывается 0x4E4E и ожидается установка бита готовности. Установленный бит готовности сообщает о том, что запись CRC закончилась и в сдвиговый регистр скопировался РДЗ. После этого можно перейти в режим чтения, прочитав регистр 0177132.

[ZPilot]

Но информация с РДЗ копируется в сдвиговый только при сброшенном бите готовности.

Я так понимаю, что сбрасывает бит готовности контроллер?

Для этого в РДЗ записывается 0x4E4E и ожидается установка бита готовности.

А это кто делает? Контроллер или УКНЦ?

[Alex_K]

Я так понимаю, что сбрасывает бит готовности контроллер?

А это кто делает? Контроллер или УКНЦ?

В режиме записи бит готовности сбрасывается при записи в регистр РДЗ 0177132, а устанавливается при копировании РДЗ в сдвиговый регистр.

[ZPilot]

Да, и я правильно понимаю, что записать CRC куда попало нельзя, она записывается точно в то место на диске/треке/секторе где должна быть?

- - - Добавлено - - -

устанавливается при копировании РДЗ в сдвиговый регистр.

Те когда контроллер считал данные из 177132?

[Alex_K]

Да, и я правильно понимаю, что записать CRC куда попало нельзя, оно записывается точно в то место на диске/треке/секторе где должна быть?

Да. CRC есть после заголовка сектора и после зоны данных.

- - - Добавлено - - -

Те когда контроллер считал данные из 177132?

Да.

[ZPilot]

И я вот думаю, смысла считать CRC нет, тк она в образ DSK не записывается, УКНЦ ее не отправляет контроллеру, а контроллеру после ее расчета сравнить ее правильность не с чем. Единственное место где она нужна, так это при чтнеии с диска, но у меня то образ.

- - - Добавлено - - -

Да. CRC есть после заголовка сектора и после зоны данных.

А значит, если я знаю где ее место, мне не важен бит WM (9). WM (9) не может быть установлен в середине сектора? Или может?