Перестали работать тестовые программы btime, minfo, ulatest3.

Перестали работать тестовые программы btime, minfo, ulatest3 на клоне Спектр Калужский вариант 48, хотя месяц назад работали. Другие программы и игры работают без изменений и глюков. В чём может быть дело? Эти три теста после старта ресетятся. Может не туда пишу куда надо, но вопрос касается софта в некоторой степени.

Прогнал другие тесты, вроде всё как было раньше.
TEST430 1
Вложение 59994
https://yadi.sk/i/tw65kKE33FEyZ8
https://yadi.sk/i/tw65kKE33FEyZ8

TEST430 2
Вложение 59985
https://yadi.sk/i/7CS-jHnZ3FEypb
https://yadi.sk/i/7CS-jHnZ3FEypb

TEST430 3
Вложение 59986
https://yadi.sk/i/kbF0JoUQ3FEyuC
https://yadi.sk/i/kbF0JoUQ3FEyuC

A48MT
Вложение 59987
https://yadi.sk/i/rezETPpl3FEz2E
https://yadi.sk/i/rezETPpl3FEz2E

IntTest
Вложение 59989
https://yadi.sk/i/TNU-phhM3FEzE4
https://yadi.sk/i/TNU-phhM3FEzE4

PD
Вложение 59991
https://yadi.sk/i/A1vAaXw23FEzSV
https://yadi.sk/i/A1vAaXw23FEzSV

PLATFORM
Вложение 59992
https://yadi.sk/i/AQgRDJUF3FEzXc
https://yadi.sk/i/AQgRDJUF3FEzXc

TactsTest
Вложение 59993
https://yadi.sk/i/aHe1nm2M3FF2cD
https://yadi.sk/i/aHe1nm2M3FF2cD

mctest2
Вложение 59990
https://yadi.sk/i/B6amLep33FF2hz
https://yadi.sk/i/B6amLep33FF2hz


Попробовал методом тыка заставить работать btime.
Лист из дебагера
Вложение 59988
https://yadi.sk/i/YyKaMJ-T3FF3CL
https://yadi.sk/i/YyKaMJ-T3FF3CL
Переправил все rst 0 на nop в коде программы. Она заработала. Потом по одному вернул rst o на место. Таким образом нашёл 2 rst 0 которые рестартят программу.Их выделил зелёным. Может кто из програмистов скажет что не так в программе (в смысле с компом) , почему программа переходит к этим зелёным командам?
Скажу честно я не силён в программировании, ну так по мелочи, и не понял предназначения выделеных красным учасков кода. Похоже на какие то ловушки для чего то. Для чего rst 0? И на первый взгляд программа до них не доходит. Но если поменять хоть один halt выделеный красным на nop, то программа не работает(ресетится). Значит программа доходит до halt, но почему не выполняется rst 0 следующий за ней? Прошерстил литературу по поводу Halt и rst 0 - ничего необычного что бы делали эти две команды в месте не нашёл. Далее тупик.

возможно `поплыл` кондёр в RC цепочке которая отвечает за длительность сигнала int

rst#0 это вообще-то программный сброс компа.
после нажатия на кнопку reset код начинается выполняться с адреса #0000 (то есть из ПЗУ),
также и после rst#0

в твоём примере что-то выполняется в подпрограмме на im2

С конденсатором уже поиграл, схему выработки int изменил, точку снятия тоесть по времени немного раньше и немного позже тоже изменил но без результатно.
В пзу зашита прошивка турбо 90. Поэтому команда rst#0 не приводит к стиранию бейсик программы и машинного кода в памяти. Только по этому я безконечно долго могу проводить эксперименты с ресетами пока не испортится содержимое памяти.
Трассировка программы показывает что перед переходом по im 2 создаётся таблица вектора перехода по адресу FDDO-FE00 чтобы исключить помехи на шине данных в момент выборки вектора прерывания. Адрес перехода таблицы при любых значениях вектора равен FEFE. Проверил, с таблицей всё в порядке. По адресу FEFE расположена программа возврата из прерывания. Последний адрес записаный в стёк перед IM 2 имеет значение C0A5. Программа возврата увеличивает регистр стёка после IM 2 на 2 и возвращает по адресу C0A5. А там расположена засада INC HL, JP COA5 которая должна зациклить комп. Это моя логика происходяшего процесса но она ошибочна, так как на самом деле этого не поисходит. В реальном времени происходит как то по другому. Трасировщик или дебагер не может нормально выполнить команду IM 2 в пошаговом режиме - происходит порча данных и на реале и на виртуалке. Так что и тут засада. Могу сказать только что, автор такого тут нарамудил, что мне разобрать не по силам. Даже имея исходники https://yadi.sk/d/7-oaIq9w3FJTq9я не понимаю как это работает.

