Любопытный тред. Спасибо. Надо будет сходить на zx.pk.ru, давно там не был. Мне интересно, как ты измеряешь время/производительность/такты чтобы выстроить график. Научи?

Нет никакого сомнения что «вопросы» можно задать к чему угодно и едва ли не бесконечное количество.
К сожалению вот только ответы давать не все хотят/умеют/могут…

Вопрос в самом деле хороший, но, глядя на обсуждение, хочется надеятся, что всё придет если даже и не к написанному коду или какому-то реально ощутимому проекту, то хотя бы к новому способу борьбы с клэшингом.

я конкретно прицепился к «требованиям software» (когда там скорей hardware+firmware+management) и «замечательной работе инженеров» (что читается как безусловное одобрение, а на самом деле вопросы есть)

Посмотрел, нашел screen_inc.asm, посмотрел locate_pixel и другие вещи. Всё красиво, всё молодец. Могу тебе рассказать дальше, в чём беда подобных вещей. Потому что когда-то, очень-очень давно пришлось пройти по этим граблям. С подобного разумного, организованного (библиотечного) подхода, (типичного для PC/ассемблера x86) начинают многие. Эта «разумность» и «организованность» и подводит. К сожалению, подобный поход не работает на ZX Specrum в практическом плане, потому что оказывается слишком медленным. Тут парадигма программирования (приводящая к успеху) несколько иная. Могу рассказать, если есть интерес.

Я же подразумеваю иное. Мой разговор и мои мысли строятся вокруг исходного вопроса статьи — почему в Sinclair сложилась именно такая архитектуру железа и экрана?
Ответ — в своем локальном вопросе, оторванном от практики несомненно ты прав, с этим никто не спорит и выше я многократно дал понять что понимаю этот вопрос.
Но обсуждаемой тобой задачи, как можно более лёгкого и быстрого доступа к экранной памяти ЛЮБОГО программного обеспечения ВООБЩЕ — у Sinclair не стояло в принципе. На практике и в истории стояли иные задачи:
1. Задача обязательно обеспечить совместимость с ZX80, ZX81 — отсюда 32x24 символа или 256x192 и 32x24 атрибутов для окраски текста.
2. Разгрузить CPU от программного формирования экрана, т.е. как можно больше поднять производительность машины (в BASIC!).
3. Максимизировать объем памяти доступный для BASIC, т.к. это учебный компьютер для BASIC.
4. Обеспечить не только текстовый экран с псевдо-графикой, но полноценный графический экран.

Сочетание всех этих факторов вместе обусловило следующий проект Sinclair «ZX82» или ZX Spectrum.

На самом деле и то и другое — как и мне многим было и интересно да что же за фигня то такая и этим вопросом мучались, так и «ломали голову» как с этим работать в асме. Еще одним косвенным показателем является то, что моя статья про это на другом ресурсе о котором говорил поставила рекорд по лайкам. А это и всё те же мои статьи и здесь — и про денди, и про спектрум и про всякие микропроцессоры. И вот. Абсолютный рекордсмен среди всего этого — статья про то почему у спектрума нелинейная видеопамять. Такие дела…

> в том, что минимальный размер экрана не означает экономного расходования памяти

Так. Разговор имеет тенденцию уходит в недосказанное, в непонятно что. А причиной тому то ни я до конца не высказываю мысли, ни ты. Ты там у себя в мыслях, насколько я понял имеешь в виду конкретную вот эту мысль, про расход памяти и минимальный размер экрана. Это да, всё верно. Сама мысль верна.

Мы, может, не поняли друг друга? Что именно названо «страданием»? Страдание при реализации или страдание от незнания окончательной правды? Похоже что в моем случае первое, а в твоем случае последнее, хотя дела обстоят, конечно, не столь трагично. Люди просто не знали этого 100% точно и всё.

P.S.
Ну а число людей с которыми я эту тему обсуждал и ранее гораздо больше. При этом не знали люди даже тут.

«Мир не страдал.»

Ой вот не надо, эту статью я опубликовал не только тут и три разных человека как минимум мне написали, что всю жизнь тоже «мучались», «ломали голову» почему так и что им «удалось при жизни узнать эту тайну». Число незнающих и строящих гипотезы на самом деле зашкаливает.

Если делать с ловушкой, можно выкинуть dec c: ret z (на коротких линиях это довольно плохая идея)

и так можно, для хвоста отдельный лучше кусок (а на вертикали и не был нужен)

Если делать DDA вместо Брезенхэма, можно выкинуть одну из sub d / add e, но придётся делить в преамбуле.

ну вот видишь, ты подумал, что приехал, и успокоился
хотя делить там совершенно необязательно

Дело в том, в реальной жизни никогда нет 16К на процедуру рисования линии. И даже 8К обычно тоже нет на самом деле. А на масштабе 3-5К примерно одно и то же и выходит.

ничего не понял, почему нет, почему одно и то же, в каких масштабах…

Господи, сколько понтов. Было бы ещё чем делиться.

	set 7,(hl) : dec c : ret z
	sub d : jp nc,HD_L0P6
	add e : inc h

Если делать с ловушкой, можно выкинуть dec c: ret z (на коротких линиях это довольно плохая идея). Если делать DDA вместо Брезенхэма, можно выкинуть одну из sub d / add e, но придётся делить в преамбуле. Всё, приехали. Дальше начинаются разные циклы для разных углов наклонов, группировка пикселов вместе и прочая вакханалия. Дело же не в том, что никто не знает как делать быстрые линии, мягко говоря не новая тема для исследований. Дело в том, в реальной жизни никогда нет 16К на процедуру рисования линии. И даже 8К обычно тоже нет на самом деле. А на масштабе 3-5К примерно одно и то же и выходит.

Сидят те, кто не может сделать лучше, или не хочет. А кто смог — не делятся исходниками))

Ну вот поэтому, грубо говоря, люди и сидят на линии из эксперта до сих пор.

Каких нафиг 2-3 раза, даже в теории? У меня по диагонали сейчас выходит на пиксель в среднем ~37 тактов в основном цикле. Так ведь 15 тактов нужно только чтобы поставить точку, минимум 4 на ступеньку, минимум 11 проверка ступеньки без перехода. Без учёта вспомогательных операций для группы точек. А еще на запуск накладные расходы и завершение — то единственное, что еще осталось оптимизировать, чтобы на коротких снизить потери. Что еще там можно придумать? Разве что выбирать готовые фрагменты за счёт совершенно невменяемого размера. И то сомневаюсь, что заметный выигрыш может выйти.

30% на основной процедуре может дать 15-20% разницы в итоговом fps (и на практике люди замечали столько в элите). Еще может быть смысл позаниматься быстрыми короткими процедурами (те же 13k на диагональ, как в оригинале Spectrum Expert, достижимо в разы меньшим расходом памяти).

У меня есть линия с похожими характеристиками, так что думаю я понимаю как ты её сделал. Но мне кажется, что это всё же охота на блох, в том смысле, что по-настоящему интересно будет только в том случае, если ускорить линию в 2-3 раза. С моей точки зрения ускорение на 20-30% на практике никто не заметит.

Отблагодарил человека!
Исходники бы глянуть :)

Всё так, всё так.
Список https://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips

отсюда: hype.retroscene.org/blog/889.html#comment23545