Код:
Spensor: А кому оно (SMUC) надо? Желающих это иметь 1,5 человека, не считая меня...
Trident: Всем надо. Оно никому не надо пока его нет, по крайней мере, пока нет доступной схемы в плане повторения (не на экзотике как оригинал). Нет распространенной железки - нет много софта под неё. Нет много софта под неё - нет особой надобности. Надеюсь, цепочка понятна?
Trident: И потом, почему все воспринимают SMUC как очередной IDE контроллер?! И без конца сравнивают с NEMO IDE?! NEMO IDE это всего-навсего банальный 16-ти разрядный порт для связи с внутренним контроллером HDD и все! SMUC же представляет собой намного более мощное устройство... У меня складывается впечатление, что большинство людей вообще весьма смутно представляют предмет разговора и соответственно ценность данной разработки оценить не в состоянии, отсюда и такая вялая заинтересованность...
Spensor: В сущности такое сравнение недалеко от истины, по той причине, что в настоящее время основное применение SMUC состоит именно в работе с IDE-устройствами. Подсистема работы с виртуальными дисководами не востребована,
Trident: Востребована, просто она реализована через одно место…Неудобно.
Spensor: по той причине, что работа идет только через #3D13 (#3D2F не обрабатывается),
Trident: По идее, оно и должно так быть. Чтобы поддержать #3D2F придется эмулировать ВГ93, а это уже слишком... К тому же Максогор сказал, что на практике оказалось невозможным сымитировать ВГ при работе с винчестера. Поэтому в ATMке это делается с RAM-диска, который практически всю память и занимает.
Spensor: да и собственная файловая система несет некоторые проблемы - на PC TRD-образы на такой HDD не насыплешь.
Trident: Ну о файловой системе разговор особый…
Spensor: Есть такой вопрос - а ты когда-нибудь видел SMUC, который бы показывал версию 1.2?
Trident: Нет.
Spensor: Используется ли бит D3 порта #7FBA? Надо прочесть состояние бита, записав в этот же порт число с обнуленным битом 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? Надо в этот порт послать число с установленным битом D7 и проверить уровни сигналов на CS0 и CS1 (выводы 37 и 38 разъема IDE соответственно).
Trident: Провел тут ряд экспериментов, как с реалом, так и с эмулем, выяснилось следующее - бит 7 системного регистра SMUC имеет двойное назначение:
1. он управляет сигналом RD/WR микросхемы CMOS;
2. он действительно переключает регистры HDD!
Но! 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? Если да, то за что они отвечают? Надо почитать этот порт, заземлив вывод IRQ разъема IDE (вывод 31), не подключая HDD.
Trident: Насчет чтения бита 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 перекрывают друг друга. Как оно тогда работает?..
Переписка с Trident
Ответить с цитированием