А Вы не могли бы дать ссылку на этот даташит?
А Вы не могли бы дать ссылку на этот даташит?
Если кто-то решит ковырять дальше - фотографии все еще там залиты, в том же месте, просто расширение сайта с .ru нужно .com сменить...
CodeMaster(01.08.2024), Titus(01.08.2024)
На каком этапе сейчас реверс ВГ93?
Потранзисторная схема есть, но нет описания и расшифровки, верно? Т.е. на этапе нескольколетней давности?
воз и ныне там. Olivier Galibert делал LLE симуляцию WD1772 по PLL, в его репозитории процесс встал года 4 назад, хотя в том году он говорил что вроде ковыряет его потихоньку
https://github.com/galibert/retrofpg.../master/wd1772
Titus(01.08.2024)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
да, 1772 чуть новее, но "схемы" этих чипов до боли похожи, да и в целом они из того же "семейства" FD1771/FD179x/WD177x. так что, при наличии симуляции чего-то одного допилить под чуть другую модель должно быть достаточно просто.
есть такая книжка от Western Digital с даташитами и мануалами по всему семейству FD17xx и не только
http://bitsavers.org/components/west...s_Handbook.pdf
Достал я из архива потранзисторный реверс от deathsoft'а, 2019 года, и там есть всякое интересное.
Может это уже обсуждалось, но, например, детекторы маркеров A1 и C2 имеют в себе ошибку (видимо, при клонировании ВГ93 с оригинального FD1793 ошиблись).
Из-за чего детекторы этих маркеров могут срабатывать не только на специальных синхропоследовательностях , у которых специально удален бит синхронизации, чтобы отличить их от данных. Но и могут сработать, если встретят комбинацию бит похожую на синхропоследовательность. Видимо, именно поэтому не работало чтение дорожки целиком, т.к. первый попавшийся байт похожий на синхропоследовательность сбивал синхронизацию.
Кстати, никто не в курсе, использовался ли на Спектруме в качестве защиты от копирования или в качестве нестандартного формата режим FM-модуляции? (по умолчанию мы все пишем в MFM)
мне как-то рассказывали, что ........
"Проблема в декодировании битов в байты, на этапе когда происходит
отбрасывание клоковых битов, (каждая mfm кодируется парой битов), так
вот, если происходит смещение на один бит из этой пары (на пол бита
данных), то вместо битов данных в байты начинают переводится биты клоков
и получается мусор. А проблема с C2 возникает из за того, что паттерн C2
при смещении на пол бита совпадает с паттерном данных типа 0x18 и т.п.
Более того, даже дорожка считанная в виде битового потока на амиге даст
такой же результат при декодировании (ели декодировать просто влоб путем
поиска маркерной последовательности). Ты можешь сам это легко проверить
взяв любой трэк считанный на амиге (там должно получится ~50000 бит, или
~100000 полубитов mfm) найти там 0x4489 (это маркер A1), а дальше
викинуть все четные биты (это клоки), в результате останутся только данные.
Более того, проблема усугубляется тем, что на ПЦ и спектруме дискеты
пишутся по секторам (а на амиге за один проход целиком), и между
заголовком сектора и зоной данные есть помехи, когда зона данных
записывается при "записи" (заголовок сектора формируется при
"форматировании" (записи дорожки)), т.к. невозможно точно попасть на
границу битовой ячейки.
Более того, судя по сканам кристалла ВГ93 даже декодер A1 использует не
все биты, (игнорируется бит 13, хотя может быть это просто баг при
стравливании маски).
При декодировании дорожек C2 вообще использовать не надо, надо делать
синхронизацию по A1 (0x4489), C2 этот непонятно зачем и для кого
записывается, он нигде не используется."
эта-же проблема есть и на WD1772
https://info-coach.fr/atari/hardware...c_Byte_Pattern
Эту тему просматривают: 7 (пользователей: 1 , гостей: 6)