Может просто пока их просто не отпаивать (если есть такая возможность)? Просто временно оставить провода подпаяными к плате, а с другой стороны пока что припаять диагностический разъем.Цитата:
Сообщение от cy6
Вид для печати
Может просто пока их просто не отпаивать (если есть такая возможность)? Просто временно оставить провода подпаяными к плате, а с другой стороны пока что припаять диагностический разъем.Цитата:
Сообщение от cy6
Чуть выше я приводила диаграммы "шинного анализатора", что процессор не стартует. Почти вся работа с ШД, ША и ШУ, происходит на нижней плате.Цитата:
Сообщение от perestoronin
Верхняя плата, почти не должна влиять на чтение команд из ПЗУ, вроде бы.
Она поставляет для нижней: тактовую частоту (F1, F2), управляющие сигналы: STROBE (для формирования сигналов ШУ из байта состояния с ШД) и READY (для торможения процессора).
Логично было было бы предположить, что если работают эти сигналы, а также "порча" ШД не происходит, то процессор должен выполнять блок нициализации из ПЗУ.
На вывод на ШД подключена только один корпус верхней платы - DD39. И он был проверен. Через этот регистр, считываются данные из ОЗУ.
Следовательно, процессор не стартует из-за проблем с сигналом STROBE и/или READY. Сигнал STROBE формируется конденсатором C32, на основании тактовой частоты F1. Сигнал READY формируется ПЛМ DD17.
Выводы DD16 не содержат "ничего интересного" для запуска процессора. Она управляет своими же мультиплексорами (мультиплексоры ОЗУ и регенерация), формирует сигналы STVD и SND28/ для "видео-блока". Притом, на нижнюю плату попадает только SND28/.
п/о для Saleae Logic/Цитата:
Сообщение от perestoronin
Есть тестовая ПЗУ для ПК8000 ?Цитата:
Сообщение от cy6
Все дело в том, что без работающего ОЗУ с рабочей ПЗУ ничего не "стартанет". Любой разгрузчик при запуске из ПЗУ сразу же требует себе под стек ОЗУ и если с таковым проблемы, то на том весь старт и заканчивается и все "виснет". Вероятно именно это и наблюдаете.
Потому предлагаю начинать анализ с DD16 или же искать (или писать) тестовое ПЗУ, которое до обнаружения проблем с ОЗУ не требует для своей работы стек в ОЗУ.
Если тестовой ПЗУ (не требующей стека в ОЗУ) нет в природе, то за основу можно взять тестовое ПЗУ скажем от Океана, и адаптировать его под ПК8000.
Дизассемблированный тест Океана выложен здесь
Также у меня вопрос, а можно ли перевести ПК8000 в пошаговый режим ? Пусть не таким навороченными способом с помощью хитрых плат как в случае с Иришей, но может хотя бы таким простым способом как в случае с Океаном с помощью схемы из двух простых микросхем логики ?
- - - Добавлено - - -
А есть альтернативное ПО в исходных кодах для работы с данными этого анализатора?Цитата:
Сообщение от cy6
Заготовку нашел https://github.com/saleae/SampleAnalyzer но и она к сожалению требует для сборки бинарные библиотеки https://github.com/saleae/AnalyzerSDK
А есть ли готовый кастомизированный анализатор сырых данных от логера (тех, что Вы ранее публиковали для DD17) заточенный под анализ функций булевой логики ? скажем тех же PLS100, но работающих только в режиме комбинаторных схем (как раз наш случай для DD16 и DD17).
PS. Идеальный случай - если анализатор нарисует сам формулу функции интересующего нас выхода от входных линий.
Все что останется нам - сравнить её формулу с той, что выдает нам jedutil в виде EQN из самих прошивок.
В тех логах что Вы прислали, кроме выходных линий на PLS100 (DD17), все её входы, включая сигнал выборки корпуса OE приведены ?
PS. Может кто-то захочет поупражняться в программировании ?
Цитата:
Сообщение от perestoronin
Вот? как раз два вопроса, которая я начала задавать ПК8000 - создание тестового ПЗУ и методики типовой проверки.Цитата:
Сообщение от perestoronin
Тестового ПЗУ пока нет, а шагалку тоже надо разрабатывать, в разрыв КТ1 и КТ2 (сигнал READY). :)
ПЗУ Суры уже сделано достаточно грамотно, оно не использует команд работы со стеком (CALL/RET, PUSH/POP) и ячейки ОЗУ, на стадии первоначальной инициализации.Цитата:
Сообщение от perestoronin
Дизассемблировано 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] уменьшается).
Не встречала, но возможно и есть. Хотя, у него уже есть встроенный анализ современных протоколов, в родном п/о.Цитата:
Сообщение от perestoronin
Если в скобках младшие 8 бит адреса, а рядом - данные, то эта рабочая конфигурация странная.Цитата:
Сообщение от cy6
Первый байт не буду трогать, начиная с F3 должно быть так
(00) F3 (01) C3 (02) 20 (03) 29 (20) 3E (21) 84 (22) D3 (23) 87 (87) 84 (24) 3E (25) 00
т.е. даже тут много странностей. Жирным выделил запись в порт.
Как я понимаю, это шд и ша не прямо с процессора, т.к. были бы видны еще и слова состояния.
Попробую разобрать "функцию" 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, а на оригинале, полный полет фантазии, похоже. :v2_dizzy_tired2:
Оригинальную схему можно увидеть в Сура ПК 8000. Схемы принципиальные электрические. Книга 4.Цитата:
Сообщение от micklab.ru/PK8000.htm
Да, это чтение с разъема расширения. Притом, RESET пришлось туда явно выводить проводом, так как он не припаян. Что это слово состояния, на разъеме не узнать, нужен STROBE.Цитата:
Сообщение от ivagor
Cлово состояния иногда глотает ардуина, так как таймауты на скетче не очень точные, мягко говоря. Это нормально. :)
Чтобы это хорошо работало, надо переписывать все на avr-asm и таймауты считать. Либо выводить на разъем еще и STROBE. Верно?
Возможно стоит разобраться для начала с адресами, которые выходят на разъем расширения. Или попробовать взять их из другого места. Смотрю на дамп с новой платы и там во многих местах адреса каждый цикл (или это не каждый цикл?) уменьшаются на 2. Процессор подряд так не может, уменьшить за раз адрес на 2 он может только командой перехода.
- - - Добавлено - - -
Кстати, еще момент. Если процессор реагирует на прерывания, значит он DI не прочитал, до него этот код команды не дошел.
А как же вход в прерывание, по сигналу INT? Он вроде должен пытаться сохранять текущий адрес из [PC], это же два байта.Цитата:
Сообщение от ivagor
Видим байт состояние A2, и первую команду "DI".Код:Start
0000: (FF)A2 (00)F3
Возможно, процессор не дожидается сигнала READY, находясь в цикле ожидания.
И получает сигнал INT.
О чем нам говорит адрес 38h, который является вектором прерывания 7 (RST 7), и первую команду этого вектора,конечно же JMP.Код:(38)C3 (38)C3
Прерывание 7 вызывается всегда, как я понимаю. Поскольку, ШД подтянута к логической "1", а вектор прерывания ни одно из устройств явно не выставляет.
Цитата:
Сообщение от ivagor
Цитата:
Сообщение от cy6
Вход в прерывание, pop, ret - все они читают из стека по одному байту, за цикл адрес уменьшается на 1. - туплюЦитата:
Сообщение от cy6
rst, push, call - записывают в стек по одному байту, за цикл адрес уменьшается на 1. - а так правильно
Цитата:
Сообщение от cy6
Команда DI может и была где-то на шине данных в компе, но процессор по каким-то причинам этот код команды не прочитал и команду не выполнил. Если бы выполнил, то перехода по прерыванию на 38h не было бы, адрес 38 выставил процессор.Цитата:
Сообщение от cy6
Имхо с чтения команд процессором стоит начать.
И на этом месте возвращаемся к тому, что требуется для дальнейшего запуска рабочее ОЗУ, так как стек находится именно в нем.Цитата:
Сообщение от ivagor
Или тестое ПЗУ, которое может делать хотя бы "бииип" без использования ОЗУ.
Можно мне набраться наглости и попросить Вас сваять сваять самый простой тестер-бииипер для ПК8000 без использования стека и ОЗУ для его прошивки в ПЗУ ? Пусть этот биипер заодно пишет в разные свободные порты разных ВВ55 байтики 55h и ААh чередуя их примерно два раза в секунду ну или как там получится ?
Затем его следует проверить на рабочей плате и далее уже мучить этим тестом в ПЗУ новодельные платы.