Полигон-2

В давние времена как-то стороной прошла для меня тема Электроники-60, ДВК и прочих СМ. Не то, чтобы совсем стороной, нет, даже плату двойного размера в корзину конструировал и изготавливал, но в те времена 8-битные огрызки почему-то весь интерес переключили на себя. Похоже, что там просто потенциальный барьер вхождения банально ниже. Время прошло, а пробел остался. Поэтому долго вынашивал идею сконструировать что-нибудь на чем-нибудь из ряда 1801ВМ1/2/3. Гонял их всех на стенде, смотрел временные диаграммы, примеривал разную периферию, контроллеры памяти типа 1810ВТ3, 588ВГ2, разное из серии 1801ВП1. Выжать максимум быстродействия и максимум размера памяти - такой задачи не стояло, цель была сделать что-то более-менее сбалансированное, гармоничное, показательное и не потерявшее духа архитектуры PDP-11. В конце концов выбор остановился на 1801ВМ1. Он не провоцирует на извращения, и если не мудрить и согласиться с предлагаемой им концепцией, то, как мне показалось, он вполне сможет за это отблагодарить.

У ВМ1 существует не так явно выраженная привязка к внешним средствам обеспечения его полноценного функционирования. Причем привязка плотная. В простом изделии эту привязку можно было бы игнорировать, но это вызвало бы ограничения и условности при программировании, а мне подобные ограничения не нравятся: команда у процессора есть, а в программе ее применять нельзя. После размышлений, экспериментов и прикидок того, как оно в результате будет выглядеть целиком, принял решение использовать контроллер ОЗУ 1801ВП1-030 с совмещенными функциями системного контроллера: он как раз предоставляет те самые внешние средства и обладает приемлемым для 1801ВМ1 временем отклика на обращение к ОЗУ. К тому же было желание сделать накопитель ОЗУ на 565РУ3. Таким образом, обозначилось ядро процессора, состоящее из 1801ВМ1, 1801ВП1-030 и ПЗУ 573РФ3 или 1801РР1. Для завершения картины к этому набору нужно добавить ОЗУ с ее буферными регистрами, в результате получается модуль, имеющий интерфейсом только шину МПИ. У такого модуля достаточно плотная топология электрических соединений, в одну шину не вытягивается из-за универсальности ВП1-030 и клубка вокруг ОЗУ. В одноплатной реализации трудно обеспечить компактность модуля, небольшие емкости шин и длины трассировки. Поэтому я сделал этажерку из 4 плат 100x80. Одна плата это процессорное ядро из 3-х БИС с мелкой логикой. На ней расположен наружний разъем МПИ и разъемы присоединения накопителя ОЗУ: AD0-AD15, мультиплексная адресная шина, управление, питание. Вторая плата это буферы данных-адреса-управление ОЗУ, две остальных - половинки накопителя по 16 к слов каждая.

Никаких усилителей внешней шины не применяется, выходы МОПовских микросхем присоединяются к ней непосредственно, это очень нехорошо, но для разового проекта индивидуального пользования пойдет, если никому не позволять хватать руками.

Карта памяти следующая, вопреки обычаям, ОЗУ в режиме USER сделано большего размера:

USER
000000 .. 172776 ОЗУ (30.75 к слов)

HALT
000000 .. 157776 ОЗУ (28 к слов)
160000 .. 163776 ПЗУ ODT (1 к слов)
164000 .. 172776 ПЗУ с утилитами/тестами или ОЗУ (1.75 к слов)

Верхняя область, одинаковая для обоих режимов
173000 .. 173776 ПЗУ загрузчика (256 слов)
174000 .. 177576 Регистры ВУ (960 слов)
177600 .. 177676 Служебное ОЗУ (32 слова)
177700 .. 177776 Регистры для нужд процессора (32 слова)

Сейчас изготовлено 4 платы, спаял две, ядро процессора и буферы ОЗУ. На время отладки хочу вместо РУ3 поставить РУ6, давным-давно был печальный опыт с выгоранием множества РУ3, когда пропало напряжение питания подложки.

ODT aka Пульт при запуске у меня ОЗУ вначале не использует, сперва проверяет наличие регистра терминала, потом вычисляет контрольную сумму области ПЗУ ODT, сравнивает ее с эталоном, выдает на терминал результат проверки, потом проверяет наличие работающего ОЗУ в служебной области, выдает на терминал результат проверки и только после этого запускается пульт. Если что-то из этого не проходит, то программа сваливается в бесконечное чтение SEL2 в цикле. Это чтобы можно было осциллографом смотреть импульсы на SEL2.

Вчера на макетную плату поставил 1801ВП1-065, вывел ее шиной на разъем МПИ процессорного модуля, подсоединил щуп осциллографа к ноге TF -065, включил и увидел на экране телеграфную посылку. Порасшифровывал, первые два символа CR LF, все так и должно быть. Хм, с первого раза увидеть телеграфную посылку, нечасто случается. То есть, регистры откликаются, содержимое читается, нужные данные пишутся и отсылаются.
Или это знак?

Теперь надо на макетку поставить преобразователь в уровни RS232, на плату напаять хотя бы старшую половину накопителя ОЗУ и включить еще раз, уже с присоединенным настоящим терминалом.

Оказывается, 1801ВП1-065 шлет символ с двумя стоповыми битами. Значит, у терминала тоже нужно будет сделать формат посылки с двумя стопами. На 10% хуже, чем с одним стопом, но тут ничего не поделаешь.

Продолжение следует ... По мере продвижения ...

Mixa написал:

[q]

Оказывается, 1801ВП1-065 шлет символ с двумя стоповыми битами.

[/q]

Это задаётся коммутацией её 7й ножки.

_Patron_, вот у меня на работе отечественные гибридки-драйверы rs232 при одностороннем сигнале, укладывающемся по максимуму в 3..15в, в break встают до резета, после первого же возврата с +15..3 к нулю и обратно к +3..15, без перехода к отрицательному напряжению в линии... Не надо так народ развращать...

Прошу прощения за оффтоп, но 2Anonymos - можно обнародовать название гибридок?

Присоединил DB-9. _Patron_, спасибо за подсказку, так и решил пока на макетке ТТЛ-овскими уровнями обойтись. (Но я так никогда не делаю, ни-ни, вы не подумайте!!). Это же не навсегда, только для макетки и отладки, цифровые боги, наверное, не возмутятся, в конечном варианте все будет с нормальными уровнями. Тем более диодики из 60-х, спаянные с ТЭЗов какой-то ЭВМ.
Даже инверторы не потребовались, полярность сигналов у ВП1-065 уже в нужной ориентации.
Макетку использовал ту, про которую давным-давно упоминал тут на форуме
(почти 3 с половиной года назад это было, но нам же не к спеху, правда? )

На передачу поставил резистор 1 кОм, на прием тоже 1 кОм, но с ограничением диодами в пределах от 0 до питания. Вполне себе и конвертером распознается, и 065-ой принимается. (по крайней мере RR нога 31 взводится при нажатии клавиши терминала).
Наблюдал сегодня живые сообщения от программы начального пуска
Пока что это выглядит неказисто, извините за отсутствие художественности. Но оно реально шевелится! Дальше - напаивать РУшки и собирать этажерку.


Anonymous, 7-я нога у меня к +5 подтянута, но говорят, она заведует форматом 7 или 8 бит. Я попробую его переключить на землю, расскажу, что получится. Vslav здесь утверждает, что стопов всегда два.

MC68k, да, речь как раз про границу 80-х и 90-х, было иное мировосприятие.
Размер плат из Eagle перешел. Схему рисовал там, начал предварительно размещать - а размерчик что надо, ну и оставил.
С этажеркой покруче будет, это тяжелое наследие прошлого тяжелого наследия. Вторая самоделка была по мотивам Микро-80, в ней тоже разнес управление накопителем и накопитель по разным платам (кстати, именно там РУ3 массово пожег). Но там не этажерка была, а лишние сигналы на общем разъеме. Сейчас КМК симпатичнее вышло. Но - рановато об этом, надо, чтоб оно зашевелилось дальше. Выложился с неоконченным изделием, в том числе, чтобы и подстегнуть себя чуть-чуть.
Полностью выкладывать проект - ну кому нужен сплошной нестандарт, у меня, вон, шина на МРН-44 разведена. А так, секретов нет.

Да, я уже позабывал все эти ВП1, у 35 5/7/8 бит 7 и 8 ноги делали, у 65 только 7 ногу оставили.

Mixa написал:

[q]

В свое время штук 5 или 6 раздобыл, но они преподнесли неприятный сюрприз

[/q]

Так у вас не РФ3, а РФ32, судя по фото, а они заведомо битые, для того и такая маркировка.

Интересно, базовый адрес микросхем РФ3 после программирования можно стереть ультрафиолетом и запрограммировать на другой?

Mixa написал:

[q]

Че дальше-то делать?

[/q]

Можно загрузить RT-11 через терминальный порт и позапускать всякие программы.

Был один пунктик концепции - схема без косяков и как следствие, плата без исправлений. Не срослось. Поменялось на: исправления - минимальные, малозаметные и красивые схемотехнически и логически.
Исправлял привязку RPLY к фазам тактирования. Был косяк непростительный. Решил, что оптимальным вариантом будет привязка в середине каждого полутакта CLK. Распространение получила привязка активации RPLY к спаду CLK, чтобы быть зафиксированной по фронту CLK. Привязка в середине каждого полутакта обеспечивает положение фазированного RPLY к тому же фронту CLK, при этом исходное RPLY может даже на четверть такта запоздать. Это определенно положительный момент.
Фазировка деактивации RPLY приводит к задержке RPLY процессору, что может привести к задержке снятия SYNC, но не более, чем на 1 такт. Практика показала, что такая вариация снятия SYNC в целом не влияет на длительность цикла шины.
(И чего я к этим тактам привязываюсь? Тяжелое наследие простейших синхронных шин и идиосинкразия к сигналу типа READY, в стиле READY - для слабаков! Не, надо быть выше этого)

Да, все-таки проводное ИЛИ RPLY красиво логически, красиво схемотехнически, но тяжеловесно физически. Но, что поделаешь, придется принять как есть.
Размазанную было концепцию фиксируем как: шина МПИ, слаботочная, асинхронная. И на этом расслабляемся. Недостатки получаем в довесок, но не ропщем, не жалуемся, принимаем стоически ради логической и схемотехнической лаконичности.

Venya_Fox написал:

[q]

5559ИН** какая нибудь? На них инфа открыта же

[/q]

Нет, со штатными горя нахлебались, на упомянутые выше - серии нет, только шифр КБ, заказ мелкосерийный.

Вообще-то ориентация буфера управляющих сигналов меняется по SACK и ВТ2 в любом случае изолирован от внешних RPLY, пока не захватит шину. T.к. до тех пор, пока не появится SACK, как реакция на DMGO, SYNC/DIN/DOUT/WTBT являются входными сигналами для платы, а RPLY - выходным.

Так оно ж идеологически так должно быть. Пассивное устройство от принимает сигналы от активного.
Как вы планировали рулить направлением SYNC, DIN, DOUT? Вот так же надо завязать и RPLY.

Mixa написал:

[q]

Пока никак не планировал, не было нужды.

[/q]

Во все моменты времени, пока некая плата не хочет ПДП, сигналы SYNC, DIN, DOUT являются для неё входными, а RPLY выходным.
Таким образом плата не видит чужих RPLY.
А во время захвата шины направление сигналов меняется на противополоное.
Т.е. какое то разделение должно быть. Не может вход микросхемы резко стать выходом

andyTh написал:

[q]

Во все моменты времени, пока некая плата не хочет ПДП, сигналы SYNC, DIN, DOUT являются для неё входными, а RPLY выходным.
Таким образом плата не видит чужих RPLY.
А во время захвата шины направление сигналов меняется на противополоное.
Т.е. какое то разделение должно быть. Не может вход микросхемы резко стать выходом

[/q]

Здесь ключевое слово "плата"
Поначалу концепция представлялась как набор маленьких-маленьких плат, которые вставляются в маленькую-маленькую корзину, на разъемах разведена МПИ, платы функционально разделены, а специального умощнения не делается, потому что все маленькое и несерьезное. Заложился на нагрузочную способность самих микросхем.
То есть, плата процессора, плата памяти, плата ИРПС, плата с КПДП и IDE, плата еще чего-нибудь. ИРПС в такой концепции это ВП1-035/065, с незначительной обвязкой.
588ВТ2 тоже более-менее в концепцию ложился (только АД нужно инвертировать), и направлением своих сигналов сам управляет.
По мере реализации оказалось, что процессор, контроллер ПЗУ и ОЗУ неразделимы, в связке, кроме МПИ, много других сигналов, которые на разъеме не нужны. Поэтому возникла этажерка.
Сейчас вот вырисовывается, что ВТ2 и всю 588-ю компанию нужно за забор поместить. И это даже хорошо, потому что глядя на пологость некоторых фронтов (которые ОК или ОС), хочется сказать стоп, шина почти на пределе.

Anonymous написал:

[q]

Точно так, как и процессор - ждут какое-то время ответа, затем выставляют флаг ошибки шины в регистре состояния, при этом замораживается счётчик адреса и переданных слов, чтоб можно было понять, на чём мы остановились, шина возвращается процессору и дёргается прерывание от устройства.

[/q]

Я вот еще хочу запретить КПДП обращаться по шине к пространству УВВ. То есть всякий select УВВ разрешить, если активен BSY процессора (или неактивен SACK).

У 588ВТ2 есть вход ошибки. Импульс на нем завершает текущую пересылку, вырабатывается аппаратное прерывание и взводится триггер ошибки, его значение читается битом 14 в регистре состояния. Вот туда можно завести ошибку таймаута на шине.
Еще один вход есть, RQINT называется, "Запрос прерывания". Низкий активный уровень на нем завершает текущую пересылку, вырабатывается аппаратное прерывание. Пока уровень низкий, он читается единицей в бите 13 регистра состояния. Причем еще есть бит 15, который читается как ИЛИ битов 13 и 14.
Интересно, какое прерывание имели в виду разработчики этой микросхемы?

P.S. ВТ2 вырабатывает аппаратное прерывание по окончании пересылки блока, но между этим настоящим прерыванием и тем RQINT никакой связи не обнаружилось.
P.P.S. Постскриптум не читать, это была старая, древняя инфа, сейчас провел эксперимент и был приятно удивлен тем, что на ER и на RQINT есть вполне симпатичная и полезная реакция. Текст выше — исправил.

Постом выше описывал поведение ВТ2 по памяти, по прошлым экспериментам. Но тогда стенд менее совершенен был, видимо, что-то упустил. Сейчас оно оно куда лучше оказалось. Сообщение исправил.

Думал, пришел к заключению, что RQINT ВТ2 это требование прекратить передачу блока, исходящее от внешнего устройства, которое обнаружило, что что-то пошло не так. Другими словами, это сигнал от устройства, возникший во время передачи блока и служащий для аварийного завершения передачи блока. В логику IDE это не укладывается, поэтому оставлю незадействованной эту полезную фичу.
ПДП для IDE обслуживает не устройство, а буфер. При обмене с буфером прерываний не возникает. Ошибок тоже. В смысле, никаких флагов, индикаторов и т.п. во время обмена с буфером нету. А прерывание от устройства, ошибки устройства у IDE обслуживаются по другим каналам, не связанным с ПДП.
Пока как-то так.

Mixa написал:

[q]

2 ячейки для IDE я тоже считаю перебором

[/q]

Для ДВК без специализированных контроллеров типовым следует считать адреса Самарского IDE + 100 ( 8 ) :
177720....177757 с словной выборкой.
ПЗУ Самары не сложно пропатчить для новых адресов.
В оригинале на адресах Самарского IDE сидят регистры 1801ВМ3.
Драйвер использовать от БК11М BY.SYS, начальная загрузка - 160000G.
Приводы 0 и 1 - флоп. Большие номера - винт.
ТО Самарского IDE :
http://zx-pk.ru/threads/26264-...-nemu.html
Специфический софт для работы с IDE, очевидно, надо адаптировать под RT-11 ( т.е. косметический патч ).

