Порты SMUC

Спасибо всем за ответы.
Хотелось бы отдельно поблагодарить Conanа за схемы - не думал даже, что у кого то они найдутся "живьем". Я так полагаю, у него материала на БСЭ (большую спектрумовскую энциклопедию) наберется:).

Что касается Романа, то также спасибо за ответы и ждем информации от МОА.

Теперь, что касается SMT.
Во-первых, спасибо за фрагмент драйвера RTC.
Во-вторых, что касается вопроса “кто контролирует i2c: аппаратно в альтере или программно спеком?”. Если есть схема под рукой, то такой вопрос не должен возникать.
Управление I2C-шиной производит непосредственно комп, путем записи/чтения соответствующих бит. Что в данном случае должна была делать альтера? Преобразовывать последовательный поток в параллельный и наоборот? Так как в альтеру заходит только 3 бита данных (D3,D6,D7), то вопрос отпадает сам собой.
Как видно из схемы раскладка порта #FFBA пока следующая (далее /w – запись в порт, /r – чтение из порта):
D0 - /w - RESET HDD/ISA; /r – нет.
D1 - /w - a7 ISA; /r – нет.
D2 - /w - a8 ISA; /r – нет.
D3 - /w - неизвестно; /r неизвестно.
D4 - /w - SDA OUT I2C; /r – нет.
D5 - /w - WR/RD I2C; /r – нет.
D6 - /w - неизвестно; /r неизвестно.
D7 - /w - вывод /DS MC146818; /r неизвестно.
Поскольку биты D3,D6,D7 заходят в альтеру, то через них может производится как запись, так и чтение информации. Итого осталось 5 неизвестных. Из них один бит чтения должен быть SDA IN I2C. Как происходит управление линией SCL пока остается под вопросом. Дело в том, что есть два варианта: путем установки/сброса бита в порту #FFBA (подходят только D3 и D6) и путем просто записи/чтения порта. Также остается открытым вопрос управления i8259.
В-третьих, что касается схемы включавшей HDD в любом режиме, то на сколько я помню “пробегала” информация, что типа лучше было бы отвязать SMUC от TR-DOS и для этого надо отрезать проводник сигнала /DOS и подать на него “землю”. В общем, как обычно “коряворукие доработчики” кидали идеи, которые, наверное, где-то и были воплощены. На оригинальной схеме это реализовать не удастся, поскольку сигнал /DOS заведен на дешифратор портов SMUC.
В-четвертых, что касается неполной дешифрации портов в SMUC – то я не согласен. Дело в том, что в Nemo-IDE порты изначально 8-битные и соответственно нет возможности их “закрепить” за 16-битные адреса, скажем если их привязать к портам FFxx жесткой дешифрацией, то драйвера не будут корректно работать. А вот у SMUC имеются “законные” адреса и при желании можно ввести полную дешифрацию.
В-пятых, что касается ряда проблем при инициализации "винта", то где то проходила инфа, что было бы рационально хранить установки "винта" в CMOS RTC, так вот Flash подходит для этого больше.
Ну и наконец в-шестых, подскажите, а где собственно искать “тему про скорпион-пзу”.

И еще люди, не в службу, а в дружбу подкорректируйте свои профели - ну хотябы год рождения. Ведь интересно же какой контенгент занимается Spectrum.

насчёт i2c уже понял. всё общение c NVRAM происходит через #FFBA, биты 4 и 6.

а почему не отвязать весь smuc от tr-dos, не только hdd?

Цитата:

---

Сообщение от spensor

подскажите, а где собственно искать “тему про скорпион-пзу”.

---

По всей видимости, речь шла вот об этом топике:

http://zx.pk.ru/showthread.php?t=25&page=1&pp=10

Спасибо за ссылку – почему-то этот топик я ранее проигнорировал, и поэтому задавал вопросы уже обсужденные там. Как вариант решения подобных проблем предлагаю вводить краткую аннотацию темы. В противном случае, получается "начали за здравие, а кончили за упокой".
Теперь вопрос к SMT - а собственно, какой бит за что отвечает, и какой на запись, а какой на чтение. Я так предполагаю, в порте #FFBA за I2С отвечают следующие разряды:
D4 - /w - SDA OUT I2C; /r – нет.
D5 - /w - WR/RD I2C; /r – нет.
D6 - /w - SCL OUT I2C; /r - SDA IN I2C.
Или быть может, я ошибаюсь?
А насчет отвязки SMUC от TR-DOS я не согласен. На спеке нет такой фичи как "обращение к процедурам BIOS через прерывания" и соответственно нет гарантии, что чья-то процедура не запишет на "винт" недопустимые значения. По серьезному неплохо было бы использовать прерывания профПЗУ - надежность работы устройства в этом случае была бы максимально-возможной, но даже использование "TR-DOS триггера" дает некоторые гарантии безопасности, например, если в случае какого-то сбоя приложение начнет писать во все порты отфонарные значения. Вспомните, как у некоторых повреждалась инфа на IS-DOS дисках из-за простых сбоев в программах.
Хотя возможно во мне говорит "железячник" - например, я не представляю на Спектруме многозадачность без аппаратного супервизора (по моему так называется фича следящая за доступом приложений к своим областям памяти).

