Просмотр полной версии : Тайминги Pentagon 128 :)
Обнаружил любопытный факт - все существующие эмуляторы имеют свои тайминги пентагона, из 7 протестированных эмуляторов только у трех тайминги одинаковые - это ZXMAK, ZXMAK2 и SpecEmu :)
Для тестов использовал программу из stest2.tap.zip (http://zx.pk.ru/attachment.php?attachmentid=41099&d=1366516838). Суть программы - нажимая кнопки Q и A найти два значения тактов, для которых при переходе от одного к другому гаснет красная полоска в левом верхнем углу экрана.
Результаты такие:
Unreal: 17990 -> 17991
Spectaculator: 17981 -> 17982
Fuse: 17989 -> 17990
Spin: 17988 -> 17989
SpecEmu: 17987 -> 17988
ZXMAK: 17987 -> 17988
ZXMAK2: 17987 -> 17988 (в последней версии 2.7.3.0 исправлно - теперь 17984->17985)
У кого-то есть реальный пентагон 128, можете проверить какие значения получаются на нем? Сразу предупреждаю - кнопку Q прийдется держать очень долго :)
[bETA]mEN
28.04.2013, 14:10
Сразу предупреждаю - кнопку Q прийдется держать очень долго :)
стартовое значение в программе несложно поменять
[bETA]mEN
28.04.2013, 15:47
Это надеюсь про такой тест речь?
nope
C реальным Пентагоном все еще круче!
Мало того, что ни с одним (!) из эмуляторов не совпадает,
так еще и ведет себя по другому.
17983 - полоска есть
17984 - полоска мерцает с частотой 25 герц (один кадр есть, другой - нет)
17985 - полоски нет
Мой старый ZX-Emul v0.31b выдал 17993-17994
Новый ZX-Emul (в разработке) показал 17982-17983
C реальным Пентагоном все еще круче!
Мало того, что ни с одним (!) из эмуляторов не совпадает,
так еще и ведет себя по другому.
17983 - полоска есть
17984 - полоска мерцает с частотой 25 герц (один кадр есть, другой - нет)
17985 - полоски нет
А на каком именно пентагоне ты проверял? Я думаю между разными версиями может быть разница
[bETA]mEN
28.04.2013, 16:22
Новый ZX-Emul (в разработке)
:v2_dizzy_heart:
А на каком именно пентагоне ты проверял? Я думаю между разными версиями может быть разница
А хрен его знает. Комп древний. Купил как-то по случаю лет пять назад. Фотки прилагаю. Может спецы определят по ним.
Но версии Пентагона не должны влиять на времянки. Иначе это уже не Пентагон будет.
17984 - полоска мерцает с частотой 25 герц (один кадр есть, другой - нет)
похоже это происходит за счет того что на разных кадрах захват значения с шины данных происходит в разные моменты времени, поэтому в одном кадре успевает захватить байт на одном такте, а в следующем кадре на другом такте
А еще есть владельцы пентагонов? нужны еще результаты теста на реальном железе :)
introspec
28.04.2013, 17:07
Сразу предупреждаю - кнопку Q прийдется держать очень долго :)
Обязательно доделаю timechart летом. Давно уже нужно сделать программу, которая сделает на реале максимум измерений на автомате, а затем предоставит возможность что-то по необходимости подкрутить и выдать в человеческом виде полученные тайминги для эмулятора. Пока ещё остались работающие реалы...
SAM style
28.04.2013, 17:20
C реальным Пентагоном все еще круче!
Мало того, что ни с одним (!) из эмуляторов не совпадает,
так еще и ведет себя по другому.
17983 - полоска есть
17984 - полоска мерцает с частотой 25 герц (один кадр есть, другой - нет)
17985 - полоски нет
Мой старый ZX-Emul v0.31b выдал 17993-17994
Новый ZX-Emul (в разработке) показал 17982-17983
Xpeccy, дефолтная (пентагоновская) геометрия: 17984 есть полоска, 17985 нет. Так что я близко :)
В последней версии ZXMAK2 аналогично, судя по всему это правильный тайминг пентагона.
Ждем подтверждения от владельцев реального железа :)
И похоже правильно мультиколор пентагона эмулируется пока только в наших двух эмуляторах :biggrin:
http://savepic.org/3451033.png
Каким образом эта программа подстраивает HALT под нужный такт из 4? А может, она его вообще не подстраивает и результат рандомный?
introspec
28.04.2013, 22:32
Каким образом эта программа подстраивает HALT под нужный такт из 4? А может, она его вообще не подстраивает и результат рандомный?
У Яна Бобровского выложены все исходники:
http://wizard.ae.krakow.pl/~jb/qaop/tests.html
Код там грязненький (на мой вкус, конечно), но трюки хорошие тоже есть. Нужно только делать поправку, что его цель - не переносимость, а тестирование эмуляторов/клонов ULA на совместимость с классикой.
Вот его выравнивание (я разбирался для своей TimeChart):
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
pop de
rst 0 ; really crazy way to handle timing errors (e.g. it crashes on Scorpion due to unaccounted M1 delays)
_align ; 55T
inc de
halt
rst 0
Я использую похожую схему для своей TimeChart. Если правильно подогнать такты - выравнивание не нужно.
Каким образом эта программа подстраивает HALT под нужный такт из 4? А может, она его вообще не подстраивает и результат рандомный?
не знаю как подстраивает, но у нее фрейм всегда с нулевого такта начинается. В ZXMAK2 если включить View->Debug info, то последней строчкой показывает с какого такта начался текущий фрейм.
пробовал сбить ее с толку - менял начальный такт фрейма от 0 до 7 (это можно сделать из отладчика кликнув на ftmT=...), но она шибко умная, при нажатии на кнопку тут-же выравнивается на 0! :cool_std:
Так что с этим все ОК! Жаль что на скорпионе она не работает.
У Яна Бобровского выложены все исходники
Поюзай лучше настройки от Alone. Сколько пользуюсь - ни разу не пожалел. Работает как пчёлка!
Обработчик прерываний inc sp:inc sp:ei:ret вполне может захватиться дважды на реальном пентагоне.
introspec
28.04.2013, 22:51
Поюзай лучше настройки от Alone. Сколько пользуюсь - ни разу не пожалел. Работает как пчёлка!
У меня этот код лежит в специальной папочке, просто пока случая не было приспособить в дело :)
Хотя, да, у меня есть небольшая страсть к самопальным решениям...
---------- Post added at 19:51 ---------- Previous post was at 19:50 ----------
Обработчик прерываний inc sp:inc sp:ei:ret вполне может захватиться дважды на реальном пентагоне.
Я же говорю, код грязный, но идеи правильные есть.
Дополнение: он почему-то считает, что прерывание обрабатывается 20 тактов. Я секретно подозреваю, что это и есть тот самый знаменитый потерянный такт, о котором писали большевики из ZX Spectrum FAQ, но вникать в подробности мне не хотелось.
Обработчик прерываний inc sp:inc sp:ei:ret вполне может захватиться дважды на реальном пентагоне.
каким образом? Обработка сигнала INT блокирует прерывания, так что на первой инструкции inc sp прерывания уже заблокированы.
После выполнения EI прерывания запрещены до следующей инструкции. Следующая инструкция RET, т.е. пока обработчик не завершится, повторное прерывание невозможно.
Время выполнения обработчика 26 тактов + 19 тактов на обработку INT, итого - 45 тактов. Повторный вход на пентагоне невозможен, т.к. длительность прерывания - 32 такта
Вызов обработчика два раза за один фрейм сбивает всю синхронизацию.
В данном случае он просто приводит к выходу из цикла.
---------- Post added at 22:02 ---------- Previous post was at 21:59 ----------
Повторный вход на пентагоне невозможен, т.к. длительность прерывания - 32 такта
Длительность прерывания на пентагоне определяется RC-цепочкой.
Вызов обработчика два раза за один фрейм сбивает всю синхронизацию.
В данном случае он просто приводит к выходу из цикла.
---------- Post added at 22:02 ---------- Previous post was at 21:59 ----------
Длительность прерывания на пентагоне определяется RC-цепочкой.
попробовал поднять длительность до 46 тактов - тест сбрасывается
introspec
28.04.2013, 23:10
попробовал поднять длительность до 46 тактов - тест сбрасывается
Этот тест вообще сбрасывается почти везде и почти по любому поводу.
Такой пользовательский интерфейс! :)
Alex Rider
28.04.2013, 23:17
Поюзай лучше настройки от Alone. Сколько пользуюсь - ни разу не пожалел. Работает как пчёлка!
Не работает на Scorpion c Even M1. Если речь идет про выравнивалку из ZX-Guide #3. Если надо, выложу пофикшенный.
так всетаки, есть у кого-то еще реальный пентагон?
Не работает на Scorpion c Even M1. Если речь идет про выравнивалку из ZX-Guide #3. Если надо, выложу пофикшенный.
Выкладывай. А почему не работает?
introspec
28.04.2013, 23:28
Не работает на Scorpion c Even M1. Если речь идет про выравнивалку из ZX-Guide #3. Если надо, выложу пофикшенный.
Было бы здорово посмотреть на ещё одно решение. На скорпионе, кстати, проще выравнивать, там всегда получается чётный такт на выходе из halt.
Alex Rider
28.04.2013, 23:41
Собсна,все отличие в добавлении 10-тактовой jp $ + 3 в обработчик прерывания. Причина видится мне в том, что в обработчике используются нечетнотактовые pop hl и or 4. Похоже, jp $ + 3 это компенисрует. Сделано методом тыка и отлажено в Unreal.
ld (exit_addr),hl
ld bc,#06ff
.return:
xor a
ld hl,.loop
ei
.loop:
dec a
jp (hl)
.isr:
pop hl
ld e,(hl)
rl e
rla
ld e,d
ld d,a
sub e
sub c
sbc a,a
or 4
dec b
and b
jp $ + 3 ; 10 for even M1 machines
jr nz,.return
inc hl ; 6
exit_addr = $ + 1
jp #0000 ; 10
так всетаки, есть у кого-то еще реальный пентагон?
у меня есть, только разъём на переферию вообще не распаян.
постараюсь сделать в майские праздники.
похоже это происходит за счет того что на разных кадрах захват значения с шины данных происходит в разные моменты времени, поэтому в одном кадре успевает захватить байт на одном такте, а в следующем кадре на другом такте
А еще есть владельцы пентагонов? нужны еще результаты теста на реальном железе :)
Посмотрел схему Пентагона. Процессор имеет приоритет над видео-контроллером. Как только активен MREQ и на шине адреса - оперативка, в следующем такте происходит чтение памяти процессором. Все остальное время каждый такт происходит по очереди чтение атрибутов или пикселей. Так как они считываются асинхронно с границей знакоместа, то сначала они помещаются в буферные регистры, а на границе знакоместа переносятся в регистры вывода, а оттуда попиксельно выталкиваются на экран.
Исходя из выше-сказанного, мерцание пикселей в тесте легко объясняется. Судя по всему за один кадр видео-контроллер успевает считать нечетное количество байт (атрибуты + пиксели). Поэтому, в одном кадре непосредственно после записи #FF в верхний левый угол экрана считываются пиксели (полоска есть), а в другом - считываются атрибуты, а пиксели уже считались до записи (полоски нет).
Tackts: 17983 | 17984 | 17985
Frame 0: RAT=32 | WRT=FF | RPX=FF (полоска есть)
Frame 1: RPX=00 | WRT=FF | RAT=32 (полоски нет)
RAT - чтение атрибутов, RPX - чтение пикселей, WRT - запись CPU
---------- Post added at 13:04 ---------- Previous post was at 12:52 ----------
Получается, что на текущий момент ни один из эмуляторов точно не воспроизводит времянку Пентагона.
Забавно, всегда считал, что эмулировать Пентагон проще всего. Оказалось, наоборот.
И было бы неплохо, что бы были версии этих тестов для прошивки в ПЗУ
И было бы неплохо, что бы были версии этих тестов для прошивки в ПЗУ
Конкретно данный тест перенести в тест-ПЗУ не получится. Он частично написан на Бейсике.
Сообщение от alvis
И было бы неплохо, что бы были версии этих тестов для прошивки в ПЗУ
Конкретно данный тест перенести в тест-ПЗУ не получится. Он частично написан на Бейсике.
Не обязательно конкретно этот (хотя теоретически и его можно скомпилить). Речь о том, чт нужен нормальный тест конфигурации/характеристик прошиваемый в ПЗУ. Железячникам будет удобно.
Есть какие-то новости про результаты-на реальном пентагоне?
Продолжил изучение схемы Пентагона и теста.
Импульс прерывания начинается на пересечении кадрового и строчного синхроимпульса. Будем считать, что он начинается на такте 0. Далее следует 16 строк кадрового синхроимпульса и 64 строки верхнего бордюра.
Длина строки 224 такта. Итого, до начала синхроимпульса первой строки экрана 80*224=17920 тактов.
Далее следует 32 такта (гашение, со строчным синхроимпульсом внутри) и 32+4 такта левого бордюра (4 такта, или 8 пикселей, добавляются в схеме для того, чтобы видео-контроллер заведомо успел считать из памяти данные пикселей и атрибутов).
Итого, от начала прерывания до первого пикселя экрана 17920+64+4=17988 пикселя. Первый пиксель экрана имеет номер 17988 (если считать с 0).
Цикл записи Z80 состоит из трех тактов, непосредственно запись в схеме Пентагона происходит во второй половине второго такта. Поэтому, уже в третьем такте цикла записи видео-контроллер сможет считать из памяти записанное туда значение.
Z80 реагирует на прерывание, если в последнем такте предыдущей команды сигнал INT уже в низком уровне. То есть, идеально выровненный кадр начинается не с первого такта, а со второго. Именно поэтому длительность процедуры прерывания теста 46 тактов, а не 45:
RAM:C086 IntSubSample: ; 1 + 19
RAM:C086 inc sp ; 6
RAM:C087 inc sp ; 6
RAM:C088 ei ; 4
RAM:C089 ret ; 10
Код самого теста:
RAM:C018 Test:
RAM:C018 call AlignInt ; 46
RAM:C01B
RAM:C01B Loop:
RAM:C01B im 1 ; 8
RAM:C01D ld de, 4000h ; 10
RAM:C020 xor a ; 4
RAM:C021 ld (de), a ; 7
RAM:C022 ld bc, (WriteTackt) ; 20
RAM:C026 call WaitBCTackts ; WT-106
RAM:C029 ld a, 0FFh ; 7
RAM:C02B ld (de), a ; 4+1 Write!
Получается, что перед тактом записи выдерживается пауза: 46+8+10+4+7+20+WT-106+7+4+1=WT+1 такт
Итак:
1. Выставляем в тесте значение 17983. Запись в память происходит на такте 17985. Видео-контроллер всегда успевает считать и атрибуты, и пиксели в тактах 17986 и 17987. Полоска на экране всегда есть.
2. Значение 17984. Запись в память - 17986. До начала первого пикселя контроллеру остается только 1 такт. В одном кадре контроллер считывает атрибуты, а в другом пиксели - полоска мерцает с частотой в 25 герц.
3. Значение 17985. Запись в память - 17987. Следующий такт - вывод первого пикселя на экран. Контроллер не имеет шансов считать записанное в память значение. В качестве пикселей берется значение считанное контроллером до записи в память на такте 17986 или 17985. Полоски на экране нет.
Как-то так.
Запустил на настоящем Пентагоне другой тест камрада Бобровского - btime. Скриншоты прилагаю.
Что любопытно, в схеме Пентагона нет выравнивания бордюра по границе пикселей. Данные попадают на экран непосредственно после записи в порт (плюс задержка на распространение сигнала). Поэтому точно выровнять полоску бордюра со знакоместом на экране не представляется возможным. Довольно заметная разница составляет приблизительно 0.5-1 пиксель. Этим же и обуславливается разрешение бордюра у Пентагона - бордюр можно менять только с точностью до такта, а в одном такте, как известно, 2 пикселя.
Lion17, на твоём пентагоне последняя часть Rage показывает ровно или со сдвигом на 1 или 2 пикселя?
Lion17, на твоём пентагоне последняя часть Rage показывает ровно или со сдвигом на 1 или 2 пикселя?
Уверен на 100%, точного совпадения не будет. Но, чтобы выяснить на сколько именно будет смещение и в какую сторону, сейчас запущу.
---------- Post added at 13:56 ---------- Previous post was at 13:50 ----------
Да, результаты btime:
реальный Пентагон: 17762-17763 (слева-справа)
Старый ZX-Emul v0.31b: 17762 точно
Новый ZX-Emul: 17762 точно
Но, это и понятно - я подстраивал положение импульса прерывания под бордюрные эффекты. Теперь предстоит работа - вывести эмуляцию на расчетный уровень, так, чтобы учесть эффект работы видео-контроллера.
последняя часть Rage показывает ровно или со сдвигом на 1 или 2 пикселя?
Ты хочешь сказать, что на всех реальных Пентах должен быть сдвиг в один пиксель? а на эмулях, где нет сдвига - это неправильная эмуляция выходит?
Запустил Rage. Замучился, пока поймал строго-вертикальную границу черного и белого сегментов. Спас режим серийной съемки в смартфоне.
Как и ожидалось, полного схождения нет. Изображение на бордюре примерно на пол-пикселя левее, чем на экране.
ЗЫ: Пока писал ответ и заливал фотки, вращение сегментов в демке остановилось! :)
Ты хочешь сказать, что на всех реальных Пентах должен быть сдвиг в один пиксель? а на эмулях, где нет сдвига - это неправильная эмуляция выходит?
Запись в порт бордюра (D43-TM8) в Пентагоне происходит при:
IORQ=0, A0=0, WR=0 по переднему фронту сигнала.
После того как была произведена запись, сигналы подаются на входы мультиплексоров цветов (D46/D47-КП2) с них сигналы выводятся на видео-усилитель.
Согласно, официальной доке по Z80, при цикле записи в порт, адресная шина устанавливается почти сразу в первом такте, в начале первой половины второго такта устанавливается IORQ, и немного позже (приблизительно 0.25 второго такта) сигнал WR. Задержка сигнала происходит на элементе D8.2 (ЛЕ1) и собственно при записи в D43.
Длина одного пикселя ~143ns. Задержка на элементе К555ЛЕ1 - 20ns, на К555ТМ8 - 30ns. Итого - получается больше трети пикселя. То есть, изменения на бордюре проявятся в начале первой половины 2 такта цикла записи. Что, согласуется с тем что разница в сигнале на глаз видна, как 0.5-1 пиксель.
Смещение бордюра будет зависеть от скоростных характеристик этих микросхем. Поэтому на разных сборках Пентагона оно может немного отличаться.
PS: Кстати, надо учесть и задержку распространения прохождения сигнала пикселей.
вполне возможно что разница в 1 пиксель возникает из-за того что значение бордюра и пикселей захватывается по разным фронтам импульса. Но не исключено что это особенность конкретной платы пентагона (конденсаторы и т.п.). Не факт что на других платах эта задержка тоже будет присутствовать. Для проверки нужны результаты и с других экземпляров...
вполне возможно что разница в 1 пиксель возникает из-за того что значение бордюра и пикселей захватывается по разным фронтам импульса. Но не исключено что это особенность конкретной платы пентагона. Не факт что на других платах эта задержка тоже будет присутствовать. Для проверки нужны результаты и с других экземпляров...
Они не захватываются по разным концам импульса. Запись в порт происходит по отрицательному фронту сигнала WR процессора.
Выталкивание пикселя происходит по отрицательному фронту тактового сигнала, с частотой в 7МГц. Его фронты приходятся на начало и середину такта. После сигнал пикселя смешивается с сигналом Flash на ЛП5 (дополнительная задержка) и подается на мультиплексор.
Они не захватываются по разным концам импульса. Запись в порт происходит по отрицательному фронту сигнала WR процессора.
Выталкивание пикселя происходит по отрицательному фронту тактового сигнала, с частотой в 7МГц. Его фронты приходятся на начало и середину такта. После сигнал пикселя смешивается с сигналом Flash на ЛП5 (дополнительная задержка) и подается на мультиплексор.
тут еще не учитываются паразитные емкости проводников, конденсаторы для "подгонки", внутрение задержки микросхем и т.п. Чтобы отсеять хотябы часть этих факторов, нужны результаты с других экземпляров.
тут еще не учитываются паразитные емкости проводников, конденсаторы для "подгонки", внутрение задержки микросхем и т.п. Чтобы отсеять хотябы часть этих факторов, нужны результаты с других экземпляров.
Я об этом уже написал выше.
Но, согласен, посмотреть на результаты других Пентагонов будет интересно.
Тем не менее, я в своем эмуляторе запись в порт установил согласно своему Пентагону.
btime теперь выдает 17762-17763 (на пиксель влево и на пиксель вправо)
В Rage смещение на один пиксел влево.
Теперь пытаюсь воспроизвести работу видео-контроллера - поочередное извлечение из памяти пикселей и атрибутов, с перерывами на обращение процессора.
Тем не менее, я в своем эмуляторе запись в порт установил согласно своему Пентагону.
btime теперь выдает 17762-17763 (на пиксель влево и на пиксель вправо)
В Rage смещение на один пиксел влево.
это имхо неправильно, даже если это смещение свойственно всем пентагонам, там-же смещение не один пиксель, а на половинку пикселя.
К тому-же, речь тут идет не об ошибках эмуляции таймингов, а об ошибках отрисовки. Поэтому вносить коррективы в тайминги на основании артефактов смысла нет - захват будет производиться некорректно. В данном случае логичнее было бы ввести коррекцию отрисовки, в которой учесть задержки сигналов перед смешиванием.
Т.е. другими словами есть тайминги, в соответствии с которыми происходит захват значений цвета. А есть внутрисхемные задержки, за счет которых бордер может быть немного смещен относительно пикселов
это имхо неправильно, даже если это смещение свойственно всем пентагонам, там-же смещение не один пиксель, а на половинку пикселя.
К тому-же, речь тут идет не об ошибках эмуляции таймингов, а об ошибках отрисовки. Поэтому вносить коррективы в тайминги на основании артефактов смысла нет - захват будет производиться некорректно. В данном случае логичнее было бы ввести коррекцию отрисовки, в которой учесть задержки сигналов перед смешиванием.
Т.е. другими словами есть тайминги, в соответствии с которыми происходит захват значений цвета. А есть внутрисхемные задержки, за счет которых бордер может быть немного смещен относительно пикселов
Почему неправильно? Если все Пентагоны показывают бордюр именно так, то почему в эмуляторе нужно показывать иначе? Получается что это некачественная эмуляция.
Насчет точного отставания залезу с осциллографом и измерю. Тогда будет ясно, пол-пикселя, пиксель или иначе.
Попробовал запустить на Пентагоне MCTEST2. Стабильно сбрасывается. А в эмуляторе все нормально.
Почему неправильно? Если все Пентагоны показывают бордюр именно так, то почему в эмуляторе нужно показывать иначе? Получается что это некачественная эмуляция.
пока что есть результаты только с одного пентагона, соответственно делать выводы о том, что все пентагоны так работают, пока рано.
Получить такой эффект смещения, добавив конденсатор в схему, не представляет сложности. И нам ничего не известно о наличии конденсаторов или некачественного монтажа с паразитной емкостью в этом экземпляре пентагона.
Если мы меняем тайминги, то захват цвета будет происходить в другой момент времени, в результате этот тест может и будет работать также, но другой, уже нет.
Если мы меняем задержки (т.е. только отрисовку), то захват цвета будет происходить в один и тот-же момент времени, появится только смещение между пикселами и бордюром.
Полоски между знакоместами и яркий чёрный тоже не мешало бы сэмулировать.
Попробовал запустить на Пентагоне MCTEST2. Стабильно сбрасывается. А в эмуляторе все нормально.
это значит на твоем пентагоне нестабильная шина, и это может объяснять почему в тесте Бобровски на 17984 полоска мерцает...
---------- Post added at 17:59 ---------- Previous post was at 17:57 ----------
Полоски между знакоместами и яркий чёрный тоже не мешало бы сэмулировать.
ну это уже слишком, а вот разницу между ink и paper одного цвета эмулировать бы не помешало, но отрисовка слишком сложная получается :)
это значит на твоем пентагоне нестабильная шина, и это может объяснять почему в тесте Бобровски на 17984 полоска мерцает...
Тест шины запускал. Шина стабильна.
Мерцание полоски к шине не имеет никакого отношения.
Это следует из схемотехники Пентагона.
Повторю еще раз.
Например, на оригинальном Спектруме чтение памяти экрана ВСЕГДА происходит в один и тот же такт, а процесор тормозится. На Пентагоне чтение памяти экрана происходит когда ее не занимает процессор. По первому требованию процессора, память отдается ему. Когда процессор не обращается к памяти, в каждом такте читаются атрибуты или пиксели. По очереди. Если влезает процессор очередь сдвигается. Поэтому в один и тот же такт в разных кадрах может считываться либо пиксели, либо атрибуты.
Замерил осциллографом сигналы.
На первой осциллограмме изменение бордюра привязанное к тактовой частоте 7МГц. На второй изменение пикселя, привязанное к той же частоте.
Делаем замеры:
Период 7МГц (143нс) - 43 пикселя
Разница между Border и Pixel - 20 пикселей
Смещение равно x/143=20/43, x=66нс (46%)
Почти пол-пикселя.
Повторю еще раз.
Например, на оригинальном Спектруме чтение памяти экрана ВСЕГДА происходит в один и тот же такт, а процесор тормозится. На Пентагоне чтение памяти экрана происходит когда ее не занимает процессор. По первому требованию процессора, память отдается ему. Когда процессор не обращается к памяти, в каждом такте читаются атрибуты или пиксели. По очереди. Если влезает процессор очередь сдвигается. Поэтому в один и тот же такт в разных кадрах может считываться либо пиксели, либо атрибуты.
думаю что у пентагона, как и у других машин, в каждом кадре циклограмма одинаковая, т.к. обратное было бы нелогично. А я верю в логику людей проектировавших пентагон. :)
Думаю мерцание связано с каким-то другим фактором. Сейчас найду схему, посмотрю.
---------- Post added at 19:04 ---------- Previous post was at 18:59 ----------
Тест шины запускал. Шина стабильна.
Мерцание полоски к шине не имеет никакого отношения.
Это следует из схемотехники Пентагона.
очень интересно, за счет чего тогда сбрасывается? Проверил, MCTEST устойчив к длительности INT, единственное что его заставляет сбрасываться - нестабильная шина, т.к. вектор прерывания задавался в расчете на стабильную шину.
думаю что у пентагона, как и у других машин, в каждом кадре циклограмма одинаковая, т.к. обратное было бы нелогично. А я верю в логику людей проектировавших пентагон. :)
Думаю мерцание связано с каким-то другим фактором. Сейчас найду схему, посмотрю.
То, что у Пентагона нет медленной памяти, думаю, оспаривать не будете?
А это означает, что процессор может обратиться к памяти в любой момент. Каким же образом мы в каждом кадре сделаем одинаковую циклограмму, если вот в такте 10000 мы читаем атрибут, а на следуюшем кадре на такте 10000 процессор осуществляет выборку интрукции? Тут уж приходится извращаться и читать память не тогда, когда захочется, а когда есть возможность. Гениальные разработчики Пентагона решили, а хрена мы будем тормозить процессор и сжирать драгоценные такты, когда в любом цикле выборки инструкции процессор обращается к памяти только один раз. Для этого достаточно одного такта, значит 3 других мы можем использовать для нужд видео-контроллера.
Alexander Makeev, а как же длительность сигнала INT?
если вот в такте 10000 мы читаем атрибут, а на следуюшем кадре на такте 10000 процессор осуществляет выборку интрукции?
в случае с stime/btime на каждом кадре выполняются одна и та-же последовательность инструкций, начиная с одного и того-же 0-го такта. Почему-же циклограмма должна быть разной?
---------- Post added at 19:43 ---------- Previous post was at 19:37 ----------
Alexander Makeev, а как же длительность сигнала INT?
длительность INT тут ни на что не влияет, т.к. если INT слишком длинный, тест просто сбрасывается.
А вот влияние на фронт INT тут скорее всего есть, по схеме на INT висит конденсатор С7, следовательно фронт сигнала INT будет смазан. И в зависимости от емкости конденсатора, это может задержать срабатывание INT до одного такта, т.е. этот конденсатор вполне может быть источником мерцания, как и конденсатор С5 через который сигнал заводится на D51.
Lion17, а у тебя такая картинка при включении питания?
http://t2.gstatic.com/images?q=tbn:ANd9GcTL0uhAmuLz4IdG9PFj-zH40PEScINmG1LEhRBLrAUYNEbuUeW3
в случае с stime/btime на каждом кадре выполняются одна и та-же последовательность инструкций, начиная с одного и того-же 0-го такта. Почему-же циклограмма должна быть разной?
Переключатель Атрибуты/Пиксели работает не зависимо от кадров. Считали пиксели, в следующий раз читаем атрибуты. И наоборот. В кадре четное количество тактов. Если бы не процессор, то все было бы одинаково. Но вот представь, что процессор за кадр 20001 раз обратился к памяти, получается что контроллеру остается 71680-20001=51679 тактов. То есть он начал кадр чтением атрибутов и закончил кадр чтением атрибутов, а следующий кадр начал чтением пикселей.
---------- Post added at 21:06 ---------- Previous post was at 20:57 ----------
Lion17, а у тебя такая картинка при включении питания?
http://t2.gstatic.com/images?q=tbn:ANd9GcTL0uhAmuLz4IdG9PFj-zH40PEScINmG1LEhRBLrAUYNEbuUeW3
Доберусь до компьютера - сфоткаю.
Считали пиксели, в следующий раз читаем атрибуты. И наоборот. В кадре четное количество тактов. Если бы не процессор, то все было бы одинаково. Но вот представь, что процессор за кадр 20001 раз обратился к памяти, получается что контроллеру остается 71680-20001=51679 тактов. То есть он начал кадр чтением атрибутов и закончил кадр чтением атрибутов, а следующий кадр начал чтением пикселей.
Насколько я понимаю, сигналы захвата аттрибутов и пикселов формируются на основе текущего состояния счетчиков. Счетчики никогда не останавливаются, что-бы там процессор ни делал, т.к. иначе число тактов в каждом кадре будет нестабильным и нарушится синхронизация видеосигнала.
Таким образом, в каждом кадре выборка аттрибутов/пикселов всегда начинается одинаково. Потому что счетчики считают без остановки, а сигнал выборки формируется логическими элементами для определенного состояния выходов счетчиков. Или другими словами сигнал выборки всегда формируется для конкретных тактов схемы, номера этих тактов никогда не меняются.
Другое дело что выборка может быть заблокирована и произведена на следующем такте, но это никак не повлияет на следующий кадр, т.к. счетчики продолжают счет без останова. К тому-же, учитывая что выполняется одна и та-же последовательность инструкций, с одного и того-же такта, то в каждом кадре выборка аттрибутов и пикселов будет происходить на одних и тех-же тактах...
PS: Что-то я не найду читаемой схемы пентагона, может кто-то подскажет ссылочку?
запустил свой пентагон.
mctest2 - работает.
тест с полоской выдаёт такие-же результаты как сообщил Lion17
17983-есть
17984-мерцает
17985-нет
http://i230.photobucket.com/albums/ee81/ex0l0n/pentagon004.jpg
http://i230.photobucket.com/albums/ee81/ex0l0n/pentagon002.jpg
а вот экран без процессора
http://i230.photobucket.com/albums/ee81/ex0l0n/pentagon006.jpg
[QUOTE=Alexander Makeev;598421]Насколько я понимаю, сигналы захвата аттрибутов и пикселов формируются на основе текущего состояния счетчиков. Счетчики никогда не останавливаются, что-бы там процессор ни делал, т.к. иначе число тактов в каждом кадре будет нестабильным и нарушится синхронизация видеосигнала.
Таким образом, в каждом кадре выборка аттрибутов/пикселов всегда начинается одинаково.
QUOTE]
Неверно. Вот у нас есть 8 пикселей, или 4 такта. За это время нам нужно получить для следующих 8 пикселей атрибут и сами пиксели. Все эти четыре такта на всех линиях счетчиков одинаковое значение (не берем во внимание младшие линии). Перемешиваем эти линии счетчиков на мультиплексорах и получаем два адреса - адрес атрибута и адрес пикселя. Но вот в каком порядке мы считаем эти данные - это большой вопрос тут масса вариантов.
C-процессор, P-пиксели, A-атрибуты
Все варианты:
CPAP CAPA PCAP ACPA PACP APCA PAPC APAC PAPA APAP
Как видишь мы можем получить наши данные десятью способами, а счетчики остаются на прежних местах.
запустил свой пентагон.
mctest2 - работает.
тест с полоской выдаёт такие-же результаты как сообщил Lion17
17983-есть
17984-мерцает
17985-нет
спасибо, а какие результаты в btime?
можно еще вторую фотку, там где mctest2 - левый верхний угол в большем разрешении. интересует - есть ли там сдвиг бордюра относительно экранной области или нет?
запустил свой пентагон.
mctest2 - работает.
тест с полоской выдаёт такие-же результаты как сообщил Lion17
17983-есть
17984-мерцает
17985-нет
А btime? Еще minfo запусти, длина INT какая?
---------- Post added at 21:59 ---------- Previous post was at 21:57 ----------
спасибо, а какие результаты в btime?
можно еще вторую фотку, там где mctest2 - левый верхний угол в большем разрешении. интересует - есть ли там сдвиг бордюра относительно экранной области или нет?
На седьмой строке видно, что сдвиг бордюра небольшой есть.
Вот у нас есть 8 пикселей, или 4 такта. За это время нам нужно получить для следующих 8 пикселей атрибут и сами пиксели. Все эти четыре такта на всех линиях счетчиков одинаковое значение (не берем во внимание младшие линии). Перемешиваем эти линии счетчиков на мультиплексорах и получаем два адреса - адрес атрибута и адрес пикселя. Но вот в каком порядке мы считаем эти данные - это большой вопрос тут масса вариантов.
C-процессор, P-пиксели, A-атрибуты
Все варианты:
CPAP CAPA PCAP ACPA PACP APCA PAPC APAC PAPA APAP
Как видишь мы можем получить наши данные десятью способами, а счетчики остаются на прежних местах.
да, это было бы актуально для случайного набора инструкций. Но это не наш случай. В нашем случае каждый кадр начинается с одного и того-же такта, если вести отсчет от начала сигнала INT. Диаграмма всех сигналов Z80 будет тоже одинаковая для всех кадров, т.к. выполняется одна и та-же последовательность инструкций. В итоге получим что на каждом кадре выборка атрибутов и пикселов произойдет на одних и тех-же тактах... Т.к. все сигналы в каждом кадре будут полностью идентичными.
Вот то что конденсаторы С5 и С7 вносят джиттер в сигнал INT, за счет чего он может срабатывать на такт позже - это более реалистично. В этом случае для видеогенератора такты остаются теми-же, а вот для процессора это выглядит как сдвиг таймингов на 1 такт с уменьшением длительности кадра на этот самый 1 такт.
А btime? Еще minfo запусти, длина INT какая?
тесты обязательно запущу, но только завтра - извиняйте.
да, это было бы актуально для случайного набора инструкций. Но это не наш случай. В нашем случае каждый кадр начинается с одного и того-же такта, если вести отсчет от начала сигнала INT. Диаграмма всех сигналов Z80 будет тоже одинаковая для всех кадров, т.к. выполняется одна и та-же последовательность инструкций. В итоге получим что на каждом кадре выборка атрибутов и пикселов произойдет на одних и тех-же тактах... Т.к. все сигналы в каждом кадре будут полностью идентичными.
Неверно. Уже устал объяснять. Постарайся понять. Если количество обращений процессора к памяти (или видеоконтроллера к памяти) в кадре будет четным, то все ОК - кадры будут абсолютно идентичными. Если количество обращений процессора к памяти будет нечетным, то такты чтения пикселей/атрибутов будут меняться в каждом кадре.
Держи схему. http://speccy.info/w/images/8/88/Pentagon_128K_1991_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. Буду изучать. Какие есть тесты стабильности шины? Возможно, тот, что я использовал, работает некорректно.
Держи схему. http://speccy.info/w/images/8/88/Pentagon_128K_1991_Schematic.png Переключатель атрибуты/пиксели выполнен на D15. Как видно, сброса у нее нет, простой счетчик, он независит от других счетчиков, он считает только свою пару адресов и все.
по этой схеме триггер DD15 захватывает состояние по сигналу С15, но я не вижу как этот С15 формируется, облазил всю схему, больше С15 не нашел, где он формируется?
С15 не нашел, где он формируется?
D45
по этой схеме триггер 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 на землю. Действительно, он может немного замедлить сигнал.
Переключатель атрибуты/пиксели выполнен на D15. Как видно, сброса у нее нет, простой счетчик, он независит от других счетчиков, он считает только свою пару адресов и все.
DD15.2 - это триггер, а не счетчик, работает совместно с DD6.2 как делитель инверсного сигнала С23. Сигнал C23 переключает младшие/старшие 8 бит адреса для ОЗУ при выборке значений видеогенератором.
По схеме сложно понять сколько импульсов за кадр приходит на этот делитель. Т.е. ты хочешь сказать что видеогенератор пентагона с каждым кадром меняет порядок чтения аттрибута и пикселов?
PS: stime измеряет время вывода пиксельного байта, нужно сделать то-же самое для аттрибутного, тогда ситуация прояснится
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 пикселов знакоместа.
господа. эт вам не пригодится ?
http://sblive.narod.ru/ZX-Spectrum/Pentagon128k/Pentagon128k.htm
там такая красивая картинка ;)
и схемы
Для записи в область атрибутов, после загрузки stime, превать ее по Break, выполнить команду "POKE 49183,88", и вновь запустить.
---------- Post added at 01:30 ---------- Previous post was at 01:30 ----------
господа. эт вам не пригодится ?
http://sblive.narod.ru/ZX-Spectrum/Pentagon128k/Pentagon128k.htm
там такая красивая картинка ;)
и схемы
Этот сайт у меня давно в закладках. Схемы там правда не ахти.
---------- Post added at 01:40 ---------- Previous post was at 01:30 ----------
Проверил с записью в область атрибутов.
17983 - белый квадрат (#FF)
17984 - у белого квадрата мерцают верхние 8 пикселей (#FF или #00)
17985 - белый квадрат с черной полоской сверху (#00)
Все в полном соответствии с теорией.
Немного не так - переключает младшие/старшие линии адреса C14. А C23/С40 выбирают тип адреса процессор/видеоконтроллер. Сигналы С29/С30 выбирают тип адреса видеоконтроллера атрибут/пиксель.
Порядок меняется не с каждым кадром, а только если за кадр было нечетное число операций.
а какой смысл несет С15?
Сделать элементарно. Сейчас тест пишет в #4000, надо писать в #5800. Поменять один байт. Если я прав, то атрибут также будет мерцать на 17984. Вернее будет мерцать не весь атрибут, а только верхние 8 пикселов знакоместа.
да, я уже сделал, см. в аттачменте :)
а какой смысл несет С15?
Это же сигнал CAS. По его восходящему фронту переключаются типы адресов, как процессор/видео, так и атрибут/пиксель. А по нисходящему фронту выбранный адрес фиксируется в микросхеме памяти.
да, я уже сделал, см. в аттачменте :)
Прилагаю фотки с тестом атрибутов. А также память при старте.
Все-таки не понятна природа шахматной доски при старте. Если бы были только вертикальные, или только горизонтальные полосы, тогда еще есть гипотезы. А как образуются квадраты? Получается память переключается по линии A3 по горизонтали, и по линии A6 по вертикали.
Все-таки не понятна природа шахматной доски при старте. Если бы были только вертикальные, или только горизонтальные полосы, тогда еще есть гипотезы. А как образуются квадраты? Получается память переключается по линии A3 по горизонтали, и по линии A6 по вертикали.
я думаю массив ячеек внутри РУ5 делится на блоки, половина блоков имеет начальное значение 0, половина 1. А за счет того что адресные линии на память немного перемешиваются в схеме компьютера, то получаются разные узоры, в зависимости от того какие адресные линии перемешали... :)
Вот прикрутил шахматную доску в эмулятор :)
http://savepic.org/3436289.png
А btime? Еще minfo запусти, длина INT какая?
btime - результаты как у тебя.
17762и17763 сдвиг полоски на один пиксель.
minfo - 71680
EI is prefix - YES
INT time скачет 43/44
Нашел причину, по которой не работал mctest2.
Александр был прав - при чтении с адреса #FF шел мусор (всегда считывалось #3F). Оказалось у меня в компе есть спец-переключатель, который разрешает доступ к портам TR-DOS из Бейсика. Соответственно, он был включен.
разбирался со схемой пентагона, получились такие циклограммы:
процессор не обращается к озу:
C25 11110000111100001111000011110000
C17 00110000000000000011000000000000
C18 00000000001100000000000000110000
процессор на каждом такте обращается к озу:
С25 11110000111100001111000011110000
С17 00110000001100000000000000000000
С18 00000000000000000011000000110000
С25 - тактовая частота
С17 - выборка аттрибута
С18 - выборка пикселов
т.е. если процессор обращается к озу, то пентагон в течении одного такта не производит смену аттрибут/пиксел и продолжает выбирать тот-же байт что и на прошлом такте. Непонятно зачем так сделано, ведь обращение к памяти всеравно получается идет... или регистр захвата срабатывает, но чтение памяти не производится из-за блокировок по другим сигналам?
т.е. если процессор обращается к озу, то пентагон в течении одного такта не производит смену аттрибут/пиксел и продолжает выбирать тот-же байт что и на прошлом такте. Непонятно зачем так сделано, ведь обращение к памяти всеравно получается идет... или регистр захвата срабатывает, но чтение памяти не производится из-за блокировок по другим сигналам?
Думаю, это сделано для того чтобы после того, как процессор обратился к памяти, видеоконтроллер не считывал опять тот же атрибут или пиксель, который он уже считал до обращения процессора к памяти.
Например, читаем атрибут, в следующем такте - процессор (а у видеоконтроллера по-прежнему атрибут, но сейчас этот адрес не используется), в следующем такте опять активен видеоконтроллер и он переключает адрес на пиксель и читает его.
А сигналы С17 и С18 блокируются при обращении процессора на элементах D7.1-2
"Значит так... Солнце на западе… Значит, Ашхабад – там" © кин-дза-дза
Значит так, в эмулях в RAGE бордюр и экран совпадают, вот пусть будет совпадение и на реальных Пентагонах. Не будем нарушать отчетность, пусть будет красиво. Тем более в своем Speccy2010 этого все же добился..
а полпикселя-пиксель подгонять программно - это нереально, тогда и статика на бордюре некрасиво будет смотреться..
упд - ну да, пусть не настоящий пентагон, пусть эмулятор, но все же..Картинку выкладывал, но выложу еще раз, До и ПОСЛЕ...
http://savepic.org/3446340m.jpg (http://savepic.org/3446340.htm)
Переделал рендер бордюра в своем эмуляторе. Теперь пискель бордюра на котором происходит смена цвета настраивается. Его цвет равен смешанному цвету из бывшего и нового цвета. Доли цветов настраиваются. Если установить долю в 0, то бордюр будет совпадать с экраном. Если установить в 100 бордюр будет отставать на 1 пиксель. Как выглядит картинка, когда доля установлена на 50 можно посмотреть на скриншотах.
Также полностью переделан рендер экрана. Теперь эмулятор как и реальный Пентагон на каждом такте (кроме тактов обращения к памяти Z80) считывает по очереди байты пикселей и атрибутов. Байты складываются в буфер и по окончанию кадра из них формируется изображение текущего кадра. Тесты показывают полную идентичность с реальным Пентагоном.
Демонстрация работы теста stime (http://www.youtube.com/watch?v=XpzIuWk0nVk)
introspec
30.04.2014, 02:42
Также полностью переделан рендер экрана. Теперь эмулятор как и реальный Пентагон на каждом такте (кроме тактов обращения к памяти Z80) считывает по очереди байты пикселей и атрибутов. Байты складываются в буфер и по окончанию кадра из них формируется изображение текущего кадра. Тесты показывают полную идентичность с реальным Пентагоном.
Lion17, замечательная новость! Когда и где можно ожидать релиза нового эмулятора?
Lion17, замечательная новость! Когда и где можно ожидать релиза нового эмулятора?
Как только доведу до состояния, когда его можно будет запустить не на моем компе. И то это будет не релиз, а ранняя альфа. Пока все слишком сыро и неоптимизировано.
Doronetty
30.04.2014, 18:27
Lion17 присоединяюсь к ожидающим релиза (был поклонником старого эмулятора)!
Помню тоже был поклонником, даже звонил Владимиру в Ростов — спрашивал про новые версии :)
Создал тему с релизом http://zx.pk.ru/showthread.php?t=23363
Spectramine
08.11.2017, 11:15
Посмотрел схему Пентагона. Процессор имеет приоритет над видео-контроллером. Как только активен MREQ и на шине адреса - оперативка, в следующем такте происходит чтение памяти процессором. Все остальное время каждый такт происходит по очереди чтение атрибутов или пикселей. Так как они считываются асинхронно с границей знакоместа, то сначала они помещаются в буферные регистры, а на границе знакоместа переносятся в регистры вывода, а оттуда попиксельно выталкиваются на экран.
Исходя из выше-сказанного, мерцание пикселей в тесте легко объясняется. Судя по всему за один кадр видео-контроллер успевает считать нечетное количество байт (атрибуты + пиксели). Поэтому, в одном кадре непосредственно после записи #FF в верхний левый угол экрана считываются пиксели (полоска есть), а в другом - считываются атрибуты, а пиксели уже считались до записи (полоски нет).
Tackts: 17983 | 17984 | 17985
Frame 0: RAT=32 | WRT=FF | RPX=FF (полоска есть)
Frame 1: RPX=00 | WRT=FF | RAT=32 (полоски нет)
RAT - чтение атрибутов, RPX - чтение пикселей, WRT - запись CPU
Получается, что на текущий момент ни один из эмуляторов точно не воспроизводит времянку Пентагона.
Забавно, всегда считал, что эмулировать Пентагон проще всего. Оказалось, наоборот.
Вопрос к хардварщикам. Правильно ли я понимаю, что при обращении к портам ввода-вывода видеоконтроллер Пентагона тоже приостанавливает чтение видеопамяти (т.к. в этот момент шины адреса/данных также заняты процессором, по идее)? И если да, на сколько тактов, на один или на два?
s_kosorev
08.11.2017, 15:16
какая то каша в голове, что значит "тоже" в цитате " Правильно ли я понимаю, что при обращении к портам ввода-вывода видеоконтроллер Пентагона тоже приостанавливает чтение видеопамяти" ?
Spectramine
08.11.2017, 17:50
Из приведенной мной цитаты сообщения Lion17 можно понять, что в Пентагоне процессор имеет приоритет над видеоконтроллером при доступе к памяти, и на время такта обращения процессора к памяти видеоконтроллер приостанавливает поочерёдное чтение байтов пикселей/атрибутов следующего знакоместа. Я предположил, что, поскольку доступ процессора к портам ввода-вывода тоже использует шины адреса и данных, на время доступа процессора к порту видеоконтроллер _тоже_ приостанавливает поочередное чтение байтов пикселей/атрибутов. В данной теме этот вопрос не подымался. Я также предположил, что, поскольку цикл доступа к порту занимает не 3 такта, как цикл доступа к памяти, а 4, то видеоконтроллер, возможно, приостанавливается в этом случае не на один такт (как при доступе к памяти), а на два.
Spectramine
11.11.2017, 23:12
Модифицировал тест btime так, что вместо вывода в бордюр он теперь переключает экранные страницы, с целью исследовать поведение реального Пентагона на этой операции: 62853. Как и ожидалось, поведение нового теста на разных эмуляторах разное.
Предполагаю, что эмуляторы ZX DevStudio (http://www.animalservice.ru/ZXDevStudio/ZXDevStudio_1.4.0.zip) и ZXMAK2 ведут себя ближе всего к реальному Пентагону, поэтому приведу их результаты:
62854
http://s019.radikal.ru/i633/1711/a6/7ddf2addb60a.png (http://radikal.ru)
Просьба к владельцам реальных Пентагонов (не аппаратных эмуляторов) проверить тест, и привести здесь результаты теста по тактам, буду очень благодарен. Надеюсь, что этот тест поставит точку в раскладке таймингов Пентагона. По завершению приведу полную раскладку.
Portos13
12.11.2017, 19:34
Виноват.. не очень понял как записать. Снял видео.
https://youtu.be/tiM_N8xuARs
128 Пентагон , красная плата 2014года
Spectramine
12.11.2017, 22:51
Виноват.. не очень понял как записать. Снял видео.
https://youtu.be/tiM_N8xuARs
128 Пентагон , красная плата 2014года
Огромное спасибо! Видео даже лучше. Из вашего видео видно, что поведение теста на реальном Пентагоне в точности соответствует поведению эмулятора ZX DevStudio. Чуть позже выложу полную раскладку таймингов Пентагона.
- - - Добавлено - - -
Итак, тайминги Пентагона.
Нового тут немного, но, возможно, будет полезно свести данные в одном месте.
Основные:
Частота процессора: 3.5 МГц (при кварце на 14 МГц) или 3.575 МГц (при кварце на 14.3 МГц; ближайшие номиналы — 14286 и 14318)
Частота строк: 15.625 кГц или 15.96 кГц (см выше)
Частота кадров: 48.828 Гц / 49.87 Гц (см выше). Для эмулятора — можно спокойно округлять до 50Гц.
Число строк развертки: 320
Тактов процессора на строку: 224
Пикселей на такт: 2
Длина кадра в тактах процессора: 320*224=71680
Длина импульса прерывания — подстраивается, но лучше, чтобы была в районе 36 тактов.
Экранные строки по порядку сверху вниз:
16 строк кадрового синхроимпульса (невидимых)
16 невидимых строк верхнего бордюра (хотя дема Across the Edge считает их видимыми, они не отображаются на большинстве мониторов, TV, и эмуляторов. Фактически, я знаю только один эмулятор, отображающий их — Z80Stealth, плюс их выводит ZX DevStudio, помечая их яркостью как невидимые. upd. Форк UnrealSpeccy от tsl также выводит невидимые строки верхнего бордюра.)
48 видимых строк верхнего бордюра (как минимум, на большинстве эмуляторов)
192 строки растрового экрана (с знакоместами)
48 строк нижнего бордюра
Экранная строка верхнего/нижнего бордюра:
32 такта гашения со строчным синхроимпульсом
192 такта вывода бордюра (192*2=384 пикселя)
Экранная строка с знакоместами:
32 такта гашения со строчным синхроимпульсом
36 тактов левого бордюра (72 пикселя)
128 тактов растровой картинки (INK/PAPER) (256 пикселей)
28 тактов правого бордюра (56 пикселей)
Количество строк верхнего и нижнего бордюра, а также ширина левого и правого бордюра, реально отображаемого на экране, зависит от ТВ/монитора. В большинстве эмуляторов отображается 48 строк бордюра сверху и снизу, и по 48 пикселей бордюра слева/справа.
Важные начальные такты:
0й такт. Захват прерывания происходит на последнем такте команды предыдущего кадра. Но, чтобы он был захвачен, импульс прерывания должен начаться ещё раньше, на предпоследнем такте команды. Т.е. самым первым тактом кадра, при программном выравнивании на начало кадра, фактически является предпоследний такт предыдущей команды. Поэтому, если такты нового кадра в эмуляторе нумеруются с начала цикла подтверждения прерывания, начиная с нулевого (а это практически стандарт), дальнейшие значения нужно уменьшать на 2.
(16+64)*224 = 17920й такт — начало первой строки экрана с растровой картинкой
17920+32 = 17952й такт — начало вывода левого бордюра первой растровой строки
17920+32+36 = 17988й такт — начало вывода растровой картинки первой растровой строки
17920+32+36+128 = 18116й такт — начало вывода правого бордюра первой растровой строки
Ещё раз по тактам кадра, выровненного программно:
0й такт — начало импульса INT
1й такт — захват импульса INT процессором
2-й такт — начало цикла подтверждения прерывания. для IM 2 он длится 19 тактов
21-й такт — начало первой команды обработки прерывания IM 2
…
17988-й такт — начало вывода растра (INK/PAPER)
Внимание — эмуляторы в большинстве (Spectaculator, SpecEmu, Unreal, ZXMAK2, скорее всего и другие) нумеруют такты, считая, что 0й такт — такт начала цикла подтверждения прерывания. Т.е. в эмуляторах номера тактов в выровненном программно кадре такие:
предпоследний такт предыдущего кадра — начало импульса INT
последний такт предыдущего кадра — захват импульса INT процессором
0-й такт — начало цикла подтверждения прерывания. для IM 2 он длится 19 тактов
19-й такт — начало первой команды обработки прерывания IM 2
…
17986-й такт — начало вывода растра (INK/PAPER)
…
71679 такт — последний такт кадра
Пока на 5 машинах (Lion17, goodboy, JV-Soft, IL_DECAMERON, Portos13) тесты показали единообразие таймингов. Единственное отличие пока что — в таймингах переключения экранов, которые отличаются на такт на двух машинах с совпадающими во всём остальном таймингами.
Хотя, возможно, существуют Пентагоны с другой растактовкой, со смещением начала сигнала INT относительно начала кадра (и, соответственно, смещением такта начала растра относительно такта начала цикла подтверждения прерывания), можно предположить, что вышеописанная схема — самая распространенная, и её можно принять за стандарт.
(upd. Протестирована машина с началом INTa на один такт позже от предыдущих машин — соответственно, количество тактов от начала подтверждения прерывания до вывода растра на 1 такт меньше, и результаты в тестах на 1 такт раньше. Причем, на этой машине переключение экранов происходит после 2го такта машцикла вывода в порт (а изменение цвета бордюра — по-прежнему после 1-го).
upd2: Протестирован ещё один комп с такими же результатами (начало INT на такт позже).)
Видеоконтроллер Пентагона.
Видеоконтроллер Пентагона читает байты пикселей/атрибутов попеременно на каждом такте процессора, за один такт один байт. Когда процессор обращается к ОЗУ, видеоконтроллер приостанавливает чтение видеопамяти на этот такт (второй такт машинного цикла обращения к ОЗУ), при этом также приостанавливая изменение триггера выборки пикселей/атрибутов. Этот триггер, к тому же, не сбрасывается на границе кадра. Поэтому, в зависимости от количества обращений процессора к ОЗУ, в любом такте с одним и тем же номером в разных кадрах может происходить как выборка пикселей, так и атрибутов.
По завершению вывода 8 пикселей растра видеоконтроллер на следующем такте начинает выводить следующие 8 пикселей по значениям пикселей/атрибутов, заблаговременно считанным им ранее.
Бордюр
Вывод нового цвета бордюра в Пентагоне не выровнен на границу пикселей растрового поля. Поэтому пиксели бордюра слегка смещены по сравнению с пикселями растра. В частности, в конце демо Rage после остановки вращения сегментов на реальном Пентагоне видно, что вертикальная полоска на бордюре слегка смещена влево, по сравнению с полоской на растровом поле.
http://zx-pk.ru/attachment.php?attachmentid=41384&d=1367664905
По данным Lion17, вывод нового цвета бордюра видеоконтроллером начинается спустя некоторое время после начала 2-го такта машинного цикла вывода в порт. Однако, для эмуляторов достаточно принять, что цвет бордюра меняется сразу после 1го, начиная со 2-го такта цикла вывода в порт.
В Пентагоне цвет бордюра обновляется каждый такт, соответственно точность отображения бордюра — 2 пикселя (в отличие от фирменных машин, в которых цвет бордюра обновляется каждые 4 такта, и точность отображения бордюра — 8 пикселей).
Переключение экранных страниц
Моя модификация теста btime от Jan Bobrowski, тест ptime-p показал, что есть два варианта таймингов переключения экранных страниц для видеоконтроллера.
На некоторых машинах переключение идет после 1-го, начиная со 2-го такта машинного цикла вывода в порт, а на некоторых - после 2-го, начиная с 3-го такта цикла.
Видео поведения теста, снятое Portos13
https://www.youtube.com/watch?v=tiM_N8xuARs
и IL_DECAMERON:
https://www.youtube.com/watch?v=wEUNfrcKTnA
На сегодняшний день наиболее точно отражает поведение реального Пентагона в плане эмуляции видеоконтроллера эмулятор ZX DevStudio. На нём правильно работают тесты stime и тест ptime-p. Все остальные эмуляторы (включая, я так понимаю, и аппаратные), выдают в этих тестах результаты, отличные от поведения реального Пентагона. Однако, в этом эмуляторе неправильно эмулируется команда PUSH : изменена последовательность записи в память - сначала пишется младший байт, потом старший, что подтверждено тестом ltime.
Скачать набор тестов в TRD-образе можно здесь: http://zx-pk.ru/attachment.php?attachmentid=63018&d=1511457692
Ознакомиться со всеми результатами тестов - здесь: http://zx-pk.ru/threads/28382-artefakty-demok-v-emulyatorakh-i-na-realnom-pentagone.html?p=936256&viewfull=1#post936256
Выражаю благодарность всем, протестировавшим свои Пентагоны, и поделившихся результатами:
Lion17, goodboy, Portos13, IL_DECAMERON, и особо - JV-Soft-у, протестировавшему 3 своих Пентагона.
shurik-ua
12.11.2017, 23:12
настолько глубоко похоже никто не копал до этого )
Spectramine
12.11.2017, 23:24
Ну вроде как у Lion17 в эмуляторе ZX DevStudio всё это уже есть. Данные разрознены по разным сообщениям, а по переключению экранов вообще конкретной информации не было.
Вот здесь это ещё ражёвывалось, рекомендую почитать, может пригодится, начиная с моего поста от 02.02.2014 16:58:55:
http://forum.tslabs.info/viewtopic.php?f=31&t=20&start=225
Spectramine
13.11.2017, 10:50
Вот здесь это ещё ражёвывалось, рекомендую почитать, может пригодится, начиная с моего поста от 02.02.2014 16:58:55:
http://forum.tslabs.info/viewtopic.php?f=31&t=20&start=225
Спасибо за наводку, нашел ещё несколько демок для тестов, и тест MulFix.
Вопрос - что означает параметр HSInt в данном контексте?
HSInt в данном контексте
вроде какая то переменная в прошивке для PentEVO.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot