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

[ivagor]

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

[Mick]

Сменил шину данных на адреса ОЗУ (MA0-MA7)

Быстрый проц - https://yadi.sk/d/FpLAmbr3dTtHRg
Медленный проц - https://yadi.sk/d/qifQL3SG6q_ioQ

[ivagor]

Логи хорошие, криминала не видно, а ошибки с быстрым процом есть. У меня пока нет идей в рамках 16 каналов, разве что можно попробовать (временно) поменять РУ5 на более быстрые озушки, вроде после изменения SC/ ты это не пробовал.

[Mick]

разве что можно попробовать (временно) поменять РУ5 на более быстрые озушки, вроде после изменения SC/ ты это не пробовал.

Хорошо, попробуем поставить и посмотреть.

То есть у тебя подозрения что память не отрабатывает, но тогда как же при 3,5МГц или 4МГц она все успевает.

[ivagor]

У меня иррациональные подозрения, рациональных пока нет. Мало того, что на 3.5 и 4 работает, еще и на логах 3 МГц проблем не видно, кроме того, что читаются неправильные данные из озу. И даже на 3 МГц быстрые процы работают, когда проверка сразу после записи. Как это все непротиворечиво совместить я не знаю.

[Mick]

У меня иррациональные подозрения, рациональных пока нет.

Если рассуждать логически. Синхрогенератор у нас один и не зависит от типа процессора (медленный или быстрый). Значит тут проблем не должно быть.
Смотрим процесс чтения из ОЗУ.
Когда идет сигнал SYNC на шине данных 82h (чтение данных). Данные удерживаются процессором в течении всего SYNC и чуть больше.
Я так понимаю, потом процессор должен отдать шину на чтение данных
Затем возникает непонятный 3F и длится по сути пока RAS/ перейдет в 0. Вероятно как раз в этот момент шина отдана и фиг знает что там.
По срабатыванию CAS/ в 0 сначала всегда какой то мусор и только потом нормальное значение.

Так вот WRBUF у нас активен по H1=0 и H0 =1 (CAS/ =0). То есть в этот момент происходит на шине мусор а потом данные.
Не может ли быть коллизия именно в этот момент, проц шину еще не отпустил, а данные уже ему по CSRAM пытаются вкарячить.

Иными словами, что такое 3F и что такое мусор за ним?

[ivagor]

Если я правильно понял, ты про первый тест, где все CSRAM/ до ошибочного включительно начинались с 3F, а после ошибочного чтения с 43. Это данные из озу под пзу, т.к. чтение из озу каждый H1=0, кроме тех случаев, когда WE/=0. Команды из пзу читаются, адреса на шине адреса, но на шину данных c "нашей" стороны ИР22 они попадают только при CSRAM/=0. Потом (с 3 или 4 теста, я уже забыл, надо уточнить) я стал при старте заполнять все озу (от 0000 до FFFF) значением 0F, что можно увидеть в логах c D0-D7.

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

С 4й версии, там я написал

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

Еще один момент - если возникнет вопрос, почему в 4й версии не всегда CSRAM/ начинается с 0F на ШД, то там легко заметить, что "не 0F" наблюдается в случаях, когда на предыдущий H1=0 попадал SYNC, и в это время на ША была всякая ерунда.

[ivagor]

Есть вопрос по логам, на который я не знаю ответ - в первом логе ошибочное чтение было с tCAC ("время выборки относительно сигнала выбора адреса столбцов") 10 нс, это совершенно нереально для dramины (если не страничные и другие подобные режимы, и то для более быстрых, чем РУ5). Остальные чтения, в т.ч. ошибочные в следующих логах, с tCAC=50-60 нс, что все равно очень быстро для РУ5Г (официально 120 нс, для РУ5Б - 70 нс), но это еще туда-сюда, тем более никто не торопит и cas не убирает, там запас времени есть. Возвращаясь к непонятному - ладно бы через 10 нс данные продолжали дергаться, меняться, но они замерли и не менялись.

[Mick]

Насколько я понял у анализатора частота выборки 100МГц, т.е. 10нс. Как сам заметил там сигналы кратны 10нс и даже если возникнет короткая иголка она будет и анализатор ее уцепит, то она будет длиной 10нс.
Если допустим мусор возникает при смене CAS/ из 1 в 0 к тому же WRBUF становится активным в это же время, то возможно анализатор ухватывает изменение данных из РУ5Г.
Тут вопрос какова задержка в РУ5 с момента выставления адреса до появления данных. В нашем случае сколько времени после CAS/ появляются данные на выходе.

Но вопрос тогда в другом при тех же условиях медленный проц работает без сбоев.
Может там все таки в сигналах процессора (длиннее или короче чем нужно)

[ivagor]

В нашем случае сколько времени после CAS/ появляются данные на выходе.

Это как раз tCAC, и для практически всех чтений в логах это 50-60 нс.
Насчет той ошибки с tCAC как бы 10 нс. Понятно, что в реальности картина скорее следующая: в районе перехода CAS/ в активное состояние переходит в активное состояние и WRBUF и то, что мы видим через 10 нс явно висело на шине MD к тому моменту и теперь дошло на выход ИР22. Но у меня основное недоумение в том, почему дальше, через те самые 50-60 нс не появились нормальные данные из озу, соответствующие текущему адресу и даже никаких дерганий на шине. Ну и почему такое проявление ошибки было одно, а в двух других логах вобще не за что зацепиться.
Кстати, я высказывал в теме мысль, что у медленных процов задержка (по крайней мере некоторых) сигналов относительно клоков больше, чем у быстрых. В логах можно заметить, что CSRAM у медленных запаздывает чуть сильнее, чем у быстрых, на 10-20 нс. Связываю это с большим запаздыванием DBIN у медленных процов. Но это просто наблюдение, не вижу, как это может повлиять на ошибки.