ld h, htable ; 7
ld l, y      ; 4
ld a, (hl)   ; 7
inc h        ; 4
ld h, (hl)   ; 7
add a, x     ; 4
ld l, a      ; 4

37 тактов и 512 байт памяти

LD BC, port  ; 10
out (c), reg ; 12
in l, (c)    ; 12
inc b        ; 4
out (c), reg ; 12
in h, (c)    ; 12

62 такта, что к следующему порту можно перейти так.

или в случае 8-битых портов

ld a, reg      ; 4
out (port), a  ; 11
in a, (port)   ; 11
ld l, a        ; 4
ld a, reg      ; 4
out (port), a  ; 11
in a, (port)   ; 11
ld h, a        ; 4

60 тактов

Но дело в другом, такое не принято исходя из соображений здравого смысла. Проблемы вычислений адреса — это по-логике проблемы процессора, проблемы даже алгоритма, а не аппаратуры. Такого не было, даже на PC-шных EGA/CGA/VGA видекартах с их чумовейшими битпланами, на амигах/атарях, на консолях или на монструозных arcade game board.
Однако это не значит что данный подход плох или не работает. Работает, и такая идея и меня давно посещала также, и для вычисления адреса, и позже — для выполнения умножения/деления, либо для более генеральных вещей — для общения с «сопроцессором». Подобное весьма активно использовалось на NES/SNES, в дополнительных RISC-микропроцессорах стоящих на картридже игры, только работало не через OUT, а через запись в ячейки памяти и/или DMA.

«Иными словами, вычислять экранный адрес по двум координатам?»

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

down_hl, как раз, занимает всего лишь 4 такта при правильной готовке. И выполняется так с вероятностью 7/8, то есть 87.5%
Это не делает его удобнее или быстрее чем при постолбцовой раскладке где столбцы 256 байт, но ситуация не так уж и печальна. Скажем так, для столь мелкого экрана как 6144 байта это всё же чудесное решение.

1) на z80 возня с портами неудобна, медленна и, как следствие, обычно невыгодна
2) даже если был бы небольшой выигрыш, всё равно адрес по координатам объекта (спрайта, конца отрезка) вычисляется однократно, и в % от всего объекта будет уж совсем незначительным
3) не решает основную проблему нелинейной раскладки — медленный и неудобный down_hl, который нужен многократно на весь объект
4) в оригинальной юле, насколько помню, места не осталось уже совсем; добавлять вторую = удорожать комп; а если уж удорожать, то не для такой ерунды, а чего-нибудь намного полезнее (например, автоматического пересчета удобного логического адреса произвольного окна в неудобный физический адрес экрана, не отказываясь от экономии памяти)

ну типа того, да.

Иными словами, вычислять экранный адрес по двум координатам?
Это не имеет смысла, так как он и так быстро вычисляется по таблице 512 байт, если расположить её в памяти с адреса кратного 256:

ld h, htable ; 7
ld l, y      ; 4
ld a, (hl)   ; 7
inc h        ; 4
ld h, (hl)   ; 7
add a, x     ; 4
ld l, a      ; 4

Т.е. в принципе сдвигами или таблицей выборки получилось бы быстрее, чем через порты ввода-вывода?

*60 тактов

а нахрена?
вообще можно конечно прилепить МК какой (УЛА тут и не нужен), который будет слушать порты и плевать ответы. но:
1. это уже будет не совсем спектрум
2. 2 OUT + 3 IN — 48 тактов, это без учета установки регистра C

Другой плюс — можно делать произвольную ширину экрана в столбцах, и код работы с экраном при этом не меняется, всегда остаётся inc/dec l для перехода между пиксельными строками и inc/dec h для перехода между столбцами знакомест. Собственно, если вдруг кто не знает, у Специалиста и Ориона довольно необычное разрешение 384x256, т.е. 48 знакомест в ширину.

Уточню про прерывания — я рассказываю о ситуации на 1990-92 год. Позже там все могло быть иначе.

Экранчик столбцами весьма интересен, согласен.
У экранчика столбцами есть одно интересное (и я уверен — мало кому известное) свойство. Дело в том, что tearing графики на нём наблюдается весьма интересно, потому что графика «рвётся» лучом не пополам как на построчном экране (что юзеру хорошо заметно глазом), а иначе. Сложно рассказать как, но плюс в том, что заметность «разрывов» или глюков при движении спрайтов гораздо меньше, эти дефекты иного уровня.

На «Специалисте» или «Орионе» прерываний нет вообще. То есть о синхронизации посредством halt/прерывания там никто никогда не знал. А между тем, игрушки выглядят и работают вполне нормально.

кстати, у «векторной» раскладки памяти есть и плюс — сравнительно просто реализовать аппаратный вертикальный скроллинг :)

тогда Brown Storm, всё логично :)))

«Специалист» я паял, и он у меня был два года, в том возрасте это как сейчас 10 лет. =) Помню, вверх-вниз это INR/DCR L, влево-вправо INR/DCR H. Я понял, что ты мечтал бы о квадратном экране 1:1 с организацией 32 столбца по 256 байт = 8192 байта, пол-памяти. Дальнейшее ведет к милому сердцу обсасыванию техдеталей, с включением хотелок и мечталок на полную мощь, но история не терпит сослагательного наклонения. Увы…

да и вообще нехрен спрайтики выводить продуктами такой серьёзной компании ))

ты не понял, мб и «самым приятным образом» для 6.75k, но не для любого 32x192
и software «в узком смысле» (пзу васика) порой тоже может попортить крови

Если сузить вопрос до «выполнили задачу или нет», выполнили конечно. В особенности если учесть что R.Altwasser на тот момент было 24 года, делал он всё в одну каску, и сроки стояли весьма сжатые. Про деньги тоже молчу. А ведь это 81й год, карандаш с бумагой, паяльник и макетки.
Кто бы знал что всё это будет жить не благодаря, а вопреки?

выводить спрайты познакоместно. Самые красивые игры на Спектруме так их и выводят.

Например Rex или Myth.

Ты слишком широко воспринял мысль, я не про экран в целом. Я про то как биты адреса заданы в данном конкретном случае экрана 32x192. Они заданы самым приятным образом.
Software ты тоже мыслишь очень широко — любое вообще, втч воображаемое :)