Mixa написал:

[q]

Сколько вообще ячеек позволительно контроллеру НЖМД иметь, чтоб по совести было, и никто на него косо не смотрел и не завидовал?

[/q]

Сколько надо, столько и задействуйте, сейчас конкуренции на рынке нет и никто 100500 контроллеров разных устройств не поставит в одну машину.
У меня в контроллере PATA IDE 10 слов используются для доступа к регистрам диска, 1 слово для доступа к наплатному микроконтроллеру и часам, 31 слово - на пзу загрузчика, зато просто и прозрачно.
А в контроллере scsi имеется 37 регистров, но доступ к ним организован по указателю на регистровый файл, в результате контроллер более правильный и занимает всего 4 слова в адресном пространстве.
Думаю, 512ВИ1 следует тоже по принципу ПЦшки подключить, задействовав регистр-указатель адреса и регистр данных.
p.s. я это к тому, что 4к слов на ввод-вывод у pdp-11 не позволяет быть столь расточительным, как в х86, где 64кб на ввод-вывод отведено, но и на ПиСи экономят по возможности на количестве адресов в/в.
p.p.s а вот контроллер ethernetа под МПИ вовсе 2 слова занимает, хотя использует здоровенные структуры в памяти.

К воронежцам или к дековцам?

Mixa написал:

[q]

К воронежцам или к дековцам?

[/q]

К воронежцам. Настороженное. Заочное. Вот лежит в коробочке 1807ВМ1, вроде симпатичный зверек, но что-то останавливает. Это что-то — иррациональное. Собственно, как и все, что здесь на форуме. Кроме продаж.
Кстати, справедливости ради, конкретно в 1807ВМ1 дополнительно останавливает и идея, идущая от дека, именно - программирование режима работы при начальном старте.
И 1804 как по маслу воспринимался только при чтении Мик-Брик. Запоем и не оторваться.
И 531 серия печка и жрет. Хотя как имеющая в своем составе ГГ1 или как ЛН1/ЛА3 для генератора на 32 МГц - полезна.

Anonymous написал:

[q]

сделайте контроллер i2c

[/q]

Перавя реакция — не, максимум, что позволительно это 1556Х[Л,П] и 556РТ1. Вторая мысль - он же прост, сдвиговый регистр и обвязка. Посмотрел, когда он был придуман, - в начале 80-х, годится. Надо подумать, мысль интересная.

Это все так. Но от дека у меня есть AlphaStation 255, и я ее берегу как экспонат. Alpha - событие знаковое. 1804, хоть она и из Воронежа, у меня проходит по категории AMD. Электронику-60 экспонатом не хочу. Она большая, глючная, и вентиляторами дребезжит, такой характерный рокочуще-звенящий звук, ну знаете, его невозможно не знать. А вокруг дека легенда, аура и восторги. Я не фанат, восторга поиметь не случилось, но к легенде прикоснуться и любопытно, и хочется. Через ангстрем и интеграл с транзистором прикасаться, как по мне, вполне годится. Не глючит и не дребезжит.
Не, мож я конечно не с той стороны к деку захожу, но что уж есть, то есть.

В общем, с 512ВИ1 решил пока повременить. Было бы, конечно, логично поместить ее на шину с прямыми АД, которая необходима для 588-й серии и из-за этого как бы уже есть и типа бесплатно. Но она концептуально чужая на плате IDE, хоть и тоже из Минска. Земляки земляками, а дело делом. К тому же, плата маленькая. И еще, сейчас связующая логика достаточно внятна по своей структуре и хорошо впихивается в ХП4. ВИ1 вносит навороченность, которую хочется избежать. Так что, RTC окладываются, но не исключаются.

Шесть линий CS селектора УВВ 588ВТ1 используются для выбора:
IDE CS0
IDE CS1
КПДП 588ВТ2
Регистр RA контроллера прерываний 588ВН1
Регистр RB контроллера прерываний 588ВН1
Регистр RS контроллера прерываний 588ВН1

При этом занято 16 ячеек пространства УВВ, 8 для IDE CS0, 2 для IDE CS1, 3 для 588ВТ2 и по одной на каждый регистр 588ВН1. Ровно 16. И это единый блок, при адресации меняются только АД4..АД1.
Вот такое хитрое преобразование адресов будет, чтоб 588ВТ1 активировала нужный CS.
Не при деле останутся два CS от селектора УВВ 588ВТ1, но все равно ВИ1 в эту компанию просто так не вписывается, логика преобразователя вылезает за пределы ХП4, а дополнительных корпусов иметь не хочется.

Ну да, из кубиков с буквами П, О, А, Ж сложить слово Счастье, примерно так. Ставим призмы, зеркала и т.п., смотрим в дырочку, читаем: "Счастье", и на этом успокаиваемся и радуемся.

Дык слушаю, со всем уважением, еще, помнится, в mo.dec на мои глупые вопросы отвечал

Концепция немного меняется. От ВТ1 пока не отказываюсь, ее тормознутость сочетается с общей тормознутостью проекта. Попробую порисовать, чтобы получилось следующее:
Блок УВВ платы IDE с ее DMA и прерываниями занимает 8 ячеек. Они декодируются непосредственно в 8 линий CS ВТ1. Три линии группируются по ИЛИ:
CS0,1,2 -> CS КПДП
CS3 -> CS регистра режима контр. прерываний. Регистры векторов не используются, код вектора задается "механически" на ногах ВН1. Можно переключателями.
CS4 -> IDE_CS0
CS5 -> IDE_CS1
CS6 -> индекс-счетчик адреса регистра для IDE_CS0/1, с возможностью автоинкремента
CS7 -> пустой что ли? Надо подумать, подо что заюзать. Можно под один регистр вектора ВН1, для большей гибкости (а нужна ли она??). Можно под еще че-нть полезное.

Упрощения: убираем хитрое преобразование адресов, убираем необходимость подстановки адреса 0 для IDE в режиме DMA
Усложнения: пока не оценивал, буду рисовать
Бонусы: автоинкремент индекса регистра IDE_CS0 позволяет передавать адресный блок харда и следом команду тоже по ПДП. Удобно же, разложил адрес сектора, написал команду, зарядил ПДП и сказал фас. И дальше оно все само.

Работает не схема, работает концепция. Схема это одно из многих возможных отражений концепции. В этой схеме есть спорные фрагменты, образовавшиеся в результате компромиссов, и в общем случае такое не подлежит тиражированию. Поэтому если схему и выкладывать на всеобщее обозрение, то это в некотором смысле ответственность, и нужно подробным образом, на уровне учебника, разжевывать, почему так делать не рекомендуется. А такое обязательство брать на себя не хочется.

Разрисовал связующую логику для платы IDE с ПДП, между буферизированной шиной МПИ, микросхемами 588 серии и шиной IDE. В соответствии с текущим пониманием тонкостей работы используемых экземпляров 588-й серии. Структура этой логики заметно отличается от того, к чему привык, разрисовывая подобное для 580, 1810, Z80. А привык к тому, что обычно получается экономно и в некотором смысле эффектно. Сейчас об эффектности речи нет, лишь бы уместилось компактно. В общем, результат где-то на троечку, но по-другому и не получается. Симпатичная программная модель не всегда означает, что электрическая реализация тоже на высоте. Все-таки, шина МПИ на выводах микросхем это проблема, если вдруг возникает необходимость в буферизаци или еще какой коррекции. Из микросхем нужно было выводить заготовку шины и сигналы управления шинными буферами. Чтоб и между собой на плате стыковалось, и чтоб межплатной шиной управлять. Но, имеем то, что есть, без вариантов.

Вот что получается по предварительной прикидке:
- Самая нерегулярная часть связующей логики помещена в одну ХЛ4. Но нерегулярны только четыре сигнала, остальные 4 выхода это очень простые функции от входов, типа 2И или даже просто НЕ. Ресурс израсходован неэффективно, нерегулярность и та простая, ну и хрен с этим, зато один корпус.
- ЛИ1 для формирования 4 сигналов как функция ИЛИ в отрицательной логике.
- ЛЛ1 для формирования 2 сигналов как ф-ция И в отрицательной логике, и два повторителя.
- 561ТВ1, формирование запросов на ПДП по протоколу чередования циклов ПДП и ЦП, и генерация таймаута шины в цикле ПДП.
- ИЕ7 индексный регистр-счетчик для адресации IDE.
- две RC-цепочки для формирования задержек.
- три диода, ф-ция ИЛИ в отрицательной логике, усиленная повторителем на четвертинке ЛЛ1. Почему не 3И ? Да потому что и так все вразнос пошло, раз уж RC-цепи появились, не-ТТЛ серия, то и это можно. Гулять так гулять.

У ИЕ7 +1 считает задники обращений по IDE CS0. На -1 заведен старший разряд, запрещая счет, если там 0. То есть, получилось:
- Разряды 0-2 адрес, разряд 3 разрешение автоинкремента.
- Автоинкрементируются только обращения к IDE CS0. (и в циклах ПДП тоже)
- Автоинкремент автоматически запрещается после обращения по адресу 111, новый адрес при этом 000. То есть, если заполнение адресной инфы и команда на чтение делаются с автоинкрементом, то для чтения буфера данных адрес выставлять не требуется. Это удобно.

Если ИЕ7 заработает так, как написано, то это будет достаточной компенсацией за шероховатость остального. И если 561ТВ1 оправдает надежды, на него возлагаемые, то это будет еще лучше. ТВ1 там запланирован, потому что не требует вообще никакой обвязки, стыкуется со всеми сигналами сам. Концепция вроде бы спасена, угроза отведена.

Теперь все это нужно будет отмакетировать и подтвердить концепцию.

andyTh написал:

[q]

Может быть тогда вписалась бы и к примеру EPM7128?

[/q]

Это шаг к тому, чтоб все сделать резиновым и безалкогольным, внутри фпгашки.
7128 у меня вроде даже где-то валяются приготовленными, но там были идеи относительно 1806ВМ2. Может и пробьет когда на безумие. Но только после этого безумия.

andyTh написал:

[q]

а где задержки поставили?

[/q]

Одна отсчет таймаута шины в цикле ПДП, другая задержка READY в ответ на IOWR от DMA контроллера в сторону девайса, с целью уширения этого IOWR. Если READY заземлить (всегда активен), то строб IOWR коротким получается, 100 нан или менее. Не помню, проглатывает такое IDE или нет, но некомфортно, увеличиваю до 200-250.

ЗЫ EPM7128, говорите? 128 триггеров? На ней одной имхо можно сваять контроллер IDE вместе с ПДП и интерфейсом МПИ с прерываниями. И еще какую-нибудь свистелку. Но туда сразу просится до кучи и интерфейс ОЗУ, ПЗУ, начальный пуск. Т.е. ВМ1, эта CPLDшка, ОЗУ, ПЗУ, IDE, еще-что-то, и все на маленькой плате. Но тогда ВМ1 выпадает из концепции, ВМ2 кмоповский более гармонирует.

Mixa написал:

[q]

Какой из двух лучше?

[/q]

Критерий истины - практика. Берем микросхему, впаиваем, берем осциллограф, смотрим. Сачала КР561ТВ1А.
КПДП программируется на пересылку блока из 3 слов.
SACK, SYNC, RPLY и DMA_Active. (У 588ВТ2 он называется EM, похоже на Enable Memory, но со смысловой привязкой беда, какая Memory и почему Enable). КПДП переводится в активное состояние по команде от процессора, это вызывает установку DMA_Active. Окончание пересылки блока индицируется снятием DMA_Active.

Циклы DMA не начинаются, пока не появится запрос DMA_RQ. Эти запросы и их снятие формируются синхронно с установкой SYNC, запрашиваются в цикле ЦП, снимаются в цикле ПДП. Такой алгоритм обеспечивает чередование циклов ПДП и процессора. Формируются они как раз этим самым ТВ1.


На первый взгляд все хорошо, но если посмотреть на окончание ПДП с увеличением, то будет видно вот что. Это снятие DMA_Active:


А это снятие DMA_RQ. Оно задержано относительно синхронизирующего спада SYNC почти на 300 нс и находится в опасной близости от снятия DMA_Active. Опасной потому, что если еще немного повременить со снятием DMA_RQ, то это будет воспринято как запрос на пересылку следующего блока. DMA_Active при этом останется активным и начнется пересылка блока длиной 65536 слов. Заряд такой мощности способен дважды уничтожить весь мир и прощай Hello, world!


Играть со спичками рядом с ядерным детонатором не хочется, поэтому пришлось раздобыть КР1561ТВ1. И сразу обозначилась разрядка международной напряженности, задержка уменьшилась раза в три и отошла от опасной черты:


К тому же наклон фронтов ТВ1 перестал контрастировать с сигналами от ВМ1, поэтому правильный ответ - КР1561ТВ1. Ставим галочку.

Хотя, казалось бы, при взгляде с высоты птичьего полета, картина как бы и не поменялась:


Семафор открыт, продолжение будет.

Mixa написал:

[q]

Ой-ёё.. В книжке у него клок спадом , а на самом деле подъемом .. Блин, узел переделывать, а ведь ничего лишнего не осталось. Один инвертор с ОК нужен теперь, наверное, просто транзистором обойдусь.

[/q]

В последнее время я перестал пользоваться книжками для этого дела. С одной стороны конечно из за того, что приделали ноги
двум моим Шило, а с другой держать в голове все опечатки? Гуглим "аналог" нужной микрушки и читаем даташит от первоисточника.
Понятное дело, что попадаются микросхемы и без аналога (исчезающе редко) или с корёженной цоколёвкой, но как бы в 99.9%
способ работает.

Блин, засада ... Заранее не обратил внимание на SACK, решил, что это некий аналог BSY, только от другого ведущего, и заложился на то, что они не перекрываются.. А вот и нет. BSY еще не снят, а SACK уже появился. И SYNC еще активен! Перекрытие 300 нс. И кто, спрашивается, управляет шиной ??? У меня встречные буфера на SYNC, WTBT, DIN, DOUT. В одном направлении включается при помощи BSY, в другом при помощи SACK. В результате 300 нс какого-то идиотизма на шине, с конфликтами уровней и прочей "прелестью". Ушел думать.

_Patron_ написал:

[q]

3. Устройство, приняв DMG, активирует режим ДМА выставив SACK ( сразу после снятия SYNC / снятия RPLY, смотря что позже ) и сняв DMR.

[/q]

У 588ВТ2 есть сигнал, по смыслу похожий на SACK. Он везде называется по-разному, минскую терминологию специально приводить не буду, она какая-то странноватая. Поэтому пусть будет SACK. Но на самом деле это не чистый SACK, потому что вышеприведенный п. 3 не выполняется, этот сигнал ставится сразу по приходу DMG без ожидания снятия SYNC. Я его использовал как SACK и ничего хорошего из этого не получилось. Хорошо, пусть это будет Early SACK, ESACK его назовем.
Patron, спасибо большое за разъяснения, у меня какая-никакая а шина, поэтому буду подгонять обмен сигналами в направлении этого протокола. А то уж всякие совсем грязные хаки в голову полезли, и от этого стало грустно.

