ПК-6128Ц: Обсуждение

[Improver]

Для варианта типа ...

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

Помню, что это READY процессора, куда еще идет не смотрел.

На вывод RA (35) процессора и на шину ВУ, где он обозначен, как "RATO".

Забыл - зачем активный RAS в крайних правых столбцах? Что, у 6128 отдельная от обновления экрана регенерация?

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

Немного инфы по "фаршу" в адресах, по схеме получается у ПК6128 такая раскладка:

RAS   A2   A1   A0  A12  A11  A10   A9   A8
CAS  A16  A15  A13   A7   A6   A5   A4   A3

A14 -- выбор комплекта микросхем для обращения, A15 и A16 выставляется по значению A15 процессора и записанной в порт 0Eh конфигурации.

[Advertiser]

[ivagor]

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

Т.е. за 4 такта (3 МГц) видеоадрес (часть для ras) меняется несколько раз?

[Improver]

Т.е. за 4 такта (3 МГц) видеоадрес (часть для ras) меняется несколько раз?

Нет, смена адреса происходит один раз, по такту МХ2 (750кГц). Если вопрос про вторую, придуманную мной регенерацию, то там по RAS подаётся адрес для CAS, кажется такой финт был на Векторе... Но, повторюсь, что если это всё мои заблуждения, то я совершенно не буду возражать по её удалению.

[ivagor]

смена адреса происходит один раз

Значит чтения видеоданных вполне достаточно для регенерации.
Вобще, если они все же использовали страничное чтение через 166 нс, то могли пойти дальше и прочитать так все 4 байта из одной линейки озу. И еще остается время для одного доступа проца. Вероятно их остановило то, что такой экстремальный для РУ5Г режим приводил к проблемам с надежностью работы.

[Improver]

Вот ещё есть идея, можно немного увеличить длительность CAS, но между двумя CAS так и останется полтакта 6МГц:

D0(RATO) 1 1 1 1  1 1 1 1  0 0 0 0  0 0 0 0
D1(RAS)  1 1 0 0  0 0 0 1  1 0 0 0  0 0 0 0 
D2(CAS)  1 1 1 1  0 0 0 0  1 1 1 0  0 1 0 0
D3(MX1)  1 1 1 0  0 1 1 1  1 1 0 0  0 0 0 1
D4(MX2)  0 0 0 0  0 0 0 0  1 1 1 1  1 1 1 1
D5(FR6)  1 1 1 1  1 1 1 1  1 1 1 1  0 1 1 1
D6(FR7)  1 1 1 1  1 1 1 1  1 1 1 1  1 1 0 1
D7(FR1)  1 1 1 1  1 1 1 1  1 1 0 0  0 1 1 1
         ^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^
               ОЗУ               Экран

ivagor, как думаешь, такой вариант будет лучше для микросхем памяти?

[ivagor]

Официально (смотрю по МПССиС 1985/3, стр. 93) tCP (длительность интервала между сигналами /cas в страничном режиме) у РУ5Г 120 нс, т.е. формальные требования не выполняются. Но если можно удлинить cas, то почему бы и нет, хуже не станет, скорее наоборот. Насколько я понимаю, cas можно сделать длинным, все равно при чтении данные появятся с определенной задержкой (tCAC) относительно спада /cas. У РУ5Г официально tCAC=120 нс, но на практике меньше, Mick смотрел анализатором.

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

Доступ процессора надо аккуратнее разобрать. Я бы сжал ras и cas примерно до

ras  1 0 0 0 1 1 ... 
cas  1 1 0 0 1 1 ...

чтобы выставление адреса и чтение или запись уложились в один такт 3 МГц. Сюда должен попасть T2 процессора.
И с RATO (READY) надо внимательно посмотреть. READY должен быть активен (или неактивен) за некоторое время (tRYS) до начала второго такта проца, чтобы проц его (READY) воспринял. Скорее всего надо сузить активную область READY - примерно от середины первого такта до середины второго.

[Improver]

tCP (длительность интервала между сигналами /cas в страничном режиме) у РУ5Г 120 нс

А там как измеряется? Это время от завершения первого CAS до начала второго, или время между началами двух CAS? Если между началами, то там 249нс получается, в последнем варианте, но между сигналами всего 83нс.

при чтении данные появятся с определенной задержкой (tCAC) относительно спада /cas. У РУ5Г официально tCAC=120 нс

А вот с этим может быть проблема -- второе чтение в сдвиговый регистр выполняется через 83нс после CAS, и это никак не исправить, надежда только на то, что практически там будет меньше.

Доступ процессора надо аккуратнее разобрать. Я бы сжал ras и cas примерно до

