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

[ivagor]

Mick
Ну что, эпопея с тестами приближается к концу. Как считать производительность программы при выполнении из ПЗУ или внешней памяти - уже известно. Как считать производительность программы при выполнении из внутреннего ОЗУ - по результатам прошлых и недавних тестов я тоже вроде догадался, но, чтобы все было четко и чтобы мне хоть кто-то поверил, сделал практически "всеобъемлющий" тест. Исходник и readme прилагаются. Запуск на эмуляторе показал, что ошибок в растактовке команд в b2m нет, все по справочнику . Как должно быть на самом деле на ПК8000 мы сможем узнать, когда ты сфоткаешь экран RAMSPD с результатами. Желательно (на всякий случай) прогнать программу 2 раза и сфоткать 2 раза.

[Advertiser]

[Mick]

Mick
Ну что, эпопея с тестами приближается к концу. Как считать производительность программы при выполнении из ПЗУ или внешней памяти - уже известно. ......

Постараюсь прогнать его в субботу. И потом, после обработки всех промежуточных результатов мы все ждем так сказать официальных выводов твоего "исследования".

[Mick]

Как должно быть на самом деле на ПК8000 мы сможем узнать, когда ты сфоткаешь экран RAMSPD с результатами. Желательно (на всякий случай) прогнать программу 2 раза и сфоткать 2 раза.

Ну вот запустил, как ты просил два раза - результат одинаков. Но сфоткал как просил два раза.

Кстати, когда запустил тест, мне сразу показалось что комп заглючил, на экране всякая фигня начала мельтешить. Думаю, ну вот и все - Ivagor умудрился убить машину тестом
А потом когда появились результаты - сразу стало легче

[ivagor]

Ну вот запустил, как ты просил два раза - результат одинаков. Но сфоткал как просил два раза.

Аж не верится , полное совпадение цифр.

Кстати, когда запустил тест, мне сразу показалось что комп заглючил, на экране всякая фигня начала мельтешить. Думаю, ну вот и все - Ivagor умудрился убить машину тестом

Не умею я тестами убивать . Там 2 причины миганий: постоянное переключение режимов экрана и изменение цвета бордюра в одном из тестов.

По SCR1 и SCR2 предположения подтвердились, результаты объяснимые. Там такая штука происходит: как и при выполнении программы из ПЗУ или из внешней памяти, каждое обращение к памяти вызывает задержку в 1 такт, а дальше уже разница - ждем окно для чтения/записи, которое случается 1 раз в 4 такта. Т.е. почти как в векторе, только еще хуже из за задержки в такт. Для полноты картины приведу число тактов на команду для SCR1 и SCR2 при выполнении из внутреннего ОЗУ (посчитано по скриншотам):
INX - 8
DAD - 12
MVI R - 12
LXI - 16
LHLD - 24
ADD R - 8
LDA - 20
OUT (по крайней мере в порт 88h) - 20. Тут какая-то дополнительная задержка есть.
XTHL - 36
IN (по крайней мере из порта 81h) - 16
PUSH - 20
По моему мнению, вполне можно распространить эти результаты на команды, которые я указал в readme к RAMSPD.
Используя полученные результаты пересчитал число тактов на строку в TOPBR7 - получилось 160 тактов, все ОК.

По SCR0 не все понятно. Как я думал - задержка в такт на каждое обращение к памяти, а потом ждем окно для чтения/записи, которое случается 1 раз в 3 такта. Результаты получились близкие, но не на 100%. Еще такой момент - в строке при Fтакт=2,5 МГц должно быть 160 тактов, для SCR1 и SCR2 это совпало. А для SCR0, 160 на 3 не делится. Может там по бокам по 4 такта (10*4=4), а в активной области по 3 (40*3=120)? Или там 53*3+1=160?

[ivagor]

