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

Вид для печати

Показывать 40 сообщений этой темы на одной странице

17.08.2022, 11:54
Improver

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

Забыл - зачем активный 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 конфигурации.
17.08.2022, 12:12
ivagor

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

Значит чтения видеоданных вполне достаточно для регенерации.
Вобще, если они все же использовали страничное чтение через 166 нс, то могли пойти дальше и прочитать так все 4 байта из одной линейки озу. И еще остается время для одного доступа проца. Вероятно их остановило то, что такой экстремальный для РУ5Г режим приводил к проблемам с надежностью работы.
17.08.2022, 13:50
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, как думаешь, такой вариант будет лучше для микросхем памяти?
17.08.2022, 15:03
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 - примерно от середины первого такта до середины второго.
17.08.2022, 15:42
Improver

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

Например вот, там рядом вроде еще есть.
17.08.2022, 17:16
Improver

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

Спасибо, поизучаю.
19.08.2022, 14:23
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, а дальше я тут что-то начинаю путаться...

Показывать 40 сообщений этой темы на одной странице