пин SCL nvram-памяти работает только на ввод (шину i2c тактирует master).
read: D6: SDA (afaik, значимый только этот бит, остальные установлены в 1)
write: согласен с Вашим описанием.
увы, Кирилл Фролов давно не появлялся в форуме, а именно его подробную карту портов я недавно нагуглил:

Код:

---

Все сообщения из раздела
Сообщение 1 в разделе
От:Kirill Frolov (Kirill.Frolov@p2.f827.n5030.z2.fidonet.org)
Тема:SMUC неизвестные порты
View this article only
Группы новостей:fido7.real.speccy
Дата:2002-07-17 15:31:54 PST

Hемедленно нажми на RESET, All!
[...skip...]
  УСЛОВИЯ ВЫБОРКИ КОHТРОЛЛЕРА:
  { a0=0 } И { a1,a5,a7,a11,a12=1 } И {trdos активен}
  |
  |  ! АДРЕСА ISA-BUS:
  |  ! a8,a9,a10,a13,a14,a3,a4 isa/ide/pic address (A0-A6)
  |
  | +- a6=1 обращение к ISA слоту
  |  |  (!) ВЛИЯHИЕ a13 HА ЭТИ ПОРТЫ HЕИЗВЕСТHО!
  |  | +- a2=1
  |  |  |
  |  |  | +- a15=1  ??? (ISA A9 ?)  HЕИЗВЕСТHЫЙ РЕГИСТР
  |  |  |  | +- a13=1  ???
  |  |  |  |
  |  |  |  +- a13=0  ???
  |  |  |
  |  |  |
  |  |  +- a15=0 isa bus ports rw
  |  |      | isa address bits(A9-A0): (cp==control port bit)
  |  |      | { ? (0), cp.2, cp.1, a4, a3, a14, a13, a10, a9, a8 }
  |  |      |
  |  |      +- a13=1 ???
  |  |      |
  |  |      +- a13=0 ???
  |  |
  |  |
  |  +- a2=0 ???
  |      |
  |      +- a15=1 ??? HЕИЗВЕСТHЫЕ РЕГИСТРЫ
  |      |    |
  |      |    +- a13=1 ???
  |      |    |
  |      |    +- a13=1 ???
  |      |
  |      +- a15=0 ???
  |            |
  |            +- a13=1 ???
  |            |
  |            +- a13=0 ???
  |
  |
  +- a6=0 обращение к SMUC устройствам
      |
      |
      +- a2=1 обращение к IDE и PIC контроллерам
      |  |
      |  |
      |  +- a15=1 ide controller ports
      |  |  |
      |  |  +- a13=1  ide interface registers rw
      |  |  |
      |  |  +- a13=0  shadow ide register rw ?
      |  |
      |  |
      |  +- a15=0 interrupt controller register block rw
      |      |
      |      +- a13=1 <DEFAULT>
      |      |        ( каково влияние этого бита    )
      |      |        ( на работу SMUC и контроллера )
      |      +- a13=0 ( прерываний? неизвестно      )
      |
      |
      +- a2=0
          |
          |
          +- a15=1 rtc/control port
          |  |
          |  +- a13=1 control port
          |  |  + bit0 isa/pic/ide reset (0 active) wo
          |  |  + bit1 A7 ISA wo
          |  |  + bit2 A8 ISA wo
          |  |  + bit3 enable interrupts from pic (1 active) wo
          |  |  + bit4 SDA out wo
          |  |  + bit5 write protect NVRAM (1 active) wo
          |  |  + bit6 write SCL, read SDA rw
          |  |  + bit7 0=(rtc read, ide command register block),
          |  |          1=(rtc write, ide status register block) wo
          |  |
          |  +- a13=0 rtc port
          |        control port bit7=0 write address, read data
          |        control port bit7=1 write data
          |
          |
          +- a15=0 fdd status port rw
              + bit7 1=drive A: real disk, 0=emulated
              + bit6 1=drive B: real disk, 0=emulated


