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 ───