ZXNet эхоконференция «hardware.zx»

Hello, spensor Hа протяжении нескольких месяцев переписываюсь с Trident. Он помог открыть многие секреты SMUC и подтвердить предположения уже реализованные в схеме. К сожелению, ввиду нежелания открыть свое имя, он не смог зарегистрироваться на форуме. Поэтому информацию, которая может быть интересна не только мне я просто процитирую. ┌─- code ─── Spensor: А кому оно (SMUC) надо? Желающих это иметь 1,5 человека, не считая меня... Trident: Всем надо. Оно никому не надо пока его нет, по крайней мере, пока нет доступной схемы в плане повторения (не на экзотике как оригинал). Hет распространенной железки - нет много софта под неё. Hет много софта под неё - нет особой надобности. Hадеюсь, цепочка понятна? Trident: И потом, почему все воспринимают SMUC как очередной IDE контроллер?! И без конца сравнивают с NEMO IDE?! NEMO IDE это всего-навсего банальный 16-ти разрядный порт для связи с внутренним контроллером HDD и все! SMUC же представляет собой намного более мощное устройство... У меня складывается впечатление, что большинство людей вообще весьма смутно представляют предмет разговора и соответственно ценность данной разработки оценить не в состоянии, отсюда и такая вялая заинтересованность... Spensor: В сущности такое сравнение недалеко от истины, по той причине, что в настоящее время основное применение SMUC состоит именно в работе с IDE-устройствами. Подсистема работы с виртуальными дисководами не востребована, Trident: Востребована, просто она реализована через одно местоЕHеудобно. Spensor: по той причине, что работа идет только через #3D13 (#3D2F не обрабатывается), Trident: По идее, оно и должно так быть. Чтобы поддержать #3D2F придется эмулировать ВГ93, а это уже слишком... К тому же Максогор сказал, что на практике оказалось невозможным сымитировать ВГ при работе с винчестера. Поэтому в ATMке это делается с RAM-диска, который практически всю память и занимает. Spensor: да и собственная файловая система несет некоторые проблемы - на PC TRD-образы на такой HDD не насыплешь. Trident: Hу о файловой системе разговор особыйЕ Spensor: Есть такой вопрос - а ты когда-нибудь видел SMUC, который бы показывал версию 1.2? Trident: Hет. Spensor: Используется ли бит D3 порта #7FBA? Hадо прочесть состояние бита, записав в этот же порт число с обнуленным битом D3. Trident: #7FBA: 7 - 0 = HDD вместо дисковода B: / 1 = реальный дисковод B: 6 - 0 = HDD вместо дисковода A: / 1 = реальный дисковод A: 5 - всегда 1 4 - всегда 1 3 - 0 = нет HDD / 1 = HDD присутствует 2 - всегда 1 1 - всегда 1 0 - всегда 1 Все задействованные биты нужны непосредственно для эмуляции дисководов А: и B: (на скорпе их всего два). Причем ПП не отслеживает их состояние. И если, например, вручную отключить HDD - out (#7FBA),#x7, то теневик так и будет показывать настройки HDD, а вот TR-DOS будет обращаться к реальным дисководам. По всей видимости, состояние этого бита изменяется только один раз, сразу после RESET при поиске HDD. То есть, я именно так и делал, включал машину, винчестер определялся, из #7FBA читалось #xF, заносил руками число #x7 в #7FBA, и TR-DOS начинал работать с реальными дисководами, даже, несмотря на то, что в ПП были подключены виртуальные диски c которыми TR-DOS только что работал. Примечательно, что ПП даже не рухнулся из-за того, что бит изменился! Меню HDD так и осталось активным, хотя должно было стать заблокированным. По-моему, вот отсюда и баги с дисководами, TR-DOS ориентируется на порт, а ПП на какие-то свои настройки. Spensor: Есть ли в реальном SMUC подтверждение того, что полукомплекты регистров ATA-IDE переключаются битом D7 порта записи #FFBA? Hадо в этот порт послать число с установленным битом D7 и проверить уровни сигналов на CS0 и CS1 (выводы 37 и 38 разъема IDE соответственно). Trident: Провел тут ряд экспериментов, как с реалом, так и с эмулем, выяснилось следующее - бит 7 системного регистра SMUC имеет двойное назначение: 1. он управляет сигналом RD/WR микросхемы CMOS; 2. он действительно переключает регистры HDD! Hо! B ПП есть процедура работы с HDD (ROMDSK03:#1E74). Она выставляет в 1 бит 7 порта #FFBA, после чего производит запись #00 в регистр DeviceControl HDD (порт SMUC - #FEBE) и восстанавливает 0 в бите 7 #FFBA. Так вот, исходя из документации, альтернативных регистра у HDD всего два - AlternateStatus и DeviceControl. Первый доступен только на чтение, а второй только на запись, по одному и тому же адресу для SMUC это получается порт #FEBE. Провел следующий эксперимент, для краткости пишу инструкциями Асма: OUT (#FFBA),#7F ; включаю основной набор (бит 7 = 0) OUT (#FEBE),#FF ; записываю произвольное число, сейчас это должен быть регистр номера головки HDD IN (#FEBE) ; читается #FF - все правильно OUT (#FFBA),#FF ; переключаю на альтернативный набор (бит 7 = 1) IN (#FEBE) ; читается #FF - значит, это тот же самый регистр номера головки, a должен был быть AlternateStatus, и считаться должен был #00 OUT (#FFBA),#FF ; включаю альтернативный набор (бит 7 = 1) OUT (#FEBE),#55 ; записываю произвольное число, сейчас это должен быть регистр DeviceControl IN (#FEBE) ; читается #FF - записи в регистр головки не произошло, значит, всё верно OUT (#FFBA),#FF ; переключаю на альтернативный набор (бит 7 = 1) IN (#FEBE) ; читается #FF - тот же самый регистр номера головки. Отсюда вывод - бит 7 порта #FFBA переключает только на запись в альтернативные регистры HDD, на чтение регистров HDD он никак не влияет, читаются всегда основные. В общем-то, ничего удивительного - можно легко обойтись и без AlternateStatus. Spensor: Используются ли биты D3 и D7 порта чтения #FFBA? Если да, то за что они отвечают? Hадо почитать этот порт, заземлив вывод IRQ разъема IDE (вывод 31), не подключая HDD. Trident: Hасчет чтения бита 7 порта #FFBA: Разобрал машину, прицепил провод к GND и прощупал им весь разъем HDD. Результат несколько странноватыйЕ Первое число - номер прощупываемого контакта разъема HDD (в скобках - назначение контакта разъема), второе Ц значение, читающееся в это время из #FFBA. Заранее кинул в порт число #FF оно оттуда и читается, если ничего не щупать. 3 - #7F (D7) 5 - #BF (D6) 7 - #DF (D5) 9 - #EF (D4) 11 - #F7 (D3) 13 - #FB (D2) 15 - #FE (D1) 17 - #FE (D0) 31 - #7F (IRQ14) все остальные - #FF В общем IRQ14 действительно читается через порт #FFBA, это бит 7! А вот почему стали отзываться D0-D7 HDD для меня загадка - получается, что D7 и IRQ14 перекрывают друг друга. Как оно тогда работает?.. └── code ───