У жены комп ласты склеил: из трех винтов два недоступны. Оказалось, что у одного из винтов шлейф питания где-то плохо контачить стал с годами. Чуть коснёшся - винт заводится, чуть шевельнешь - опять гасится. А второй от скуки, за компанию. Где-то саташный канал, что ли, завешивают. Обжал, почистил ластиком - заработало. Пока работает.
Одновременно осцилограф на моём компе че-то на драйвера ругается. Туды-сюды, день потерял на попытку научным тыком всё это заставить работать, потом ночью винду переставлял. В результате.
А зачем осцилограф ? А вот:
1) Лисин стал на девятке гавкать на какую-то комбинацию регистров управления. То ли при прогреве компа, то ли ещё почему-то. Стал проверять:
Должно вернуться 16 штук BF. Возвращается то 3F, то ещё что нибудь интересное. И только на этой комбинации.
Причем не на холодной машине, а только после выхода из Лисина.
Анализатор показывает интересную картинку:
На шине данных сперва старший разряд адреса мелькает: C2, а потом ответ модуля: BF. Многие линии шины данных переключаются. И на анализаторе видно, что не совсем сразу: некоторое время линия, переходящая из 1 в 0 сперва качается. Обычно недолго - допустим, 50 нс. Но иногда, почему-то, дольше: может и 100 качаться. А тут уже проц читает шину. И получает мусор.
Отодвинул фазу вывода данных на шину на такт раньше. Заодно перевёл все управляющие шины в низкий ток и slow slew rate. Вроде помогло. Заодно перевёл такт анализа шины адреса тоже на один раньше.
Очень хотел это всё раглядеть на осциллографе, но увы - pcsu1000 не вывозит настолько кратковременные нестабильные сигналы. Формально он до 60 МГц, но это только для периодических сигналов: он пытается их анализировать статистически, а тут со статистикой напряг. Но всё таки кой что он показал: какие-то пульсации там правда накапливаются. Хотя и ниже 1.4 вольта. Но анализатор-то показывает из выше 1.4...
2) Но теперь Лисин стал стабильно гавкать на тесте "МАРШ". И только на нём. Зато гавкает радостно и много.
Настолько, что даже удалось написать прогу, повторяющую эффект:
loop:
lda #$FF
sta $40F8
lda $40F8
cmp #$FF
bne next
inc $800
next:
jmp loop
Включаем C2A0:0 и C706.
И получаем в левом верхнем углу бешенный счётчик сбоев.
Тут осциллограф опять пассует, а вот анализатор показывает кой что интересное:
на шине данных чтение процом команды LDA $40F8 даёт в конце байт $40, а при её последующем исполнении модуль-новодел выдаёт FF на шину.
И начинается РАСКОЛБАС! (не каждый раз, но хотя бы даже это случалось 1/20 - всё равно же работать невозможно).
Все биты резко подлетают к высокому уровню (вероятно, из-за того, что на предыдущем этапе борьбы выдача была подвинута ближе к фронту F0, эффект обострился), и так хорошо они подлетают, что даже тянут вверх линию "ВК" у буферов шины адреса ! Причем это происходит опосредованно, т.е. на входе D13.1 ничего не фиксируется, а вот на его выходе уже кой что есть. Я так думаю: линии данных до проца идут параллельно линии "ВК", если данные подлетают резко вверх, то магнитным полем они затягивают к верху и "ВК" (а может это паразитные ёмкости внутри буферов?).
Процесс очень кратковременный, но матрица успевает среагировать и так как адрес изменился (а может какой-то другой сигнал влияет), она моментально отключает выходной буфер. Уровни резко падают (может они даже не успевают достигать high..) и всю шину, включая F0 и даже немного задевая 14МГц, начинает бить в конвульсиях.
ЦП на это мало обращает внимания, но, в результате, LDA $40F8 получает всё что угодно, но - преимущественно - нули.
Теперь понимаете, какой гемор для разработчиков был переход на более плотный монтаж девятки и почему под пузиком материнки девятки тянутся два толстых провода от разъёма питания? Это питание буфера шины данных.
По хорошему, на плате новодела, вероятно, следует предусмотреть резисторы последовательно с шиной.
Но пока победил это так: сигнал DIR выходного буфера и OE SRAM протащил через RS-триггер: в одну сторону включаю по условию обращения к модулю (совпадение адресов, конфигураций, номера фазы...), а выключаю по спаду F0 на очередном такте 14 МГц. Похоже, достаточно задушить одну пульсацию, чтобы она не переросла за пару периодов в ураган мусора.
{ Тут расчёт на то, что даже если на входе SRAM кратковременно изменится адрес, это отразится на выходе SRAM довольно таки не быстро. Главное, чтобы data_bus хоть какое-то время не болталась во все стороны. Пусть успокоение займет даже 100 нс, у нас на самом деле ещё много времени до fall F0, когда ЦП будет захватывать данные с data_bus }
3 или 0) Кажется, удалось найти решение для управления БлкПЗУ. Сделал управление 3-state: если нужно отключить ПЗУ, перевожу в low, а в момент fall F0 до очередного raise 14 MHz задираю в High. В остальных случаях Z-state.
Таким образом получается управлять линией с точностью до периода F0, позволяя разным модулям управлять линией без конфликтов.
Если нужно работать в паре с оригиналом, то модули нужно расставить в порядке: новодел - менее приоритетный, оригинал - более приоритетный. Альтера задушит рт13, если будет нужно, а оригинал может заблокировать новодел по цепи приоритета.
Во всяком случае два новодела тест "ЛОГ" у Лисина начали проходить. Но это было ещё до вылезания других багов .....
