search

samstyle / Xpeccy

Multiplatform emulator of retro computers
MIT License
71 stars 13 forks source link

Pentagon timing #116

Closed holub closed 2 years ago

holub commented 3 years ago

Если судить по Across The Edge - Pentagon timing не совсем точный. https://zxaaa.net/view_demo.php?id=9284

В ShockMD также бордюр эфект не точен: https://zxart.ee/eng/software/demoscene/demo/shock-megademo/

Это проблема множественных клонов Pentagon, или ошибки в эмуляции?

samstyle commented 3 years ago

Часто замечаю смещение бордюра налево на 1 точку. Почему - ума не приложу. Что касательно именно пентагоновских таймингов, то там есть особеность в чтении пикселей/атрибутов. Как это сэмулировать, тоже пока не придумал.

holub commented 3 years ago

Там может смещенте быть на 1,2,3 точки если тайминги перед HALT не кратны 4. Но тут вроде больше чем 1 точка. Может для инструкции спецефичных не правильно tstate эмулируется? Рад, что ты всеже над этим думаешь.

holub commented 3 years ago

https://hype.retroscene.org/blog/773.html Набрел, может заинтересует

samstyle commented 3 years ago

Вывод нового цвета бордюра в Пентагоне не выровнен на границу пикселей растрового поля. Поэтому пиксели бордюра слегка смещены по сравнению с пикселями растра. В частности, в конце демо Rage после остановки вращения сегментов на реальном Пентагоне видно, что вертикальная полоска на бордюре слегка смещена влево, по сравнению с полоской на растровом поле

Так это значит, что у меня всё правильно? :)

holub commented 3 years ago

Выходит что да, если не брать во внимание, что Rage вообще под эмулем не запускатеся. :D

samstyle commented 3 years ago