Вполне возможно. А есть хорошая документация по ВМ85? Я нашёл неплохую, но там картинки не приложили, нет диаграмм работы.

[ivagor]

в последнем варианте, но между сигналами всего 83нс

Речь про это, поэтому и нехорошо.

А вот с этим может быть проблема -- второе чтение в сдвиговый регистр выполняется через 83нс после CAS

Насколько я помню записи анализатора Micka, в реальности данные появлялись примерно через 70-90 нс, в зависимости от варианта озушки. Понятно, что для серийного устройства нехорошо на это рассчитывать.
В принципе это ведь не совсем реплика, можно сделать иначе. Читаем первые 2 байта в промежуточные регистры. Потом читаем вторые 2 байта из озу и переписываем 2 байта из промежуточных регистров. И требования к скорости чтения видеоданных резко ослабляются.

есть хорошая документация по ВМ85?

Например вот, там рядом вроде еще есть.

[Improver]

Понятно, что для серийного устройства нехорошо на это рассчитывать.

Вот, наверно, поэтому и было так мало выпущено ПК6128...

В принципе это ведь не совсем реплика, можно сделать иначе.

В данном случае это ещё не новый проект, не реплика, а попытка восстановления схемы ПК6128, попытка понять, как он работал. Что-то менять в схеме будем на следующем этапе...

Читаем первые 2 байта в промежуточные регистры. Потом читаем вторые 2 байта из озу и переписываем 2 байта из промежуточных регистров. И требования к скорости чтения видеоданных резко ослабляются.

Есть такая микруха, 74HCT597, она по функционалу идентична К555ИР10, но в её составе уже есть регистр на входе параллельной загрузки данных, который запоминает 8 бит по отдельному тактовому сигналу, в остальном их работа не отличается. Заменить на неё D45 и D47 и необходимость жёсткой привязки по времени загрузки отпадёт. И даже триггер D49 станет ненужным. Примерно также я и делал в своей графической карте.

Например вот, там рядом вроде еще есть.

Спасибо, поизучаю.

[Improver]

Вот что получается по выравниванию частот по процессору...

По мануалам, RATO должен начинаться за 100нс (t_RYS) до переднего фронта тактовой частоты на такте Т2, и заканчиваться за такое же время до переднего фронта тактовой частоты на цикле ожидания. Тактовая частота отстаёт от фронтов входной частоты на t_XKR = 25..120нс, итого, получается, нули в RATO должны начаться до задержки минимум за 2 бита (передний фронт тактовой частоты) + 1 бит (=~83нс), итого за три бита. Тут пока всё просто.

Чтение данных из памяти производится на тактах Т2 и Т3, точнее сказать от начала Т1 в момент t_AD=(5/2+N)T - 150, где N -- число циклов ожидания. Получается t_AD =~683нс + N*T. В нашем случае это значит, что на Т3 в ШД уже должны быть данные. Возможно стоит сместить чтение графики на 8 бит влево (в предыдущем варианте прошивки), совместив его с Т1 и Т2, когда обращения к памяти нет, а чтение данных из памяти выполнить после, получается примерно так:

D0(RATO) 0 0 0 0  0 0 0 0  1 1 1 1  1 1 1 1
D1(RAS)  1 0 0 0  0 0 0 1  1 0 0 0  0 0 0 1
D2(CAS)  1 1 1 0  0 1 0 0  1 1 1 0  0 0 0 0
D3(MX1)  1 1 0 0  0 0 0 1  1 1 0 0  1 1 1 1
D4(MX2)  1 1 1 1  1 1 1 1  0 0 0 0  0 0 0 0
D5(FR6)  1 1 1 1  0 1 1 1  1 1 1 1  1 1 1 1
D6(FR7)  1 1 1 1  1 1 0 1  1 1 1 1  1 1 1 1
D7(FR1)  1 1 0 0  0 1 1 1  1 1 1 1  1 1 1 1
         ^^^^^^^^^^^^^^^^  ^^^^^^^^^^^^^^^^
               Экран             ОЗУ
Циклы:     Т1       Т2       TW       T3
           Т4       Т1       T2       T3... -- норм

        ...Т2       ТW       TW       T3
           Т4       Т1       T2       T3... -- норм

          ...       Т1       T2       T3
           Т4       Т1       T2       T3... -- норм

                    ...      Т1       T2
           Т3       ...                     -- плохо

В общем, если Т2 попадёт на последнюю четвёрку адресов РЕ3, то задержки не будет и на Т3 процессор не получит данные. Такая ситуация возможна? Это я только прикинул по циклам самого простого MOV, а дальше я тут что-то начинаю путаться...