Дальше становится интереснее. Как определить момент для выставления настоящего SACK? Отслеживать шинные SYNC и RPLY внешними схемами не хочется, нафига тогда эта большая ИС ВТ2, большая - подразумевается умная, а как иначе? Посмотрел повнмательнее на поведение ВТ2. Она все-таки следит за шиной, дожидается окончания SYNC и только после этого начинает свой цикл. Начинает она его с формирования интервала времени при помощи внешней RC цепочки. И если бы не эта внешняя хрень, узнать, когда эта БИСина задумывает сделать свой цикл, невозможно в принципе. Только угадывать внешними схемами, но это ж фу-у-у.. Единственная зацепка, единственный шанс для ВТ2 остаться контроллером ПДП в этом изделии.
Значит, так тому и быть, будем формировать цифровой сигнал из аналогового. Процесс - быстрый разряд C через открытый ключ до нуля и закрывание ключа с последующим медленным зарядом через R до напряжения питания, соответственно, сигнал это короткий отрицательный импульс вниз от питания и обратно.
Напрашивается следующее решение. RS триггер, ESACK в своем пассивном состоянии держит его в одном положении. ESACK активируется, отпускает удержание триггера, а импульс на C перекидывает триггер. В конце цикла пассивный ESACK перекидывает его обратно. Как раз правильный SACK на этом триггере и сформируется. Пошел думать дальше, из чего этот триггер сделать

Я как-то где-то делал несимметричный RS триггер (внутри ХЛ8 емнип, одна макроячейка всего), логически - закольцованные И и ИЛИ, оба без инверсии. Оба выхода прямые (или оба инверсные). Второй вход И это /R, второй вход ИЛИ это S (если считать, что выходы прямые). Как раз своей разнополярностью R и S для этого триггера SACK подходят. Но для превращения в шинный SACK его нужно пропустить через повторитель с ОК. В любом случае ресурсы нужно изыскивать.

Ну что, не все уж так и плохо, только неожиданными фишечками схемка обрастает.

Как оказалось, квитанции DMR - DMG это не более, чем обмен любезностями. Если SACK после этого обмена не подать, процессор продолжит свои циклы, как обычно. Стало быть, делаем по плану Б, то есть налезаем ранним SACK на хвост цикла ЦП. С другой стороны, ЦП сам напрашивается налезть ему на хвост, просигналив DMG.
DMR: дай поиграть
DMG: бери
/DMR, SACK: беру
/DMG: отдашь, как наиграешься
(активный SACK не мешает закончить текущий цикл, но препятствует началу нового цикла ЦП)
/SYNC: вижу, ты свое закончил, переключаю буфера.
/SACK: отдаю, надоело

Если делать более приближенно к протоколу:
DMR: дай поиграть
DMG: бери
/DMR: понял
/DMG: ну да
(непонятная пауза, нужно спешить выставить SACK, пока не началось... SYNC закончился, ставим SACK!)
SACK: ну этта, я типа взял, ага? (нет ответа)
/SACK: отдаю, надоело

Первый вариант выглядит более осмысленным. Так и делаем.

В узле индекс-регистра-счетчика ИЕ7 поменял на ИЕ13. Не углядел, что у ИЕ7 вход -1 может работать как запрет счета только для триггера младшего разряда. С ИЕ13 все правильно получается, с той разницей, что автоинкремент разрешен нулем. Индекс загружается значением адреса и битом запрета инкремента адреса, т.е., чтоб поработать только с регистром 3, к примеру, нужно загрузить ^B1011, а не 3. Ну или 100003, смотря куда этот бит прикрутить. Слегка противоестественно, но машине пофиг. А если вдруг свободный инвертор нарисуется после всего, то в этом узле его можно будет утилизировать в первую очередь.

Mixa написал:

[q]

непонятная пауза, нужно спешить выставить SACK, пока не началось...

[/q]

Пауза гостированная = 10 мкс ( 64 такта ). В момент выставления DMG запускается счётчик на 64 такта, который тикает параллельно с ожиданием RPLY и снятием SYNC. Процессор гарантированно снимает SYNC до обнуления счётчика. Процессор не начинает новый цикл шины при активном сигнале DMR до истечения таймаута SACK. В момент обнуления счётчика ожидание SACK прекращается и процессор возвращается к нормальной работе.

Не факт, что у ВМ1 это так, но это так по стандарту Q-Bus. Таймаут SACK не может быть меньше таймаута RPLY именно для того, чтобы даже после снятия SYNC по таймауту RPLY - всё равно оставалось время для ожидания выставления SACK.

Mixa написал:

[q]

еще до окончания SYNC ВМ1 выдает DMG, на что сразу снимается DMR и следом в ответ DMG тоже. SYNC еще активен.

[/q]

Процессор действует по стандарту - приняв DMR выдаёт DMG и запускает таймер ожидания SACK. По стандарту, в случае снятия DMR до прихода SACK - ожидание SACK прекращается немедленно.

Если устройство выдаёт SACK после снятия DMR - это нонсенс. Устройство должно выдавать SACK до снятия DMR и DMG. Пока не снят DMR - активен DMG. Пока активен DMG - тикает таймер ожидания SACK и процессор не может начать новый цикл шины. Когда таймаут SACK истекает - процессор снимает DMG, что означает игнор DMR, отказ от ожидания SACK и продолжение обычной работы.

Решение проблемы ( на мой взгляд ) - защёлкивание "нашего" DMR до выставления "нашего" SACK. Тогда всё будет по стандарту и процессор не снимет DMG до истечения таймаута SACK.

Mixa написал:

[q]

другим bus masters, если такие вообще появятся, это не помешает

[/q]

Абитражу DMA вообще ничто не может помешать, потому что в Q-Bus нет линии DMG. Вместо этого у каждого устройства есть вход DMGI и выход DMGO ( у процессора - только DMGO ). DMGO процессора поступает на DMGI первого басмастера, DMGO первого басмастера поступает на DMGI второго басмастера и т.д. Как только басмастер выставляет DMR - он отключает DMGI от DMGO, поэтому младшие басмастеры не имеют шансов увидеть DMG до тех пор, пока старшие не закончат работу с шиной.

DMR - это линия, поэтому если два устройства выставили DMR - снятие DMR старшим басмастером никто не заметит, но это и не играет роли - если в момент снятия SACK активен сигнал DMR - процессор снова выставляет DMG и на этот раз его принимает второй басмастер, ожидавший своей очереди.

Так, с ПДП разобрались, утвердили, продолжаем.

Смотрю, что получилось с прерываниями. 588ВН1 имеет два входа прерываний, A и B. Задумка такая, что на INT A приходит irq14 от IDE, на INT B идет прерывание от 588ВТ2, знаменующее окончание сеанса ПДП.
588ВН1 может выдавать вектор, запрограммированный на 6-ти специально отведенных для этого входных линиях, либо из содержимого двух внутренних 7-разрядных регистров, по регистру на каждый источник прерывания.
В общем, 588-я серия продолжает преподносить сюрпризы и непонятки. В данном случае трудно понять, чем руководствовались минские разработчики, выделив 6 разрядов под внешнее кодирование вектора и 7 разрядов под внутренне-регистровое, и то, как их распределили по шине АД. Если шину АД подсоединять как по справочнику (всего 7 линий, АД7..АД1, АД0 не существует, но это понятно и очевидно, что он не требуется), то гранулярность кодирования вектора как при внешнем способе, так и при внутреннем, составляет 1 слово. На практике это не нужно, обычно гранулярность 2 слова, для адреса обработчика по четному адресу слова и PSW по нечетному адресу слова.

Ради любопытства попробовал закодировать вектор по нечетному адресу слова, и расположив в памяти адрес входа в процедуру и PSW "с перекосом" соответственно, увидел, что так тоже работает. Но так никогда не делается, зачем такая возможность - совершенно непонятно.

7 разрядов регистров покрывают область векторов 000..376 полностью, внешние 6 разрядов только половину (старший разряд устанавливается в 1), то есть покрывается вторая половина области векторов. Логичнее было бы использовать в обоих способах 6 разрядов, с гранулярностью 2 слова, с полным покрытием и при это ничего лишнего.

В общем, в построении концепции кирпичики оказались крупноваты и по форме несуразны, неоформившаяся идея казалась симпатичнее, но вперед движемся, от проекта не отказываемся.

