ПК8000 - Быстродействие архитектуры. Исследование.

[ivagor]

Черная полоска закончилась под Г (она высотой в одну строку, поэтому надо вглядеться), т.е. 8 символьных позиций от начала активной области строки. 8 (в данном случае думаю не 4) тактов от HLT+20 тактов RST+20 тактов OUT=48 тактов/4 такта на символ=12 символьных позиций от момента прихода прерывания. Т.е. если я ничего не забыл, то запрос прерывания становится активен где-то за 16 тактов до начала отображения активной области первой строки нижнего бордюра.
По поводу тактовой частоты мое мнение не изменилось, я считаю, что 2,5 МГц.

---------- Post added at 23:45 ---------- Previous post was at 23:33 ----------

К слову, сейчас заметил, что при переделке из TB115 перестарался и убрал задание счетчика строк, поэтому счетчик заканчивает считать уже при выводе символов - в результате обещанной черной полоски справа вверху нет. Если интересно, могу выложить откорректировнный вариант, но на определение момента прихода прерывания это никак не влияет.

[ivagor]

Пара слов по поводу невозможности 1,8 МГц. В этой теме есть много доказательств.
Если тактовая была бы 1,8 МГц, то между прерываниями было бы 1,8e6/50=36000 тактов. То, что прерываний в секунду в районе 50 Mick проверил на реале сравнением с внешним эталоном здесь. Результаты ранних тестов с бордюром и попытки их интерпретации лучше просто пропустить . Также Mick заметил (ссылку при необходимости найду) при сравнении с эмулятором, что при проигрывании музыки по прерываниям она играет чуть быстрее, чем в эмуляторе, т.е. Int Rate немного больше 50 Гц, что потом и подтвердилось другими тестами.
Дальше смотрим результаты подсчета количества выполненных из внешнего ПЗУ DAD и INX за прерывание. 1172HEX=4466DEC, 1FF5HEX=8181DEC. 36000/4466=8 тактов на один DAD, т.е. <10, что на ВМ80 невозможно, 36000/8181=4,4 такта на один INX, т.е.<5 что опять же невозможно.
Вернемся в наше время. Результаты pst1.1. Опять же возьмем DAD. В SCR1/2 за прерывание их выполняется 1001HEX=4097DEC. 36000/4097=8,79 тактов, т.е. опять <10 - не получится на ВМ80. В SCR0 аналогично. Надеюсь, что этих доказательств достаточно хотя бы для оценки того, что тактовая частота ПК8000 несомненно больше 1,8 МГц. В качестве альтернативы можно только предположить, что в ПК8000 стоит волшебный клон 580ВМ80, который исполняет команды за меньшее число тактов, чем обычные ВМ80

[DemonId7]

Может и не волшебный, но если не ошибаюсь, то был ВМ80 на 5МГц Спасибо, теперь ясно.
Тогда другой вопрос, почему скорость так сильно отличается от заявленной в документации? Это из-за ожиданий циклов регенерации памяти? Если да, то тесты для SCR 0 нужно повторить, там ведь регенерация портилась.

[ivagor]

Могу привести свои соображения. Вроде я их уже в разных местах писал, но пусть здесь будет "сборник". Сначала "аксиомы" (если их принять, то можно объяснить полученные результаты)
1. При чтении из памяти добавляется задержка в 1 такт.
2. При записи в память добавляется задержка в еще один такт.
При выполнении команд из внутреннего ПЗУ (для него п.2, конечно, не имеет смысла) и внешней памяти этой информации достаточно для расчета числа тактов/команду.
При выполнении команд из внутреннего ОЗУ, используемого процессором совместно с видеоконтроллером, нужно учитывать, что:
3. В SCR1/2 доступ процессора к ОЗУ возможен один раз в 4 такта, т.к. в активной области для вывода каждых 8 точек видеоконтроллеру нужно выбрать по 3 байта из ОЗУ, по крайней мере для SCR2 это 100% справедливо. В SCR1 есть непонятный момент - атрибуты читаются из 155РУ2, почему при этом тормоза аналогичны SCR2 - не знаю. Если бы не п.п.1-2, то тормоза в ПК8000 были бы аналогичны вектору.
4. По поводу SCR0/недокументированного полной уверенности нет, но для простых команд я посчитал - все сходится. Текущее IMHO такое: в активной части строки нужно для вывода каждых 6 точек читать из ОЗУ 2 байта, что дает нам область 40*3=120 тактов, в которой процессор имеет доступ к ОЗУ 1 такт из трех. Сбоку остается 10*4=40 тактов с циклами, аналогичными SCR1/2. "Сбоку" в SCR0 как раз выбираются байты из конца строки, служащие для регенерации ОЗУ.
Наличие в течении строки областей с разным торможением подтверждается и таким результатом - там есть "переходной процесс" и "установившийся режим" на нижнем бордюре, т.е. вначале отработки прерывания, при том, что задержка по строкам задавалась одними и теми же командами.