По SCR0 не все понятно. Как я думал - задержка в такт на каждое обращение к памяти, а потом ждем окно для чтения/записи, которое случается 1 раз в 3 такта. Результаты получились близкие, но не на 100%. Еще такой момент - в строке при Fтакт=2,5 МГц должно быть 160 тактов, для SCR1 и SCR2 это совпало. А для SCR0, 160 на 3 не делится. Может там по бокам по 4 такта (10*4=4), а в активной области по 3 (40*3=120)? Или там 53*3+1=160?

Посчитал, все же в SCR0 похоже 10*4+40*3 (как именно они разложены в строке не знаю, но в среднем именно так), тогда получается объяснить полученные растактовки. Например 4х или 5 тактные команды на "трехтактном участке" выполняются 6 тактов, а на "четырехтактном" - по 8. Четырехтактные участки длятся четверть строки, трехтактные 3/4. (6*3+8*1)/4=6,5 тактов, что и получилось для INX и ADD. Остальные тоже проверил, примерно совпадает.
Остались вопросы (по всем режимам):
1. Точный (до такта) момент прихода прерывания. Пока понятно примерно с точностью четверть строки.
2. Торможение при OUT и специфические эффекты иногда проявлявшиеся при OUT в порт бордюра.

[ivagor]

Радикально отредактировал много своих старых постов в данной ветке - убрал цифры, оказавшиеся ошибочными.

[ivagor]

Внимательно еще раз проанализировал результаты тестов. С вероятностью 99.99% могу утверждать, что у ПК8000 308 строк в кадре, соответственно прерываний в секунду не 50, а чуть больше (примерно 50.73), что подтверждается еще и этим постом Micka:

Кстати полоски, сложилось у меня такое впечатление - бегут быстрее чем в эмуляторе.

Немного удивительно, как Mick на глаз увидел такую маленькую разницу, наверно параллельно запускал driller в эмуляторе и на реале.

[b2m]

Так надо просто посчитать, сколько прерываний, например, за 20 минут будет. Тест очень простой: нажимаем клавишу - пошёл счёт, ещё раз нажимаем - останавливаем и выводим результат.

[ivagor]

Так надо просто посчитать, сколько прерываний, например, за 20 минут будет. Тест очень простой: нажимаем клавишу - пошёл счёт, ещё раз нажимаем - останавливаем и выводим результат.

Сначала у меня только подобная идея была, плюс такие детали тестирования - нажимаем клавишу запуска теста на ПК8000 и одновременно фотографируем экран и часы (проще всего, наверное, было бы использовать часы самого фотика). Потом через продолжительное время еще раз фотографируем экран и "независимые" часы.
Потом вспомнил один PCшный тест, используя идею которого можно получить точный ответ за пару секунд (тестерских, не программерских):
Меняем цвет бордюра, делаем задержку (на 154 или на 156 строк), еще раз меняем цвет бордюра, снова делаем задержку на 154 или на 156 строк, и все это при запрещенных прерываниях. Чтобы "рисунок" на бордюре начинался в предсказуемом месте, можно начать цикл после прерывания, хотя это совсем не обязательно. Если бордюр неподвижен при 154 строковой задержке, то на ПК8000 308 строк.

Первый вариант проще написать (т.к. легко можно проверить работоспособность в эмуляторе), второй проще тестировать (но легко ошибиться при написании с величиной задержки).

Сам я не собираюсь делать ни тот тест ни другой, но с интересом посмотрел бы на результаты.

[ivagor]

Возможен еще и третий вариант теста, простой для тестера и для программиста (т.к. он уже сделан, отлажен и даже опробован на реальном ПК8000). Это ранее выкладывавшийся TOPBR7. Нужно заменить один байт - количество строк изменить на 115, запустить и сфоткать. По месту стыка верхнего бордюра и активной области изображения можно будет увидеть, как там на самом деле.
Тест из форума я убрал, но у Mickа он, наверное, остался, так что он может попробовать. Правда, я скорее всего выкладывал в тот раз без исходника.
Вопрос к Mickу и/или Xobbimanу - если я выложу модифицированный тестик, Вы попробуете на реале и покажете фотки результата?