Rage грешит OUT (#FD),A и не работает на некоторых клонах А насчет вывода я проверил - у меня вообще сделана запись в порт после команды (т.е в конце 3го такта цикла iowr). и всё равно иногда бордюр сдвинут налево. но не везде.

holub commented 3 years ago

Нет желания сделать поддрежку несколькоих клонов Pentagon? Ну хотябы чтобы 2 было...

holub commented 3 years ago

  1. Есть вот такая картинка. Не могу быть уверенным насколько она правдива. https://zxuno.com/forum/viewtopic.php?t=122 В эмуле видимый бордюр не в соответсвии с ней рисуется. Другие отсупы.

  2. Поговорил с TmK из deMarche. Он сказал Across the Edge тестили на реальном железе, unreal, fuse. В Xpeccy я вижу на уровне скрина добавляются примерно 2 такта и картинка смещается вправо. (ну или над скрином теряются)

samstyle commented 3 years ago

с этой "правдивой" картинкой всё разъезжается намного больше, ещё и по вертикали. попробую менять бордюр после 2го такта цикла iowr, а не после 3го. по идее на эти 2 точки и уезжает. странно, что не везде

holub commented 3 years ago

0й такт. Захват прерывания происходит на последнем такте команды предыдущего кадра. Но, чтобы он был захвачен, импульс прерывания должен начаться ещё раньше, на предпоследнем такте команды. Т.е. самым первым тактом кадра, при программном выравнивании на начало кадра, фактически является предпоследний такт предыдущей команды. Поэтому, если такты нового кадра в эмуляторе нумеруются с начала цикла подтверждения прерывания, начиная с нулевого (а это практически стандарт), дальнейшие значения нужно уменьшать на 2.

Это не они?

holub commented 3 years ago

Вот похоже нашел твой один плавающий пиксель: http://web.archive.org/web/20080509193736/http://www.ramsoft.bbk.org/floatingbus.html Тут про 48 и 128, но видимо рыть надо в этом направлении - для #4000 и #5800 отступ разный должен быть.

samstyle commented 3 years ago

Последнее, скорее, применимо к медленной памяти и порту FF в ней. Даже если это оно, эффект будет заметен только при изменении экрана прямо под лучом, что маловероятно. Склоняюсь к проблеме с INT на последнем такте команды.

samstyle commented 3 years ago

Захват INT на последнем такте ничего не решил. Это бы устранило захват INT-а, который попал на последний такт, но тогда смещение уже было в 8 точек (4 такта на ещё одну итерацию HALT). К геометрии экрана пентагона тоже никаких нареканий, она соответствует той, что описана здесь - https://hype.retroscene.org/blog/773.html Как костыль, можно сделать запись в порт после 2го такта цикла iowr. Сейчас после 3го. Это сдвинет бордюр на 2 точки налево. Других причин, почему имеется расхождение в 1 такт, я пока не вижу.

holub commented 3 years ago

Славил очень прикольный эффект. Делаю снапшот, загружаю по F3 и каждый раз имею разную картинкую xpeccy_193522_764 xpeccy_193549_200 xpeccy_193527_519

samstyle commented 3 years ago

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

holub commented 3 years ago

Нет-нет-нет. Эта картинкт через несколько секунд после восстановления сделаны. Перерывание статичеси сдвигается и экран так и продолжает рендерится до конца.

samstyle commented 3 years ago

Я немного не про то. INT может попасть на 1й,2й или 3й такт HALT-а (на 4й, как выяснилось, оно уже не захватится после текущей итерации), который синхронизирует проц с видео. Это уже разница в 6 точек в ту или иную сторону. Сам по себе HALT не значит, что прерывание всегда будет захватываться в одном и том же положении луча. SNA это ну вообще никак не учитывает. ЗЫ: Исправленный IOWR я уже закоммитил

holub commented 3 years ago

Мне кажется, что я скачки видел в 10 пикселей. Потещу еще. Но на текущий момент твое объяснение звучит правдопадобно.

holub commented 3 years ago

Всеже ссылки вверху, по-моему, объясняют почему в AtE бордюр сдвинут вправо. Screenshot_20210515-221859~3 Screenshot_20210515-221844~3

samstyle commented 3 years ago

Это да, за 0й такт у меня считается такт на котором прерывание захватилось. Более точно можно смотреть по координатам луча справа. Внутри я не могу контролировать точный такт возникновения прерывания, т.к. каждый такт ничего не проверяется. Только в момент iowr/iord/memwr/memrd, перед последним тактом и после команды. Реализация CPU не потактовая. Предвидя, что "можно определять по отрисованным точкам с момента возникновения прерывания" - нетЪ. Для спектрума и CPU без турбы это сработает (1T = 2 точки), а для всего остального - нет. ЗЫ: Разве что вешать на видео коллбэк в точке INT-а и как-то там шаманить с тактами, потому что к счетчику они прибавляются всё равно после команды.

holub commented 3 years ago

Так ты уже починил AtE. Почему даже не намекнул? Красота с бордюром неимоверная. Спасибо!

holub commented 3 years ago

Новый челенж я придумал: https://youtu.be/b-kkzl2foaQ 0:40 - здесь основной картинка "статическая", а в xpeccy моргает. Либо тактов на цыкл не хватает, либо пепеключение экранов не правильно рендерится.

samstyle commented 3 years ago

Отключи нофлик в анриле и снова посмотри этот момент. Так можно и в xpeccy его включить и ничего мерцать не будет. Вот эти полосы как бы намекают, что он был включен при записи Screenshot_20210516_120355

Так ты уже починил AtE. Почему даже не намекнул?

https://github.com/samstyle/Xpeccy/issues/116#issuecomment-841646727

holub commented 3 years ago

Был бы у меня анрыал на линуксе, я бы хорошим людям мозг не долбил бы. С noflick работает. Есть небольшие подергивания, но я, всеравно, счастлив вопреки этому.

holub commented 3 years ago

И снова здравствуйте! С прыгающим INT после востановления снэпшота крайне неприятная штука. С одной стороны круто что можно потыкавшись в правильное состояние. Но врядли комуто это нужно - для игрух не критично. Я сохраняю sna из SjAsmPlus и он практически является начальным состоянием как после load "", а бордюр дергается. Может базовай INT всегда сбрасывать в одно состояние после востановления снэпшота?