Дискуссии вокруг УКНЦ и прочее.

Цитата:

---

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

Хотите 1801ВМ3 в УКНЦ запихать?

---

С одной стороны - нет (во всяком случае - в существующие варианты).

С другой стороны - бродит мысль всё таки сделать, как минимум, всю обвязку в FPGA (завершить, так сказать, начатое Titus-ом), но именно что бродит - если и возьмусь - то непредсказуемо - когда. Это мысль из семейства - собрать все компы, которые у меня когда-либо были (кроме PC) на новой (включа FPGA) элементной базе :) Ну и тогда - почему бы не вставить в "new УК-НЦ" 1801ВМ3 или что-то помощнее (J11) :)

FB монитор RT-11 прекрасно идёт на УКНЦ, даже с системными заданиями, подтверждаю :)
Можно насчёт RSX - задачу упростить, загрузить образ RSX специально написанной программой и специально сгенерённый. Но без драйверов не будет доступа к дискам :(
Но система будет в памяти и с ней кое-что можно сделать :)
Если кому-то очень надо было - драйвер MZ переделать из драйвера MY не так уж и сложно.
На УКНЦ даже UNIX стартанули....
Но так как смысла особого не видно, то на этом всё и остановилось.

Цитата:

---

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

Можно насчёт RSX - задачу упростить, загрузить образ RSX специально написанной программой

---

А ты думаешь - как я первоначально RSX на Квант-е грузил? И образ был не специально сгенерённый, а обычной.

У меня прикольнее было, я не дописал программу-драйвер, коя позволяла читать дискеты FAT-12 на ДВК с КМД(думаю, что и на MZ она вполне бы работала), примерно как магнитную ленту, устройство со специальной файловой структурой, кою обслуживает драйвер, при условии если файлы были записаны в корневом каталоге и имя соответствовало канонам RT-11 ... Размер, геометрия дискеты определялись и устанавливались в драйвере отдельной программой. Запись немного недопилил :(
Были и отдельные программы для чтения-записи файлов, но у меня всё прикидывалось родным устройством и читать спокойно могли родные программы RT-11 :) .
Смотрел как написаны были драйверы магнитной ленты и драйвер LD: , и уж на этой основе писал своё...
Ещё у меня есть подозрения, что возможно, существует файловый процессор для FAT под RSX.(не я один был такой умный)

Цитата:

---

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

возможно, существует файловый процессор для FAT под RSX

---

Ну, в случае RSX всё проще (штатный механизм для таких дел) и сложней - FCS и RMS больно сильно заточены под ODS-1 - придётся как-то это решать. Хотя в простейших случаях всё не так уж плохо (сложно) :)

Цитата:

---

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

Только в ОЗУ ЦП, никакого DMA. Обмен идёт через видеоконтроллер, т.к. он имеет доступ ко всему ОЗУ.

- - - Добавлено - - -


Можно попробовать неофициальную 093, она как раз для СОЗУ 1809РУ1.

---

Но для ЦП УКНЦ сее действо выглядит, так как будто работает DMA...
На первых КМД - глюки были при работе выше 64 К :(
Запускаешь XM c дискетки программу в расширенной памяти и приехали :(
Я тогда времени и нервов убил :(

Когда программа в нижней памяти - всё хорошо. :)
С DW: на XM всё и везде замечательно работало :)

- - - Добавлено - - -

Ну я полагаю, что файловый процессор, для случае файлов в корне диска и когда имя файла более-менее соответствует соглашению RSX-11, написать не так уж и сложно...
Можно и в подкаталог влезть , если не глубоко :)
На один уровень...

- - - Добавлено - - -

И вообще, мне сдаётся, что не только FAT, но и NTFS прикрутить можно, Но будут некие ограничения... :( Вопрос про память ... Там для работы с NTFS её много надо :(
Иначе будет ползать как сонная муха...

Цитата:

---

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

Но для ЦП УКНЦ сее действо выглядит, так как будто работает DMA...

---

DMA это запрос доступа к шине с использованием сигналов DMR/SACK/DMGO. Ничего подобного в УКНЦ нет. ПП осуществляет доступ к планам 1 и 2 через регистры 177010/177014. Таким образом доступны все 128 кБ. Контроллер ПП общается с видеоконтроллером сигналами RQ, CC0, CC1 и по шинам AC, DC.

- - - Добавлено - - -

Цитата:

---

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

На первых КМД - глюки были при работе выше 64 К
Запускаешь XM c дискетки программу в расширенной памяти и приехали
Я тогда времени и нервов убил

---

Ошибка в прошивке 091, там сохранялись только младшие 16 разрядов из 22-разрядного адреса, а шесть старших очищались.
Вот это место в прошивке 091:

Код:

---

; Обработка полученного кода функции
3060$:  BIC    #177740,R5    ; Оставить биты кода команды и GO

---

А это уже в прошивках 092 и 255:

Код:

---

; Обработка полученного кода функции
3112$:    BICB    #340,R5        ; Оставить биты кода команды и GO

---

Старшие биты адреса были в старшем байте. Потому, если адрес блока выше 64К, то облом.

Какая разница, способов организовать доступ к памяти много, с использованием сигналов DMR/SACK/DMGO - это всего лишь один из способов :)
Да и программно отследить доступ по сигналам DMR/SACK/DMGO, можно только по притормаживанию доступа к памяти и по изменению её содержимого...
То, что да, обычно используют по канонам DMR/SACK/DMGO... Но на УКНЦ зашли с другой стороны. Упростив конструкцию.
И ощущения у программиста ЦП - как будто идёт DMA. Константы в регистры закинул, в памяти массив данных появился(или прочитался из памяти) :)
Все эти тонкости начинают вылазить, только когда лезешь в ПП. Что ДМА типа фальшивый ;)

И ещё, на PDP-11 хорошо сделана работа с прерываниями... :) А вот с ДМА всё хардкорно :(

Цитата:

---

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

Какая разница, способов организовать доступ к памяти много, с использованием сигналов DMR/SACK/DMGO - это всего лишь один из способов

---

DMA - это именно DMR/SACK/DMGO, т.к. доступ идёт к шине, а значит не только к памяти, но и к странице ввода/вывода. Так что доступ к ОЗУ через РА/РД это никакое не DMA.
Вот в КМД ДВК там реально организован классический DMA.

Цитата:

---

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

Какая разница, способов организовать доступ к памяти много, с использованием сигналов DMR/SACK/DMGO - это всего лишь один из способов

---

Ну, строго говоря, во фразе некоторое количество ошибок, например - DMR/SACK/DMGO не используются для доступа к памяти даже при ПДП.

Доступ к памяти (да и вообще любой доступ к шине QBus/Unibus) - это сигналы SYNC/DATI/DATO/DATOB/RPLY (и их аналоги на Unibus)

А DMR/SACK/DMGO - это совсем про другое и только потому что они ОБЫЧНО предворяют ПДП - они получили такое название.

Шины QBus и Unibus - это шины с одним ведущим (master) и одним ведомым (slave) в каждый КОНКРЕТНЫЙ момент времени. А какой ведомый и как будет отвечать - определяет ведущий. Если на шине требуется наличие нескольких ведущих, в действие вступает арбитр шины - он назначает ведущего. И сигналы DMR/SACK/DMGO - это как раз общение с арбитром. Обычно (ОБЫЧНО!) в роли арбитра выступает процессор и обычно (ОБЫЧНО!) запрос на управление шиной - это запрос ПДП. Но обычно не означает, что оно всегда так. Никто не мешает сделать своего арбитра шины.

В случае с УК-НЦ, получается, что схема работает немного не так - доступ к памяти управляется через свою шину и со своим арбитром. И в такой схеме вполне возможно организовать и "одномоментный" доступ - типа двухпортовой памяти. Так это или нет в УК-НЦ - надо смотреть реализацию доступа к памяти в видеоконтроллере - я не стал выяснять, для меня этот вопрос на текущий момент не актуален.

И вот по всему вышеописанному - я бы не стал называть доступ к памяти через регистры - ПДП

- - - Добавлено - - -

Цитата:

---

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

DMA - это именно DMR/SACK/DMGO

---

Та же ошибка, DMR/SACK/DMGO - это не ПДП, это запрос к арбитру шины. Что потом будет делать (новый) ведущий - это уже второй вопрос.