ПК8000 - Печатные платы

[alvis]

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

Может просто пока их просто не отпаивать (если есть такая возможность)? Просто временно оставить провода подпаяными к плате, а с другой стороны пока что припаять диагностический разъем.

[cy6]

А почему анализ начали с DD17, а не с DD16 ? С DD16 все ок ?

Чуть выше я приводила диаграммы "шинного анализатора", что процессор не стартует. Почти вся работа с ШД, ША и ШУ, происходит на нижней плате.

Верхняя плата, почти не должна влиять на чтение команд из ПЗУ, вроде бы.
Она поставляет для нижней: тактовую частоту (F1, F2), управляющие сигналы: STROBE (для формирования сигналов ШУ из байта состояния с ШД) и READY (для торможения процессора).
Логично было было бы предположить, что если работают эти сигналы, а также "порча" ШД не происходит, то процессор должен выполнять блок нициализации из ПЗУ.
На вывод на ШД подключена только один корпус верхней платы - DD39. И он был проверен. Через этот регистр, считываются данные из ОЗУ.

Следовательно, процессор не стартует из-за проблем с сигналом STROBE и/или READY. Сигнал STROBE формируется конденсатором C32, на основании тактовой частоты F1. Сигнал READY формируется ПЛМ DD17.

Выводы DD16 не содержат "ничего интересного" для запуска процессора. Она управляет своими же мультиплексорами (мультиплексоры ОЗУ и регенерация), формирует сигналы STVD и SND28/ для "видео-блока". Притом, на нижнюю плату попадает только SND28/.

Какими удобными программами можно мне локально смотреть файлы из архива DD17_logic_data.rar ? Желательно под linux.

п/о для Saleae Logic/

[perestoronin]

Следовательно, процессор не стартует из-за проблем

Есть тестовая ПЗУ для ПК8000 ?
Все дело в том, что без работающего ОЗУ с рабочей ПЗУ ничего не "стартанет". Любой разгрузчик при запуске из ПЗУ сразу же требует себе под стек ОЗУ и если с таковым проблемы, то на том весь старт и заканчивается и все "виснет". Вероятно именно это и наблюдаете.

Потому предлагаю начинать анализ с DD16 или же искать (или писать) тестовое ПЗУ, которое до обнаружения проблем с ОЗУ не требует для своей работы стек в ОЗУ.
Если тестовой ПЗУ (не требующей стека в ОЗУ) нет в природе, то за основу можно взять тестовое ПЗУ скажем от Океана, и адаптировать его под ПК8000.
Дизассемблированный тест Океана выложен здесь

Также у меня вопрос, а можно ли перевести ПК8000 в пошаговый режим ? Пусть не таким навороченными способом с помощью хитрых плат как в случае с Иришей, но может хотя бы таким простым способом как в случае с Океаном с помощью схемы из двух простых микросхем логики ?

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

п/о для Saleae Logic/

А есть альтернативное ПО в исходных кодах для работы с данными этого анализатора?

Заготовку нашел https://github.com/saleae/SampleAnalyzer но и она к сожалению требует для сборки бинарные библиотеки https://github.com/saleae/AnalyzerSDK
А есть ли готовый кастомизированный анализатор сырых данных от логера (тех, что Вы ранее публиковали для DD17) заточенный под анализ функций булевой логики ? скажем тех же PLS100, но работающих только в режиме комбинаторных схем (как раз наш случай для DD16 и DD17).
PS. Идеальный случай - если анализатор нарисует сам формулу функции интересующего нас выхода от входных линий.
Все что останется нам - сравнить её формулу с той, что выдает нам jedutil в виде EQN из самих прошивок.

В тех логах что Вы прислали, кроме выходных линий на PLS100 (DD17), все её входы, включая сигнал выборки корпуса OE приведены ?



PS. Может кто-то захочет поупражняться в программировании ?

[cy6]

Есть тестовая ПЗУ для ПК8000 ?

а можно ли перевести ПК8000 в пошаговый режим ?

Вот? как раз два вопроса, которая я начала задавать ПК8000 - создание тестового ПЗУ и методики типовой проверки.
Тестового ПЗУ пока нет, а шагалку тоже надо разрабатывать, в разрыв КТ1 и КТ2 (сигнал READY).

ПЗУ, которое до обнаружения проблем с ОЗУ не требует для своей работы стек в ОЗУ

