#29 не стработает, если в пред байте последние 2 бита были 00Цитата:
Сообщение от Dexus
Вид для печати
#29 не стработает, если в пред байте последние 2 бита были 00Цитата:
Сообщение от Dexus
Это не у Акробата проблемы, а у того, кто создавал PDF. У него есть стандарт и есть те, кто его не поддерживают (специально или случайно). Данный PDF действительно "пуст" если открывать в Акробате Х, но стоит открыть в том же FoxIt'е (который при этом безбожно тормозит и постоянно норовит закрыться) и напечатать в PDF (саму печать я совершал минут 5, т.к. на каждый чих FoxIt перерисовывает туеву хучу объектов этого PDF в масштабе 3%) как всё внезапно нормально работает в Акробат Х, ИЧСХ не тормозит (в отличии от FoxIt'а)!Цитата:
Сообщение от goodboy
https://jpegshare.net/images/a1/2e/a...d1fb1c5248.png
Если жуткие тормоза не считать проблемой, то да, все ОК.Цитата:
Сообщение от goodboy
PS Mozilla FireFox тоже открывает исходный PDF норм, только при увеличении все транзисторы сливаются. У Хромого так же?
https://jpegshare.net/images/74/21/7...86f6576314.png
- - - Добавлено - - -
PPS Пофикшеная версия PDF, если кому надо.
- - - Добавлено - - -
А вот это может быть интересным:
https://jpegshare.net/images/af/0c/a...915a34baca.png
https://jpegshare.net/images/97/94/9...101e9e52b9.png
И оба в режиме MFM.
Эти транзисторы в воздухе висят истоками? Т.е. их как бы и нет?Цитата:
Сообщение от HardWareMan
умные люди просили передать
" Умники там, пусть сделают в акробате pdf с линейными размерами как у этой схемы, там несколько метров ширина и высота. В pdf рестрикшены на размеры тянутся с древних времен и ни разу не актуальны, все нормальные вьюеры кроме акробата поддерживают любые размеры по x и y (больше тех что в pdf стандарте). У меня виндовый фоксит не тормозит, ну и акробат с таким числом объектов будет работать точно также, чудес то не бывает, линий там очень много. У чела возможно комп дохлый, на x64 никаких проблем с фокситом нету."
" со сбоем синхронизации существует 3 совершенно не связанные друг с другом проблемы. И каждый пытается доказать свой случай.
Первая проблема - это не уникальный маркер C2 (про который подробно и с картинками написано на сайте про atari), при этом даже если дорожка вся записана за 1 раз будет все равно сбой синхронизации, если такой битовый патерн со сдвигом на пол бита появится в данных. Синхронизация по C2 делается ТОЛЬКО командой чтения дорожки и только на ВГ93 (делается для того, чтобы при чтении дорожки байты от индексного отверстия до первого A1 читались нормально, а не мусором (когда вместо клоков отсеиваются биты данных, а с выхода сдвигового регистра вместо данных идут патерны клоков)).
Вторая проблема (присутствует и на ПЦ на i8272 (про то, что кононас писал, что такого на ПЦ не бывает)) - это проблема с записью секторов поверх отформатированных секторов, там из за непопадания точно в битовую ячейку может быть какой угодно сдвиг, для этого и вводятся GAP байты, но эти GAP байты будут читаться неправильно, т.к. команда чтения дорожки делает синхронизацию по A1 и по C2, а все что записано до A1 (не при форматировании, будет читаться в фазе от A1 предыдущего сектора и естественно может быть мусор, если при записи был сдвиг на пол бита).
Ну и третья проблема - не использование бита 13 в A1 и в C2 (но это может быть и не реальная проблема, а просто протравлено при снятии слоев кислотой, у меня есть только один набор фотографий, т.ч. сравнить не с чем (может еще и брак конкретно этого завода), и в импортной микросхеме WD1772 таких проблем нету, там декодер правильный и все биты используются).
Ну и таки MFM интервалы - это t, 1.5t и 2t (а не 2, 3 и 4)."
Бит 13 это правильно.
Пара бит 00 в пред байте + #29, дают сигнатуру #A1, если проигнорировать бит 13
Каким образом, цепочку всю можешь нарисовать? У меня никаким образом из #A1 не получается #29, ни в bin, ни в mfm, ни при каких сдвигах.Цитата:
Сообщение от s_kosorev
Ну это совсем несерьёзный пассаж. К чему тут эти терминологические занудства? При t=2 оно и получится 2 3 и 4, и выбраны они лишь для удобства показа mfm потока как строки.Цитата:
Сообщение от goodboy
Понятно. То есть недостоверно.Цитата:
Сообщение от goodboy
Но все-таки сбой с #29 существуют. И высказанные "объяснения" ничего толком не объясняют. Conan высказал что якобы FM ФАПЧ вторгается и переключает кодирование на FM. Каким образом? FM сигнатур-переключателей вроде не существует.
http://prntscr.com/p095w8Цитата:
Сообщение от Dexus
Чтобы это сработало не 13й бит должен игнорироваться а 12й. И #14 (1010100100010010) подходил бы еще лучше.
Ну это смотря как считать, с 0 или 1Цитата:
Сообщение от Dexus
По схеме там вообще 17 линий. И если считать с 1 (что неверно) этот висячий - 14й.