Тайминги Pentagon 128 :)

[ZXMAK]

Вот у нас есть 8 пикселей, или 4 такта. За это время нам нужно получить для следующих 8 пикселей атрибут и сами пиксели. Все эти четыре такта на всех линиях счетчиков одинаковое значение (не берем во внимание младшие линии). Перемешиваем эти линии счетчиков на мультиплексорах и получаем два адреса - адрес атрибута и адрес пикселя. Но вот в каком порядке мы считаем эти данные - это большой вопрос тут масса вариантов.
C-процессор, P-пиксели, A-атрибуты
Все варианты:
CPAP CAPA PCAP ACPA PACP APCA PAPC APAC PAPA APAP
Как видишь мы можем получить наши данные десятью способами, а счетчики остаются на прежних местах.

да, это было бы актуально для случайного набора инструкций. Но это не наш случай. В нашем случае каждый кадр начинается с одного и того-же такта, если вести отсчет от начала сигнала INT. Диаграмма всех сигналов Z80 будет тоже одинаковая для всех кадров, т.к. выполняется одна и та-же последовательность инструкций. В итоге получим что на каждом кадре выборка атрибутов и пикселов произойдет на одних и тех-же тактах... Т.к. все сигналы в каждом кадре будут полностью идентичными.

Вот то что конденсаторы С5 и С7 вносят джиттер в сигнал INT, за счет чего он может срабатывать на такт позже - это более реалистично. В этом случае для видеогенератора такты остаются теми-же, а вот для процессора это выглядит как сдвиг таймингов на 1 такт с уменьшением длительности кадра на этот самый 1 такт.

[Advertiser]

[goodboy]

А btime? Еще minfo запусти, длина INT какая?

тесты обязательно запущу, но только завтра - извиняйте.

[Lion17]

да, это было бы актуально для случайного набора инструкций. Но это не наш случай. В нашем случае каждый кадр начинается с одного и того-же такта, если вести отсчет от начала сигнала INT. Диаграмма всех сигналов Z80 будет тоже одинаковая для всех кадров, т.к. выполняется одна и та-же последовательность инструкций. В итоге получим что на каждом кадре выборка атрибутов и пикселов произойдет на одних и тех-же тактах... Т.к. все сигналы в каждом кадре будут полностью идентичными.

Неверно. Уже устал объяснять. Постарайся понять. Если количество обращений процессора к памяти (или видеоконтроллера к памяти) в кадре будет четным, то все ОК - кадры будут абсолютно идентичными. Если количество обращений процессора к памяти будет нечетным, то такты чтения пикселей/атрибутов будут меняться в каждом кадре.

Держи схему. http://speccy.info/w/images/8/88/Pen..._Schematic.png Переключатель атрибуты/пиксели выполнен на D15. Как видно, сброса у нее нет, простой счетчик, он независит от других счетчиков, он считает только свою пару адресов и все.

---------- Post added at 22:19 ---------- Previous post was at 22:15 ----------

Вот то что конденсаторы С5 и С7 вносят джиттер в сигнал INT, за счет чего он может срабатывать на такт позже - это более реалистично. В этом случае для видеогенератора такты остаются теми-же, а вот для процессора это выглядит как сдвиг таймингов на 1 такт с уменьшением длительности кадра на этот самый 1 такт.

Это тоже проверил - различные тесты всегда, при многократном повторе выдают длину кадра в 71680. Если бы полоска мерцала из-за этого, то тесты тоже бы в 50% случаев показывали бы разную длину кадра.

---------- Post added at 22:26 ---------- Previous post was at 22:19 ----------

Посмотрел код mctest2. На первый взгляд, действительно, наиболее вероятная причина сброса - считанный вектор прерывания не равен #FF. Буду изучать. Какие есть тесты стабильности шины? Возможно, тот, что я использовал, работает некорректно.

[ZXMAK]

Держи схему. http://speccy.info/w/images/8/88/Pen..._Schematic.png Переключатель атрибуты/пиксели выполнен на D15. Как видно, сброса у нее нет, простой счетчик, он независит от других счетчиков, он считает только свою пару адресов и все.

по этой схеме триггер DD15 захватывает состояние по сигналу С15, но я не вижу как этот С15 формируется, облазил всю схему, больше С15 не нашел, где он формируется?

[Eltaron]