Пока в раздумьях, на каком из вариантов остановиться:
1. Подключение АД "по справочнику"
плюсы
- как бы и нету, какие могут быть плюсы в подключении, рекомендуемом справочником. Типа эталон.
минусы
- а вот минусы быть могут, описаны выше

2. Подключение АД со смещением на 1 разряд
плюсы
- гранулярность векторов 2 слова
- полное покрытие векторов в режиме внешнего кодирования
минусы
- не могу определится, минусы это или нет. Есть особенности: сдвинутые биты регистра управления и состояния относительно "справочного" положения, неиспользуемый разряд при кодировании регистрами (выдается вхолостую на АД8), присутствие на шине не только в пределах младшего байта, выдача "1" в разряде АД8 в цикле "чтение вектора" при внешнем кодировании.

Вот написал, и, похоже, что с выбором определился. Подключение со смещением на 1 разряд. Ни одна из особенностей минусом не является. Кодирование вектора внешнее, разделение источников INT A и INT B при помощи специального схемотехнического приема. У микросхемы есть вывод, на котором появляется сигнал при подтверждении прерывания INT B , если его завести на одну из линий внешнего кодирования, то на прерывания A и B будут выдаваться разные векторы. Такой трюк работает, проверил.

Anonymous написал:

[q]

Mixa написал:

[q]

Вот написал, и, похоже, что с выбором определился. Подключение со смещением на 1 разряд.

[/q]

Именно так всегда и делалось, справочники - как газеты, их после еды читать лучше. DEC же поправился, что область плавающих пользовательских векторов до 01000 простирается, а до 0400 размещаются системные вектора, т.к. системный стек расположен в верхней половине первых 64кб, а пользовательский стек находится в отображении памяти пользователя. Но это для процессоров с ДП.

[/q]

Я почему-то решил, что вектор воспринимается только с линий АД7-АД1 , но оказалось, что и с линии АД8 тоже. На входах кодирования установил уровни, чтоб вектор 200 выдавался, а в результате прыгнуло на 600, потому что по АД8 единица передалась. Фигня, поменяю местами подключения к АД7 и АД8, будет всегда выдаваться 1 на АД7. Появляется ограничение на выбор вектора, ну и ладно, выберем какой-нибудь из второй половины системных.

Anonymous написал:

[q]

Mixa написал:

[q]

сигнал при подтверждении прерывания INT B , если его завести на одну из линий

[/q]

Обычно он заводился на AD2, давая вектор-B на 4 больше вектора-A, как в большинстве устройств с несколькими векторами принято.

[/q]

Ну да, так и делаю Вначале опасался, что подтверждение VECB с большой задержкой будет проходить с линии кодирования на выход АД, но нет, все нормально, даже иголки практически нет, только намек на нее.

Mixa, я у себя только буфер младшего байта открываю в цикле передачи вектора, таким образом старший байт всегда равен нулю за счёт подтяжек МПИ со стороны процессора.

Mixa написал:

[q]

CS1 представляет из себя тот еще костыль, один из множества уродцев из наследия, начало которому положило IBM PC. К тому же с очень малоиспользуемой функцией

[/q]

Почему малоиспользуемой? Там же не только программный сброс накопителя, там и разрешение прерываний от него.

Затею пока не оставил, перешло в фазу переноса всего на печатку. И вот думаю, что по большому счету нет смысла иметь настраиваемые адреса регистров и векторов прерывания. С прерываниями вообще получается два способа задания вектора, потенциалами снаружи и программированием изнутри. Какую из этого можно извлечь пользу или прикол - пока ясности нет. Вот на макете у меня сейчас, железные вектора это 240 и 244, а база для 8-ми регистров - 174200. То есть, диапазон с 174200 до 174216.
Может, их железно сделать и оставить ? Векторы сделать 220 IDE и 224 DMA, по стандарту они диск и лента, диск остается диском, ленты нет и не предвидится. И регистры, занять место того же RK11, 177400 до 177416. Все равно ведь потом будет, ну сделаю возможность задавать перемычками или переключателями, ну поставлю в какое-то значение, но и все.

Ну что. Типа всё Из этого собирается этажерка - и оно работает!


Косяк все же есть, на IDE перепутал CSы. Резать дорожки не стал, обошелся перекручиванием проводов на шлейфе, на фотке видно.
Последовательный порт вывел на разъем IDC-10, стандартный для мультикарт от PC. На митинской барахолке нашел COM-овский хвост, подошел. Там же нашел 588ВТ1 в керамике, его и впаял. Нефиг ему на витрине сверкать под лампочками.

Преобразователь уровней - MAX232. Из-за него пропал смысл наличия отрицательного напряжения питания. И также пропал смысл применения РУ3. Оставил "отладочные" РУ6. Пускай всё от +5 питается. Винчестер не в счёт.

Итого, имеется нечто, с последовательным портом, прерыванием 50 Гц, интерфейсом IDE c DMA и прерываниями. Проект шел под девизом прикоснись к легенде, сейчас как-то само собой трансформировалось в "представь, что это легенда". Какое-то оно карманное, 10х8х8 см (ну, к чему стремился). Чего-то не хватает для самоочевидности. Наверное, масштабности размеров, запаха нагретой изоляции, мигающих лампочек и каких-то звуков.

Винт буду цеплять Seagate ST-157A. Как раз духу того времени соответствует.

RSX-11 не хочу (а она вообще комфортна в 32 к слов?). Посматриваю в сторону RT-11, это правильное направление? Периферии достаточно для нее (терминал, диск, таймер 50 Гц)? А вообще, Ксоникс хочу, это мотивирующая цель.

Любопытная этажерочка
Интересно будет поглядеть на драйвер IDE, а может и загрузчик даже.

Mixa написал:

[q]

По этому полю ни разу не ходил.

[/q]

Можно для экстремальной простоты сделать начало полезного пространства винчестера примерно так с ~10-го мегабайта - что бы была возможность предварительно разметить ФС под МС ДОС, и разместить там группу файлов по 32 метра типа .DSK

Напрмер , классичсекая RT-11 V5.00 позволяет иметь на устройстве до 8 томов по 32 метра каждый, итого - 256 метров.
Ну и несколько "устройств" - AD:, BD:, CD:, DD:....
Так запросто можно 2 Км и занять.

А вот насчет новодельных ОС с 31-м томом на устройстве и разрешающих 2000-й год - хрень там полная, каталоги не совместимы с классикой V5.00, не рекомендую.

Anonymous написал:

[q]

MM написал:

[q]

А вот насчет новодельных ОС с 31-м томом на устройстве и разрешающих 2000-й год - хрень там полная, каталоги не совместимы с классикой V5.00, не рекомендую.

[/q]

Тут же не БКшка и БКшные ОС тут смысла нет заводить и обсуждать.

[/q]

Не ясно, при чем тут БК - речь идет о клоне МС1201.01 с ( почти ) новым обвесом.

Mixa написал:

[q]

Память полная, более того, простирается до 172776. Но есть опция "как надо", до 157776, выставляется джампером.

[/q]

RT-11 при загрузке проверяет память до адреса 170000, чтобы задействовать больше 60 Кб - надо подправить код загрузчика:


4$:     CLR     R4              ;Look for top of core
5$:     ADD     #4000,R4        ;Move to next 1K bank
..28KW  == .+2    ;**PATCH** CHANGE TO 160000 TO AVOID CHECKING OVER 28K
        CMP     R4,#170000      ;Reached 30K?
        BEQ     NXM             ;Yes, 30K system with MSV11-D memory
        MOV     @R4,@R4         ;No, see if this location exists
        BR      5$              ;Keep going if we didn't trap
NXM:



_Patron_ написал:

[q]

надо подправить код загрузчика

[/q]

А где такие загрузчики с комментариями водятся?

Mixa написал:

[q]

_Patron_ написал:

[q]

надо подправить код загрузчика

[/q]

А где такие загрузчики с комментариями водятся?

[/q]

Может быть целесообразно аппаратно ограничить ОЗУ на отметке 167776 ?
Тогда и патчить не надо...

MM написал:

[q]

Не ясно, при чем тут БК - речь идет о клоне МС1201.01 с ( почти ) новым обвесом.