ПЗУ Суры уже сделано достаточно грамотно, оно не использует команд работы со стеком (CALL/RET, PUSH/POP) и ячейки ОЗУ, на стадии первоначальной инициализации.
Дизассемблировано demetrius2003

ROM:0000                 di
ROM:0001                 jmp     INIT
...
ROM:2920 ; ---------------------------------------------------------------------------
ROM:2920 ; START OF FUNCTION CHUNK FOR START
ROM:2920
ROM:2920 INIT:                                   ; CODE XREF: START+1j
ROM:2920                 mvi     a, 81h ; 'Á'
ROM:2922                 out     87h
ROM:2924                 mvi     a, 0
ROM:2926                 out     84h
ROM:2928                 mvi     a, 82h ; 'Â'
ROM:292A                 out     83h
ROM:292C                 mvi     a, 0FCh ; '¹'
ROM:292E                 out     80h
ROM:2930                 mvi     a, 0DFh ; '-'
ROM:2932                 out     86h
ROM:2934                 mvi     a, 5
ROM:2936                 out     87h
ROM:2938                 mvi     a, 77h ; 'w'
ROM:293A                 out     88h

И только далее начинает использоваться ОЗУ, встроенный мини-тест ОЗУ

ROM:293C
ROM:293C loc_293C:                               ; CODE XREF: START+2951j
ROM:293C                 lxi     b, 0
ROM:293F                 lxi     h, 0F000h
ROM:2942
ROM:2942 loc_2942:                               ; CODE XREF: START+294Cj
ROM:2942                 xra     a
ROM:2943                 mov     m, a
ROM:2944                 cmp     m
ROM:2945                 jz      loc_2949
ROM:2948                 inx     b
ROM:2949
ROM:2949 loc_2949:                               ; CODE XREF: START+2945j
ROM:2949                 inx     h
ROM:294A                 mov     a, h
ROM:294B                 ora     l
ROM:294C                 jnz     loc_2942
ROM:294F                 mov     a, b
ROM:2950                 ora     c
ROM:2951                 jnz     loc_293C
ROM:2954                 lxi     sp, BGSTRAR     ; По этому адресу (&hF7FF) инициализируется SP при INIT
ROM:2957                 lxi     b, 0

В самом конце, начальная установка указателя стека.

Но, если первая команда "di" не отрабатывает (как в случае с моей новодельной верхней платой), то стек начинает использоваться без инициализации (при входе в прерывание процессор автоматически использует стек). Что прекрасно видно на диаграмме шинного анализатора, по характерному уменьшению адреса (при последовательном выполнении команд, адрес обращения к ЗУ [PC] увеличивается, а при использовании стека CALL/PUSH - [SP] уменьшается).

А есть альтернативное ПО в исходных кодах для работы с данными этого анализатора?

Заготовку нашел https://github.com/saleae/SampleAnalyzer
А есть ли готовый кастомизированный анализатор сырых данных от логера (тех, что Вы ранее публиковали для DD17) заточенный под анализ функций булевой логики ? скажем тех же PLS100, но работающих только в режиме комбинаторных схем (как раз наш случай для DD16 и DD17).

Не встречала, но возможно и есть. Хотя, у него уже есть встроенный анализ современных протоколов, в родном п/о.

[ivagor]

Дамп с рабочей конфигурации

Если в скобках младшие 8 бит адреса, а рядом - данные, то эта рабочая конфигурация странная.
Первый байт не буду трогать, начиная с F3 должно быть так
(00) F3 (01) C3 (02) 20 (03) 29 (20) 3E (21) 84 (22) D3 (23) 87 (87) 84 (24) 3E (25) 00
т.е. даже тут много странностей. Жирным выделил запись в порт.
Как я понимаю, это шд и ша не прямо с процессора, т.к. были бы видны еще и слова состояния.

[cy6]

Попробую разобрать "функцию" RDY

Если o12 = RDY (D5), i5 = CSRAM/ (A4), i6 = WRRAM/ (A3), i9 = CSROM/ (A0), i20 = C2 (A15), i21 = C1 (A14), i22 = C0 (A13), i23 = CT (A12)
То

