Скрытый текст
Profi 6.2 Rev.B / 1024
Profi v5.02 /1024/палитра/FDD3,5"/FDD5,25"/HDD130/XT-Keyb/Covox
Profi v4.00 /1024
АТМ Turbo /512/ - собран но еще не запускался
ATM Turbo 2+ v7.10 - собран на 80%
Pentagon 128 - в планах восстановить (раскуроченная плата)
ZXMC20/NemoIDE/AT-Keyb (by Caro)
Revers U8EP3C
Speccy2010, r2
[свернуть]
Чуть выше я приводила диаграммы "шинного анализатора", что процессор не стартует. Почти вся работа с ШД, ША и ШУ, происходит на нижней плате.
Верхняя плата, почти не должна влиять на чтение команд из ПЗУ, вроде бы.
Она поставляет для нижней: тактовую частоту (F1, F2), управляющие сигналы: STROBE (для формирования сигналов ШУ из байта состояния с ШД) и READY (для торможения процессора).
Логично было было бы предположить, что если работают эти сигналы, а также "порча" ШД не происходит, то процессор должен выполнять блок нициализации из ПЗУ.
На вывод на ШД подключена только один корпус верхней платы - DD39. И он был проверен. Через этот регистр, считываются данные из ОЗУ.
Следовательно, процессор не стартует из-за проблем с сигналом STROBE и/или READY. Сигнал STROBE формируется конденсатором C32, на основании тактовой частоты F1. Сигнал READY формируется ПЛМ DD17.
Выводы DD16 не содержат "ничего интересного" для запуска процессора. Она управляет своими же мультиплексорами (мультиплексоры ОЗУ и регенерация), формирует сигналы STVD и SND28/ для "видео-блока". Притом, на нижнюю плату попадает только SND28/.
п/о для Saleae Logic/
Последний раз редактировалось cy6; 14.01.2019 в 07:01.
wtf
Есть тестовая ПЗУ для ПК8000 ?
Все дело в том, что без работающего ОЗУ с рабочей ПЗУ ничего не "стартанет". Любой разгрузчик при запуске из ПЗУ сразу же требует себе под стек ОЗУ и если с таковым проблемы, то на том весь старт и заканчивается и все "виснет". Вероятно именно это и наблюдаете.
Потому предлагаю начинать анализ с DD16 или же искать (или писать) тестовое ПЗУ, которое до обнаружения проблем с ОЗУ не требует для своей работы стек в ОЗУ.
Если тестовой ПЗУ (не требующей стека в ОЗУ) нет в природе, то за основу можно взять тестовое ПЗУ скажем от Океана, и адаптировать его под ПК8000.
Дизассемблированный тест Океана выложен здесь
Также у меня вопрос, а можно ли перевести ПК8000 в пошаговый режим ? Пусть не таким навороченными способом с помощью хитрых плат как в случае с Иришей, но может хотя бы таким простым способом как в случае с Океаном с помощью схемы из двух простых микросхем логики ?
- - - Добавлено - - -
А есть альтернативное ПО в исходных кодах для работы с данными этого анализатора?
Заготовку нашел https://github.com/saleae/SampleAnalyzer но и она к сожалению требует для сборки бинарные библиотеки https://github.com/saleae/AnalyzerSDK
А есть ли готовый кастомизированный анализатор сырых данных от логера (тех, что Вы ранее публиковали для DD17) заточенный под анализ функций булевой логики ? скажем тех же PLS100, но работающих только в режиме комбинаторных схем (как раз наш случай для DD16 и DD17).
PS. Идеальный случай - если анализатор нарисует сам формулу функции интересующего нас выхода от входных линий.
Все что останется нам - сравнить её формулу с той, что выдает нам jedutil в виде EQN из самих прошивок.
В тех логах что Вы прислали, кроме выходных линий на PLS100 (DD17), все её входы, включая сигнал выборки корпуса OE приведены ?
PS. Может кто-то захочет поупражняться в программировании ?
Последний раз редактировалось perestoronin; 14.01.2019 в 07:48.
Вот? как раз два вопроса, которая я начала задавать ПК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] уменьшается).
Не встречала, но возможно и есть. Хотя, у него уже есть встроенный анализ современных протоколов, в родном п/о.
Последний раз редактировалось cy6; 14.01.2019 в 08:08.
wtf
Если в скобках младшие 8 бит адреса, а рядом - данные, то эта рабочая конфигурация странная.
Первый байт не буду трогать, начиная с F3 должно быть так
(00) F3 (01) C3 (02) 20 (03) 29 (20) 3E (21) 84 (22) D3 (23) 87 (87) 84 (24) 3E (25) 00
т.е. даже тут много странностей. Жирным выделил запись в порт.
Как я понимаю, это шд и ша не прямо с процессора, т.к. были бы видны еще и слова состояния.
Последний раз редактировалось ivagor; 14.01.2019 в 08:32. Причина: исправил на пзу весты, там 84 вместо 81 по адресу 2921 и добавил запись в порт для out
Попробую разобрать "функцию" 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, а на оригинале, полный полет фантазии, похоже.
Оригинальную схему можно увидеть в Сура ПК 8000. Схемы принципиальные электрические. Книга 4.Сообщение от micklab.ru/PK8000.htm
Да, это чтение с разъема расширения. Притом, RESET пришлось туда явно выводить проводом, так как он не припаян. Что это слово состояния, на разъеме не узнать, нужен STROBE.
Cлово состояния иногда глотает ардуина, так как таймауты на скетче не очень точные, мягко говоря. Это нормально.
Чтобы это хорошо работало, надо переписывать все на avr-asm и таймауты считать. Либо выводить на разъем еще и STROBE. Верно?
Последний раз редактировалось cy6; 14.01.2019 в 08:52.
wtf
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Возможно стоит разобраться для начала с адресами, которые выходят на разъем расширения. Или попробовать взять их из другого места. Смотрю на дамп с новой платы и там во многих местах адреса каждый цикл (или это не каждый цикл?) уменьшаются на 2. Процессор подряд так не может, уменьшить за раз адрес на 2 он может только командой перехода.
- - - Добавлено - - -
Кстати, еще момент. Если процессор реагирует на прерывания, значит он DI не прочитал, до него этот код команды не дошел.
А как же вход в прерывание, по сигналу INT? Он вроде должен пытаться сохранять текущий адрес из [PC], это же два байта.
Видим байт состояние A2, и первую команду "DI".Код:Start 0000: (FF)A2 (00)F3
Возможно, процессор не дожидается сигнала READY, находясь в цикле ожидания.
И получает сигнал INT.
О чем нам говорит адрес 38h, который является вектором прерывания 7 (RST 7), и первую команду этого вектора,конечно же JMP.Код:(38)C3 (38)C3
Прерывание 7 вызывается всегда, как я понимаю. Поскольку, ШД подтянута к логической "1", а вектор прерывания ни одно из устройств явно не выставляет.
wtf
Вход в прерывание, pop, ret - все они читают из стека по одному байту, за цикл адрес уменьшается на 1. - туплю
rst, push, call - записывают в стек по одному байту, за цикл адрес уменьшается на 1. - а так правильно
Команда DI может и была где-то на шине данных в компе, но процессор по каким-то причинам этот код команды не прочитал и команду не выполнил. Если бы выполнил, то перехода по прерыванию на 38h не было бы, адрес 38 выставил процессор.
Имхо с чтения команд процессором стоит начать.
Последний раз редактировалось ivagor; 14.01.2019 в 09:43. Причина: исправил тупизну про pop и ret
И на этом месте возвращаемся к тому, что требуется для дальнейшего запуска рабочее ОЗУ, так как стек находится именно в нем.
Или тестое ПЗУ, которое может делать хотя бы "бииип" без использования ОЗУ.
Можно мне набраться наглости и попросить Вас сваять сваять самый простой тестер-бииипер для ПК8000 без использования стека и ОЗУ для его прошивки в ПЗУ ? Пусть этот биипер заодно пишет в разные свободные порты разных ВВ55 байтики 55h и ААh чередуя их примерно два раза в секунду ну или как там получится ?
Затем его следует проверить на рабочей плате и далее уже мучить этим тестом в ПЗУ новодельные платы.
Последний раз редактировалось perestoronin; 14.01.2019 в 09:49.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)