[/q]

Это был комментарий к вашему замечанию, которое встречалось только на БК и УКНЦ, где исполнительная среда БКшных программ использовала дополнительные слова в каталоге для хранения своей информации и которая терялась при перезаписи файла стандартными средствами ОС. Вот я написал, что БК не надо сюда тянуть, на стандартном софте и оборудовании таких проблем нет.

Mixa написал:

[q]

Не, целых полтора килобайта пропадет. Пусть будут, пригодится.

[/q]

Можно научить драйвер какой-нибудь туда пересаживать часть себя и таким образом экономить память. Только ОС при этом должна быть старших версий, т.к. более ранние не поддерживают запрос, позволяющий указать процедуры, выполняемые при загрузке и выгрузке драйвера, в которых можно было бы обеспечить такой функционал, эта возможность появилась с версии 5.3.

Anonymous написал:

[q]

MM написал:

[q]

Не ясно, при чем тут БК - речь идет о клоне МС1201.01 с ( почти ) новым обвесом.

[/q]

Это был комментарий к вашему замечанию, которое встречалось только на БК и УКНЦ, где исполнительная среда БКшных программ использовала дополнительные слова в каталоге для хранения своей информации и которая терялась при перезаписи файла стандартными средствами ОС. Вот я написал, что БК не надо сюда тянуть, на стандартном софте и оборудовании таких проблем нет.
...

[/q]

Впервые слышу о дополнительных словах ( и др. данных ) в каталогах стандартных ОС RT-11 SJ V5.00
Да, по ТО на ФС RT-11 они допускаются, но на практике - не видал .
По крайней мере свои поделки с такими "пирогами" я никому не списывал, и вроде как нигде не обсуждал. Да и сама RT-11 там не присуствовала.

Anonymous написал:

[q]

MM, тогда на какие новодельные ОС, несовместимые по каталогам с RT-11, но имеющие с ней проблемы, вы ссылались? Да и странное "с 31-м томом" ни к одной из существующих ОС не подходит. Я подумал, что про подобный софт пишите, извините.

[/q]

Пытался пристроить драйвер BY.SYS самой первой версии ( который практический голый - код занимает 1 экран в DESS ) к RT-11 SJ , которая с 2000-м годом и разрешает много томов в драйвере - вылетало на вторичном загрузчике в лес ( МС1201.03 ), причем явно не на первом драйвере.
Потом скачал от Хобота RT-11 SJ V5.01 - начало грузиться, но не с первого раза ( особенности ?! недостоверный дамп ядра ? ).

Но вся фишка в том, что я на на 100% аналогичном конфиге на МС1201.04 работал 5 лет, но с RT-11 V5.00, поставляемой с А. в составе МС507 ( ДВК-3 ).
Пробовал отлавливать баг - дело в вторичном загрузчике дров, ему не нравится каталог, т.е. дефект идеологический.
Ну или все образы SJ битые попались...

П.С. От БК использовался исключительно сам BY.SYS , остальное - скачанное из всяких мест, особенно от Хобота.
Возился неделю, по 4 часа каждый день.
И в итоге еще и потерял диск, который вроде как начал загружаться .
На а формат-контроль диска BY: - сторонней программой TESTBY.SAV, которая отлично работает везде.
*
В принципе, BY.SYS можно заменить и на драйвер PY.SYS :
http://zx-pk.ru/threads/26134-...page4.html

MM написал:

[q]

Пытался пристроить драйвер BY.SYS самой первой версии

[/q]

Так драйвер надо пересобирать под каждую новую версию, дело в неправильном драйвере. Возьмите и пересоберите мой http://qbus.narod.ru/by.zip - у нас версия архивная с начала 90х была 5.4, хоть и появилась новомодная 5.6 в 91 году, ее до выхода 5.7 аж в 98м не давали. Но драйвер прекрасно работает под всеми, начиная с 5.3.


Mixa написал:

[q]

А вот ПЗУшный загрузчик по адресу 173000, что он должен уметь кроме чтения первого сектора в начало памяти?

[/q]

Ничего не должен, считываем блок с загрузчиком в 0 адрес памяти и обнуляем PC, адрес хранения загрузочного блока может отличаться от 0го, например, для совместимости диска со стандартом ПиСишки, куда диск можно было бы перетыкать. На всякий случай, для совместимости, ещё перед обнулением PC, заносим 010000 в SP и 0340 в RS.

По поводу драйвера винчестера IDE для ДВК-подобных ЭВМ.
Можно в SET-командах установить привязки томов ( по 32 метра ) к файлам в FAT-16.
И при начальной загрузке разыскивать указанный файл в FAT-16.
Разумеется, без учета фрагментации.

Anonymous написал:

[q]

Чем дело кончилось?

[/q]

Вообще нет данных об самой затее.
А СМК - это самодел неизвестных лиц без ТО и КД, я как бы не в курсах о таком девайсе.

Запрограммировал загрузчик в ПЗУ по адресу 173000. Проверил на четырех разных IDEшных дисках, успешно грузит первый сектор в начало памяти и передает туда управление. В тех секторах мусор с точки зрения процессора, в HALT вываливается в итоге по разным причинам. Однако, похоже, что всё работает.

Фотки напоследок.
Этажерка в сборе:


и готовая к софтовым экспериментам система:


Расклад регистров получился такой:
177400 DMA CSR
177402 DMA счетчик слов
177404 DMA адрес начала блока
177406 Обращение к ATA CS1FX
177410 (байт) Обращение к ATA CS3FX
177411 (байт) Задание адреса на шине ATA
177412 Прерывания CSR
177414 Прерывания вектор A (от DMA)
177416 Прерывания вектор B (от ATA)

Device handler требует задания CSR устройства и вектора прерывания. Как такового ATA CSR в получившемся раскладе нету. И вектор прерывания не один, а два их. Размышляю, как лучше поступить. Вопрос в том, что такое на самом деле указываемый CSR устройства. Если это просто базовый адрес блока управления устройством, работа с которым индивидуальна для каждого устройства, то это одно. Если это адрес универсальной структуры с обращением к ней универсальным способом, и вдруг это где-то параметризуется, то это другое, и в моем случае не проходит. Лучше, чтобы было первое.

Вторая непонятка с двумя векторами прерывания. Не разобрался еще с механизмом инициации вектора прерывания, но все равно возникает вопрос со вторым вектором, его нужно как-то инициировать.
Есть ли какой-нибудь способ для драйвера до начала его использования вызвать код его инициализации, который резидентом не остается?

MM написал:

[q]

"Программирование внешних устройств Руководство программиста 00008-01.33.01-2"
Скан его найдете на моем форуме-справочнике из подписи ниже по тексту.

[/q]

Спасибо! Как-то сходу его там не нашел среди остального собрания, но судя по структуре оглавления это перевод RT-11 Software Support Manual. Он есть, его и почитаю.


MM написал:

[q]

Если кратко и по существу - начальную подготовку регистров и векторов производит начальный загрузчик в 173000, он вычитывает 0 блок тома, при этом сообщая номер тома и имя драйвера. В 000000 блоке тома тоже желательно повторить процедуру инициализации регистров и векторов, т.к. понадобится подпрограмма чтения блоков тома по номеру блока - более подробно в брошуре.

[/q]

Начальный загрузчик 173000 я сделал совсем простым, про прерывания он ничего не знает.
Насчет векторов - гляну .DRVTB, это для Multi-Vector handlers, похоже, то, что нужно.

Тут обнаружил, что то, чем управляет DW.MAC, очень похоже на WD1010, почти. Команды чтения-записи-форматирования-рекалибровки те же, почти все биты состояния на месте, так же работает с буфером сектора. А DMA, хе-хе, у него нету
И прикол, (наверное в стиле PDP?) в подпрограмму передачи сектора как параметр передается машинная команда, которая, исполняясь в этой подпрограмме, передает сектор туда или сюда, в зависимости от того, чтение это сектора или запись. Надо обдумать такой приемчик.