c2005Google

---

Цитата:

---

Сообщение от SMT

подробную карту портов я недавно нагуглил

---

Проанализировал вышеупомянутые данные, нашел одну неточность - возможно автор не имел под рукой схемы SMUCа - адресная линия A9 не изменяет своего значения (жестко висит на +5В).
Еще сварганил небольшую табличку, что-бы было видно на каких портах висят внутренние девайсы SMUCа.
Просьба к обладателям сего чуда техники, выяснить возможен ли доступ к второй "половине" регистров IDE. Автор раскладки предположил, что комбинация CS0(CS1)=1, CS1(CS3)=0 появиться если обратиться к портам IDE при a13=0 (shadow ide register rw). Тоесть надо считать данные из портов #D8BE-#DFBE. Если сказать более конкретно, то при наличии такой возможности, ситать удасться только порт #DEBE - альтернативный регистр состояния. С остальнами результат будет один и тот же - будет считано #FF, как при наличии, так и при отсутствии данной возможности. У кого есть реальное устройство, большая просьба проверить данное предположение.

Цитата:

---

Сообщение от spensor

скажем если их привязать к портам FFxx жесткой дешифрацией

---

ну блин, грубая дешифрация - плохо, подайте ить #FD,
неполная - опять плохо, давайте когонибудь куданибудь закрепим...
никто ничего закреплять не будет - есть реальный серийный РАБОТАЮЩИЙ девайс. и этот факт заявляет собой с ним мириться даже тем кому он не нравиться. хотя лично я проблем в такой дешифрации ВООБЩЕ не вижу. даже более того - вижу суперплюс - она позволяет писать более ***БЫСТРЫЙ*** драйвер!

Цитата:

---

Сообщение от spensor

Вспомните, как у некоторых повреждалась инфа на IS-DOS дисках из-за простых сбоев в программах

---

...не помню. что значит некоторых ? конкретнее надо быть в обвинениях.
и потом если машина сама на сотне проводков наладом дышит - чего ей бы не поглючить, причем тут сразу вдруг контроллер хдд?

Цитата:

---

Сообщение от spensor

возможно во мне говорит "железячник"

---

может быть...
однако пора там заговорить инженеру, для которого критерием является минимальное (простейшее) воплощение задачи (в данном случае иде-контроллера) в схемотехнике, а не "навороченность" из нагромождения кучи корпусов обвитых километрами проводов.

Цитата:

---

Сообщение от Ronin

лично я проблем в такой дешифрации ВООБЩЕ не вижу. даже более того - вижу суперплюс - она позволяет писать более ***БЫСТРЫЙ*** драйвер!

---

Быстрый драйвер? А как насчет поддержки старших процессоров линейки Z80. Туманная перспектива,согласен, но нафиг себе еще палки в колеса ставить. Ясно же, что команды работы с 8-битными портами прийдется упразнять, в противном случае, про перспективу можно забыть.

Цитата:

---

Сообщение от Ronin

...не помню. что значит некоторых ? конкретнее надо быть в обвинениях.и потом если машина сама на сотне проводков наладом дышит - чего ей бы не поглючить, причем тут сразу вдруг контроллер хдд?

---

Ты, думаешь, я могу вспомнить источник информации с которым я сталкивался лет 7 назад. А насчет "дохлых" проводников, согласен, это реалии и эти машины в работе. Нужны примеры - предоставлю. Я и не говорил, что виноват HDC. И поэтому нужно перестраховываться.
А "железячник" во мне правильно говорит - надежность, а не цена превыше всего. А "китайчатины", в которой половины компонентов нет, у нас и так предостаточно.

Цитата:

---

Сообщение от spensor

Как общеизвестно SMUC помимо IDE-адаптера (если кому угодно контроллера), содержал на "борту" также часики (CMOS RTC), адаптер ISA-шины, Serial Flash память (NVRAM) и контроллер прерываний i8259A. Вопрос в следующем – кто знает полную раскладку портов устройства?

---

Начинать надо с того, что SMUC, да и любое другое железо, адресуется
не "портами", а определёнными комбинациями сигналов ША и некоторых
других. Это принципиальный момент.

http://groups-beta.google.com/group/...3f020858053fc8
http://groups-beta.google.com/group/...58ab1899a1ed7e
http://groups-beta.google.com/group/...4240c5cee111de

Цитата:

---

Сообщение от spensor

1. Обращение к IDE происходит только через 8 портов (#xxВЕ). В других адаптерах 16 портов. Достаточно ли 8 портов для полноценной работы с IDE?

---

http://www.ata-atapi.com