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

[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 - примерно от середины первого такта до середины второго.

[Advertiser]

[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 станет ненужным. Примерно также я и делал в своей графической карте.

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

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