У себя девайс назову WD. Так понял, что оно любое двухбуквенное, лишь бы уникальное?

А номер ID для девайса тоже любой, лишь бы уникальный? (варианты, 0 как у RK, или 53 как у DW)

Mixa написал:

[q]

У себя девайс назову WD. Так понял, что оно любое двухбуквенное, лишь бы уникальное?

[/q]

Да.


Mixa написал:

[q]

А номер ID для девайса тоже любой, лишь бы уникальный?

[/q]

Типа.
По сути - вряд ли на что-то влияет.

Anonymous написал:

[q]

А так уже драйвер для УКНЦ называется

[/q]

Вот незадача. Проект изолированный, но мало ли что. Тогда попробую XD Или DA. Или AD, как во фряхе.

Имя устройства, фигурирующее внутри драйвера, будет иметь значение при работе загрузчика, там оно помещается в переменную B$DEVN, определяемую в макросе .DRBOT и по ней затем уже ищется драйвер в каталоге системного устройства. В рабочей системе можно переименовывать драйверы, перезагружаться даже не надо при этом, достаточно командой вручную удалить/добавить драйвер в таблицу монитора.

Mixa написал:

[q]

макрос генератор входа в прерывание называется .DRAST? В чем логика?

[/q]

driver asynchronous service trap, в мануале по системной макробиблиотеке же есть.

Mixa написал:

[q]

Вот незадача. Проект изолированный, но мало ли что. Тогда попробую XD Или DA. Или AD, как во фряхе.

[/q]

Кстати, попалось тут: оказывается, XD.SYS тоже был, для RT-11 v4.x это предшественник LD.SYS, привязывался к файлу утилитой XDATCH.SAV и не входил в основной дистрибутив, поставлялся отдельно. А в ОС РАФОС для этой цели были UX/UY/UZ.

ВП065 снимает RPLY позже, чем нужно для ВМ1???
Удивительно. Вы не пробовали сравнивать вашу схему и схему к примеру МС1201.01 на
предмет отличий в привязке к тактовой частоте?

Именно, по вектору не переходит. Там какое-то пограничное состояние. Сначала проверял прерывание на прием символа, трапалось на 4. Отсоединил от шины контроллер ATA, стало трапаться на 60, как и положено. Погрешил на возможный конфликт на шине, стал проверять прерывание по передаче символа. Трапается на 4, а должно на 64. Про таймаут шины как-то не думал, хотя вот оно, вопиёт. Полез осциллографом сигналы смотреть, проверил все линии АД, вектор 64, как и требуется. Масштаб по времени уменьшил, вызвала подозрение какая-то тишина на шине после приема вектора. Длина тишины как раз те самые ~10 мкс. Ну и посмотрел, что у нас с SYNC'ом происходит, а он совсем крошечный после цикла IAK, а дальше таймаут. Более подробно не смотрел, но надо будет.

Привязка к тактам есть, и отличается. Сначала по лени не сильно думая скопировал узел с МС1201.01, а в инете схем МС1201.01 две, с отличающимися вариантами этого узла. Мне первой попалась с привязкой и активации, и снятия, я ее подправил до варианта начало RPLY немедленно, без привязки, а снятие с привязкой к такту (ошибочно, хотел наоборот, активация с привязкой, снятие немедленно). Потом, исправляя, привязал тупо к удвоенной тактовой, в моменты посередине уровней тактовой. Привязались и активация, и снятие RPLY. Вот на задержку снятия сейчас и грешу.

Картинки потом покажу, как осциллом сниму все эти безобразия.
(посмотрел еще раз вариант 1 и вариант 2 схем, исправил текст в соответствии)

MM написал:

[q]

Оптимальная привязка RPLY на БК0010 на .641 плате, и на БК11/М.

[/q]

Посмотрел схему 0011М, там из JK D8.2 и инвертора D>неразборчиво>.5 сделан D-триггер, на котором активация и снятие RPLY привязываются к спаду CLC.

Сигналы
1 IAKO
2 SYNC
3 RPLY привязанный
4 CLC
Это как было, RPLY снимался рано, все хорошо, следующий SYNC нормальный


Как было, снятие RPLY задержалось, глюк, SYNC куцый и дальше таймаут


Как стало, привязка к спаду CLC, RPLY формируется еще позже, но теперь все нормально


И то же самое, чтоб был виден SYNC

andyTh написал:

[q]

Из серии первый блин процессор комом

[/q]

Навроде того. Сейчас подавил зуд попробовать активацию RPLY передавать как есть, без привязки. Трезвый разум говорит, что смысла нету, потому что реальный RPLY (от ВП1-030) приходит при верхнем уровне CLC, привязанный RPLY активируется на ближайшем спаде CLC, то есть, процессор при любом варианте видит активный RPLY на одном и том же фронте CLC. Тут с разумом соглашусь и хардварные тюнинги закончу (надеюсь).

Anonymous написал:

[q]

RPLY по любому фронту CLC можно синхронизировать

[/q]

Ну вот, появился зуд попробовать. Правда, синхронизация по любому из фронтов получится такой, что перепады RPLY будут идти вровень с перепадами CLC, потому что CLC это счетный триггер на одной половинке ТМ2, а привязка RPLY на другой половинке этого же ТМ2, и C у половинок будет общий.

UPD Еще раз посмотрел здесь, все же по логике работы детектора неактивного RPLY, а именно, сначала выполняется условие неактивного RPLY при низком уровне CLC, потом защелкивание этого состояния на фронте CLC, потом выдача этого состояния в привязке к спаду CLC - RPLY лучше привязать к спаду CLC. Не хочу уже паять, ищу повод не поддаваться зуду.

Так трап то 4 пишет по которому адресу - туда сразу в пульте смотрите, что там вызывает ошибку.

Mixa написал:

[q]

?MON-F-Trap to 4

[/q]

Мой Вам совет - используйте исключительно RT-11 SJ V5.00
Иначе есть существенный риск, что это сообщение ОС станет преобладающим на длительное время ( разработки драйвера ).

А как вы без .forkа-то в прерывании работаете? Понижение приоритета, чтоб всё остальное не стояло - первоочередная задача. И нельзя слишком много команд до форка использовать, т.к. через несколько из них система отберёт всё равно управление (через сколько - не помню) и будет аварийный трап тоже. Ещё есть .synch и .inten, для форка можно все регистры использовать, для синча - только $0 и $1, для интена - $4 и $5.
SJ использовать - дурной тон, там и криво обрабатываются приоритеты, и reset оно выдаёт в случайное для устройства время. Например, многие устройства с интеллектуальными контроллерами просто под sj не работают, т.к. после аппаратного сброса теряется вся последовательность инициализации устройства.

p.s. начиная с версии 5.6 sj монитор упразднили по этой причине, его больше нет в составе системы.

[q]

они короткие, без циклов, порядка двух десятков команд по пути исполнения.

[/q]

Там их меньше 8 должно быть перед форком.

[q]

Вынужден ждать в цикле, когда этот бит взведется.

[/q]

Так для этого таймерные запросы есть для драйверов...

У меня сделан запрос прерывания уровнем, а не фронтом, если диск снял запрос - контроллер его уже не отрабатывает. Но вообще странно, прерывания у диска после аппаратного сброса должны автоматом запрещаться, пока в регистре принудительно не разрешишь.

Mixa написал:

[q]

- 40 мегабайт диска это много. Пришел к осознанию необходимости как-то нарезать это пространство.

[/q]

А вот вам развлечение, подумайте, как бы можно было использовать больший объём, чем 32Мб.
Была заброшенная мечта юности: можно переписать ОС так, что 32Мб останутся ограничением, но на размер каждого одного файла, для запросов .enter, файлового запроса .lookup, запросов .readw-.readc/.writw-.writc при работе с файлами, для совместимости с софтом. А вот объём свободного пространства на диске можно было бы считать уже с большей разрядностью указателей, но внутри ОС, чтоб софт мог штатный работать. Тогда для софта всегда, для любого запроса .enter, будет 32Мб на каждый файл свободно.