С15 не нашел, где он формируется?

D45

[Lion17]

по этой схеме триггер DD15 захватывает состояние по сигналу С15, но я не вижу как этот С15 формируется, облазил всю схему, больше С15 не нашел, где он формируется?

D45 ТМ8 в нижней части схемы. Сдвиг сигналов. Большой недостаток схемы неговорящие названия у сигналов. На своей схеме я поменял многие имена - стало намного проще разбираться.

---------- Post added at 00:57 ---------- Previous post was at 00:19 ----------

Вот то что конденсаторы С5 и С7 вносят джиттер в сигнал INT, за счет чего он может срабатывать на такт позже - это более реалистично. В этом случае для видеогенератора такты остаются теми-же, а вот для процессора это выглядит как сдвиг таймингов на 1 такт с уменьшением длительности кадра на этот самый 1 такт.

Кстати, конденсаторы не могут замедлять сигнал - они наоборот пропускают высокую частоту. Фронт сигнала проходит через конденсатор практически без изменений. RC цепочка регулирует длительность сигнала, но не смещает его. Так что, сигнал INT всегда стартует вовремя, а вот длительность его может колебаться в зависимости от номиналов RC.

PS: Был не прав. Посмотрел - C7 стоит от INT на землю. Действительно, он может немного замедлить сигнал.

[ZXMAK]

Переключатель атрибуты/пиксели выполнен на D15. Как видно, сброса у нее нет, простой счетчик, он независит от других счетчиков, он считает только свою пару адресов и все.

DD15.2 - это триггер, а не счетчик, работает совместно с DD6.2 как делитель инверсного сигнала С23. Сигнал C23 переключает младшие/старшие 8 бит адреса для ОЗУ при выборке значений видеогенератором.

По схеме сложно понять сколько импульсов за кадр приходит на этот делитель. Т.е. ты хочешь сказать что видеогенератор пентагона с каждым кадром меняет порядок чтения аттрибута и пикселов?

PS: stime измеряет время вывода пиксельного байта, нужно сделать то-же самое для аттрибутного, тогда ситуация прояснится

[Lion17]

DD15.2 - это триггер, а не счетчик, работает совместно с DD6.2 как делитель инверсного сигнала С23. Сигнал C23 переключает младшие/старшие 8 бит адреса для ОЗУ при выборке значений видеогенератором.

По схеме сложно понять сколько импульсов за кадр приходит на этот делитель. Т.е. ты хочешь сказать что видеогенератор пентагона с каждым кадром меняет порядок чтения аттрибута и пикселов?

Немного не так - переключает младшие/старшие линии адреса C14. А C23/С40 выбирают тип адреса процессор/видеоконтроллер. Сигналы С29/С30 выбирают тип адреса видеоконтроллера атрибут/пиксель.

Порядок меняется не с каждым кадром, а только если за кадр было нечетное число операций.

---------- Post added at 01:22 ---------- Previous post was at 01:20 ----------

PS: stime измеряет время вывода пиксельного байта, нужно сделать то-же самое для аттрибутного, тогда ситуация прояснится

Сделать элементарно. Сейчас тест пишет в #4000, надо писать в #5800. Поменять один байт. Если я прав, то атрибут также будет мерцать на 17984. Вернее будет мерцать не весь атрибут, а только верхние 8 пикселов знакоместа.

[esl]

господа. эт вам не пригодится ?
http://sblive.narod.ru/ZX-Spectrum/P...ntagon128k.htm
там такая красивая картинка
и схемы

[Lion17]

Для записи в область атрибутов, после загрузки stime, превать ее по Break, выполнить команду "POKE 49183,88", и вновь запустить.

---------- Post added at 01:30 ---------- Previous post was at 01:30 ----------

господа. эт вам не пригодится ?
http://sblive.narod.ru/ZX-Spectrum/P...ntagon128k.htm
там такая красивая картинка
и схемы

Этот сайт у меня давно в закладках. Схемы там правда не ахти.

---------- Post added at 01:40 ---------- Previous post was at 01:30 ----------

Проверил с записью в область атрибутов.
17983 - белый квадрат (#FF)
17984 - у белого квадрата мерцают верхние 8 пикселей (#FF или #00)
17985 - белый квадрат с черной полоской сверху (#00)

Все в полном соответствии с теорией.