RDY = not(
    (CSRAM/ & not(CT) & C0 & C1 & not(C2))
    or (not(CSROM/) &  not(WRRAM/) & not(CT) & C0)
    or (not(CSROM/) & (WRRAM/ & not(CT) & C0 & C1 & not(C2))
)

/o12 = i5 & /i23 & i22 & i21 & /i20 +
       /i9 & /i6 & /i23 & i22 +
       /i9 & i6 & /i23 & i22 & i21 & /i20

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

Обнаружила, что на схеме Mick'а и на оригинальной схеме, по-разному расписаны выводы А0..А15.
Притом, на схеме Mick'а все соответствует datasheet, а на оригинале, полный полет фантазии, похоже.

6. Электрическая и монтажная схемы платы ПХ3.099.006 (верхняя) в формате pdf - скачать

Оригинальную схему можно увидеть в Сура ПК 8000. Схемы принципиальные электрические. Книга 4.

ут много странностей. Жирным выделил запись в порт.
Как я понимаю, это шд и ша не прямо с процессора, т.к. были бы видны еще и слова состояния.

Да, это чтение с разъема расширения. Притом, RESET пришлось туда явно выводить проводом, так как он не припаян. Что это слово состояния, на разъеме не узнать, нужен STROBE.
Cлово состояния иногда глотает ардуина, так как таймауты на скетче не очень точные, мягко говоря. Это нормально.
Чтобы это хорошо работало, надо переписывать все на avr-asm и таймауты считать. Либо выводить на разъем еще и STROBE. Верно?

[Advertiser]

[ivagor]

Возможно стоит разобраться для начала с адресами, которые выходят на разъем расширения. Или попробовать взять их из другого места. Смотрю на дамп с новой платы и там во многих местах адреса каждый цикл (или это не каждый цикл?) уменьшаются на 2. Процессор подряд так не может, уменьшить за раз адрес на 2 он может только командой перехода.

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

Кстати, еще момент. Если процессор реагирует на прерывания, значит он DI не прочитал, до него этот код команды не дошел.

[cy6]

Смотрю на дамп с новой платы и там во многих местах адреса каждый цикл (или это не каждый цикл?) уменьшаются на 2. Процессор подряд так не может, уменьшить за раз адрес на 2 он может только командой перехода.

А как же вход в прерывание, по сигналу INT? Он вроде должен пытаться сохранять текущий адрес из [PC], это же два байта.

Start

0000: (FF)A2 (00)F3

Видим байт состояние A2, и первую команду "DI".

Возможно, процессор не дожидается сигнала READY, находясь в цикле ожидания.
И получает сигнал INT.

(38)C3 (38)C3

О чем нам говорит адрес 38h, который является вектором прерывания 7 (RST 7), и первую команду этого вектора,конечно же JMP.
Прерывание 7 вызывается всегда, как я понимаю. Поскольку, ШД подтянута к логической "1", а вектор прерывания ни одно из устройств явно не выставляет.

Если процессор реагирует на прерывания, значит он DI не прочитал, до него этот код команды не дошел.

если первая команда "di" не отрабатывает (как в случае с моей новодельной верхней платой), то стек начинает использоваться без инициализации (при входе в прерывание процессор автоматически использует стек).

[ivagor]

А как же вход в прерывание, по сигналу INT? Он вроде должен пытаться сохранять текущий адрес из [PC], это же два байта.

Вход в прерывание, pop, ret - все они читают из стека по одному байту, за цикл адрес уменьшается на 1. - туплю
rst, push, call - записывают в стек по одному байту, за цикл адрес уменьшается на 1. - а так правильно

О чем нам говорит адрес 38h, который является вектором прерывания 7 (RST 7)

Видим байт состояние A2, и первую команду "DI".

Команда DI может и была где-то на шине данных в компе, но процессор по каким-то причинам этот код команды не прочитал и команду не выполнил. Если бы выполнил, то перехода по прерыванию на 38h не было бы, адрес 38 выставил процессор.
Имхо с чтения команд процессором стоит начать.

[perestoronin]

Вход в прерывание, pop, ret - все они читают из стека по одному байту, за цикл адрес уменьшается на 1

И на этом месте возвращаемся к тому, что требуется для дальнейшего запуска рабочее ОЗУ, так как стек находится именно в нем.
Или тестое ПЗУ, которое может делать хотя бы "бииип" без использования ОЗУ.

Можно мне набраться наглости и попросить Вас сваять сваять самый простой тестер-бииипер для ПК8000 без использования стека и ОЗУ для его прошивки в ПЗУ ? Пусть этот биипер заодно пишет в разные свободные порты разных ВВ55 байтики 55h и ААh чередуя их примерно два раза в секунду ну или как там получится ?
Затем его следует проверить на рабочей плате и далее уже мучить этим тестом в ПЗУ новодельные платы.