Возможно, плавает длительность кадра - время в тактах между прерываниями. В оригинальном спеке она вроде как завязана на кадровую развертку, а как на этом клоне - не знаю. По задумке автора, до команд RST0 процессор доходить нигде не должен - до них должно произойти прерывание, которое обходит их инкрементом SP, т.е. возврат из прерывания происходит на заранее загнанный в стек адрес.

Длительность кадра задана жёстко как в балтике и ленинграде счётчиками. И что до RST 0 доходить не должно я тоже понимаю , но доходит в двух случаях. А вот что это за случаи я понять не могу. Процессор поменял без результатно. Есть идея поменять пзу и озу. ради экперимента. Но это несколько напрягает.

Похоже, если раньше работало, а сейчас не работает, изменились условия торможения процессора - возможно, торможение стало меняться от кадра к кадру, соответственно, длительность кадра для процессора тоже меняется. Программы в начале работы вычисляют длительность кадра, в расчете, что она будет постоянной, а она меняется, слетают вычисленные программные задержки, и выполняется RST0. Вряд ли дело в проце, ПЗУ или ОЗУ, возможно, дело в той части схемы, которая тормозит процессор.

То есть проверить формирование сигнала WAIT ? Попробую пробежать по всем сигналам , может выловлю что небудь.

Проверил счётчики.
Формирование всех сигналов.
Длительность кадров.
Длительность синхоимпульсов. ССИ = 10 мкс, КСИ = 256 мкс Ну тут есть отличия от тв стандарта, но в каждом кадре всё одинаково.
Поиграл длительностью INT от24 до 40 и более.
Заменил пзу и озу.
Проверил WAIT, ничего подозрительного в формировании не заметил кроме того что он формируется из MREQ, M1, WRBUF , а в ленинграде участвует ешё RD.
В итоге всё без изменений. Я уже начинаю думать, а не приснилось ли мне случаем, что они работали.
Может ещё советы будут что проверить?
А вообще эти тесты на всех клонах должны идти или есть какие то ограничения?

Проверил на эмуле ZXMAK2 под моделью Ленинград-1 - сбрасываются.

Вот в этой теме есть полезная информация http://zx-pk.ru/threads/21212-tajmin...8-)/page2.html. Проведя эксперименты с эмулятором ZXMAK2 пришёл к выводу, что все клоны имеющие соотношение takt/int = 65184/1 и количество линий в кадре 291 с этими програмками не работают и похоже мне всё же приснилось, что они работали. Может какое-то влияние оказывает торможение памяти.
Остаётся не понятным код программы - что происходит когда отрабатывают 69888 тактов? Почему не доходит до rst 0? Тут какая то хитрость. Если тактов меньше и int приходит раньше, то доходт до rst 0.

код

Код:

---

ALIGNINT:
        ld de, _align
        push de
        ld de, _try
        push de
        im 2
        halt
        rst 0                ; the interrupt handler never returns (it pops the last value off the stack) Обработчик прерывания никогда не возвращается (он выталкивает последнее значение из стека)
_try                        ; 46T+
        push de                ; 57T+

        ld bc,32677        ; 67T+
        call DELAY        ; 32744T+
        ld bc,(FRAMET)        ; 32764T+

        call DELAY        ; 69884T+
        nop                ; 69888T+ - the idea seems to be that if we run for exactly FRAME tacts, we are perfectly aligned Идея состоит в том, что если Мы бежим точно за тактами FRAME, Мы идеально выровнены
        pop de
        rst 0                ; really crazy way to handle timing errors (e.g. it crashes on Scorpion due to unaccounted M1 delays)  Действительно сумасшедший способ обработки временных ошибок (Например, он терпит крушение на Scorpion из-за неучтенных задержек M1)

_align                        ; 55T
        inc de
        halt
        rst 0

---