Да, только вместо чисто nopов будет микс команд. Вечером сделаю.Сообщение от tnt23
можно, а почему вдруг такой вопрос?
- - - Добавлено - - -
А, наверно я не понял вот это
Т.е. в таком смысле вряд ли.
Да, только вместо чисто nopов будет микс команд. Вечером сделаю.
- - - Добавлено - - -
А, наверно я не понял вот это
Т.е. в таком смысле вряд ли.
Потому что сейчас у меня ожидание прерывания сделано как JMP ., а это значит, что точный момент первого изменения палитры в обработчике будет плавать в зависимости от того, на какой машинный такт команды JMP по времени придется прерывание по лучу.
jmpом лучше не ждать, лучше halt. Есть даже картинка от другого компьютера (ПК8000) где я зачем-то (сем не знаю зачем) ждал прерывания jmpом. Полоса странного цвета на бордюре между зеленым и синим как раз "дрожание", последняя версия emu80 Pyka даже практически умеет эмулировать этот момент.
tnt23, я тут накопипастил три тестика, надеюсь найдешь время их попробовать.
Ожидаемые результаты: во всех два цвета - зеленый и красный.
test153 - недолет, кадры бегут, граница между цветами диагональная, в сторону /
test154 - перелет, кадры бегут, граница между цветами диагональная, в сторону \
test768 - попадание, картинка неподвижна, 5 строк одного цвета и 5 - другого (но строки могут начинаться в любом месте).
- - - Добавлено - - -
Забыл (как обычно) - выход в дос по нажатию любой клавиши.
Последний раз редактировалось ivagor; 20.02.2019 в 09:27. Причина: удалил вложение в связи с выклаыванием новой версии
ivagor, результаты домашки прилагаю.
(Вместо выхода в дос у меня рисуется дивной красоты сине-белый матросский матрас. Видимо, включается альтернативная страница видео-ОЗУ)
UncleDim(09.08.2024)
Виноват, выход в дос сначала был, а прямо перед выкладыванием я его случайно "соптимизировал" и не обратил внимания.
Результаты 153 и 768 не вызывают удивления, а вот над 154 надо подумать.
- - - Добавлено - - -
Важный вопрос - в 153 и 154 кадры бегут?
- - - Добавлено - - -
Понял, в названии 153 и 154 run, а в 768 stand still
В 153 и 154 кадры бегут, заснять это на видео сложно.
Предлагаю следующее толкование результатов.
То, что мы видим на фото - это результат комбинации двух разверток: развертки ТВ/монитора и развертки фотоаппарата (вероятно в телефоне).
Если внимательно посмотреть на фотографию 153 (strips_run_right.jpg) то мы видим 3 линии. 2 потемнее с одинаковым наклоном - это результат работы программы, а светлая диагональная (примерно по центру) с другим наклоном - это результат сочетания развертки ТВ и фотоаппарата для данной картинки.
На 154 (strips_run_left_do_they_not.jpg) видны две светлые линии с наклоном / - это опять результат сочетания развертки ТВ и фотоаппарата для данной картинки. А результат работы программы - это три фрагмента темной линии с наклоном \. Три фрагмента получились из-за развертки фотика.
Развертка фотоаппарата сказывается на динамичных бегущих кадрах, на стабильных все нормально.
Что из этого следует. Получить с использованием того же фотоаппарата картинки только с "нужными" линиями на бегущих кадрах не получится. В лучшем случае можно поменять картинку, чтобы эффект был более заметен.
А если предварительно засинхриться по окончанию кадрового гасящего импульса? Тогда, по моим представлениям, тесты 153 и 154 будут образовывать стабильную диагональ, и останется только подобрать режим съемки (или попробовать видеозахват).
Да, только я в эмуляторе не могу отладить такую программу.
- - - Добавлено - - -
Вернее так - нужно не предварительно засинхриться, а синхрить каждый кадр.
- - - Добавлено - - -
Сообразил, как можно совместить стабильную картинку и наклон и отладить (но не посмотреть) в эмуляторе.
Делаем в кадре максимальное число строк по 153 или 154 такта, а остаток до 49152 добиваем балластом.
153*321 + 39 (балласт) = 49152
154*319 + 26 (балласт) = 49152
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием