Просмотр полной версии : Изменение кадровой частоты БК-0011М с 48.8Гц на 50Гц
Как всем известно, у БК-0010/0011М кадровая частота видео сигнала не совсем вписывается в ТВ-стандарт, потому при подключении по SCART ко многим современным ЖК-телевизорам, происходит рассогласование ожидаемой телевизором (50Гц) и фактической (48.8Гц) частотами, в результате чего получаем подергивание изображения в сценах с равномерно движущимися объектами: очень хорошо это заметно при наблюдении за бегущими строками - подергивание примерно раз в 1-2 секунды.
Manwe мне подал идею поднять исходную частоту кварца в БК с 12Мгц до 12.295Мгц (ориентировочная цифра), в следствии чего кадровая частота БК поднимется до 50Гц, что позволит добиться плавности изображения для всех ТВ-приемников.
Поскольку "в природе" существует кварц 12.288МГц, довольно близкий к требуемой частоте, то самым простым способом проверить идею была его установка в БК-0011М вместо исходного. После установки я прогнал все части "Инсульта" и убедился, что видео эффекты нигде не "поехали" (на глаз во всяком случае не заметно), а также убедился, что действительно бегущие строки стали плавными; из-за неполного соответствия частоты кварца требуемой частоте, подергивания всё же остались, но стали гораздо более редкими - примерно раз в 15 секунд.
Вопрос знатокам:
1. На каких демках/программах лучше проверять, нет ли критичных последствий такого метода для существующего софта?
2. Каков наиболее простой схемотехнический путь для получения на видео выходе БК точной кадровой частоты 50Гц?
marinovsoft
18.02.2019, 10:13
А если взять такой кварц и поделить частоту на три?
https://www.chipdip.ru/product/36.883mhz-hc-49u
konst_st
18.02.2019, 10:48
Manwe мне подал идею поднять исходную частоту кварца в БК с 12Мгц до 12.295Мгц
Но тогда ведь изменится строчная частота и не факт что телевизор будет нормально ее брать.
так не получится кмк
лучше сразу пересчитать на кварц 14 мгц , ну или 14,31818
и заодно процессор подразогнать
или 1801ВМ2 сразу уж
давно ведь собирался
ПС 12300 есть
http://www.quartz1.com/price/model.php?akt=3475.01
и еще есть программируемые
Очень круто, что получилось!
На каких демках/программах лучше проверять, нет ли критичных последствий такого метода для существующего софта?Scroller, Shock, Электробулка, Однажды.
Теперь резонатор 12.288 МГц трудится в моей БК и чувствует себя прекрасно :) Всем советую.
Теперь резонатор 12.288 МГц трудится в моей БК и чувствует себя прекрасно Всем советую.
Всё же некоторые проблемы могут быть. Например в 5й части Инсульт, где в окошке звездное небо движется вниз, оно начинает двигаться раза в 2 быстрее, непропорционально разгону.
в 5й части Инсульт, где в окошке звездное небо движется вниз, оно начинает двигаться раза в 2 быстрееТакое может быть если какие-то команды процессора стали выполняться за меньшее количество тактов, другого объяснения пока не вижу. Но это очень маловероятно. На всякий случай проведу тесты, напишу о результатах.
- - - Добавлено - - -
Спрошу ещё в этой теме, чтобы новую не создавать:
Напомните, пожалуйста, какие схемы турбирования БК-0010 были? На 4, 5 и 6 МГц? Мне казалось, что моя БК-0010 была разогнана на 5 МГц. Но точно не помню.
Напомните, пожалуйста, какие схемы турбирования БК-0010 были?
Напомню о "Частометре БК" :
https://zx-pk.ru/threads/26913-plata-perestraivaemogo-generatora-taktovoj-chastoty-bk0011-m-s-chastometrom.html
*
Разрешите так же обратить внимание на разное быстродействие БК0010-01 с скрипучей клавой на ПКН-111 ( плата .641 ) и переразведенной БК0010-01 под клаву МС7008 - у этой на порядка 5% быстродействие выше, за счет устранения задержки 1 такт на тактировании сигнала МПИ RPLY ( на 6 мгц ). Измерения проводились на опломбированных БК0010-01.
*
Был вариант тактирования БК11 без "М" на частоте 4.608 мгц - ОП 1988 г, в серию не пошел.
Напомню о "Частометре БК"Мощная штука.
Разрешите так же обратить внимание на разное быстродействие БК0010-01 с скрипучей клавой на ПКН-111 ( плата .641 ) и переразведенной БК0010-01 под клаву МС7008 - у этой на порядка 5% быстродействие выше, за счет устранения задержки 1 такт на тактировании сигнала МПИ RPLY ( на 6 мгц ).Ничего себе! Я думал все БК-0010 одинаковы по скорости.
А как с этим у БК-0011 (без М)? Их же переделывали в М-версию в домашних условиях. Возникает вопрос: совпадало ли быстродействие с заводской БК-0011М?
Пытаюсь придумать как объяснить ускорение 5-ой части демо «Insult». Если бы она замедлялась в два раза после смены кварцевого резонатора на более быстрый, тогда я бы ещё понял: процессор и кадровый таймер ускорились пропорционально, а скорость отклика памяти осталась прежней, поэтому к нужному времени программа не успевает выполнить нужные расчёты и пропускает прерывание кадрового таймера. Ждёт следующего прерывания и поэтому всё в два раза медленней.
Замедление объяснимо. Но ускорение...
Но это очень маловероятно.
Наоборот, это как раз очень вероятно. Вы же знаете как работает ВП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 тактов задержки, получается на один цикл доступа уходит несколько десятков тактов.
Так что не всё так однозначно.
из-за соотношения частот 4МГц к 6МГц процессор очень часто (почти всегда) не успевает попасть в цикл доступа к памяти и ожидает лишние 1..8 тактов 4МгцНо если мы пропорционально увеличили и частоту процессора, и частоту контроллера памяти – разве соотношение циклов как-то изменится? Замеры показывают, что частота кадров увеличилась согласно расчётам, значит ВП1-037 разогнан так же как и ВМ1. Между ними не должно появиться дополнительной рассинхронизации.
получается на один цикл доступа уходит несколько десятков тактов.
Вот тут это я наврал. Не несколько, а максимум 10-16 тактов, т.е. полтора десятка, если очень не повезло и приходится ждать очередного цикла доступа к памяти, а потом завершить операцию обмена
разве соотношение циклов как-то изменится?
Да. На БК-11 доступ к памяти в процессе выполнения инструкции, чтобы прочитать операнды и записать результаты, штука очень непростая.
Т.е. сам по себе и микрокод процессора достаточно хорошо описан, и Patron сделал достаточно точную его эквивалентно потактовую эмуляцию. Но вот связка процессора с ВП1-037 штука непростая. Не получается сделать однозначных и простых формул зависимости времени быстродействия от частот.
Всё равно это не объясняет почему демка идёт вдвое быстрей. Если она привязана по времени к экранному таймеру (а скорее всего так и есть), то выполняться вдвое быстрей она может только в одном случае: раньше (с кварцем 12 Мгц) расчёт и вывод кадра длился чуть дольше 1/48,83 секунды. И поэтому не успевал за одно кадровое прерывание, ждал следующего (частота кадров падала вдвое до 24,41 fps). Теперь же (с кварцем 12,288 Мгц) расчёт и вывод кадра длится чуть меньше 1/50 секунды и успевает к каждому кадровому прерыванию (не пропускает через один).
В БК есть несинхронная задержка DOUT ~~1 такт - можно для опытов временно отпаять конденсатор задержки.
В БК есть несинхронная задержка DOUT ~~1 такт - можно для опытов временно отпаять конденсатор задержки.Тогда получается, что ускорив кварц на 2,3%, мы сделали эту аналоговую задержку как бы более длительную (с точки зрения процессора). Условно говоря, раньше задержка длилась чуть меньше одного такта, а теперь уже чуть больше (потому что сами такты стали короче, а аналоговая задержка какой была, такой и осталась). Может, кондёр поменьше поставить? Или я неправильно рассуждаю?
P.S. сейчас проверил свой тест луча - теперь полэкрана + обратный ход луча длится примерно 381,6 тиков таймера (чтобы перевести в такты процессора, нужно умножить на 128). Раньше было ровно 381.
P.P.S. тест команды MOV во всех сочетаниях всех типов адресации даёт те же результаты: число тактов не изменилось.
Manwe мне подал идею поднять исходную частоту кварца в БК с 12Мгц до 12.295Мгц (ориентировочная цифра)Расчёты показывают, что точная цифра – 12,2872 МГц. Отличие от 12,288 – тысячные доли процента. Вполне годится.
У меня есть программка для измерения длительности (в тактах) произвольного куска кода.
Замеры показали, что в статической быстрой памяти (СМК-512) один и тот же код исполняется:
кварц 12.000 МГц – 304 такта,
кварц 12.288 МГц – 309 тактов.
Значит, нужно подбирать для DOUT конденсатор меньшей ёмкости и добиваться результата в 304 такта.
Всё ещё не понимаю феномена 5-ой части демо Insult: если относительная длительность команд (в тактах) увеличилась, то демка должна была замедлиться, а не ускориться.
CodeMaster
24.03.2019, 20:08
Всё ещё не понимаю феномена 5-ой части демо Insult:
А ты его проверял на своей БК, он действительно есть? И если есть, то отсутствуют ли артефакты? Возможно там вопрос в том, что изменяется не длительность команд, а нарушается арифметика и инкремент увеличивается например в 2 раза, но это должно быть заметно на глаз по картинке.
если относительная длительность команд (в тактах) увеличилась, то демка должна была замедлиться, а не ускориться
Там, по всей видимости, имеет место строб-эффект, и микроскопические доли нарушения баланса быстродействие/частота кадров будут иметь существенное значение.
А ты его проверял на своей БК, он действительно есть?Посмотрел 5-ю часть «Insult» у себя. Звёзды падают вдвое медленней, чем на youtube-рипе (уж не знаю как его делали): https://youtu.be/BLCjzHAy9Ec (с 11:30)
Вот как у меня: https://youtu.be/PMYGx_dsuV8
Какой из этих двух вариантов правильный – даже не знаю. Истина только у автора – Жени Деливрона :)
CodeMaster
25.03.2019, 22:03
Какой из этих двух вариантов правильный – даже не знаю.
Ну, если вернуть оригинальный кварц должно быть понятно.
SuperMax
09.09.2020, 19:47
случайно набрел на эту тему, вижу остался открытый вопрос по быстродействию
Но если мы пропорционально увеличили и частоту процессора, и частоту контроллера памяти – разве соотношение циклов как-то изменится? Замеры показывают, что частота кадров увеличилась согласно расчётам, значит ВП1-037 разогнан так же как и ВМ1. Между ними не должно появиться дополнительной рассинхронизации.
это не совсем так:
; ОТНОСИТЕЛЬНОЕ БЫСТРОДЕЙСТВИЕ (ДЛЯ БК11 И БК11М)
; ПОДПРОГРАММA БК11М: ( ДЛЯ БК-11 И БК-11М )
; ОТНОШЕНИЕ ТАЙМЕР(100) И СИТЕМНЫЙ ТАЙМЕР
; ЗАПИСАТЬ 177777 >> 177706
; 20 >> 177712
; СЧИТАТЬ 177710 >> TMCH
; 5MHz - 176337 +-1
; 4MHz - 176577 +-1
; 3MHz - 177037 +-1
; 2MHz - 177277 +-1
; 'ТЕПЛОЕ' БЫСТРОДЕЙСТВИЕ, ВЫЧИСЛЕННОЕ НА ОСНОВЕ ИДЕИ О
; ЗАДЕРЖКИ ИЗ ЗА ОЗУ ( ТЕПЛОЕ ПОТОМУ, ЧТО ЗАВИСИТ ОТ
; ТЕМПЕРАТУРЫ 037oЙ ПРОШИВКИ (5%) И ПРОЦЕССОРА(1%)
; А ТАКЖЕ ЗАВИСИТ ОТ ЕМКОСТИ ШИНЫ - А ИМЕННО ОТ КОЛИЧЕСТВА
; ПЗУ (1%) И Т.Д.
собственно за счет "измерения" емкости шины и относительного изменения быстродействия у меня построен алгоритм измерения тактовой частоты машины с помощью внутрипроцессорного таймера
исходники тут
https://forum.maxiol.com/index.php?showtopic=3897
в данном случае, даже при разгоне 037й (которая кстати нормально съедает 7Mhz - те 14MHz кварц)
этот эффект будет иметь место, ну и может повлиять на работу программ
В БК есть несинхронная задержка DOUT ~~1 такт - можно для опытов временно отпаять конденсатор задержки.
MM, а как так получилось, что частоту сделали не 50 Гц сразу. Какие экономические были соображения, или технические?!
Какие экономические были соображения, или технические?!
1. Работали "спустя рукава".
2. Это 1981 год. ЭБ - БМК 1801-й серии, макс. тактовая по ТУ - 6 мгц. В 1801ВП1-037 как раз максимум - 6 мгц.
Остальные тайминги - производные от срочной частоты 15625 гц. ( 6 мгц / 384 ).
Ориентировались на передовые для 1981 г. 565РУ3 с выборкой под 200 нс по сигналу CAS.
https://eandc.ru/pdf/mikroskhema/k565ru3.pdf
3.Что можно было сделать на той ЭБ, но если бы было "указание руководства" :
3.1 В БМК оставить только счетчики строк/адресов видеовывода, адреса с МПИ - на внешних 589ИР12
3.2. За счет тщательной оптимизации таймингов ДОЗУ сделать разрешение строки 320 2-битных точек, а не 256, как в ВП1-037.
Но сделали "как по-проще", и вообще, для 1981 г. разрешение монитора станка ЧПУ 512х256 считалось "хорошее", "гадким" оно станет года с 1986, когда попытаются запускать RT-11 на БКшке - прототипе БК11.
Вот такой кварц:
https://www.compel.ru/infosheet/GEYER/KX-49%2012.288%20MHz
https://www.chipdip.ru/product/12.288mhz-hc-49u
512х256 считалось "хорошее", "гадким" оно станет года с 1986, когда попытаются запускать RT-11 на БКшке - прототипе БК11.Ленивые программисты 1986-го года просто не хотели делать шрифт шириной 6 точек. При нём в строку умещается аж 85 символов. Вон в читалке MKDOS с начала 90-ых есть режим 80 символов в строке, работает же. И я пару лет назад писал скоростную процедуру вывода такого шрифта – уж точно побыстрей той, что в Мониторе для вывода 64 символов в строке.
BlaireCas
21.08.2022, 11:19
Ленивые программисты 1986-го года просто не хотели делать шрифт шириной 6 точек. При нём в строку умещается аж 85 символов. Вон в читалке MKDOS с начала 90-ых есть режим 80 символов в строке, работает же. И я пару лет назад писал скоростную процедуру вывода такого шрифта – уж точно побыстрей той, что в Мониторе для вывода 64 символов в строке.
А как делался сдвиг на 2 4 6 пикселей? Просто сам делал 6х8 шрифт в УКНЦ и там-то проще ибо у ВМ2 есть например команда ash #6, R0. Но у ВМ1 такого кажется нет и сдвиг по таблицам? Или циклом?
В любом случае интересно за сколько будет заполнение всего экрана шрифтом 6х8 допустим. Имхо тормоза должны быть значительные. Там ведь по-хорошему надо еще и маску применять (стирать старый символ если он есть в месте вывода нового) то-есть bic / bis вместо mov будут вроде как.
(впрочем когда-то измерял скорость ash и допустим четыре asl/asr не медленнее вроде было чем ash #4.. а если на 6 пикселей ну чутка медленнее будет хотя не прямо критично)
Имхо тормоза должны быть значительные. Там ведь по-хорошему надо еще и маску применять (стирать старый символ если он есть в месте вывода нового) то-есть bic / bis вместо mov будут вроде какЯ не стираю фон под символами, поэтому всё быстро. И сдвигов нет. При инициализации шрифта генерится второй набор сдвинутых символов.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot