Просмотр полной версии : ПК8000 - Быстродействие архитектуры. Исследование.
Пытливый ум Ivagor'a решил узнать всю правду о заявленном быстродействии машинок данной архитектуры. Что из этого вышло, узнаете прочитав данную ветку.
Еще один тест :).
Считает скорость заполнения VRAM из ПЗУ и из ОЗУ.
Чтобы не занимать много места, выкладываю в формате cas (к слову, набирал в blueMSX), castoolsом легко преобразуется в wav.
Загружать load"ROMRAM"
26.08.2008
Удалил вложение.
Новый вариант теста - ROMRA3
А ты не мог бы попробовать vspeed или romram на реале?
А ты не мог бы попробовать vspeed или romram на реале?
Скажем так - в воскресенье буду собирать после чистки Суру, у ней вроде все кнопки рабочие. Тогда и попробую. Сейчас не все кнопки работают в Весте. :(
Вот запустил romram. Результаты на лице, тьфу ты на мониторе.
Ну а теперьрасказывай ivagor что это значит.
Спасибо, получается торможение есть.
Для SCREEN 0
При записи в VRAM процедуркой из ROM "эквивалентная частота" 1,886 МГц.
При записи в VRAM процедуркой из RAM "эквивалентная частота" 1,6277 МГц.
Эксперимент не совсем чистый, т.к. запись в обоих случаях в ОЗУ.
Чтобы узнать max быстродействие надо найти подходящую процедурку в ROM ("будем искать :)").
Mick, я немножко оборзею :)
Можешь попробовать в режимах SCREEN 0 и SCREEN 1 (нужно поменять циферку в строке 10)? В этих режимах должно быть быстрее.
Если прогнать несколько раз, цифры сильно отличаются?
Mick, я немножко оборзею :)
Можешь попробовать в режимах SCREEN 0 и SCREEN 1 (нужно поменять циферку в строке 10)? В этих режимах должно быть быстрее.
Если прогнать несколько раз, цифры сильно отличаются?
Поменял, цифры те же, без каких либо изменений.Тупо понажимал F5(RUN) - цифры не меняются.
Очередной тест :).
Это попытка с другой стороны (по сравнению с ROMRAM2), за счет исполнения львиной доли кода из ПЗУ (нашел таки приемлемую процедурку) посчитать максимальное быстродействие ПК8000.
26.09.2008 Вложение удалено
Загрузка CLOAD"MAXSPD"
Результат - примерная тактовая частота в Гц.
b2m
Все таки в твоем эмуляторе есть небольшое "плавание" длительности прерывания (это справедливо по крайней мере для вектора и для ПК8000).
Mick
Если сегодня есть время, может прогонишь тесты?
еще бы одну идею проверить - влияет ли гашение экрана на быстродействие.
ROMRAM2.rar
Загружать cload"ROMRAM2"
Желательно прогнать несколько раз, вдруг что-то будет меняться (хотя судя по прошлому тесту не должно).
Очередной тест .
Это попытка с другой стороны (по сравнению с ROMRAM2), за счет исполнения львиной доли кода из ПЗУ (нашел таки приемлемую процедурку) посчитать максимальное быстродействие ПК8000.
MAXSPD.rar
Загрузка CLOAD"MAXSPD"
Результат - примерная тактовая частота в Гц.
Тогда мы уже сегодня узнаем немного больше о ПК8000 :).
Mick
Если сегодня есть время, может прогонишь тесты?
Тогда мы уже сегодня узнаем немного больше о ПК8000 :).
Прогнал я твои тестики несколько раз - результат не меняется а именно.
А теперь - что в итоге это означает. :)
Спасибо Mick, очень интересно.
Исправленный вариант
К сожалению, в программе нашлись 2 ошибки (в BASIC части), но их можно учесть, тогда получиться вот что:
SCREEN 0
БЕЗ ГАШЕНИЯ ПРИ ГАШЕНИИ
ROM 920 920
RAM 794 794
SCREEN 1
БЕЗ ГАШЕНИЯ ПРИ ГАШЕНИИ
ROM 944 944
RAM 721 721
SCREEN 2
БЕЗ ГАШЕНИЯ ПРИ ГАШЕНИИ
ROM 944 944
RAM 721 721
1. Гашение экрана не влияет на быстродействие (в SCREEN 1 на снимке Mick это ошибка в программе)
Меньше тормозит ОЗУ SCREEN 0 (так в принципе и должно быть, читается код символа и строка символа, атрибут не читается)
Больше тормозит ОЗУ SCREEN 2 (ожидаемо, т.к. из ОЗУ читается код символа, строка символа и атрибут).
SCREEN 1 по быстродействию совпадает со SCREEN 2, (из ОЗУ читается код символа, строка символа и атрибут).
Что мне не понятно:
Почему при записи из ROM SCREEN 1 и 2 быстрее SCREEN 0?
Еще такое замечание - прошлый тест (ROMRAM) тестировал только SCREEN 0 (хотя я написал, что SCREEN 2) и смена номера режима в строке 10 не влияла (извини Mick, я уже исправился :v2_blush:).
"Эквивалентная частота" при выполнении программы из ОЗУ при отсутствии гашения:
SCREEN 0 - примерно 1,6277 Мгц
SCREEN 1 и 2 - примерно 1,478 МГц
2. "Эквивалентная частота" при выполнении программы из ПЗУ 2МГц (b2m как в воду глядел ;)). Это далеко не 2,5 МГц, которые должны быть для обеспечения обещанных в мануале 625 оп/сек, но и не 1,78 Мгц.
Пока вот такие промежуточные результаты.
По поводу быстродействия ПК8000
Нашел две ошибки в ROMRAM2,
Исправленный вариант
Вот исправленный вариант теста
26.09.2008 Вложение удалено
Загружать cload"ROMRA3"
после чего нарисовалась следующая картина
26.09.2008 Вложение удалено
Интересно было бы услышать критику, желательно конструктивную.
Загружать cload"ROMRA3"
Вот загрузил, позапускал - результат один и тот же. Экранчик предоставлен
Mick
Про ROMRA3
Ну да, теперь все правильно.
Единственное, чему я пока не вижу объяснения - почему запись процедуркой из ПЗУ в ОЗУ в режиме SCREEN 0 медленнее чем в SCREEN 1 и 2.
Ну и еще неплохо бы знать, сколько строк до верхней строки от прерывания.
По ПЗУ
После исправления тест прошел.
Mick, XobbiMan
Накропал тестик, который в интерактивном режиме возможно позволит понять сколько строк от прерывания до начала вывода изображения из VRAM.
8978
В эмуляторе его сейчас запускать нет смысла, только на реале.
Загрузка
bload"TOPBRD" (без ,r !)
После загрузки
print usr(&HE000)
Переходим в "интерактивный режим"
Ну не знаю как там на счет интерактивности. Но бейсик дал такой результат и вывалился. Пардон usr написать забыл, сейчас посмотрю :)
Воторй тест не удалось сделать - акум на фотике сел.
Mick
Спасибо. Для меня пока результат неожиданен.
А не пробовал уменьшать (стрелка вверх)? Тогда зелень сверху пропадала и начинала уменьшаться снизу или как?
Второй тест запускал? Там есть зеленая часть бордюра (левая) и синяя (правая)? Если есть, то граница между ними вертикальная или диагональная?
У меня есть дикое несуразное предположение. Может у тебя тип сигнала по этому входу ТВ можно выбирать и при прогоне программы стоял NTSC?
Mick
Спасибо. Для меня пока результат неожиданен.
А не пробовал уменьшать (стрелка вверх)? Тогда зелень сверху пропадала и начинала уменьшаться снизу или как?
Второй тест запускал? Там есть зеленая часть бордюра (левая) и синяя (правая)? Если есть, то граница между ними вертикальная или диагональная?
У меня есть дикое несуразное предположение. Может у тебя тип сигнала по этому входу ТВ можно выбирать и при прогоне программы стоял NTSC?
Пробовал и это. На счет системы сигнала - я не смотрел :)
MicK
Систему посмотри пожалуйста.
Там же в уголке обычно пишет, когда на соответсвующий вход переключаешься.
MicK
Систему посмотри пожалуйста.
Там же в уголке обычно пишет, когда на соответсвующий вход переключаешься.
А вот не пишет - ведь SCART же, я думаю ему то параллельно, но все же почитаю мануал.
Пока что получается следующее (чему я отказываюсь верить :))
Прерывание приходит после окончания вывода изображения, с началом нижнего бордюра (это здорово, но просто очень непривычно).
???Строк в кадре примерно 263-264 (погрешность в тесте +/- строка как минимум). Тогда получается кадровая 60 Гц?
Добавление
Забыл добавить, что количество строк считается правильно, если во втором тесте граница между зеленой и синей частями бордюра вертикальна.
Mick,XobbiMan
Еще один "интерактивный" тест.
На этот раз попытаемся выяснить, сколько у нас прерываний в секунду (раз возникли, по крайней мере у меня, сомнения. Если получится 60 прерываний в секунду в компьютере, предназначенном для подключения к советскому телевизору - это будет очень странно).
26.09.2008 Вложение удалено
Загружать
bload"INTRAT",r
Выводим на экран PCшные часы, ждем пока там будет 0 секунд и жмем пробел в эмуляторе. Ждем одну минуту и смотрим, на каком из счетчиков будет минута (где 50 или 60). Тест в эмуляторе показал, что в нем совершенно ожидаемо реализовано 50 прерываний в секунду.
Конечно, все это можно проделать не с PCшными часами, а с обычными, причем с режимом секундомера даже будет удобнее - не надо ждать пока натикает 0 секунд.
Когда закончили - жмем Enter и вываливаемся в basic.
Также очень хотелось бы узнать результат теста TOPBR2 на реале.
Кстати, на фотографиях видно, что верхний и нижний бордюры = 32 сканлинии (красное поле 50 линий, а высота бордюра 3/5 от красного поля). А у меня по 16. Если бордюры по 32 линии, то итого имеем 256 линий, т.е. как и у других компьютеров (Орион, Специалист 384х256). Таким образом, вертикальная развёртка не сильно отличается от стандартной, и скорее всего, максимальное значение счётчика сканлиний как и везде = 312, а кадровая частота 50 Гц.
Красное поле 64 линии. Ждем результатов TOPBR2 и INTRAT, они должны значительно пояснить картину.
Красное поле 64 линии. Ждем результатов TOPBR2 и INTRAT, они должны значительно пояснить картину.
Прогнал тестики и результат TOPBR2 на трех картинках в хронологии.
INTRAT - четко показал что время совпало при 50Гц.
По картинке видно (отсутствует вертикальная граница между зеленым и синим), что длительность строки я сосчитал неправильно, соответственно строк от прерывания до изображения не 70-72. Попробую пересчитать.
Mick
Если у тебя еще есть моральные и физические силы :), то вот очередная вариация.
26.09.2008 Вложение удалено
Загружать bload"TOPBR3"
Запуск - как в предыдущих вариантах.
Очень надеюсь, что будет видна вертикальная или хотя бы диагональная граница между зеленым и синим.
Удобную оперативную регулировку длины строки пока не сделал. Между запусками можно поменять ячейку 0E061h. Исходно там 3, можно попробовать 2 или 4.
При исходном значении ячейки E061 должно получиться примерно 120 строк от прерывания до изображения.
Очень надеюсь, что будет видна вертикальная или хотя бы диагональная граница между зеленым и синим
Дык сделай "интерактивно" :)
Mick
Если у тебя еще есть моральные и физические силы :), то вот очередная вариация.
8993
Загружать bload"TOPBR3"
Запуск - как в предыдущих вариантах.
При исходном значении ячейки E061 должно получиться примерно 120 строк от прерывания до изображения.
Делал по исходному варианту - нету 120, а есть 97 :)
Диагональ в принципе уже видна, но очень уж крутая.
А если укоротить строку - 2 в ячейку E061?
Про 120 строк я обсчитался, не смог поделить правильно пятизначное число на трехзначное :(. В первоначальном варианте TOPBR3 должно было получиться примерно 100 строк.
XobbiMan
11.09.2008, 22:16
Цитата:
Сообщение от ivagor Посмотреть сообщение
XobbiMan
Раз уж ты включил железку, может сделаешь:
Попробую разобраться
TOPBR3 с параметрами по умолчанию (с другими загружу позже):
(заметил что в screen 0 слева бедит вертикальня пунктирная черточка, может из-за переходника, ибо собран не 100% по схеме, с небольшими отклонениями в деталка - брались аналоги )
Спасибо, картинка получилось как у Micka. Но ты пережал кнопку вниз, там ведь не видно, когда за изображение заходит. При значении по умолчанию цифра должна быть в районе 100.
Попробуй poke &HE061,2, граница между зеленым и синим должна стать более вертикальной.
Mick и XobbiMan
У вас сейчас который час? В Уфе полпервого. Это я к тому, узнаем ли мы сегодня, как рисовать на бордюре и сколько в нем строк :).
XobbiMan
11.09.2008, 22:35
У вас сейчас который час? В Уфе полпервого. Это я к тому, узнаем ли мы сегодня, как рисовать на бордюре и сколько в нем строк .
У нас, пол десятого. Но проэксперементировать дальше смогу только завтра (вечер неспокойный - родные присесть спокойно за техникой не дают)
ОК, спасибо, может у Mickа сегодня получится.
ОК, спасибо, может у Mickа сегодня получится.
Вчера не получилось. Сегодня попробую вечером.
Вчера не получилось. Сегодня попробую вечером.
Вот запустил с параметрами 2 и 4 соответсвенно.
Mick
Который с 2 - уже тепло, можешь еще с 1 попробовать?
Mick
Который с 2 - уже тепло, можешь еще с 1 попробовать?
Да пожалуйста :)
Видно из картинок и циферок, что длительность строки лежит между значениями 1 и 2 в программе TOPBR3.
Mick
Подготовил TOPBR4.
26.09.2008 Вложение удалено
Там сделал поле из 4х команд (E06A-E06D), чтобы в случае необходимости "отюстировать" с точностью до такта, изменение параметра цикла для этого слишком грубо (при такой сравнительно маленькой тактовой частоте).
Mick
Подготовил TOPBR4, которая делает 92 такта на строку
9013
Там сделал поле из 4х команд (E06A-E06D), чтобы в случае необходимости "отюстировать" с точностью до такта, изменение параметра цикла для этого слишком грубо (при такой сравнительно маленькой тактовой частоте).
Вот тебе скриншотики.
Подготовил TOPBR4, которая делает 92 такта на строку
Мне вот интересно, как ты количество тактов прикидывал? Судя по схеме и догадываясь о содержимом РТ2, процессор получает возможность считать байт из памяти каждый третий такт в режиме 0, и каждый 4-тый в режиме 1 и 2. Т.е. торможение приблизительно такое-же, как в Векторе. При этом, тактовая частота, насколько я понял из схемы 2,5 МГц. Учитывая торможение как Векторе, реальная частота 2,5 / 4 * 3 ~ 1,875 МГц, что похоже на правду.
b2m
Ну "номинальных" тактов в строке 160, я сначала, когда делал TOPBRD, думал что на бордюре торможения нет (сразу скажу, увидев РТ2 в схеме даже не пытался разбираться).
Строк от прерывания (которое приходит с началом нижнего бордюра) до активной области - 120 (у Mickа получилось 119 т.к. в программе на опрос клавы тратится почти 2 строки, а я прибавлял при выводе результата одну). Итого 120+192=312 строк.
(про гашение - тогда я думал что гашение влияет на быстродействие, но многочисленные эксперименты, проведенные Mickом это опровергли)
Там просто производилась запись в ОЗУ, количество записанных байт я пересчитал в такты/сек. TOPBR4 дает меньшую погрешность.
Открытых вопросов для меня еще много, буду еще делать тестики, если Mick не бросит это дело.
Там получается примерно 2млн тактов в секунду на реале
Это что-же получается, что там резонатор другой стоит? По схеме (Суры) - 20 МГц, а если при выполнении из ПЗУ ничего не тормозит и тактовая 2 МГц, то получается, что стоит 16 МГц. Может поэтому изображение вытянутое? А кадровую частоту они подобрали путём специальных значений в ПЗУ (РТ2). Счётчик знакомест там хитрый, загружается каким-то числом, считает до определённого места (задано в ПЗУ) и снова загружается. По схеме, загружается числом 56 (или 54 в зависимости от режима 40/32), судя по всему переходит через максимум 64, после чего на выходах оказывается адрес и считает до какого-то числа (конец или начало СГИ).
Добавлено через 5 минут
А номинальных тактов получается 128:
64мкс строка / 0.5 мкс один такт
А номинальных тактов получается 128:
64мкс строка / 0.5 мкс один такт
Может там просто при выполнении программы из ПЗУ wait в 1 такт при чтении, тогда при реальных 2,5 МГц получится "доступных" примерно 2 млн. тактов (для "среднестатистической" смеси команд).
Mick
Теперь для режима 0.
26.09.2008 Вложение удалено
Тут активная область экрана ограничена сверху и снизу красными полосками. Это для некоторого увеличения точности подсчета числа строк, т.к.
1. будет видно, сколько от нижней красной до зелено-синего бордюра (должно быть примерно 1-2 строки).
2. если "пережмешь", то "бордюр" вылезет за красную линию сверху.
Mick
Теперь для режима 0.
9024
Тут активная область экрана ограничена сверху и снизу красными полосками. Это для некоторого увеличения точности подсчета числа строк, т.к.
1. будет видно, сколько от нижней красной до зелено-синего бордюра (должно быть примерно 1-2 строки).
2. если "пережмешь", то "бордюр" вылезет за красную линию сверху.
Вот получай результаты.
Mick
Спасибо, чем дальше в дебри видео ПК8000 тем интереснее.
Либо бордюр делится на 2 части с разной степенью торможения, либо внутри строки торможение неравномерное и то что видно в начале бордюра (снизу от нижней красной линии) - это "подстройка", а потом до конца (до верхней красной линии) идет установившийся режим. Для установившегося режима удалось с первого раза угадать длительность строки.
Еще один интересный момент - в screen 0 при изменении цвета бордюра (между зеленым и синим) нет "переходного процесса" как в screen 2 (там между ними полоса непонятного цвета).
Mick
Очередные тесты.
TOPBR6 - scr 0
TOPBR7 - надеюсь это предпоследний тест scr 2
26.09.2006 Вложение удалено
Mick
Очередные тесты.
TOPBR6 - scr 0
TOPBR7 - надеюсь это предпоследний тест scr 2
Я уже смутно представляю происходящее :) , но всеравно держи результаты.
Первые две картинки - TOPBR6, вторые две - TOPBR7
Как мог пытался высказывать свое понимание промежуточных результатов в предыдущих постах. В будущем, когда все станет ясно, обязательно накропаю файлик, в котором соберу все что здесь было высказано (за вычетом неподтвердившихся гипотез).
Если кратко:
TOPBR7 дополнительно показал 2 вещи по scr 2:
1. Прерывание приходит не совсем в начале первой строки после изображения, а через некоторое время. На подготовку изменения цвета бордюра конечно тоже тратиться время, его оцениваю в 16-20 тактов, что несколько меньше наблюдаемого смещения (max 20 тактов - это менее чем четверть строки, а запаздывание зелени - примерно треть строки, т.е. все равно прерывание приходит не совсем в начале строки). Начиная с TOPBR6 обработчик прерывания посадил прямо с 38h и убрал оттуда опрос клавиатуры, соответственно момент прихода прерывания оценивается отображается более точно.
2. Сравнивая картинки TOPBR4 и TOPBR7 можно заметить, что не в любом месте строки можно "безболезненно" поменять цвет бордюра. В TOPBR4 наблюдаются "переходные полосы" между зеленым и синим, а в TOPBR7 этого нет. Похоже придется делать еще "интерактивное" вращение по горизонтали чтобы поймать эти моменты.
TOPBR6 (scr 0) немного расстроил.
1.Видно, что прерывание приходит чуть позже (правее) чем в scr 0.
Уважаемые реальщики!
26.09.2008 Вопрос снят, извините за беспокойство
XobbiMan
22.09.2008, 21:45
На недельке проверю, заинтересовал тестик.
Mick
Если будет время, может попробуешь прошить в "картридж" и прогнать на реале прилагаемый тестик?
Его смысл - сравнить быстродействие программы из внутреннего ПЗУ и внешнего ПЗУ.
В отличие от предыдущих тестов, бейсик не используется, поэтому для упрощения программки цифры выводятся в 16ричном виде.
Верхняя цифра на реале должна быть 0399 или близко к тому.
Прилагаю конфиг, чтобы можно было и в эмуляторе попробовать, надеюсь на реале будет работать аналогично (только цифры будут другие).
Mick
В отличие от предыдущих тестов, бейсик не используется, поэтому для упрощения программки цифры выводятся в 16ричном виде.
Верхняя цифра на реале должна быть 0399 или близко к тому.
Прилагаю конфиг, чтобы можно было и в эмуляторе попробовать, надеюсь на реале будет работать аналогично (только цифры будут другие).
Ну что же получай.
0398 испытано на Суре.
Скриншот тому подтверждение.
Спасибо. Т.е. быстродействие программы при выполнении ее из внешнего ПЗУ (или SRAM) и из внутреннего одинаково и > чем из ОЗУ.
Mick
Еще 2 тестика накропал. Это еще один подход к проблеме определения быстродействия. Проверяется, сколько успеем исполнить за прерывание сначала DAD, потом INX.
spdtst2 - для ROM
SPTST3 - для RAM
Mick
Еще 2 тестика накропал. Это еще один подход к проблеме определения быстродействия. Проверяется, сколько успеем исполнить за прерывание сначала DAD, потом INX.
spdtst2 - для ROM
SPTST3 - для RAM
Проверил, скриншотики прилагаются.
Цифры:
spdtst2 - 1172 и 1FF5;
sptst3 - 04BF и 1DF3.
Mick, этот подход оказался плодотворным, одна штука стала ясной. Теперь я уверен, что при выполнении программы из внутреннего ПЗУ и из памяти, подключенной к разъему расширения, на каждое чтение из памяти добавляется один такт задержки. Т.е. dad будет не 10 а 11 тактов, inx не 5 а 6 и т.д. Дополнительное подтверждение
Прогнал я твои тестики несколько раз - результат не меняется а именно.
на правом скриншоте написано 2 МГц, но это просто результат умножения на неправильное число тактов (без учета введения задержки), я пересчитал, добавляя на каждое чтение из ПЗУ по 1 такту и получилось 2,5 МГц, как и должно быть. Т.е. реклама все же обманывала, 625000 оп/сек на ПК8000 не получишь, максимум 500000.
Главный итог - теперь понятно, как с точностью до такта определить быстродействие программы, выполняющейся из внутреннего ПЗУ или из памяти, подключенной к разъему расширения (если нет обращений к внутреннему ОЗУ или портам).
А вот результаты теста при выполнении из ОЗУ меня привели в ступор, как нужно считать, чтобы получить такое жуткое торможение при выполнении dad мне не понятно.
Забыл добавить, все вышесказанное справедливо по крайней мере для SCR0, забыл другие режимы проверить.
Mick, сделал вариант предыдущего теста, который проверяет скорость выполнения DAD и INX во всех трех режимах (SCR0-SCR2). Чтобы доверие к результатам было чуть больше :) прилагаю исходники. Компилировал с использованием tasm 3.2, а т.к. он не поддерживает директив повтора, то оформление у исходника не очень. Чтобы максимально унифицировать тест, работающий из внешнего ПЗУ и из внутреннего ОЗУ даже отказался от сжатия в CAS варианте, поэтому придется немного подождать при загрузке. ПЗУшный тестик при нажатии любой клавиши рестартует, а ОЗУшный выходит в бейсик. ОЗУшный можно перезапустить без повторной загрузки, стартовый адрес 8000h.
Mick, сделал вариант предыдущего теста, который проверяет скорость выполнения DAD и INX во всех трех режимах (SCR0-SCR2).
Попробовал. Результаты на экранах :)
Слева - тест spdtst4, справа - sptst5
Результаты теста при выполнении из внешней памяти предсказуемые и объяснимые. Видно, что режим вывода на экран на торможение внешней памяти (и скорее всего внутреннего ПЗУ тоже) не влияет.
С торможением ОЗУ стало понятнее, но нужно еще подумать. Также надо отметить, что результат sptst3 в отношении dad (04BF) был аномальный, к сожалению, причину такого "взбрыка" я не нашел, в эмуляторе все работает предсказуемо.
Mick
Ну что, эпопея с тестами приближается к концу. Как считать производительность программы при выполнении из ПЗУ или внешней памяти - уже известно. Как считать производительность программы при выполнении из внутреннего ОЗУ - по результатам прошлых и недавних тестов я тоже вроде догадался, но, чтобы все было четко и чтобы мне хоть кто-то поверил, сделал практически "всеобъемлющий" тест. Исходник и readme прилагаются. Запуск на эмуляторе показал, что ошибок в растактовке команд в b2m нет, все по справочнику :). Как должно быть на самом деле на ПК8000 мы сможем узнать, когда ты сфоткаешь экран RAMSPD с результатами. Желательно (на всякий случай) прогнать программу 2 раза и сфоткать 2 раза.
Mick
Ну что, эпопея с тестами приближается к концу. Как считать производительность программы при выполнении из ПЗУ или внешней памяти - уже известно. ......
Постараюсь прогнать его в субботу. И потом, после обработки всех промежуточных результатов мы все ждем так сказать официальных выводов твоего "исследования". ;)
Как должно быть на самом деле на ПК8000 мы сможем узнать, когда ты сфоткаешь экран RAMSPD с результатами. Желательно (на всякий случай) прогнать программу 2 раза и сфоткать 2 раза.
Ну вот запустил, как ты просил два раза - результат одинаков. Но сфоткал как просил два раза. :)
Кстати, когда запустил тест, мне сразу показалось что комп заглючил, на экране всякая фигня начала мельтешить. Думаю, ну вот и все - 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?
По 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 в порт бордюра.
Радикально отредактировал много своих старых постов в данной ветке - убрал цифры, оказавшиеся ошибочными.
Внимательно еще раз проанализировал результаты тестов. С вероятностью 99.99% могу утверждать, что у ПК8000 308 строк в кадре, соответственно прерываний в секунду не 50, а чуть больше (примерно 50.73), что подтверждается еще и этим постом Micka:
Кстати полоски, сложилось у меня такое впечатление - бегут быстрее чем в эмуляторе.
Немного удивительно, как Mick на глаз увидел такую маленькую разницу, наверно параллельно запускал driller в эмуляторе и на реале.
Так надо просто посчитать, сколько прерываний, например, за 20 минут будет. Тест очень простой: нажимаем клавишу - пошёл счёт, ещё раз нажимаем - останавливаем и выводим результат.
Так надо просто посчитать, сколько прерываний, например, за 20 минут будет. Тест очень простой: нажимаем клавишу - пошёл счёт, ещё раз нажимаем - останавливаем и выводим результат.
Сначала у меня только подобная идея была, плюс такие детали тестирования - нажимаем клавишу запуска теста на ПК8000 и одновременно фотографируем экран и часы (проще всего, наверное, было бы использовать часы самого фотика). Потом через продолжительное время еще раз фотографируем экран и "независимые" часы.
Потом вспомнил один PCшный тест, используя идею которого можно получить точный ответ за пару секунд (тестерских, не программерских):
Меняем цвет бордюра, делаем задержку (на 154 или на 156 строк), еще раз меняем цвет бордюра, снова делаем задержку на 154 или на 156 строк, и все это при запрещенных прерываниях. Чтобы "рисунок" на бордюре начинался в предсказуемом месте, можно начать цикл после прерывания, хотя это совсем не обязательно. Если бордюр неподвижен при 154 строковой задержке, то на ПК8000 308 строк.
Первый вариант проще написать (т.к. легко можно проверить работоспособность в эмуляторе), второй проще тестировать (но легко ошибиться при написании с величиной задержки).
Сам я не собираюсь делать ни тот тест ни другой, но с интересом посмотрел бы на результаты.
Возможен еще и третий вариант теста, простой для тестера и для программиста (т.к. он уже сделан, отлажен и даже опробован на реальном ПК8000). Это ранее выкладывавшийся TOPBR7. Нужно заменить один байт - количество строк изменить на 115, запустить и сфоткать. По месту стыка верхнего бордюра и активной области изображения можно будет увидеть, как там на самом деле.
Тест из форума я убрал, но у Mickа он, наверное, остался, так что он может попробовать. Правда, я скорее всего выкладывал в тот раз без исходника.
Вопрос к Mickу и/или Xobbimanу - если я выложу модифицированный тестик, Вы попробуете на реале и покажете фотки результата?
Вопрос к Mickу и/или Xobbimanу - если я выложу модифицированный тестик, Вы попробуете на реале и покажете фотки результата?
Попробую.
Тесты в виде CAS и WAV, исходники и описание (readme.txt) - здесь (http://retrocomp.narod.ru/pk8000/testborder.zip).
Тесты в виде CAS и WAV, исходники и описание (readme.txt) - здесь (http://retrocomp.narod.ru/pk8000/testborder.zip).
Пока прошу прощения, занимаюсь дампером. Как буду отлаживать дампер и заодно попробую тесты.
Извиняюсь за задержку, вот выдаю результаты запуска двух тестов.
tb115_screen - что я наблюдал на экране при запуске
tb115_result - результат работы теста
И аналогично с tb117
Между прочим, никто не пробовал недокументированный (возможно неработоспособный или совпадающий с одним из документированных) видеорежим, который получится, если биты 5 и 4 порта 84h =1? Есть предположение, что он может быть подобен SCR0, но со своим знакогенератором для каждой трети.
Тест быстродействия ПК8000 - считает, сколько команд исполнится между прерываниями во всех 4х режимах. Это вариант теста ПК8002 (на нем успешно отработал) адаптированный под ПК8000. От предыдущих (моих) тестов для ПК8000 отличается тем, что охватывает практически все группы команд.
Сервиса никакого (увы) нет, результат выдает на магнитофонный выход и параллельно (для контроля) на спикер.
Работает так:
1. Загружаем bload"PST",r
2. Тест работает около трех минут (на эмуляторе, на реале время будет немного отличаться).
3. Пишет на магнитофоный выход результаты.
4. Небольшая пауза.
5. Переход на шаг 3.
Результаты практически в текстовом виде - название группы команд и сколько их успело исполнится за прерывание (в шестнадцатеричном виде). Если будет wav с результатами я переведу "сырые" результаты в число тактов/команду.
В эмуляторе работает, если на реале успешно отработает - выложу исходник.
DemonId7
13.02.2013, 10:30
ivagor, я конечно понимаю, что у программистов вечно не все как у людей, но почему бы на этот раз не сделать по человечески и не вывести результат на экран?
Тест что-то делал, а потом темный экран и никакой реакции.
PS: А вав-файл у меня не загрузился, пришлось cas через эмулятор в вав преобразовывать.
Добавил в исходный пост (http://zx-pk.ru/showpost.php?p=567540&postcount=76) wav выгруженный из EMU.
Черный экран - не обязательно индикатор окончания теста. Когда тест точно завершится должно начать пищать и одновременно писать на магнитофонный выход (раз за разом).
DemonId7
14.02.2013, 15:19
Комп был включен не меньше 10 минут. Писков не припоминаю. Но у него спикер тихий, завтра попробую еще. Как узнать начало и конец записи в вав?
Комп был включен не меньше 10 минут.
Да, за это время тест точно должен был завершиться.
Но у него спикер тихий, завтра попробую еще. Как узнать начало и конец записи в вав?
Вывод на спикер параллельно с выводом на магнитофонный выход сделал как раз чтобы можно было контролировать запись.
Если спикер не работает, можно контролировать на компьютере, куда ведется запись, в звуковом редакторе при записи видно, есть сигнал или нет. Или можно просто услышать "сквозной" сигнал, но тут зависит от настроек звуковой карты и программ.
Вариантов по крупному 2:
1. Тест работает не так или даже зависает. Возможно конечно, но ничего нового здесь я не делал, все практически тоже самое, что было и в уже отработавших на реале тестах. В эмуляторе работает.
2. Может с Вашим экземпляром ПК8000 что-то не так? Любые другие программы загружаются и работают?
А при работе теста на экране всякие "узоры" сменяют друг-друга (как в эмуляторе)?
---------- Post added at 18:14 ---------- Previous post was at 17:40 ----------
А если я переделаю тест (вернее это будет 4 теста) для вывода на экран, то Вы сделаете снимки экрана?
DemonId7
15.02.2013, 10:32
Висит. Сначала на экране "калейдоскоп". Затем "тухнет". После небольшой паузы несколько раз моргает "РГ", как при загрузке программы, и далее мервый вис.
Проверил загрузку/выгрузку. Ошибок нет. Программа "тест" от Хобби проходит нормально. Несколько игр тоже идут без проблем.
Тесты прогоню любые и в любых количествах. Одно но: мой любимый моник навернулся и сечас использую композитный выход на тв-тюнер, т.е ч/б изображение. В общем, цвета желательно подбирать контрастные.
Висит. Сначала на экране "калейдоскоп". Затем "тухнет". После небольшой паузы несколько раз моргает "РГ", как при загрузке программы, и далее мервый вис.
Проверил загрузку/выгрузку. Ошибок нет. Программа "тест" от Хобби проходит нормально. Несколько игр тоже идут без проблем.
Судя по симптомам, тест успешно проходит, а вот пищание и вывод на магнитофон - нет. Наверно мне стоило использовать более консервативный вариант сохранялки из ПЗУ (но все равно пока не понимаю, почему тот вариант не сработал).
Тесты прогоню любые и в любых количествах. Одно но: мой любимый моник навернулся и сечас использую композитный выход на тв-тюнер, т.е ч/б изображение. В общем, цвета желательно подбирать контрастные.
ТВ-Тюнер - это очень хорошо, легко сделать скриншот. Цвета стандартные - белое на черном.
В итоге разделил на 4 единообразных теста. Каждый из них, после того как отработает, выводит на экран три колонки с командами и сколько их успело исполнится между прерываниями (еще нужно учитывать небольшой фрагмент инициализации). Чтобы не перепутать результаты тестов в правом верхнем углу указывается тестировавшийся режим:
PST0 - SCR1
PST1 - SCR2
PST2 - SCR0
PST3 - UNDC
После снятия скриншота с результатами теста можно нажать на ПК8000 любую клавишу и выйдем в бейсик.
DemonId7
15.02.2013, 17:53
Судя по симптомам, тест успешно проходит, а вот пищание и вывод на магнитофон - нет. Наверно мне стоило использовать более консервативный вариант сохранялки из ПЗУ (но все равно пока не понимаю, почему тот вариант не сработал).Самый лучший вариант - это вставить в код проверку целостности. А то может при загрузке что-то портится?
После снятия скриншота с результатами теста можно нажать на ПК8000 любую клавишу и выйдем в бейсик.Все тесты успешно отработали. Что именно показывают тесты? Просто не верится, что за 1/50 секунды выполнится только 1793 команд ACI в режиме 1.
39856398573985839859
забавнее INX
1: 11d1
2: 0071
0: 1dde
U: 0B4A
и XTHL
---------- Post added at 16:13 ---------- Previous post was at 16:02 ----------
неужто так неторопливо ??
Все тесты успешно отработали. Что именно показывают тесты? Просто не верится, что за 1/50 секунды выполнится только 1793 команд ACI в режиме 1.
Спасибо за результаты, но что-то все не так, как должно быть. Это просто мистика какая-то. Для проверки можете прогнать этот старый тестик
39861
?
Выход в бейсик в нем - пробел.
Для него есть результаты, которые получил Mick, есть с чем сравнить.
неужто так неторопливо ??
Нет, пока результаты неадекватные.
DemonId7
15.02.2013, 19:44
Прогнал 3 раза, результаты один в один:
39864
ЗЫ: Один в один - это не в сравнении с результатами Micka. А где они кстати?
Результат RAMSPD полностью совпал с тем, что получал Mick.
Пока совсем нет идей, в чем засада с pst.
---------- Post added at 21:53 ---------- Previous post was at 21:48 ----------
Результаты RAMSPD которые получил Mick (http://zx-pk.ru/showpost.php?p=182237&postcount=63)
DemonId7
15.02.2013, 19:56
А переполнения регистров здесь не может быть?
Нет, тут не переполнение регистров.
Кажется у меня появилась идея, что тут может быть - особенность в обработке прерываний на ПК8000. В принципе по полученным цифрам можно попытаться проверить это предположение, но вряд ли я сегодня успею.
Если сможете проверить вот альтернативный вариант
DemonId7
15.02.2013, 21:12
Опять три прогона и циферки стабильны:
39866
DemonId7
15.02.2013, 21:15
Кстати, а есть нормальный кроссассемблер под 8080? Интернет выдает какую то ерунду, а мне хочется нечто близкое к turbo assembler, или к masm.
А компиляторы Си существуют?
:v2_thumb:
Такой вариант нормально работает! Завтра доделаю - добавлю пару миксов команд, они уже были в другой версии, а сюда забыл, + остальные режимы.
В предыдущем варианте такие странные цифры были потому, что запрос прерывания висел, когда его разрешал, то считалось сколько команд выполнится за оставшееся время до следующего прерывания, а не с начала.
---------- Post added at 23:34 ---------- Previous post was at 23:27 ----------
Кстати, а есть нормальный кроссассемблер под 8080?
Сам я вот этим (http://home.comcast.net/~tasm/) пользуюсь. Он слабенький, много чего не умеет, но как-то привык.
А компиляторы Си существуют?
Вот здесь (http://zx-pk.ru/showthread.php?t=20018) можно посмотреть.
Комплект дополненных (добавил одну команду и 3 комбинации команд) тестов, сделан на основе pst0new, поэтому все должно нормально работать. Как будут результаты с реала я выложу еще исходник и "расшифрованные" длительности команд в тактах.
Заранее могу сказать, что результаты в SCR0 и недокументированном (который полностью или частично совпадает со SCR0) режимах скорее всего будут с "нецелыми" тактами из за разного торможения при выводе разных частей экрана (в отличие от SCR1/2), т.е. это будет "среднее время выполнения команды в течении кадра". Чтобы точно определить по отдельности время выполнения команд в этих режимах на бордюре и в активной области нужен, например, таймер, синхронно работающий с процом, но его нет.
DemonId7 - не против, если я включу в финальный комплект результаты с реала, с указанием автора, конечно?
DemonId7
16.02.2013, 13:28
Сам я вот этим пользуюсь. Он слабенький, много чего не умеет, но как-то привык.Видел уже, действительно слабоват. Я и так 8080-й асм почти не помню, а тут еще и синтаксис чудной.
Вот здесь можно посмотреть.Спасибо, посмотрим.
DemonId7
16.02.2013, 13:33
Прогонял по два раза, разбросов результатов нет. Сами результаты весьма интересны и наконец то выявилась закономерность:
39872398733987439875
Чтобы точно определить по отдельности время выполнения команд в этих режимах на бордюре и в активной области нужен, например, таймер, синхронно работающий с процом, но его нет.В принципе могу подать на какой-нибудь вход импульсы известной частоты. Думаю схэмку генератора найти не сложно?
не против, если я включу в финальный комплект результаты с реала, с указанием автора, конечно?
Дык вроде и тестируем на реале для выяснения тонкостей архитектуры. Не? А чего тогда спрашивать? :)
Выкладываю полный комплект с исходниками и результатами.
В принципе могу подать на какой-нибудь вход импульсы известной частоты. Думаю схэмку генератора найти не сложно?
Нужен таймер, причем чтобы обеспечить нормальную точность нужно тактировать процессор и таймер из одного источника. Такой тест для вектора я делал (там частота таймера в 2 раза меньше чем у процессора, но это не принципиально), он успешно работал. Т.е. для ПК8000 я бы смог адаптировать тот тест. Таймер - это не единственный вариант, но, как мне кажется, самый точный. Возможно у кого-то есть альтернативные идеи, интересно было бы ознакомится.
А еще остается не полностью протестированным выполнение команд из ПЗУ и внешней памяти. Есть результаты по отдельным командам, полученные Mickом. Мне кажется, что этого достаточно, и я могу рассчитать полные результаты и по уже имеющимся, но я могу ошибиться + мне никто не поверит :)
Дык вроде и тестируем на реале для выяснения тонкостей архитектуры. Не? А чего тогда спрашивать?
Есть тонкость - некоторые предпочитают, чтобы их результаты оставались, например, на их сайтах и не утягивались в другие места.
DemonId7
16.02.2013, 16:33
А если так: цепляем на выход LPT какой-нибудь PIC на 20МГц. Выставляем в порту признак начала замера и выполняем некую команду, к примеру INX, 10000 раз. По окончании опять сигнализируем в порт и PIC подсчитывает сколько времени было затрачено на одну команду INX. Поскольку у пика частота на порядок выше и тактов на выполнение команд тратится меньше, а прогонов много, то точность будет очень даже приличной.
Идея хорошая, но детали реализации я вижу иначе. Если мы померяем время выполнения 10000 команд в SCR0/недокументированном, то это улучшит точность определения "средней температуры по больнице". Это неплохо, но мне кажется, что интереснее определить время выполнения команд в двух разных (повторюсь, речь про SCR0/UNDC, не про SCR1/SCR2, с ними и так все понятно) интервалах строки (тут я может забегаю вперед, но пока у меня рабочая версия именно с делением строки на две части в определенном отношении). Простые 1-2х цикловые команды у меня "сошлись", а длинные команды на пальцах считать сложновато, т.к. если мое предположение верно, то длина "короткой" части сравнима с длительностью сложных команд.
Многабакаф написал, но если коротко - IMHO теперь, при наличии результатов pst, важнее померять в нужные моменты времени (если смотреть изнутри - то относительно момента прихода прерывания), причем в пределе даже время исполнения одной (если длительной) команды, чем померять время исполнения большого количества команд.
господа, подскажите, везде написано что у ПК8000 частота 1.78 mhz
а по этим тестам получается ~49168 тактов в прерывании
что дает почти 2.5 мхз
где я обчитался ?
в эмуляторе B2M стоит 1800khz
у меня получилось для сравнения (вроде похоже)
для Вектора ~59824
для Корвета ~50092 (великовато, посмотрю, может где моя версияя теста кривая)
p.s. появилась идея сделать сводную тему имени теста Ivagora бысродействия
данные в табличку по вектору ПК8020 ПК8000 я свел, надо дооформить
и в ней же поставитт ссылки на сами тесты и их комментарии
По поводу частоты и раскладки экрана. На основании предыдущих и текущего тестов я считаю, что у ПК8000:
Fтакт=2,5 МГц
Число строк в кадре - 308 (116+192) - это в т.ч. по результатам тестов с бордюром
Число тактов в строке - 160.
Частота в EMU была подобрана, если мне не изменяет память, так, чтобы уверенно грузить данные с ленты.
Проблема точной эмуляции ПК8000 в том, что время выполнения из внутреннего ОЗУ в SCR1/2 - одно, в SCR 2/недокументированном - другое, из ПЗУ/внешней памяти, независимо от режима экрана (если без обращений к внутреннему ОЗУ) - третье. На уровне целых команд, к сожалению, все многообразие ситуаций учесть очень сложно, только на уровне циклов. Ведь, например, команда из ПЗУ может читать ПЗУ и записывать в ОЗУ, т.е. табличкой/режим не обойдешься. А поцикловой эмуляции, насколько мне известно, в современных эмуляторах советских компов нет и вряд ли ее стоит ожидать в ближайшем будущем.
Тема имени теста ivagora - звучит :) Есть еще результаты ПК8002. Пользуясь случаем передаю привет Константину, который провел тесты на реальном ПК8002 и в значительной степени нарисовал его схему. А b2m догадался, как объяснить результаты в турбо-режиме на бордюре, не говоря уже про то, что сделал эмулятор :). Насчет нужности отдельной темы по тесту - не уверен, может и так сойдет, по профильным темам?
DemonId7
16.02.2013, 23:01
esl, а где написано о частоте ПК8000 в 1.78МГц? В книгах вроде только 625 тыс. операций в секунду упомянуто.
Кстати, а почему же растактовка так сильно отличается от расписанной в доке на ассемблер? Неужели это издержки архитектуры? А если принять частоту в 1.8 МГц и пересчитать результаты тестов? Как тогда растактовка команд будет выглядеть?
в википедии
на сайте pk8000.narod.ru ( КР580ВМ80А (1.78 МГц).)
а с результатами там так (как я понимаю ситуацию)
например
aci - за прерывание (50hz) выполнилось 1001h=4097 команд
от сюда и пляшем
стандартно для 8080 это 7 тактов, ivagor посчитал тут 12 тактов (у вектора 8)
добавил к табличке кол-во циклов в команде и посортировал по cycle/takts
вот табличка https://www.dropbox.com/s/34kpfdiot30bfui/Takt_sortedl.pdf
колонки rX wX io - не обращать внимания, эт для себе расписывал циклы
забавно что для пк8000
обычно scr0 быстрее чем scr1/2
а для 3-5 цикловых далеко не всегда
p.s. а есть нормальная дока по циклам (а то у меня только сканы i8080, а там качество не ахти)
Расцикловка 8080/580ВМ80 по матрериалам INTELовского datasheeta (с исправлениями), растактовка ПК8002, растактовка для вектора по циклам, часть инфы по ПК8000 были на моем сайте, вот здесь (http://files.mail.ru/27DF02F50E864C5C8F1A605B93813748) выложил архив с ним. Там все по состоянию на 2010 год, поэтому страничка по ПК8000, конечно, нуждается в уточнениях, например max быстродействие в SCR1/UNDOC при выполнении из ОЗУ сейчас я бы написал 390625 оп/сек, ну и некоторые другие пункты тоже.
Информация о том, что у ПК8000 якобы частота 1,78 МГц вначале (в 2008) сбила меня с толку и долго плюхался и не мог понять, как объяснить результаты с реала. Если принять 2,5 МГц с торможением (разным в зависимости от режима и ОЗУ/ПЗУ/внешн.пам), то все становится на свои места, по крайней мере для меня.
DemonId7, если я еще не утомил, то хотелось бы узнать результаты с реала двух тестов:
1. 39899
Это попытка понять, почему же не было звука по завершению первоначального варианта PST. После старта ждет нажатия любой клавиши.
1.1. Жмем клавишу, звучит короткий сигнал, сделано аналогично ПЗУшной процедуре.
1.2. Жмем клавишу, короткий сигнал выдается на магнитофонный выход, сделано аналогично ПЗУшной процедуре.
1.3. Жмем клавишу, короткий сигнал выдается параллельно на звуковой и магнитофонный выход, так я сделал в первом варианте PST.
1.4. Жмем клавишу, короткий сигнал выдается параллельно на звуковой и магнитофонный выход, аналогично 1.3., но в противофазе.
По нажатию любой клавиши выходим в бейсик.
Интересно, будет ли звук в случаях 1,3 и 4?
2. 39900
А это попытка одним махом убить двух зайцев.
2.1. Выводится экран, заполненный символами в режиме SCR1. В данном случае мне хотелось бы увидеть, что на ТВ-тюнере видны все 32 символа в строке, а то на результатах с ТВ крайние символы не видны.
2.2. Жмем любую клавишу и выводится экран, заполненный символами в режиме SCR0. Это подготовка к шагу 3.
2.3. Жмем любую клавишу и режим меняется на недокументированный. Уже высказывал идею, что он аналогичен SCR0, хотелось бы в этом убедиться или увидеть, что это не так.
Если еще раз нажмем клавшу - выйдем в бейсик.
По SCRTST хотелось бы увидеть скриншоты.
В обоих случаях в комплекте исходники, CASы и WAVы.
DemonId7
17.02.2013, 18:19
ivagor, завтра утром гляну, проблем то никаких :)
ivagor, у 8080 все выгляди относительно просто в сравнении с pdp11 (http://zx.pk.ru/showthread.php?t=14702) ;)
А поцикловой эмуляции, насколько мне известно, в современных эмуляторах советских компов нет и вряд ли ее стоит ожидать в ближайшем будущем.
EmuStudio поцикловая.
DemonId7
18.02.2013, 10:03
1. SNDTAP.ZIP
Это попытка понять, почему же не было звука по завершению первоначального варианта PST. После старта ждет нажатия любой клавиши.
1.1. Жмем клавишу, звучит короткий сигнал, сделано аналогично ПЗУшной процедуре.
1.2. Жмем клавишу, короткий сигнал выдается на магнитофонный выход, сделано аналогично ПЗУшной процедуре.
1.3. Жмем клавишу, короткий сигнал выдается параллельно на звуковой и магнитофонный выход, так я сделал в первом варианте PST.
1.4. Жмем клавишу, короткий сигнал выдается параллельно на звуковой и магнитофонный выход, аналогично 1.3., но в противофазе.
По нажатию любой клавиши выходим в бейсик.
Интересно, будет ли звук в случаях 1,3 и 4?
1.1 Жмем любую клавишу и уходим на ребут :o
2. SCRTST.ZIP
А это попытка одним махом убить двух зайцев.
2.1. Выводится экран, заполненный символами в режиме SCR1. В данном случае мне хотелось бы увидеть, что на ТВ-тюнере видны все 32 символа в строке, а то на результатах с ТВ крайние символы не видны.
2.2. Жмем любую клавишу и выводится экран, заполненный символами в режиме SCR0. Это подготовка к шагу 3.
2.3. Жмем любую клавишу и режим меняется на недокументированный. Уже высказывал идею, что он аналогичен SCR0, хотелось бы в этом убедиться или увидеть, что это не так.
Если еще раз нажмем клавшу - выйдем в бейсик.
По SCRTST хотелось бы увидеть скриншоты.
Скрины, соответственно пунктам 2.1, 2.2 и 2.3:
399233992439925
Если я правильно понял этот ассемблер, то в режиме 0 буфер экрана заполняется последовательными символами? А как же примечание в книге №6, согласно которому в режиме 0 строки должны заканчиваться последовательностью символов 05,06,07,0D,0E и 0F, для регенерации памяти?
DemonId7
18.02.2013, 10:16
ivagor, в виду засады с режимом 0 я подправил твой сорс на режим 1. Все заработало, в 1, 3 и 4 был звук. Мафон не проверял, если только ближе к вечеру.
как же примечание в книге №6, согласно которому в режиме 0 строки должны заканчиваться последовательностью символов 05,06,07,0D,0E и 0F, для регенерации памяти?
В "предыдущем цикле" (в 2008-2009) разборок с ПК8000 везде использовал "осторожную" процедуру очистки экрана, которая трогала только первые 40 символов строки, а тут решил попробовать не одобренный вариант.
Описание (причем эта инфа есть только в доках Суры) явно писали не сами разработчики, т.к. ПЗУшка пишет в конце каждой строки 05 06 0D 0E 00. Рискну предположить почему так: возможно регенерация (по крайней мере в активной области) осуществляется перебором 7 младших (по отношению к процу) разрядов адреса. В SCR1/2 это происходит автоматом за 4 символьных (или за 32 пиксельных) строки, а в SCR0 видеоконтроллер не успевает за 160 тактов выбрать 64 символа, поэтому нужно ему "помогать". При выводе активной части экрана охватываются значения 0-39. Символ 5 - это значения младших разрядов адреса (в знакогенераторе) 40-47, символ 6 - 48-55, остаются 56-63. Скорее всего видеоконтроллер пробегает по 56-63 сам (времени сбоку для этого достаточно) и ни 07 ни 0F не обязательны. Касательно использования не только 05, 06, но и 0D, 0E - сложно сказать, наглостью с моей стороны было бы утверждение, что это точно не нужно. Интересная тема, хотелось бы проверить "забывание" части ОЗУ при отсутствии в строке символов с указанными значениями младших бит. Может даже тестик попытаюсь соорудить.
По поводу недокументированного режима - по крайней мере видно, что по результатам отображения он не совпадает ни с одним из документированных, а может и вобще ничего не показывает.
у 8080 все выгляди относительно просто в сравнении с pdp11
И ведь не поспоришь, хотя создатели ПК8000 постарались, чтобы жизнь медом не казалась.
EmuStudio поцикловая.
Провокация была направлена в другую сторону :) , а формально, конечно, мое утверждение ошибочно.
Можно по разному тестировать эту штуку, но я пока решил попробовать так:
1. Загружаем, стартует, пишет вверху NoKill, экран раз за разом заполняется символами.
2. Жмем пробел, пишет Kill 05 и или зависает/рестартует/портит экран или работает как п.1.
3. Жмем пробел, пишет Kill 05&06 и или зависает/рестартует/портит экран или работает как п.1.
4. Жмем пробел, пишет Kill 05&06&0D и или зависает/рестартует/портит экран или работает как п.1.
5. Жмем пробел, пишет Kill 05&06&0D&0E и или зависает/рестартует/портит экран или работает как п.1.
6. Жмем пробел (хотя вряд ли до сюда доживет) и выходим в бейсик (рестартуем)
Интересно, на каком этапе все испортится.
DemonId7
18.02.2013, 21:36
ivagor, будешь смеяться, но тест пройден:
39948
Ждем следующий :)
"REGEN2 - возвращение ivagora, смотрите на экранах ПК8000 вашего города!" (с)
Еще одна попытка. Загружаем, стартует, выводит в левом верхнем углу 4 символа с кодами 0-3 - "пусто", черная рожа, белая рожа, сердце (остальной экран заполнен пробелами, визуально неотличимыми от символа 0). Неприятно жужжит. В эмуляторе так и будет.
Возможно на реале через некоторое время (хотя бы полминуты-минуту, но, думаю, если изменятся, то раньше) символы изменятся, например на Ъ.
DemonId7
19.02.2013, 19:03
Или форум глючит, или опера. У меня почему то показывает 0 скачиваний regen2. В общем звук действительно мерзкий и оказывается спикер не такой уж и тихий :v2_conf2:
Вот скрин после двух минут работы:
39970
?
Фокус не удался, факир был пьян.
Тогда попытаемся повторить "удачный" опыт - можешь запустить исходный вариант SNDTAP отсюда (http://zx-pk.ru/showpost.php?p=576987&postcount=106)?
Как я понял, на реале он рестартует после первого нажатия клавиши. Можешь после рестарта выгрузить из ПК8000
bsave"какое-нибудь имя",32768,33061,32768
в WAV и выложить на форум?
DemonId7
19.02.2013, 20:25
Вроде что-то записалось.
http://yadi.sk/d/ZFRerIEz2jMS5
Если что могу повторить.
Похоже мы на верном пути - видно, что значения пяти ячеек "испортились". Наверно стоит попробовать развить успех
39971
После загрузки, стартует, выводит надпись и ждет нажатия любой клавиши. Лучше сразу не жать а немножко (пусть полминуты) подождать. После нажатия рестартует.
После рестарта пишем результаты (долго)
bsave"DUMP",16387,61269,16387
DemonId7
19.02.2013, 22:13
Сколько ни ждал, а результат один - в момент перезагрузки зависает:
399743997539976
Можно снять дамп после сброса, благо память не очищается. Только рекордер винды имеет ограничение на 1 минуту записи. Ничего другого нет. И не хочется засорять винду малополезным софтом. Может кусками записать?
Только рекордер винды имеет ограничение на 1 минуту записи.
Открываешь любой длинный wav, и пишешь поверх него. Можно ещё где-то в реестре прописать ограничение, но это надо гуглить, так не помню.
---------- Post added at 00:12 ---------- Previous post was at 00:09 ----------
Ещё там есть фича "Edit->Insert File", тоже можно увеличивать длину записи.
Сколько ни ждал, а результат один - в момент перезагрузки зависает:
Это даже хорошо, содержимое ОЗУ явно портится. Правда, оно портится сильнее, чем я ожидал, хотя возможно это побочный эффект порчи "ключевых" ячеек самой программы.
Можно снять дамп после сброса, благо память не очищается. Только рекордер винды имеет ограничение на 1 минуту записи. Ничего другого нет. И не хочется засорять винду малополезным софтом. Может кусками записать?
Как тебе будет удобно, меня устроит любой вариант. Или частями (IMHO наиболее трудоемко и неудобно), или как b2m предложил, или можно скачать Audacity (http://audacity.sourceforge.net/download/windows), там есть версия не требующая инсталляции.
DemonId7
20.02.2013, 18:14
Собственно дамп: http://webfile.ru/6389568
Интересный результат, но мне непонятно, почему сдохло (стало FF) почти все, ведь часть ОЗУ должна регенится. Или все же это побочный эффект от порчи программы.
Как все испортить уже понятно, но хотелось бы лучше понимать детали процесса и в некоторой степени управлять им.
DemonId7, раз тв-тюнер показывает очень "широко", можешь проверить, есть ли по бокам бордюр или только вверху-внизу?
например
screen1
width32
color15,0,10
DemonId7
22.02.2013, 00:58
Только вверху-внизу. Увы, это все-таки не монитор.
А монитор (к слову, какой?) показывал по бокам цветной бордюр? Я то думал, что бокового бордюра в ПК8000 просто нет, и так уже "ширина" основного изображения в SCR1/2 51,2 мкс. И еще я считал, что тв-тюнер не уступает монитору по ширине отображаемой области (это по результатам DDp для ПК-01, там тоже очень широкий экран). Стандартный то ТВ они оба (и монитор и тюнер) превосходят.
DemonId7
22.02.2013, 10:33
Подключался к "Электроника 32 ВТЦ-202". За давностью лет боюсь ошибиться, так что ничего не скажу за бордюр. Скорее всего был, иначе наверняка запомнил бы такую особенность.
Тв-тюнер, на мой взгляд, как-то вытягивает картинку по ширине:
http://stg678.rusfolder.com/preview/20130222/5/35135065_850704_850703.jpg (http://fotoifolder.ru/view_foto/l73ufle3l20v/)
Тестик для уточнения момента прихода прерывания. Это упрощенный вариант старого теста TB115 (фотки Micka с его результатами есть в этой теме), но здесь нет задачи считать строки бордюра. По сравнению с TB115 убрал реакцию на курсор, изменил режим на SCR1, экран теперь заполнен символами, а не залит красным, и, самое главное, на 12 тактов уменьшил задержку до зеленого (светлого на ч/б) бордюра.
Тест должен показать экран, заполненный символами и светлый (зеленый) бордюр. Под символами внизу-слева должна быть черная полоска - интересно, до какого символа она дойдет. Вверху справа тоже будет черная полоска, но она не интересует.
Старался максимально сохранить преемственность с TB115, поэтому надеюсь, что будет работать правильно.
DemonId7
22.02.2013, 20:51
Похоже полоса прошла все символы:
40021
О чем это говорит?
Кстати, практически по всем ссылкам на ПК8000 утверждается, что процессор работает на частоте 1.8 МГц. Пломбу срывать не хочется, я бы нашел чем замерить.
Черная полоска закончилась под Г (она высотой в одну строку, поэтому надо вглядеться), т.е. 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 перестарался и убрал задание счетчика строк, поэтому счетчик заканчивает считать уже при выводе символов - в результате обещанной черной полоски справа вверху нет. Если интересно, могу выложить откорректировнный вариант, но на определение момента прихода прерывания это никак не влияет.
Пара слов по поводу невозможности 1,8 МГц. В этой теме есть много доказательств.
Если тактовая была бы 1,8 МГц, то между прерываниями было бы 1,8e6/50=36000 тактов. То, что прерываний в секунду в районе 50 Mick проверил на реале сравнением с внешним эталоном здесь (http://zx-pk.ru/showpost.php?p=151791&postcount=23). Результаты ранних тестов с бордюром и попытки их интерпретации лучше просто пропустить :). Также Mick заметил (ссылку при необходимости найду) при сравнении с эмулятором, что при проигрывании музыки по прерываниям она играет чуть быстрее, чем в эмуляторе, т.е. Int Rate немного больше 50 Гц, что потом и подтвердилось другими тестами.
Дальше смотрим результаты (http://zx-pk.ru/showpost.php?p=180775&postcount=56) подсчета количества выполненных из внешнего ПЗУ DAD и INX за прерывание. 1172HEX=4466DEC, 1FF5HEX=8181DEC. 36000/4466=8 тактов на один DAD, т.е. <10, что на ВМ80 невозможно, 36000/8181=4,4 такта на один INX, т.е.<5 что опять же невозможно.
Вернемся в наше время. Результаты (http://zx-pk.ru/showpost.php?p=576798&postcount=96) pst1.1. Опять же возьмем DAD. В SCR1/2 за прерывание их выполняется 1001HEX=4097DEC. 36000/4097=8,79 тактов, т.е. опять <10 - не получится на ВМ80. В SCR0 аналогично. Надеюсь, что этих доказательств достаточно хотя бы для оценки того, что тактовая частота ПК8000 несомненно больше 1,8 МГц. В качестве альтернативы можно только предположить, что в ПК8000 стоит волшебный клон 580ВМ80, который исполняет команды за меньшее число тактов, чем обычные ВМ80 :)
DemonId7
23.02.2013, 08:54
Может и не волшебный, но если не ошибаюсь, то был ВМ80 на 5МГц :) Спасибо, теперь ясно.
Тогда другой вопрос, почему скорость так сильно отличается от заявленной в документации? Это из-за ожиданий циклов регенерации памяти? Если да, то тесты для SCR 0 нужно повторить, там ведь регенерация портилась.
Могу привести свои соображения. Вроде я их уже в разных местах писал, но пусть здесь будет "сборник". Сначала "аксиомы" :) (если их принять, то можно объяснить полученные результаты)
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 как раз выбираются байты из конца строки, служащие для регенерации ОЗУ.
Наличие в течении строки областей с разным торможением подтверждается и таким результатом (http://zx-pk.ru/showpost.php?p=152350&postcount=45) - там есть "переходной процесс" и "установившийся режим" на нижнем бордюре, т.е. вначале отработки прерывания, при том, что задержка по строкам задавалась одними и теми же командами.
Если да, то тесты для SCR 0 нужно повторить, там ведь регенерация портилась.
По хорошему, тесты SCR0 и недокументированного в pst1.1 стоило бы сделать более корректно, но могу высказать простое соображение, почему в них ничего не испортилось и почему результаты ранее тестировавшихся команд совпали со "старыми" (точно корректными в плане регенерации) тестами - там каждый тест в течении кадра пробегает по последовательным адресам ОЗУ, прямо как видеоконтроллер, поэтому ничего не портится. Содержимое ОЗУ все же не так просто испортить, что подтверждают результаты regen/regen2. Вопрос с регенерацией в SCR0, конечно, надо бы полностью прояснить - в какие позиции строки можно/нужно писать и какие именно коды (учитывая расхождение документации и того, что делает ПЗУшный софт).
если не ошибаюсь, то был ВМ80 на 5МГц
Наверно речь о 580ВМ1 - тактовая у него до 5 МГц, но время выполнения "старых" (общих с ВМ80) команд у него, согласно имеющимся докам, совпадает с ВМ80.
Появилось много идей по поводу SCR0, может даже удастся уточнить время выполнения команд, но перед этим хотелось бы проверить ряд моментов.
Вот программка типа предыдущей INTPOS, но для SCR0.
40034
Рисует экран в клетку и двухцветный бордюр. Интересно, куда дойдет черная полоска снизу и будет ли вертикальна граница между цветами бордюра (надеюсь, что и в ч/б это будет видно).
Рассчитал для всех команд предполагаемое время выполнения из ОЗУ в SCR0 на бордюре и в активной области. Выкладывать пока такие спекуляции рано, но уточню предыдущий пост - там я сначала написал, что доп. такт торможения есть и при обращении к портам (не только к памяти), но 99%, что все же нет.
DemonId7
24.02.2013, 14:35
Вроде все видно:
40047
Все отлично видно!
Этот тестик одним махом решил несколько задач:
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
24.02.2013, 18:25
Результаты. S0In4, S0SHSH и S0XTXT соответственно:
400494005040051
На глаз вроде одинаковы.
По клеткам тоже одинаковы, так что все отлично. Для успокоения совести еще пара тестов, они должны дать столько же клеток. Чтобы граница между зеленым и синим (светлым и темным) бордюром оставалась вертикальной, пришлось делать миксы команд. Какие именно - можно посмотреть в Int.asm, после out 88h и до mvi a,48h.
Если и тут не будет неожиданностей, то выложу уточненную табличку растактовок.
DemonId7
24.02.2013, 22:02
Идеально совпадают:
4005540056
Так что, ждем табличку растактовки?
Вот такая получилась таблица
40072
Обращу внимание на то, что растактовки для SCR0/недокументированного справедливы для случаев, когда команда целиком попадает в активную или боковую область. Если команда попадает на границу, то что получится в результате - надо смотреть индивидуально.
Для полного комплекта не хватает результатов по выполнению из ПЗУ и внешней памяти. Их просто рассчитать, но у меня есть сомнения по поводу наличия дополнительного такта задержки при записи во внешнюю память. Можно или пропустить в табличке команды с циклами записи или написать два варианта.
DemonId7
25.02.2013, 13:34
Внешняя - это которая к разъемам Х1 и Х2 цепляется?
DemonId7
25.02.2013, 15:13
Надо подумать.
DemonId7, ты можешь попытаться подрубить SRAMину? Тогда посмотри в теме про квазидиск схему Micka (http://zx-pk.ru/showpost.php?p=158645&postcount=82). Оттуда можно все убрать и оставить 2 вещи: SRAM, лучше на 64 Кб (тогда тест пойдет почти без переделок), но, в крайнем случае, можно и на 32 или даже 16, и АП6. На /CS SRAMа подавать /SLTSL (у Micka он почему-то написан без /, хотя в доках у этого сигнала низкий активный уровень)
DemonId7
25.02.2013, 22:02
40081
Так? Есть только на 15 нс, подойдет?
Если что, в субботу слетаю по магазинам, поищу вилку РП15-50, а то штырьками как-то несолидно :)
Наверно надо максимально ориентироваться на квазидиск Micka, к 3й версии он уже все продумал.
Тогда надо /ЧТЗУ еще на 1ю ногу АП6, на 19ю ногу АП6 - землю.
ОЗУшка 5 вольтовая? Можешь название написать (случайно не из кэша какой-нибудь четверки)?
15нс это круто, а на CE2 через резистор 5В будешь подавать? Может наоборот, на /CE землю, а на CE2 через что-то типа ЛН1 /SLTSEL?
DemonId7
26.02.2013, 08:52
У нас задача намного проще, чем у Micka, так что особо плагиатить нет нужды :)
С АП6 все и так ясно. Статики есть UM61512AK-15 и AS7C512-15PC, а из 32К есть W24257AK-15, IS61C256AH-15N, IS61C256AH-20N, CY7C199-20PC и SB61L256AD-12. Разумеется все с 486-х.
Есть еще динамическая мем, с видюшек.
Что касается CE2 и /CE, то не принципиально, так и так вытравлю плату - одной микрухой больше, одной меньше.
С одной стороны, мне проще было бы с 64Kб (меньше тест переделывать), но это фигня. ИМХО гораздо важнее получить работающую железку. В 32 килобайтных и выводов меньше и /CS (/CE) один, наверно лучше на них ориентироваться.
DemonId7
26.02.2013, 12:35
Развел на 64Кб. В воскресение вытравлю, заодно с пал-кодером. Готовь тесты :)
PST уже переделал, в эмуляторе (с "подключенным" внешним ОЗУ) работает.
Наверно стоит сделать тест внешнего ОЗУ, вряд ли есть готовый?
---------- Post added at 21:43 ---------- Previous post was at 20:30 ----------
Вот еще флеш картридж Micka (http://zx-pk.ru/showpost.php?p=180781&postcount=23). В нем он обошелся без АП6. Насколько я понимаю, АП6 все же не помешает при подключении SRAM, но наверно без нее можно обойтись.
DemonId7
27.02.2013, 01:38
Буфера никогда не помешают, мало ли что... Мне не трудно.
Тест памяти нужен обязательно. Хоть и невелика вероятность, но все же есть шанс воткнуть глючную микруху, я же их со списанных машин собирал. И банальных ошибок пайки никто не отменял. В общем сначала убедимся в штатной работе внешнего ОЗУ, а уж затем можно и поизголяться над машиной :)
Сначала не обратил внимания на интересную особенность SCR0 (особенно хорошо заметно на s0shsh (http://zx-pk.ru/showpost.php?p=579224&postcount=138), т.к. там рожица есть и с краю и не с краю) - в крайнем правом столбце отображается не 6, а 7 точек (т.е. по горизонтали 241 точка, а не 240)! Может даже тюнер не показывает одну самую правую точку и там их аж 8.
Тест внешнего ОЗУ примерно придумал, скорее всего в субботу сделаю и выложу.
В BS0 и остальных тестах этой серии был несколько трусливый момент - использовалось много команд, которые исполняются за одинаковое число тактов и "сбоку" и в активной области. Хотелось бы увидеть еще результаты бескомпромиссного варианта, где все команды имеют разное время выполнения в двух областях. Исходник выложу, если этот вариант нормально отработает, т.е. даст вертикальную границу между темным и светлым (синим и зеленым) бордюром.
DemonId7
28.02.2013, 23:08
Сначала не обратил внимания на интересную особенность SCR0 (особенно хорошо заметно на s0shsh, т.к. там рожица есть и с краю и не с краю) - в крайнем правом столбце отображается не 6, а 7 точек (т.е. по горизонтали 241 точка, а не 240)! Может даже тюнер не показывает одну самую правую точку и там их аж 8.
Трудно сказать за тюнер. Сегодня попробовал разделить синхру и завести на EGA-моник. Забыл про линии "контрольный R[G|B]" и вместо картинки увидел непонятно что. Но, кадр моник вроде держал, так что на досуге получу картинку. Тогда и уточним все особенности видео этой машинки.
Сделал тестик внешнего ОЗУ. Упор в нем не на подробное тестирование каждой ячейки, а на правильность подключения (не отвалилось ли чего и т.п.). Он записывает в 64 килобайта ОЗУ 32768 двухбайтных четных значений от 0000 до FFFE. Потом проверяет, есть ли там, куда записали, ожидаемые значения.
Лучше сначала запустить его в эмуляторе, чтобы знать, какие результаты должны быть.
В стандартном конфиге дает 4 Errora.
В приложенном конфиге PK8000 Sura and Xobbi Ext1RAM64.cfg даст 4 ОК.
В приложенном конфиге PK8000 Sura and Xobbi Ext1RAM32.cfg даст 2 Errora и 2 ОК. Когда снаружи 32К - это как бы отвалилась линия А15 в 64К варианте и ячейки будут повторяться в областях 0000-7FFF и 8000-FFFF. Т.к. заполнение идет с 0го адреса, то при записи в область 8000-FFFF затрет то, что было до этого записано в 0000-7FFF, поэтому дает вышеприведенную диагностику.
Чтобы упростить себе жизнь, сделал проверку только ОЗУ подключенного к X1. Если нужно к X2, то сделаю и такой вариант, там буквально несколько значений поменять.
DemonId7
02.03.2013, 10:01
Хотелось бы увидеть еще результаты бескомпромиссного варианта, где все команды имеют разное время выполнения в двух областях. Исходник выложу, если этот вариант нормально отработает, т.е. даст вертикальную границу между темным и светлым (синим и зеленым) бордюром.Результат:
40166
Прикупил пару вилок РП-15-50. Завтра плата будет готова.
Исходник к тому тесту 40167. Вся "новизна" по сравнению с другими тестами этой серии в наборе команд укладывающихся в строку (начало Int.asm).
Прикупил пару вилок РП-15-50. Завтра плата будет готова.
Жду с нетерпением :)
DemonId7
03.03.2013, 11:48
Платку собрал:
40206
Только не завелась. С АП6 вообще не включается, виснит с белым экраном. На линиях адресов какой то шабаш. Без нее включается, но не пашет. Пробовал запускать простые тесты:
di
mvi A, 11110100b
out 80h
lxi H, 4010h
vis:
mov M, A
jmp vis
Только что со чтением, что с записью - прога вылетает в бейсик :v2_conf2: Пробовал без микрух. Прога не вылетает, но на всех управляющих линиях около 5 вольт, на OE - 2.5 вольта. Откуда вообще может 5 вольт взяться на этих линиях? И по идее на линиях должны быть логические "1" (то есть 0.2 вольта). Непонятно.
Твой тест виснет, что с доп. ОЗУ, что без:
40205
Пока все. Извини, но наверное отложу на пару дней, кажется грипп подхватил, сил уже нет. Пока же жду рац. предложений что и где я мог накосячить :)
PS: Линии OE, WE и CE проверял неоднократно. Замыканий нет. Ведут строго куда положено по документации: OE - 12 контакт, WE - 14, CE - 42.
Только что со чтением, что с записью - прога вылетает в бейсик :v2_conf2: Пробовал без микрух. Прога не вылетает, но на всех управляющих линиях около 5 вольт, на OE - 2.5 вольта. Откуда вообще может 5 вольт взяться на этих линиях? И по идее на линиях должны быть логические "1" (то есть 0.2 вольта). Непонятно.
Ну вообще то лог. "1" как раз почти напряжение питания и есть.
Тут еще возможно что ты паямть повесил паралельно основной памяти. И получается одновременная запись(это не так страшно) и чтение (а вот это катастрофа).
DemonId7, у меня только одна идея - что-то не так с /СE и/или CE2. ИМХО проще всего попробовать (когда поправишься) с 32К SRAMкой. Если я правильно разглядел на фото, то надо будет убрать резистор с CE2 (в 32K там Vdd) и вставить 32K SRAMку в "нижнюю" (на фото) часть панельки. Можно будет попробовать проверить прямо из бейсика.
/WE и A11 соединены перемычкой? Если да, то зачем?
Твой тест виснет, что с доп. ОЗУ, что без
Т.е. когда в X1 ничего не воткнуто, запускаешь E1RT64 он зависает и дает картинку, которую ты привел?
---------- Post added at 16:10 ---------- Previous post was at 15:48 ----------
Картинка (untitled.jpg) с "результатом" теста получается в одном из двух вариантов:
1. если вести запись в основное ОЗУ вместо или вместе с записью во внешнее ОЗУ и, кстати, в этом случае тест как раз зависнет.
2. если видеоконтроллер вдруг начнет выбирать данные из внешнего ОЗУ, что маловероятно
---------- Post added at 16:23 ---------- Previous post was at 16:10 ----------
Неудачу E1RT64 можно очень просто объяснить. Похоже, что запись в основное ОЗУ производится не только когда в соответствующей части порта 80h записан 00 или 11, а всегда (т.е. и при 01 и при 10 - очень плохое решение). Наружу тоже пишет, что демонстрирует успех картриджа Micka. Так что все не зря, мы узнали немного больше о ПК8000, хотя и не то, что хотелось бы.
---------- Post added at 16:41 ---------- Previous post was at 16:23 ----------
Пробовал запускать простые тесты:
Твой тест в каких адресах располагал?
DemonId7, в общем выздоравливай.
Когда сможешь, прогони микротестик (выдает 6 цифр) на голом ПК8000 и с твоей платкой.
DemonId7
03.03.2013, 19:04
Тут еще возможно что ты паямть повесил паралельно основной памяти. И получается одновременная запись(это не так страшно) и чтение (а вот это катастрофа).Паралельно не получится - микруха управляется сигналом SLTSL, так что ее включение/выключение целиком на совести ПК.
DemonId7
03.03.2013, 19:07
Неудачу E1RT64 можно очень просто объяснить. Похоже, что запись в основное ОЗУ производится не только когда в соответствующей части порта 80h записан 00 или 11, а всегда (т.е. и при 01 и при 10 - очень плохое решение). Наружу тоже пишет, что демонстрирует успех картриджа Micka. Так что все не зря, мы узнали немного больше о ПК8000, хотя и не то, что хотелось бы.Мне тоже пришла в голову похожая мысль :) Потому написал простенькие тесты (во вложении), точнее расширил предыдущие. Отличаются только очередностью заполнения памяти и слота:
40229
Результат говорит сам за себя:
4023040231
Результат запуска теста "SLOT1" без доп. ОЗУ:
40232
Если принять за веру, что мой ПК не глючный, то запись в память всегда идет паралельно записи в ПЗУ или в слоты. Это объясняет интересную особенность POKE - он всегда пишет в видеопамять, даже если "поверх" нее расположена ПЗУ. Кажется мы действительно узнали что-то новенькое :)
Но нужно бы проверить еще на одной машине.
DemonId7
03.03.2013, 19:09
DemonId7, в общем выздоравливай.
Когда сможешь, прогони микротестик (выдает 6 цифр) на голом ПК8000 и с твоей платкой.
Сейчас прогоню.
DemonId7
03.03.2013, 19:12
Кстати, попутно заметил интересную вещь - импульсы записи в память почти в два раза длиннее импульсов чтения:
4023440235
Интересно было бы проверить скорость чтения/записи массивов :)
DemonId7
03.03.2013, 19:23
Результаты теста ERT (с доп. памятью и без):
4023740238
DemonId7, поздравляю с успешным запуском железки!
Интересно было бы проверить скорость чтения/записи массивов
Запись будет ждать свободного временного слота для доступа в основное ОЗУ, что несколько грустно. Тем не менее скорость чтения из внешней памяти будет выше, так что не все так плохо. Предлагаю в этом убедиться с использованием переделанного PST. PST0 и 1 скорее всего будут работать, PST2 и 3 могут зависнуть или чудить. Исходники готов выложить, если эти варианты заработают.
DemonId7
03.03.2013, 20:43
Все тесты прошли. Одно но, вместо результатов кракозябры, типа таких:
40241
Жмешь пробел и выходишь в бейсик. Может знакогенератор портится?
Может знакогенератор портится?
Точно, в исправленный вариант добавил пересылку знакогенератора.
Расшифровку обещаю не раньше чем завтра, сорри.
DemonId7
03.03.2013, 22:41
Результаты:
40244402454024640247
Ждем расшифровки.
С командами, в которых нет циклов записи все легко и просто - добавляется один такт на каждое чтение из памяти. Команды, которые пишут в память, зависят от циклов видеоконтроллера, что для SCR1/2 не привело к проблемам при подсчете. Для SCR0/недокументированного надо еще подумать над отдельными командами (поэтому обновленный комплект PST с результатами и исходниками пока не выкладываю). Пока выкладываю предварительный вариант растактовок, в котором команды, требующие дополнительных размышлений (или дополнительной проверки) выделены курсивом.
Несмотря на незначительные неясности с деталями SCR0/недокументированного очевидно, что максимальное быстродействие будет при выполнении команд из внешнего ОЗУ как раз в режимах SCR0/недокументированном. При выполнении из внешнего ОЗУ в режимах SCR1/2 команды с циклами записи будут чуть медленнее, но ощутимо быстрее, чем при выполнении из внутреннего ОЗУ. Поэтому можно, например, ускорить игрушки, дополнив их "настройщиком", который определяет наличие внешнего ОЗУ и, если оно есть, переписывает игрушку туда (своего рода "кэш" :) ). Плюс нужно пропатчить в игре 1-3 байта, касающиеся out 80h, чтобы она сама не рулила конфигурацией памяти. Также можно представить примерно аналогичный мини-настройщик для бейсика.
Ничего умного не придумал, включил в полный комплект теста внешней памяти для SCR0/недокументированного средние по больнице результаты.
Забыл в исходниках обновить номер версии и дату, думаю это не принципиально
DemonId7
04.03.2013, 20:01
Ну что же, было познавательно. В итоге не только растактовку выяснили, но и нашли два надежных способа программного определения запуска из под эмулятора - записью в слоты и чтением портов :)
Я пока на подключение еги переключаюсь. Да и пал-кодер неплохо бы поднастроить, а то рябь идет и искажения крайних строк.
два надежных способа программного определения запуска из под эмулятора
Со слотами очень простой и удобный способ, про порты я как-то пропустил, но есть еще способы связанные с растактовками - например сравнить время выполнения какого-либо фрагмента кода в SCR0 и SCR1/2 или нечто подобное. С регенерацией вобще непаханное поле. Еще есть способы направленные не "внутрь" программы, а вовне, на пользователя. Очень легко на экране реала изобразить что-то, что в эмуляторе будет выглядеть совсем не так (да и по звуку тоже). В этой теме много примеров, правда они все суховаты, можно было что-то более развлекательное и попсовое изобразить, но это уже остается на долю истинных фанатов ПК8000 :)
С другой стороны, b2m никогда не видя subj, сделал впервые в мире эмуляцию ПК8000, заработали программы, игрушки (подавляющее большинство без артефактов), диск - это круто. А написание точного эмулятора опять же остается на долю фанатов этой машинки.
---------- Post added at 22:36 ---------- Previous post was at 22:34 ----------
Удачи с ягой и кодером!
Удалил нерабочие варианты тестов.
В принципе осталось еще немало невыясненных моментов, надеюсь, что в этой теме будет что почитать ;)
DemonId7
05.03.2013, 22:19
про порты я как-то пропустилЯ попозже выложу снимки, так понятнее будет. Разница только в недоступности некоторых портов для чтения (в эмуле все читаются). Это ерунда.
С другой стороны, b2m никогда не видя subj, сделал впервые в мире эмуляцию ПК8000, заработали программы, игрушки (подавляющее большинство без артефактов), диск - это круто. А написание точного эмулятора опять же остается на долю фанатов этой машинки.Кто бы с этим спорил :)
В принципе осталось еще немало невыясненных моментовКак надумаешь - продолжим.
Надумал, только я не знал, что ты успеешь разобраться с цветом, попытался бы что-то цветное сделать.
Тем не менее этот тестик может стать шаблоном и для чего-то цветного. Попытка программно организовать некое подобие Display List. В данном случае пытаюсь его использовать для переключения знакогенераторов по ходу активной области SCR1. Если сразу правильно заработает (в чем я сильно сомневаюсь), то покажет экран, в верхней, средней и нижней третях которого будут разные символы. Выход по пробелу.
DemonId7
09.03.2013, 22:13
Цвет был лишь пробой. Нужно пару дней на создание адаптера, от которого и будут запитываться телек, яга и палкодер. Последний еще не отлажен, тоже нужно найти на него время. Так что особо не торопись :)
Собственно тест:
40347
Что-то нижней части не наблюдается. Виса нет, по пробелу выходит в васик.
Что-то нижней части не наблюдается.
Это одна из двух обнаружившихся ошибок - скопипастил лишнее, в итоге одна цифра в предварительной настройке была неправильная. Тут есть еще микроошибка (так просто не заметишь, считал строки по скриншоту) - неправильно распределил одну строку между бордюром и активной областью. Но в целом
1. "Display List" работает!
2. Переключать знакогенераторы по ходу отображения можно. Это позволяет показывать полноэкранную графику в текстовом режиме SCR1. Предвижу вопрос - зачем извращаться при наличии SCR2. Можно представить такой пример использования - полноэкранная анимация. В SCR2 в памяти хватит места на 4 экрана (фазы), а в "графическом варианте SCR1" на 8, правда малоцветных.
Доработанный (надеюсь, что все исправил) DLIST1 с исходником
40357
Ну и попытка развлекательного применения для вывода картинки (в данном случае со спека)
40358
Цвет был лишь пробой. Нужно пару дней на создание адаптера, от которого и будут запитываться телек, яга и палкодер. Последний еще не отлажен, тоже нужно найти на него время.
Разделитель синхры+палкодер+тюнер - потенциально суперкомплект
DemonId7
11.03.2013, 17:36
Доработанный (надеюсь, что все исправил) DLIST1 с исходником
Черный экран. По пробелу выход в васик.
Ну и попытка развлекательного применения для вывода картинки (в данном случае со спека):v2_thumb: Я бы вечером в цвете попробовал, но невовремя сгорел любимый паяльник. Теперь только завтра.
Разделитель синхры+палкодер+тюнер - потенциально суперкомплектЭто от безысходности :)
Комплектом это будет если удастся подключить мультичастотный мон, типа этого: http://www.avito.ru/penza/tovary_dlya_kompyutera/monitor_viewsonic_e655_110323771
Дешево и сердито. Только смущает заявленная частота гор. развертки.
Черный экран. По пробелу выход в васик.
Ничего не понимаю, надо подумать. Неработающие тесты удалил.
Я бы вечером в цвете попробовал, но невовремя сгорел любимый паяльник. Теперь только завтра.
А цвета там не было. С цветом и без извращений есть здесь (http://vector06c.narod.ru/recompile/soft/pk8000/zxscrv1.3.rar). Mick выкладывал фотку с реала, скорее всего в теме про софт.
Это от безысходности
Комплектом это будет если удастся подключить мультичастотный мон
Для всяких "исследований" тюнер удобнее, т.к. все картинки "совпадают" друг с другом по положению, а фотоаппаратом с экрана совпадение не полное. Но это для меня, "дистанционного тестера", для реальщика думаю все наоборот :)
Только смущает заявленная частота гор. развертки.
В крайнем случае еще и скандаблер понадобится. А что не так с EGAшным монитором, он же работает?
DemonId7
12.03.2013, 00:19
А цвета там не было.Предупреждать же надо :) Тогда картинка:
40402
Красиво получилось :v2_thumb:
Для всяких "исследований" тюнер удобнееМне тоже удобнее скриншот экрана в тюнере делать. Фоткать мониторы - то еще удовольствие, "пленки не напасешся" :)
В крайнем случае еще и скандаблер понадобится. А что не так с EGAшным монитором, он же работает?Работает. Но это мон от брендовой двушки и ресурс его конечно же не безграничен. Я бы прикупил еще один ega-моник, как раз для "суры", но в нашем городе на это шансов считай нет.
Красиво получилось
На спектруме хорошие художники (их копирайты на картинке есть, никаких левых копирайтов я не добавлял).
Все же непонятно. В DLIST1_v2 и PICSC1 основная часть одинаковая, при этом первый показал черный экран, а второй отработал нормально (хотя в программе можно пару мест подчистить, но на картинку это не повлияет). Даже DLIST1 (первый вариант) отработал на 66%, а в v2 всего 2 микроскопических отличия. Загадка.
---------- Post added at 09:59 ---------- Previous post was at 09:57 ----------
Я бы прикупил еще один ega-моник, как раз для "суры", но в нашем городе на это шансов считай нет.
ТВ со скартом легче купить, но там края не будут видны.
Разобрался с DLIST1_v2. Дело в начальной инициализации цветов. Я думал, что в SCR1 штатные подпрограммы каждое прерывание переписывают значения из памяти в порты A0-BF, а оказалось, что раз в 16 прерываний. Т.е. это плавающий дефект, он мог проявиться и в первом DLIST1 и в PICSC1. В общем, в SCR1 надо специально отслеживать этот момент, а лучше самому записать в порты нужные значения.
DemonId7
12.03.2013, 20:49
Получилось:
40409
:v2_thumb:
C VGA облом. С пал-кодером пока непонятки, такое ощущение, что подстроечные резисторы мне в магазине фуфловые подсунули, очень уж нестабильное сопротивление дают.
Плату развел с косяками, придется переделывать. Как назло делал плотным монтажом, уже не порежешь и не подпаяешь :(
DemonId7
26.03.2018, 22:25
Хороший знакомый приобрел неплохой осцилл. После выкручивания рук он согласился, совершенно добровольно и без принуждения, дать мне это игрушку на пару вечеров. Естественно первым делом захотелось проверить насколько точно товарищ ivagor теоретически рассчитал частоту. Замеры проводил у м/с 140АП4, сразу после токоограничительных резисторов R33 и R34, поскольку непосредственно к ВМ80 подцепиться не удалось.
https://youtu.be/HCBgC0dhoyU
Ну что тут скажешь? Мастер! :v2_clap2:
В ПК8000, сигналы ПДП (HOLD, HLDA) не используются на внутренней схеме, как я поняла. Только на устройствах, подключенных к внешним разъемам расширения.
Вся работа с пересылкой видеопамяти и регенерации ложится на процессор, верно? И сделано это при помощи прерываний.
Сигнал прерывания (INT) формируется на триггере DD18.2, фронтом сигнала SGI (ОБР. ХОД), с частотой 50 гц.
Сигнал подтверждения прерывания (INTA), формируется управляющим словом процессора, записанного в регистр DD8, по сигналу SYNC=>STROBE, выравненному по тактовой частоте F1 на ИЛИ-НЕ DD40.2. Далее, инверсный вариант INTA, с вывода И-НЕ DD9.4, сбрасывает D-тригер DD18.2, приведя сигнал INT в изначально неактивное состояние (прервание уже выполняется).
Далее возникает вопрос, выставляется ли на ШД код команды прервания (RST0-RST7) или нет?
Логика работы процессора построена так,что в последнем такте последнего машинного цикла любой команды проверяется наличие запроса прерывания. Если запрос на прерывания имеется, то ЦП выполняет цикл М1 специального типа (см.рис.10) при условии, что ранее был установлен триггер "Разрешение прерывания" (INTE). По тактовому импульсу F2 устанавливается внутренний триггер "Прерывание" (ПР). В такте Т1 цикла прерывания М1 содержимое счетчика команд не увеличивается на единицу, а сохраняется. Выдается сигнал подтверждения прерывания (INTA). В такте Т3 устройство, запросившее прерывание, выдает на шину данных код однобайтовой команды RST (или любой другой), которая выполняется.В циклах М2 и М3 (при получении команды RST n), следующих за циклом прерывания, осуществляется запись в стек по адресам указателя стека(SP-1,SP-2) первого и второго байтов содержимого счетчика команд (PC).
Шина данных подтянута к +5в, возможно выполняется всегда команда RST7 (0xFF)?
Что касается рабочей частоты, лог. анализатор дал следующие F1, F2 (см. файл).
Частота импульсов 2,4 мгц и 2,667 мгц, для обоих (F1, F2).
Файл, для просмотра в Saleae Logic (https://www.saleae.com/ru/downloads/) на яндекс диске https://yadi.sk/d/r3OiNKhllu-ZRg
Также, в файле есть ширина импульса RES.
Частота импульсов 2,4 мгц и 2,667 мгц, для обоих (F1, F2).
На интервалах по 20 мкс измерение средней частоты F1 и F2 дало 2.5 МГц, чудес не бывает.
- - - Добавлено - - -
Картинка
измерение средней частоты
То что средняя равна вычисленной чуть выше, это понятно. Кстати, как выделить вот так фрагмент для расчета средней?
Интересно было, что частота рваная (непостоянная). Если конечно лог. анализатор не врет. :)
Интересно было, что частота рваная (непостоянная).
Скорее дело в том, что не стоит измерять частоту по одному периоду. Если взять хотя бы несколько периодов, то Average Frequency приближается к ожидаемой.
как выделить вот так фрагмент для расчета средней?
Справа Annotations+Measurement, выделяем интересующий фрагмент и еще в настройках Measurement надо включить галочку Average Frequency.
Перевыложил testborder.zip на форум (раньше был на моем сайте). Там и сами тесты и исходники.
Результаты (Mick) здесь (https://zx-pk.ru/threads/9431-pk8000-bystrodejstvie-arkhitektury-issledovanie.html?p=259356&viewfull=1#post259356). readme.txt в архиве "старый", до результатов.
Ни у кого не сохранилась табличка esl из этого поста?
https://zx-pk.ru/threads/9431-pk8000-bystrodejstvie-arkhitektury-issledovanie.html?p=576924&viewfull=1#post576924
Возможно там ничего нового и нет, по крайней мере по ПК8000, но вроде бы Сергей там пытался свод по разным компьютерам сделать...
Вроде там были сведены результаты моих тестов (вектор, ПК8000, ПК8002; львова скорее всего тогда не было) и его порта speed test на корвет.
ivagor, поясни, деление на активную часть и "сбоку" в твоей итоговой табличке относится ко всем 308 строкам?
то, что "сбоку" в твоей итоговой табличке, относится ко всем 308 строкам?
Да. Тут 2 связанных момента: 1) то, на бордюре строка тоже делится на 2 части, следует из тестов задействующих бордюр в SCR0; 2) При интерпретации результатов speed test я учел информацию из п.1.
Попробовал реализовать вейты в эмуляторе на основе исследований ivagor. Без расцикловки команд не очень красиво, но что-то получилось. Для команд, выполняемых из ПЗУ, длительность по тактам округлена, ну и вообще, случай, когда в разных циклах команды идет обращение к областям адресного пространства с разными вейтами, никак не обрабатывается. Разные параметры в разных областях экрана и в разных видеорежимах постарался насколько возможно учесть.
Ссылка на тестовую сборку (исходников на github пока нет - не влил еще в master):
http://emu80.org/temp/Pk8000_waits_test.zip
Нужно взять последнюю сборку (http://emu80.org/v4beta/Emu80qt_40316.zip) и поменять в ней exe и конфиг на файлы из архива.
(На упоминания HDD в конфиге не обращайте внимания: немного не доделано еще - в этой сборке hdd нет, все в отдельной ветке.)
ivagor, спасибо за консультации - непросто сразу было разобраться в новой для меня платформе (да и сейчас еще далеко не все понятно).
Ну и скриншот:
67594
P.S. Что-то движок форума уменьшает размер файла, вот полноразмерный:
http://emu80.org/temp/emu80_s0brd.png
Pyk, неистово плюсую! Теперь можно и видеоэффекты связанные с растром отлаживать (и показывать) в эмуляторе и биперный звук.
Переделал один из тестов scr 0 в нечто разноцветное
67597
Интересно, на реале активная область так же раскрашивается? Думаю все же или как бордюр или однотонно, вряд ли как на картинке (однотонно полосатый).
Еще для полного счастья хорошо бы проверить загрузку wav с реала. Их выкладывали, но я у себя сейчас не нашел. Проверил загрзку wav полученного в emu - нормально грузит.
ivagor, подозреваю, что на реале в режиме 0 активная область будет раскрашена как бордюр. Я просто об этом не подумал, сделать можно элементарно, но, конечно, неплохо бы проверить на реале.
Вообще, в эмуляторе сделал разный цвет в пределах скан-линии только для цвета фона, да и то в основном для целей тестирования. Цвет переднего плана, адреса буферов, регистры цвета действуют на всю скан-линию целиком, а режим переключается вообще только с нового кадра. Но при необходимости можно сделать.
адреса буферов
Кстати, этот момент DemonId7 проверял на реале (https://zx-pk.ru/threads/9431-pk8000-bystrodejstvie-arkhitektury-issledovanie.html?p=583256&viewfull=1#post583256), по крайней мере для scr 1. Тестик (https://zx-pk.ru/threads/9431-pk8000-bystrodejstvie-arkhitektury-issledovanie.html?p=582862&viewfull=1#post582862) я убрал, поэтому приложил к этому посту. Когда делал тест я еще не знал, что РУ2 прописываются обработчиком прерываний только раз в 16 прерываний, поэтому чтобы картинка гарантировано была видна нужно сначала переключиться в screen 1 и только потом грузить PICSC1.
Еще один мелкий, но важный момент - яркие цвета. Вроде была фотка Micka с цветными полосками, но я ее не нашел на форуме, нашел вот это (https://zx-pk.ru/threads/8378-pk8000-soft-staryj-i-novyj.html?p=149788&viewfull=1#post149788). Т.е. яркие цвета ПК8000 скорее как у msx, не как у спека, т.е. увеличиваются все 3 компоненты, не 1 и не 2.
DemonId7
10.01.2019, 22:04
Что за шум, а драки нет?
Вот на реале. Первые две на тюнер через пал-кодер. Последняя - это фотка с монитора. Практически совпадают, только у пал-кодера цвета немного "замылены".
Реал-Эмулятор - 1:0 :)
676066760767608
ivagor, ну вот и начинают выплывать косяки со временем выполнения инструкций. Если с режимом 0 на первый взгляд все ок, то в режиме 1 что-то пошло не так, буду смотреть. По идее этот тест должен работать в эмуляторе.
DemonId7, попробовал исправить, получилась вроде бы слегка отличающаяся картинка:
http://emu80.org/temp/scrbs0.png
К сожалению, плохо видно, что там внизу на границе активной области и бордюра, можешь прислать полноразмерный PNG? Может быть даже ч/б, если будет четче...
Артефакт справа, похоже, вообще не попадает в отображаемую область, попробую разобраться, что там должно быть.
ivagor, яркие цвета мне показались похожими на захват с ТВ-тюнера из предыдущего поста. Я не совсем понял, откуда та картинка с dizzy появилась?
Попросим DemonId7 показать все 16 цветов?
- - - Добавлено - - -
DemonId7, в бейсиковском тесте есть тест с цветными полосами, можно еще с него кадр захватить?
- - - Добавлено - - -
ivagor, кажется понял, отличаются не яркие цвета, а, наоборот, пониженной яркости. Подождем результатов с реала.
Если с режимом 0 на первый взгляд все ок, то в режиме 1 что-то пошло не так, буду смотреть.
Заметил 2 неточности в таймингах (в PST для SCR1 и 2):
INX - 15 вместо 8 тактов
EI - при выполнении следующей после EI команды прерывания не проверяются, это и в доках написано и в тестах вектора и ПК8000 видно.
В SCR0 и UNDC эти команды тоже неточные.
получилась вроде бы слегка отличающаяся картинка
Артефакт справа
Pyk, на мой взгляд так не должно быть, в тесте 153 одинаковых пары строк (т.е. всего 306 цветных строк). И на бордюре и в активной области все сделано одинаково.
плохо видно, что там внизу на границе активной области и бордюра
А что там собственно смотреть? В этом тесте должны быть видны 2 черные строки между цветными, насколько вижу так и есть.
ivagor, inx еще вчера поправил (исходники, кстати, уже на github), про ei знаю и помню, но руки пока не дошли учесть этот нюанс :(
Артефакт посмотрю, насчет черных строк - у меня там одна черная строка вместо двух, а первая, которая должна быть черной, повторяет предыдущую цветную. И в PICSC1 тоже вылез артефакт на стыке буферов.
Я примерно представляю в чем дело, но до исходников смогу добраться опять-таки скорее всего только вечером. Увы, праздники закончились :(
А какой тест ПК8000 ты упоминаешь, в котором EI тестируется?
насчет черных строк - у меня там одна черная строка вместо двух, а первая, которая должна быть черной, повторяет предыдущую цветную.
? На скриншоте из эмулятора, который я вчера выложил, 2 черных строки, смотрел в графическом редакторе. Или речь о доработанном эмуляторе, в котором уже есть раскраска активной области?
А какой тест ПК8000 ты упоминаешь, в котором EI тестируется?
Вот результат (https://zx-pk.ru/threads/9431-pk8000-bystrodejstvie-arkhitektury-issledovanie.html?p=576798&viewfull=1#post576798), и в следующем посте программы и исходники.
ivagor, речь шла о доработанном, я увидел уже причину - исправлю вечером.
DemonId7, просьба прислать полноразмерный скриншот снимается (насчет палитры - остается, фото с экрана Mick я видел, но тут слишком много факторов влияют - настройки телевизора, фотоаппарата, освещение и т.п., хочется посмотреть именно кадр с ТВ-тюнера).
DemonId7, просьба попробовать доработанный тестик. По сравнению со вчерашним здесь активная область заполнена символом
.db 00011100b
.db 00011110b
.db 00011101b
.db 00011110b
.db 00011100b
.db 00011110b
.db 00011101b
.db 00011110b
Цвет фона, как и вчера
2+2+2+...
и 3+2+2+...
Цвет изображения
4+2+2+...
и 5+2+2+...
1) Можно будет убедиться, что рилтаймовое изменение не только цвета фона, но и цвета переднего плана отражается на активной области.
2) Если сделать скриншот с тюнера, то можно будет еще раз подтвердить, что в scr0 видна 241 точка
Отмечу, что здесь черная строка должна быть одна (первая строка нижнего бордюра), а выше нее должна быть одна черно-белая (нижняя строка активной области).
ivagor, помоги, пожалуйста, разобраться.
Это не очень важно на данном этапе для эмуляции, но не понимаю, поэтому хочется разобраться.
Возьмем для примера команду OUT (длину которой мне сейчас приходится явно учитывать при записи цвета бордюра)
В отсутствие вейтов такты будут следующими:
T1 T2 T3 T4 | T1 T2 T3 | T1 T2 T3 - итого 10
В режиме SCR0 получается, как я понимаю, так:
T1 T2 Tw (Tw T3) T4 | T1 T2 Tw Tw (Tw T3) | T1 T2 T3 - всего 15
А вот как получить 20 в режиме SCR1? Вроде бы 16 получается:
T1 T2 Tw Tw Tw (Tw T3) T4 | T1 T2 (Tw T3) | T1 T2 Tw T3 ?
Что я не учитываю?
- - - Добавлено - - -
Хотя, наверное, нельзя так определенно вейты распределить, должно зависеть от предыдущей команды?
просьба попробовать доработанный тестик
Так должно получиться?http://emu80.org/temp/CLBFS0.png
DemonId7
12.01.2019, 05:32
DemonId7, просьба попробовать доработанный тестик.
Постараюсь после обеда выкроить время. На крайняк вечером.
Возьмем для примера команду OUT
SCR0/UNDC. Пусть для определенности первая команда начинается с 1го такта трехтактного цикла, а "окно доступа" будет каждый 1й такт трехтактного цикла (хотя для определения среднего времени выполнения команды в последовательности это не важно)
первый out T1 T2 Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3; второй и последующие out ... T1 T2|Tw Tw Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3 ... ...
SCR1/2 или SCR0/UNDC "сбоку". Пусть "окно доступа" будет каждый 1й такт четырехтактного цикла
первый out T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 ... ... ...; второй и последующие out ... T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 ... ... ...
Обращаю внимание, что при записи добавляется не менее 2х тактов ожидания.
Так должно получиться?
Да
- - - Добавлено - - -
Так должно получиться?
Забыл, на скриншоте с тюнера надеюсь еще увидеть 241ю точку справа
DemonId7
12.01.2019, 10:02
Работы сегодня оказалось нема, так что выкладываю снимки с тюнера, в том числе в ч/б варианте (там пиксели почетче для подсчета). Заодно тесты цветов для режимов 1 и 2.
Здесь (https://yadi.sk/d/bY6q3tlibA-IOA)
DemonId7, спасибо!
1) Pyk, по clb_bw.BMP и clb1.BMP вижу, что цвет фона надо продлить еще на точку вправо относительно знакоместа.
2) Странно, что не видно 241й точки, здесь (https://zx-pk.ru/threads/9431-pk8000-bystrodejstvie-arkhitektury-issledovanie.html?p=579224&viewfull=1#post579224) по самой правой рожице ее четко видно (в S0In4 и S0SHSH).
- - - Добавлено - - -
Цвета на msxные не похожи, у Micka как-то иначе смотрелись.
ivagor, я, кажется, понял свою ошибку. При чтении должно быть не менее 1 такта ожидания, а при записи - не менее 2-х. То есть если необходимое количество Tw получаются из-за ожидания окна, больше ничего дополнительно не добавляется. Так?
Но SCR1/2 SCR0/UNDOC все равно не стыкуется:
второй и последующие out ... T1 T2|Tw Tw Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3
18 тактов получается, а должно быть 15...
по clb_bw.BMP и clb1.BMP вижу, что цвет фона надо продлить еще на точку вправо относительно знакоместа
По-моему там практически полточки получается. Даже не знаю как лучше. Все-таки у DemonId7 зазоры небольшие видны, если сдвинуть - их совсем не будет. По умолчанию в эмуляторе масштабируется картинка в режиме nearest neighbour, поэтому в некоторых местах промежутки кажутся шире, чем должны, если включить сглаживание или отключить масштабирование, то разница нивелируется. Поэкспериментирую, посмотрю, как будет лучше.
Цвета на msxные не похожи, у Micka как-то иначе смотрелись.
Цвета один-в-один с эмулятором. А не могут цвета быть разными на Суре/Хобби/Весте?
Насчет 241 точки в эмуляторе даже не знаю - делать ли. К сожалению, ни на одном скриншоте не видно, если ли за 241-й еще и 242-я. Вообще, неплохо бы уточнить параметры развертки. Может быть, попробовать проанализировать прошивку PLM, в ней ведь изображение генерируется?
Сегодня мало времени, поправлю кое-какие моменты и скорее всего сделаю новую сборку завтра.
Pyk, спасибо за разбирательство. Расписал для SCR0/UNDOC команды с более чем одним (т.е. кроме выборки кода команды) обращением к памяти, для всех кроме in/out имевшиеся объяснения подходят:
lda/sta - 24, сходится
Первая команда T1 T2 Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3; подряд T1 T2|Tw Tw Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3
lhld/shld - 30, сходится
Первая команда T1 T2 Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3; подряд T1 T2|Tw Tw Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3
call - 30, сходится
Первая команда T1 T2 Tw|T3 T4 T5|T1 T2 Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3; подряд T1 T2|Tw Tw Tw|T3 T4 T5|T1 T2 Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3
ldax/stax/mov m,r/mov r,m/ani/adi/sui/и т.п. - 12, сходится
Первая команда T1 T2 Tw|T3 T4 T1|T2 Tw Tw|T3; подряд T1 T2|Tw Tw Tw|T3 T4 T1|T2 Tw Tw|T3
pop/ret/mvi m,/jmp/inr m/dcr m - 18, сходится
Первая команда T1 T2 Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3; подряд T1 T2|Tw Tw Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3
Rcond Y - 18, сходится
Первая команда T1 T2 Tw|T3 T4 T5|T1 T2 Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3; подряд T1 T2|Tw Tw Tw|T3 T4 T5|T1 T2 Tw|T3 T1 T2|Tw Tw Tw|T3
push/rst - 21, сходится
Первая команда T1 T2 Tw|T3 T4 T5|T1 T2 Tw|Tw Tw Tw|T3 T1 T2|Tw T1 T2|Tw Tw Tw|T3; подряд T1 T2|Tw Tw Tw|T3 T4 T5|T1 T2 Tw|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3
xthl - 30, сходится
T1 T2 Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T1 T2|Tw Tw Tw|T3 T4 T5
- - - Добавлено - - -
Есть такой вариант - окно доступа к порту не совпадает с окном доступа к озу. Например если в SCR0/UNDOC его расположить через такт после доступа к озу (т.е. в примере в третьем такте цикла), то все получается:
in/out - 15
T1 T2 Tw|T3 T4 T1|T2 Tw Tw|T3 T1 T2|Tw Tw T3
- - - Добавлено - - -
Но SCR1/2 все равно не стыкуется:
Уточнение - SCR0/UNDOC не стыкуется
Расписал те же команды для SCR1/2, все совпадает с растактовками и "правилами" (https://zx-pk.ru/threads/9431-pk8000-bystrodejstvie-arkhitektury-issledovanie.html?p=578882&viewfull=1#post578882)
lda - 20, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|T3; подряд T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|T3
sta - 24, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3; подряд T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3
lhld - 24, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|T3; подряд T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|T3
shld - 32, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3; подряд T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3
call - 32, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T5 T1|T2 Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3; подряд T1 T2 Tw|T3 T4 T5 T1|T2 Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3
ldax/stax/mov m,r/mov r,m/ani/adi/sui/и т.п. - 12, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3; подряд T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3
pop/ret/mvi m,/jmp/inr m/dcr m - 16, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3; подряд T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3
mvi m,/inr m/dcr m - 20, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3; подряд T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 Tw Tw Tw Tw|T3
Rcond Y - 16, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T5 T1|T2 Tw Tw Tw|T3 T1 T2 Tw|T3; подряд T1 T2 Tw|T3 T4 T5 T1|T2 Tw Tw Tw|T3 T1 T2 Tw|T3
push/rst - 20, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T5 T1|T2 Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3; подряд T1 T2 Tw|T3 T4 T5 T1|T2 Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3
xthl - 36, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 T4 T5; подряд T1 |T2 Tw Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 T1 T2 Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3 T4 T5
in и out проверил 4 возможных варианта соотношения окна доступа к озу и портам, сходится только если эти окна в одинаковом такте цикла, в примере - первом
in - 16, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3; подряд T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|T3
out - 20, сходится
Первая команда T1 T2 Tw Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3; подряд T1 T2 Tw|T3 T4 T1 T2|Tw Tw Tw Tw|T3 T1 T2 Tw|Tw Tw Tw Tw|T3
Отмечу, что in/out для SCR0/UNDOC сходятся только в случае если окно порта через один такт позже окна озу (иначе говоря окно озу в следующем такте после окна порта), как показано в предыдущем посте. Возможно есть другое объяснение, но без анализа ПЛМ и/или временных диаграмм мы этого не узнаем.
DemonId7
13.01.2019, 11:58
Думаю я нашел куда "пропал" 241-й пиксел :)
Скриншоты (https://yadi.sk/d/tX1FYgAV8Zwb3w)
Оказывается многое зависит от параметров развертки тв-тюнера.
PS: По цветам чуть позже разберемся. Все эти пал-кодеры преобразуют цвета в аналоговые, а значит возможны изменения интенсивности и состава компонентов. Я просто сравню их с цветами на мониторе, куда они попадают в цифровом виде.
DemonId7, а можно черно-белый вариант clbfs0_704x576.BMP сделать без кодера? В цветном варианте этой картинки я вижу 241й столбец, а в ч/б - непонятно.
ivagor, спасибо!
В общем, если дойдет дело до потактовой эмуляции, уже есть правдоподобный алгоритм.
(Я правда, не сверял еще выполнение из ПЗУ, но надеюсь, что там тоже все будет ок)
Но лично я пока не готов делать потактовую эмуляцию, к сожалению :(
DemonId7
13.01.2019, 14:15
DemonId7, а можно черно-белый вариант clbfs0_704x576.BMP сделать без кодера?А ч/б вариант - это и есть без пал-кодера. Если посмотреть цветную и ч/б картинки в режиме наложения (быстрого переключения между картинками), то видна абсолютная схожесть, просто у ч/б некоторые близкие цвета почти не различимы.
Вот и выходит, что 241-й столбец есть, просто почему-то в режиме 720x576 не виден.
А ч/б вариант - это и есть без пал-кодера.
Я думал, что паразитные узоры на ч/б вариантах - от пал-кодера. Но в ч/б s0in4_704x576.BMP этих узоров не вижу. Что это могут быть за "узоры"? При делании ч/б скриншотов видеовыход ПК8000 был напрямую соединен со входом тюнера и кодер был выключен?
Pyk, не знаю, насколько тебя это утешает/успокаивает, но потактовой же эмуляции 8080 ни у кого нет. С другой стороны у тебя получилась весьма точная эмуляция SCR0, которая, как я думал, без потактовой невозможна.
ivagor, ну, насчет потактовой эмуляции я немного погорячился, но примеры качественной поцикловой эмуляции есть.
Этого было бы, пожалуй, даже достаточно, чтобы учесть все нюансы этого компьютера, но у меня мотивация на это пока отсутствует ;)
В общем, сделал новую сборку для тестирования работы с экраном и циклов ожидания:
http://emu80.org/temp/Pk8000_test_40419.zip
Исходники уже на github.
Подытожу, что сделано:
Вейты:
Длительности команд приведены в соответствие с результатами, полученными ivagor. Дробные длительности при выполнении из ПЗУ округлены до целых тактов.
В режимах 0/UNDC, если команда начинается на бордюре и заканчивается в активной области или наоборот, длительность команды берется по началу.
Ситуации, когда в разных циклах идет обращение к разным типам памяти, не обрабатываются, предполагается, что операнды всегда в ОЗУ.
Экран:
Точность эмуляции различных параметров:
- Цвет фона и текста - с точностью до точки
- Буфер знакогенератора - с точностью до скан-линии
- Остальные буферы и палитра - с точностью до 2-х скан-линий (может быть опережение на 1 скан-линию)
- Режим экрана - с точностью до кадра (некоторые параметры - до скан-линии)
- 241-я и гипотетическая 242-я точки в режиме 0 не эмулируются
Сделал более точной эмуляцию тех параметров, которые, как мне кажется, могут быть реально использованы при написании демок и т.п.
Можно, конечно, и остальными заняться, но не уверен, есть ли в этом реальная необходимость. Накручивать фичи можно долго, но нужно же на чем-то остановиться ;)
Также поправил EI и еще кое-что по мелочи.
Если нужно сразу по горячим следам еще что-то сделать, жду соображений (и, конечно, всегда можно будет вернуться к эмуляции ПК8000 и потом)
Pyk, все круто, но я вот смещение цвета фона на 1 точку на скриншотах DemonId7 вижу только на полосе с голубым фоном. Может DemonId7 сможет сделать ч/б скриншот без "узоров" или надо попробовать другое сочетание цветов, например с черным.
Кстати, DemonId7, возник еще вопрос по ч/б скриншоту clbfs0_704x576.BMP (или 720, тут без разницы). Что-то с яркостями не то, самая яркая должна быть желтая полоса, потом голубая, потом зеленая. А у тебя самая яркая - голубая, потом сиреневая/пурпурная, потом синяя, что вобще невероятно.
- - - Добавлено - - -
смещение цвета фона на 1 точку на скриншотах DemonId7 вижу только на полосе с голубым фоном.
Сейчас попробовал цветные скриншоты в оттенках серого - там действительно практически везде выглядывают полточки.
ivagor, вот для сравнения:
http://emu80.org/temp/CLBFS0_2.png
И сборка, отличающаяся от предыдущей смещением на 1 точку:
http://emu80.org/temp/Pk8000_test_40419_2.zip
Наверное так все-таки лучше?
В режимах 1/2 тоже бы проверить ± 1 точку... В сборке по ссылке выше сделал сдвиг на 1 точку как в режиме 0, так и в 1,2.
После того, как увидел в серых вариантах цветных скриншотов пол-точки (или даже меньше, треть или четверть), уже не уверен, как лучше.
Наверное так все-таки лучше?
Но лично мне этот вариант нравится больше, хотя это, конечно, не критерий.
Эмулировать пол-точки - это пожалуй перебор, лучше наверно как 40419_2
- - - Добавлено - - -
Я до исходников доберусь только во вторник, если DemonId7 не истратит запас терпения к тому времени, можно будет и scr1/2 попробовать. В scr1 есть еще источник потенциальных проблем точной эмуляции - 155РУ2. В оригинальных прогах РУ2 в активной области вроде никто не программировал, там могут вылезти особенности.
Смещение в режимах 1/2 будет не так заметно, так как оно будет видно только на стыке бордюра и активной области.
А с РУ2 можно, конечно, поэкспериментировать, не уверен только, что это может оказаться полезным на практике: можно ведь вместо извращений в режиме 1 просто использовать режим 2. Разве что для экономии памяти?
Практического смысла в программировании РУ2 на лету особого нет, разве что действительно довести косплей спека (PICSC1) до логического конца и раскрасить. Там возможно вылезет бяка, например на векторе программирование РУ2 в активной области сопровождается светлой точкой, которая несколько портит картину. Но ни один эмулятор такую ерунду не эмулирует и это даже хорошо. Нормальные люди рисовали бы в SCR2. А может окажется, что на ПК8000 РУ2 и нельзя программировать в активной области.
- - - Добавлено - - -
Pyk, просмотрел начало темы и увидел прикол (https://zx-pk.ru/threads/9431-pk8000-bystrodejstvie-arkhitektury-issledovanie.html?p=152134&viewfull=1#post152134). Рассуждения там рядом далекие от правды, а вот картинка интересная тем, что теперь в emu80 можно получить почти такую. Надо включить смешивание кадров и удачно выбрать момент для клика курсором на заголовок окна эмулятора (кликаем, держим и похожая картинка застывает). Регулировка бордюра клавишами вверх и вниз.
для клика курсором на заголовок окна эмулятора (кликаем, держим и похожая картинка застывает)
Можно еще на паузу нажать ;) (Alt-P, Pause/Break или кнопка на тулбаре)
Наверно это ЖК-телевизор так аппаратно смешал, у себя видел нечто подобное.
Небольшая программка (https://yadi.sk/d/c-NAI3lWr8JFEw), которая некрасиво рисует фрактал Мандельброта, но главное тут не рисунок, а то, что считается число прерываний/кадров, за которое сформируется картинка. Проба на векторе показала, что эта программка сравнительно точно оценивает векторовское торможение. Для этого надо сравнить время рисования без торможения и с торможением. Сделал вариант и для ПК8000. Цифру без торможения получил в emu (только надо в конфиге изменить частоту проца на 2.5 МГц) - 2039hex. Торможение позволил оценить emu80, там довольно точно реализовано торможение в озу в режимах SCR1/2 (программа работает в SCR1) - 34AFhex. В итоге для выполнения программы из озу в SCR1/2 получился коэффициент торможения 0.6116. На примере вектора можно сказать, что оценка получается чуть-чуть заниженная, поэтому округлю вверх - 0.62 или 62%. Т.е. в указанных условиях "эквивалентная частота" проца примерно 1.55 МГц. При выполнении программы из пзу (что отражено в частоте по умолчанию в emu) или внешней памяти торможение меньше и повеселее.
DemonId7
26.02.2021, 10:36
Что значит эквивалентная частота? Это если считать такты команд как в манах на процессор приведены?
"Эквивалентная частота" в кавычках, лучше говорить о коэффициенте замедления, который получился на примере мандельброта 0.62=62%. Надо будет еще что-нибудь попробовать для большей уверенности.
Думаю понятно, что это средняя температура по больнице и примерно показывает замедление работы программ на ПК8000 относительно отсутствия торможения. При расчете рилтаймовых вещей (биперная музыка, обмен с магнитофоном, мультиколорные эффекты и т.д.) этот коэффициент не поможет и надо считать по тактам.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot