В той же Элите вместе с чисткой экрана стеком делается и копирование буфера стеком.

Молодцы, конечно. Свою задачу они решили — дали процессору работать с видеопамятью во время вывода картинки. Вывод символов ускорили, видеопамять ужали, за счет этого, кстати, работу процессора в нижнем окне памяти ускорили. Бордюр со всех сторон примерно одинаковой ширины, опять же. А то, что спрайты сложно выводить, начиная с произвольной экранной строки — ну так и нечего их выводить так, клешинг устраивать, или в монохроме на цветной машине, надо учитывать ограничения машины и выводить спрайты познакоместно. Самые красивые игры на Спектруме так их и выводят.

А ещё такая раскладка видеопамяти производила (и производит) завораживающий эффект при загрузке экранов) На меня, по крайней мере)

Ок. При 224 пиксельных строках, и 28 атрибутах 8х8 на столбец неиспользуемые участки в памяти на столбец будут по 4 байта. 4*32=128 байт. Можно раскидать в них системные переменные Бейсика, или какие-нибудь палитры для атрибутов в столбце задавать. Действительно, неплохо.

Если делать растр не 256 пикселей в высоту, а, скажем, 192, а лишние байты в столбце отдать атрибутам, у нас будут в каждом столбце участки неиспользуемой памяти — для атрибутов 8х8 по 256-192-24=40 байт, т.е. в целом для 8x8 — 40*32=1280 байт будут не особо при делах. Ну да, что-то в машинном коде впихнуть туда можно, при большом желании, но для бейсика эта память будет по большей части неиспользуемой. Очень эффективно. Ну и при такой организации видеопамяти про скроллинг единственным LDIR-ом можно забыть.

Восьмикилобайтная страница видеопамяти Вектора дает черно-белую картинку 256x256. Действительно, программно адресовать нужный байт видеопамяти проще. Но при этом — черно-белая картинка, и на килобайт с лишним больше объем. Раскрашивание атрибутами, как в Спектруме, потребует ещё килобайт. Итого — 9 кб вместо 6.75 в Спектруме. Эффективно обработать такую видеопамять процессор не успевает, он и Спектрумовскую-то не очень. То есть — объем видеоОЗУ увеличивается, отношение частоты процессора к объему видеоОЗУ, или графическая производительность, падает, место под память для программ уменьшается. Так что такая структура видеопамяти эффективна только в плане некоторого удобства программирования, во всех остальных — не очень.

Мда, тут я ступил. ULA читает 32 байта атрибутов 8 раз подряд, а потом переходит к следующей 32-байтной строке атрибутов. То есть при существующей структуре видеопамяти сначала 8 раз читается первые 32-байтные блоки 128-байтных блоков, потом — вторые, потом — третьи, и так далее. Видимо, для регенерации этого достаточно. Во время вывода верхнего/нижнего бордюра и вертикального обратного хода луча чтения видеоОЗУ вообще не происходит, а это всяко больше по времени, чем переход к следующему 32байтному блоку во время вывода растра.

А причем тут скорость ввода в редакторе Бейсика, если речь идет о скорости вывода текстов Бейсиком?

Подозреваю, что дожимать было некуда — любая другая структура видеопамяти была бы менее эффективной в плане производительности вывода текстов, равно как и в плане объёма видеоОЗУ. Деление экрана на трети — побочный эффект от возможности перехода к следующей пиксельной строке инкрементом старшего байта адреса.

Я тоже не понимаю. Судя по тому, как сделана регенерация динамической памяти процессором с использованием регистра R, для регенерации нужно, чтобы из памяти регулярно, последовательно, и циклично читались ячейки из любого 128-байтового блока ячеек ОЗУ. ULA это обеспечивает регулярным чтением видеоатрибутов при выводе строки картинки, то есть структура пиксельной видеопамяти для регенерации не важна.

Третья версия рулит. При выводе текста INC H мало того, что быстрее, чем ADD HL,BC, так ещё и не требует целой регистровой пары под константу приращения адреса на следующую строку. Вариант с приращением адреса через аккумулятор ещё (намного) медленнее. Какие тут могут быть возражения?

Только вот, боюсь, Синклер вообще ничего такого не предполагал, ибо вообще был далек от разработки как железа, так и софта.

Козырно)

Спасибо. То есть, для sRGB смешивания двух уровней A и B (выраженных в целых числах 0..255) мы должны:
1) преобразовать оба уровня в линейный RGB:
A1=((A/255+0.055)/1.055)^2.4 * 255
B1=((B/255+0.055)/1.055)^2.4 * 255
2) найти среднее арифметическое линейных уровней
Mix=(A1+B1)/2
3) преобразовать его в sRGB:
sRGBmix = (1.055*(Mix/255)^(1/2.4)-0.055) *255

Или, если немного упростить:
1) A2=((A/255+0.055)/1.055)^2.4
B2=((B/255+0.055)/1.055)^2.4
2) Mix2=(A2+B2)/2
3) sRGBmix = (1.055*(Mix2)^(1/2.4)-0.055) *255

PS. проверил картинки из статьи на мониторе Samsung 931C с TN-film матрицей, и на нем всё совсем не так, как на моем Dell с IPS.
Во-первых, оттенки мерцания и смешиваний не совпадают. Во-вторых, на участках с сеткой идет дикое цветное мерцание.
Ну и в-третьих, для каждой из трех приведенных картинок результаты сравнения разные
1) черно-белая картинка с мерцанием намного ярче и pulsar, и sRGB смешивания
2) для картинки с лицом sRGB ближе к мерцанию
3) а для картинки с пляжем — ближе к мерцанию pulsar.

Статья интересная, на моем мониторе полученные в статье оттенки sRGB-смешивания выглядят гораздо ближе к мерцающим, чем у pulsar.

Но вот, пытаясь реализовать sRGB-смешивание в эмуляторе, столкнулся с тем, что собственно алгоритм смешивания и пример из статьи для меня невразумительны. В примере переводится отдельный серый цвет, а я бы хотел понять, как смешиваются два цветовых уровня A и B.

Вот формула смешивания в лоб: Mix:=(A+B)/2

Вот то, как я понял из статьи, должны смешиваться цветовые уровни по sRGB:
A1=A/255 B1=B/255
if A1=0 then A2=0 else A2=A1^(1/2.4)*1.055 — 0.55
if B1=0 then B2=0 else B2=B1^(1/2.4)*1.055 — 0.55
sRGBmix=(A2+B2)/2 *255

Но, судя по получаемым значениям, понял я неправильно. Отсюда у меня два вопроса:
1) как всё-таки правильно смешивать цветовые уровни по sRGB?
2) может ли кто-то из прочитавших статью (кроме автора) ответить на первый вопрос?

А откуда вообще взялась необходимость в изменении правил? Есть же на CC подкатегория конкурсов Intro/Demo (Combined), в которых можно представлять работы для любых компьютеров и систем. Зачем нужно впихивать невпихуемое в подкатегорию ZX Spectrum?

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

Можно считать, что релиза и демы не было. Была презентация приватного гифта, которая, в связи с близкими отношениями авторов с оргом (или орга-автора, я не в курсе) в обход правила об открытой публикации участвовала в конкурсе и заняла первое место.

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

Ну вот показ на пати они планировали, а делиться бинарником — нет. «Там, где правила игры не позволяют выиграть, джентльмены меняют правила».

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

Да накатило чёт. Осень, все дела. В порядке борьбы с творческим кризисом и экзистенциальной тошнотой стиранием фрагментов личной истории. Ну что же, демотивировал так демотивировал.