"ZX-8080" - Даунгрейд компьютера "Ленинград"

[ivagor]

Помоему не та фотка.

В левом верхнем углу вижу Родоновский с датой 8911

Значит проблема в чтении!

Хорошо, что ты локализовал проблему, но легче было бы с логическим анализатором, правда для полного счастья нужно много каналов (наверно 12-16)

[Advertiser]

[Mick]

Хорошо, что ты локализовал проблему, но легче было бы с логическим анализатором, правда для полного счастья нужно много каналов (наверно 12-16)

Может быть и легче, но пока так как есть.
Посему есть вариант для проверки.
1). Твой вариант - добавить WAIT для чтения из ОЗУ чисто для локализации проблемы.
2). Посмотреть где можно уменьшить время прохождения сигналов на чтении. При условии что у нас вся серия кроме буфера, регистра и защелки слова состояния 555 серии. Возможно что то надо поменять на 1533 или 1531.
4) Посмотреть в сторону небольшого удержания сигнала CAS/ (скажем штатную схему из Весты)

[ivagor]

Небольшая проблема в том, что есть два варианта чтения, когда оно заканчивается в слоте CPU или когда в слоте VPU. Ты, как понимаю из опробованных и предложенных способов лечения, склоняешься к тому, что проблема в первом варианте. Для этого случая еще можно попробовать чуть задержать F1 и F2, если например D35 на панельке, то поставить туда 155 серию, но тогда возможно тактовые сигналы несколько испортятся.

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

п.4 (задержать CAS) случаю с DBIN заканчивающимся в слоте CPU вряд ли поможет

[Mick]

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

Типа того. Вероятно, что сигнал DBIN возможно короче чем предполагаем и WRBUF уже срабатывает в холостую.

[ivagor]

Тут я не полностью согласен, длительность DBIN вряд ли подлежит сомнению, а вот его положение (запаздывание) может в некоторых пределах варьироваться у разных экземпляров процов, в даташите есть параметр tDF - Clock F2 to FBIN delay. Возможно в реале DBIN заканчивается даже позже, чем ты рисовал на временных диаграммах, но и этого не хватает.

[Mick]

Тут поглядел еще раз на схему. У нас чтение по сути начинается с DBIN, а точнее комбинация !DB7 OR !DBIN.
Вот сигнал записи мы удлинили, в принципе можно попробовать начать чтение чуть раньше по DB7 в регистре статуса, а заканчивать уже DBIN.
Хотя это может ничего не дать.

[ivagor]

можно попробовать начать чтение чуть раньше по DB7 в регистре статуса, а заканчивать уже DBIN.

Это поможет случаю, когда чтение начинается во временном слоте CPU, но проблема вроде со случаем, когда DBIN заканчивается в слоте CPU, хотя полной уверенности (у меня) нет.

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

Что касается тормоза который я предлагал. В комплексе (изменение F1, F2 и READY) он должен работать, а вот если сделать только READY=/H1, то вряд ли сработает, READY=0 должно быть (для A-1 и A-2) за 90 нс до окончания высокого уровня F2, а сейчас грубо 70 нс
Если не менять клоки, то можно попробовать использовать в качеcтве READY задержанный на такт проца /SYNC. Как сделать это по нормальному я не буду писать, но возможно прокатит более простой нехороший вариант, если пропустить SYNC через 5 (вряд ли 3 хватит) инверторов небыстрой серии (155, 555)

[zx_]

на cas 100 пикофарад

[Mick]

на cas 100 пикофарад

Ну что это даст, кроме как завала фронтов. Память то работает по сути правильно, проблема с чтением из нее.
Запись ведь работает.

Другой вопрос, что возможно надо сдвинуть F1 и F2 относительно RAS/. Так сказать чтобы раньше они немного приходили.

[ivagor]

надо сдвинуть F1 и F2 относительно RAS/. Так сказать чтобы раньше они немного приходили.

Ты изменил мнение и считаешь, что проблема не в тех случаях, когда DBIN заканчивается в слоте CPU (и проц не успевает прочитать из озу), а в тех, где DBIN начинается в CPU (и там к памяти слишком поздно приходит адрес с проца)?