Изменение кадровой частоты БК-0011М с 48.8Гц на 50Гц

[gid]

Но это очень маловероятно.

Наоборот, это как раз очень вероятно. Вы же знаете как работает ВП1-037, из-за соотношения частот 4МГц к 6МГц процессор очень часто (почти всегда) не успевает попасть в цикл доступа к памяти и ожидает лишние 1..8 тактов 4Мгц (потому что, нужно попасть именно к началу цикла доступа к памяти, а это происходит один раз за 8 тактов 6Мгц (и почему макс. 8 тактов 4МГц, я не знаю, так расчёты показывали)), чтобы что-то прочитать/записать из ОЗУ, а при увеличении частоты он начинает успевать в цикл и задержки (особенно задержки сделанные с помощью определённого количества определённых команд) могут существенно сократиться.

А вот на частоте 6МГц по моим расчётам почему-то выходило, что процессор опять не попадает в циклы доступа к памяти и ожидает уже 1..16 тактов, хотя в целом всё работает быстрее, чем на 4 МГц, но могло бы ещё существенно быстрее.

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

А как с этим у БК-0011 (без М)?

Схематически они абсолютно одинаковые, различаются всего лишь тремя треками на плате и ПЗУ.

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

Ещё добавлю.
При выполнении команд процессору требуется од одного (команды типа nop, mov r0,r1) до семи (команды с косвенно индексной адресацией) циклов доступа к памяти, а они происходят отнюдь не синхронно с циклами ВП1-037.
Между запросами на доступ к памяти происходит когда 2, когда 3, когда 5 тактов автомата микрокода, + ещё такты цикла самой процедуры доступа, там если посмотреть логи растактовки симулятора процессора, с памятью 0 тактов задержки, получается на один цикл доступа уходит несколько десятков тактов.
Так что не всё так однозначно.

[Manwe]

из-за соотношения частот 4МГц к 6МГц процессор очень часто (почти всегда) не успевает попасть в цикл доступа к памяти и ожидает лишние 1..8 тактов 4Мгц

Но если мы пропорционально увеличили и частоту процессора, и частоту контроллера памяти – разве соотношение циклов как-то изменится? Замеры показывают, что частота кадров увеличилась согласно расчётам, значит ВП1-037 разогнан так же как и ВМ1. Между ними не должно появиться дополнительной рассинхронизации.

[gid]

получается на один цикл доступа уходит несколько десятков тактов.

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

разве соотношение циклов как-то изменится?

Да. На БК-11 доступ к памяти в процессе выполнения инструкции, чтобы прочитать операнды и записать результаты, штука очень непростая.
Т.е. сам по себе и микрокод процессора достаточно хорошо описан, и Patron сделал достаточно точную его эквивалентно потактовую эмуляцию. Но вот связка процессора с ВП1-037 штука непростая. Не получается сделать однозначных и простых формул зависимости времени быстродействия от частот.

[Manwe]

Всё равно это не объясняет почему демка идёт вдвое быстрей. Если она привязана по времени к экранному таймеру (а скорее всего так и есть), то выполняться вдвое быстрей она может только в одном случае: раньше (с кварцем 12 Мгц) расчёт и вывод кадра длился чуть дольше 1/48,83 секунды. И поэтому не успевал за одно кадровое прерывание, ждал следующего (частота кадров падала вдвое до 24,41 fps). Теперь же (с кварцем 12,288 Мгц) расчёт и вывод кадра длится чуть меньше 1/50 секунды и успевает к каждому кадровому прерыванию (не пропускает через один).

[MM]

В БК есть несинхронная задержка DOUT ~~1 такт - можно для опытов временно отпаять конденсатор задержки.

[Manwe]

В БК есть несинхронная задержка DOUT ~~1 такт - можно для опытов временно отпаять конденсатор задержки.

Тогда получается, что ускорив кварц на 2,3%, мы сделали эту аналоговую задержку как бы более длительную (с точки зрения процессора). Условно говоря, раньше задержка длилась чуть меньше одного такта, а теперь уже чуть больше (потому что сами такты стали короче, а аналоговая задержка какой была, такой и осталась). Может, кондёр поменьше поставить? Или я неправильно рассуждаю?

P.S. сейчас проверил свой тест луча - теперь полэкрана + обратный ход луча длится примерно 381,6 тиков таймера (чтобы перевести в такты процессора, нужно умножить на 128). Раньше было ровно 381.
P.P.S. тест команды MOV во всех сочетаниях всех типов адресации даёт те же результаты: число тактов не изменилось.

[Advertiser]

[Manwe]

Manwe мне подал идею поднять исходную частоту кварца в БК с 12Мгц до 12.295Мгц (ориентировочная цифра)

Расчёты показывают, что точная цифра – 12,2872 МГц. Отличие от 12,288 – тысячные доли процента. Вполне годится.

[Manwe]

У меня есть программка для измерения длительности (в тактах) произвольного куска кода.
Замеры показали, что в статической быстрой памяти (СМК-512) один и тот же код исполняется:
кварц 12.000 МГц – 304 такта,
кварц 12.288 МГц – 309 тактов.
Значит, нужно подбирать для DOUT конденсатор меньшей ёмкости и добиваться результата в 304 такта.

Всё ещё не понимаю феномена 5-ой части демо Insult: если относительная длительность команд (в тактах) увеличилась, то демка должна была замедлиться, а не ускориться.

[CodeMaster]

Всё ещё не понимаю феномена 5-ой части демо Insult:

А ты его проверял на своей БК, он действительно есть? И если есть, то отсутствуют ли артефакты? Возможно там вопрос в том, что изменяется не длительность команд, а нарушается арифметика и инкремент увеличивается например в 2 раза, но это должно быть заметно на глаз по картинке.

[MM]

если относительная длительность команд (в тактах) увеличилась, то демка должна была замедлиться, а не ускориться

Там, по всей видимости, имеет место строб-эффект, и микроскопические доли нарушения баланса быстродействие/частота кадров будут иметь существенное значение.