Дискеты УКНЦ

[anasana]

кстати, а всё-таки, в чем-то есть прикол, что продолжая движение диска и заходя на второй круг первый сектор так же не ловится.
у меня юзается две функции, одна запрашивает только один сектор но с "ретраями", вторая типа читает всю дорожку (но обе через вызов IOCTL_FDCMD_READ_DATA). так вот дорожкой практически всегда читается, а вот у той же дискеты посектроно первый сектор "прицельно" не хочет считываться. возможно при попытке чтении трека первый сектор во втором круге сектор физически проходит уже под головой целиком, а распознование потока mfm продолжается в реалтайме, да и порядок секторов следования контроллеру безразличен. надо будет больше поэкспериментировать...

[Advertiser]

[SuperMax]

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

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

на самой УКНЦ тк там 128ая можно съесть сырой поток данных, может и на PC тоже можно считать дорожку в сыром виде и потом уже разобрать ?

[anasana]

на самой УКНЦ тк там 128ая можно съесть сырой поток данных, может и на PC тоже можно считать дорожку в сыром виде и потом уже разобрать ?

У меня, то что возвращает драйвер, по команде чтения сырых данных (уже байты, не mfm) дорожки по IOCTL_FD_RAW_READ_TRACK и с однодисководным и с двудисководным (при поддержке материнкой тогда читается и заголовок первого сектора, а не только его данные) вариантом чтения всегда всё начиналось с района индексного отверстия, а не с любого произвольного места на дискете (зато если запросить больше данных чем явно хранится на треке то она продолжает чтение и при движении головы на втором кругу после индексного отверстия). Ну и у меня только обычные дискетки были, которые без защит чтения и заголовок дорожки там штатно тоже возле индексного находится.
Вот, @Radon17 был удачно скопировал дискетку, из которой я оставил себе пару "показательных" треков без срыва синхронизации:
https://www.dropbox.com/s/meggbbu9f0...don17.zip?dl=0
Плюс там ещё наглядно оказалось, что прога-форматировщик заполняла себе особую инфу в каждом секторе (считывалось на РС в однодисководном режиме, заголовок у самого первого сектора не может быть захвачен).
(прога себе нумерует текстом сектора начиная с нуля, поэтому десять секторов МС-0515 там выглядят как 0...9). Зато, между 512-байтовым текстовым содержимым, четко сохранилась вся межсекторная кухня в бинарном виде, прямо как по классическому описанию формата дискеты: skipped{512b sector data}[CRC сектора 1]{4E} | {00}[A1A1A1]{FE}{...}[A1A1A1]{FB}{512b sector data}[CRC сектора 2]{4E} | ...).
Можно ещё увидеть:
В mihinRadon0515_rawtrack_Head0_Track0.dat, что в RAW после штатного считывания 0...9 на втором кругу по дорожке снова захватываются сектора 0-1-2-3 (и можно и дальше позахватывать).
В mihinRadon0515_rawtrack_Head0_Track79.dat - по окончании последнего гапа поток срывается и во втором кругу уже начинается "мусор".
(в конце файлов добавлены списоком сектора у которых служебные данные о них цапнулись вообще в идеале.)