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

а я даже не успел увидеть, какие правки)) но одно дело утвердительно сказать «отстаёт», и совсем другое «может отстать» или даже «авторы прошивок полагали, что отстать может» (авторы же эмуляторов полагают, что в нормальной эталонной системе скорее переключится сразу)

посмотрел, в литературе документирована 15663 — то есть #3D2F
но эмуляторы считают, что и переход на следующий адрес тоже сработает

… хотя в ПЗУ тырдоса так-то перед ней аж три нопа

может ли так быть, что оригинальный фирменный бета-диск и наши клоны выборку по-разному делают?

ну вот #3D30 как раз такая точка входа и есть

переключение банков ПЗУ отстаёт на один запрос

откуда инфа? что именно с бета-диском так происходит?

я вот сдуру сделал так в своём эмуляторе, и после этого стал неправильно работать TESTall:
vtrd.in/system/TEST_ALL.zip
который переходит на #3D30 явно предполагая, что выбираться с него будет уже опкод ret из ПЗУ тырдоса

а в других эмулях — unreal, spin, xpeccy — оно работает!

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

давно делал и компактные варианты, можно поискать в закромах

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

Для set пока что получается всего перспективней пополам еще разбить сектора, тогда можно пользоваться тем, что сразу после ступеньки проверка не нужна, то есть, например, на косую zx-диагональ их будет нужно только 191, а ведь вместе с каждой выкинутой проверкой не только sub уходит, но и jp. Плюс удобно хвост дорисовывать без счётчика пикселей и без расстановки ловушек просто переходом на нужный адрес (правда, для самых пологих так не получится). И если не гнаться за рекордом, размер цикла такого сектора естественным образом сокращается почти вдвое, хоть и несколько замедляется.

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

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

не потерял надежды сделать таблицу для DDP по данным dx и dy

а ты подсчитывал, сколько памяти тогда уйдёт под все циклы всех секторов и сколько цикл для диагонали будет работать?
сейчас тестирую альтернативный метод, позволяющий диагональ построить в цикле за ~8300 и к тому же перспективнее для коротких (правда, код опять разбухнет под 8кб)

прошлую выкладывал на zxpk демкой в снапе (а с сырцами правильно не торопился, выходит, раз переделывать))

так там и нет в ступеньках djnz:

Для развёрнутых процедур DOWN_HL будет соответственно «inc h» или «add sp:ld h,(hl)»

почему? и длинную тоже, в цикле на диагональ теперь уходит почти ровно 9000 тактов, на 500+ меньше прошлой

применять можно вместе с обсуждавшейся процедурой или отдельно
тогда примерно или +1кб и +10% скорости, или -6кб и -10% скорости

щас прикинул, может быть, даже и развёрнутую быструю процедуру утоптать получится в ~4кб без особенной потери скорости на коротких, а на длинных даже с выигрышем

Да сама табличка сверхпримитивная, основное — где она расположена, нужно выделить удобные адреса (из нескольких вариантов). Где и что у неё внутри, должно быть понятно из кода сразу. Смотри, вот так может выглядеть DOWN_HL для компактной неразвёрнутой процедуры:

djnz (на inc h)
ld b,c (или ld b,8)
add hl,sp
ld h,(hl)
inc h

Что средневзвешенно на полтора+ такта быстрее чем pop:add и не использует стек (только временно его указатель), а потому может применяться и при рисовании с двух концов (для UP_HL код аналогичный, но с альтернативной парой вместо sp и второй таблицей). Прерывания тоже не страшны, если над (sp) немного места зарезервировать. В сам sp грузим константу #XX20, где XX зависит от адресов таблиц и экрана. Например, в sp можно поместить #E020 если с #C000 рисуем на двух экранах. Код короткий, для таблиц на каждый сегмент экрана нужно 256*2 байт (на последний сегмент можно только 256, если закольцовывать не хотим).

Для развёрнутых процедур DOWN_HL будет соответственно «inc h» или «add sp:ld h,(hl)»
Средневзвешенно минус три такта на ступеньку.

Вот и всё, я даже засомневался, что никто еще до этого не допёр. :D

Ты придумал табличку? молодец. Я пока не придумал.

а вот теперь я, похоже, всё-таки молодец, и табличку тоже таки придумал :)
применять можно вместе с обсуждавшейся процедурой или отдельно
тогда примерно или +1кб и +10% скорости, или -6кб и -10% скорости

я на пальцах-то могу объяснить)) а статью, чтоб интересно и понятно — это с трудом :( времени понадобится вагон

нагло предлагаю свой мумулятор, он может работать с кадром 60гц, и синхра от видео, а не звука
также в нём есть для простых моргалок-двумя-экранами чересстрочная автогига (не блендинг!)

ссылки тут, если кто не в курсе — zx-pk.ru/entries/360-zx-ulax-download-links.html

минус — нет полноэкранного режима (автоматически размер окна на максимальный кратный масштаб)

по крайней, мере, подойдёт хотя бы для оценки, как это могло бы выглядеть
а спецтулзу для показа в полный экран (или без оконных рамок на чёрном фоне), думаю, несложно будет накодить

да я тащемта и не протестую