Если да, то тесты для SCR 0 нужно повторить, там ведь регенерация портилась.

По хорошему, тесты SCR0 и недокументированного в pst1.1 стоило бы сделать более корректно, но могу высказать простое соображение, почему в них ничего не испортилось и почему результаты ранее тестировавшихся команд совпали со "старыми" (точно корректными в плане регенерации) тестами - там каждый тест в течении кадра пробегает по последовательным адресам ОЗУ, прямо как видеоконтроллер, поэтому ничего не портится. Содержимое ОЗУ все же не так просто испортить, что подтверждают результаты regen/regen2. Вопрос с регенерацией в SCR0, конечно, надо бы полностью прояснить - в какие позиции строки можно/нужно писать и какие именно коды (учитывая расхождение документации и того, что делает ПЗУшный софт).

если не ошибаюсь, то был ВМ80 на 5МГц

Наверно речь о 580ВМ1 - тактовая у него до 5 МГц, но время выполнения "старых" (общих с ВМ80) команд у него, согласно имеющимся докам, совпадает с ВМ80.

[ivagor]

Появилось много идей по поводу SCR0, может даже удастся уточнить время выполнения команд, но перед этим хотелось бы проверить ряд моментов.
Вот программка типа предыдущей INTPOS, но для SCR0.
BS0.zip
Рисует экран в клетку и двухцветный бордюр. Интересно, куда дойдет черная полоска снизу и будет ли вертикальна граница между цветами бордюра (надеюсь, что и в ч/б это будет видно).

Рассчитал для всех команд предполагаемое время выполнения из ОЗУ в SCR0 на бордюре и в активной области. Выкладывать пока такие спекуляции рано, но уточню предыдущий пост - там я сначала написал, что доп. такт торможения есть и при обращении к портам (не только к памяти), но 99%, что все же нет.

[DemonId7]

Вроде все видно:

[Advertiser]

[ivagor]

Все отлично видно!
Этот тестик одним махом решил несколько задач:
1. Показал, "где начинается прерывание" с учетом специфики SCR0
2. Показал, что бордюра сбоку (по крайней мере в SCR0) нет. Поясню свое видение - в SCR1/2 ширина активной области 256 точек, в SCR0 - 240, причем не посередине тех 256, а правая часть. Т.е. слева в SCR0 остается область шириной 16 точек и тюнер ее показывает. Так вот она не окрасилась и осталась черной.
3. Самое главное - это точка отсчета или шаблон для определения числа тактов в активной области SCR0. Клетки - это линейка с засечками, темный (синий) участок бордюра - по нему собственно измеряем.
Если честно, то случайно еще кое-что проверил, но лучше промолчу, уже все поправил.

Похвалю себя - с первого раза все точно посчитал, да и все растактовки пока подтверждаются! Да еще и точно попал в обе области, нет "переходного режима" как в старых тестах SCR0.

Теперь можно попытаться проверить растактовки для активной области (сбоку нечего проверять, там аналогично SCR1/2). Для затравки 3 команды - xthl (2 повторения), shld (2 повторения) и in (4 повторения). Исходник приложил только для xthl, но они все однотипные, что сразу видно. Если все получится и я нигде не ошибся, то все 3 теста должны показать одинаковые картинки.

[DemonId7]

Результаты. S0In4, S0SHSH и S0XTXT соответственно:

На глаз вроде одинаковы.

[ivagor]

По клеткам тоже одинаковы, так что все отлично. Для успокоения совести еще пара тестов, они должны дать столько же клеток. Чтобы граница между зеленым и синим (светлым и темным) бордюром оставалась вертикальной, пришлось делать миксы команд. Какие именно - можно посмотреть в Int.asm, после out 88h и до mvi a,48h.
Если и тут не будет неожиданностей, то выложу уточненную табличку растактовок.

[DemonId7]

Идеально совпадают:

Так что, ждем табличку растактовки?