Почему у ZX Spectrum нелинейная адресация видеопамяти

v.1.0. черновая.

Почему экран ZX Spectrum устроен так необычно? Казалось бы, линейный экран намного проще?

Рассмотрим ZX Spectrum 16K. Контроллеру дисплея требуется считывать сразу два байта подряд (На самом деле он считывает в burst’е 2+2 байт, но для объяснения это несущественно). Сначала считывается байт атрибутов, затем байт пиксельных данных. Адрес приходится выставлять дважды: адрес атрибутов и адрес пикселей.


Объем DRAM 4116 составляет 16кбит или 14 бит. 14 битный адрес мультиплексирован по 7+7 бит и выставляется во времени раздельно, двумя частями. Сначала выставляются младшие 7 бит адреса, сопровождаемые сигналом RAS (row address strobe), при этом микросхема запоминает эту часть адреса внутри. Затем выставляются старшие 7 бит адреса, сопровождаемые сигналом CAS (column address strobe). При этом передача первой и второй части адреса в цикле RAS-CAS требует определённого времени, это важно.

Микросхема DRAM 4116 является одной из первых микросхем PM (page mode) со страничной адресацией. Она позволяет выставлять только одну часть (7 bit) мультиплексированного адреса, оставляя предшествующую часть (выставленную RAS) неизменной. Это работает быстрее, так как не требуется каждый раз посылать обе части адреса. Вместо двух циклов RAS-CAS для передачи полного 7+7 бит адреса остаётся только один цикл CAS. В терминологии PM микросхем DRAM такая ситуация называется страничный доступ.

Теперь вспомним, Z80 разделяет время с контроллером дисплея, и чем быстрее будет цикл чтения контроллера дисплея, тем меньше времени будет простаивать Z80. Ситуация на самом деле хуже, так как если бы чтение выполнялось 4мя циклами RAS-CAS-RAS-CAS, Z80 пришлось бы остановить на всё время чтения строки дисплея. Поэтому Ричарду Альтвассеру пришла мысль использовать страничный доступ 4116 и пере-использовать часть адреса контроллера дисплея. В этом заключается ещё одна маленькая хитрость устройства ZX Spectrum.

Когда контроллер дисплея считывает два байта, адрес байта атрибутов выставляется полный, 14 бит двумя циклами по 7 бит RAS-CAS. Чтение байта пикселей выполняется сразу вслед за этим в страничном режиме, одним циклом CAS. При этом выставляются только старшие 7 бит адреса, младшие 7 бит используются от атрибутов. Тем самым вместо долгого цикла из RAS-CAS-RAS-CAS происходит более короткий цикл RAS-CAS-CAS.
Это и есть ответ на загадку дисплея ZX Spectrum. Из-за ускорения чтения циклом RAS-CAS-CAS по 7+7+7 бит адреса, и из-за того что адрес пикселей использует часть адреса атрибутов, биты адреса пришлось разделить, перегруппировать и отсылать частями.

Рассмотрим, как именно.
Счётчик контроллера экрана условно представлен битами:
v7,v6,v5,v4,v3,v2,v1,v0,c4,c3,c2,c1,c0
где v – 8 битов vertical, пересчитывающих 0..191, c- 5 битов column, пересчитывающих 0..31. С column-частью адреса всё в порядке, перемешивание идёт с v-битами.
В микросхемы DRAM адрес отсылается по 7 бит, сначала сопровождаемые RAS-стробом идут 7 младших бит адреса атрибутов: [v4,v3,c4,c3,c2,c1,c0] – при этом биты v2,v1,v0 счётчика пиксельной строки пропущены.
Затем, по CAS-стробу передаются оставшиеся старшие биты адреса:
[0,1,1,0,v7,v6,v5] – 7 старших бит адреса атрибутов.
Отметим, что биты счётчика v7-v5 следуют за битами v4-v3, продолжая их, т.е. адрес атрибутов линейный. Биты 0,1,1,0 заданы аппаратно. После этого будет прочитан байт атрибутов.
Затем, по CAS-стробу в страничном режиме должны быть переданы 7 бит старшей части пиксельного адреса.
[0,v7,v6,v2,v1,v0,v5] – какова логика такой расстановки битов? Младшая часть пиксельного адреса используется от адреса атрибутов, переданного по RAS. Биты счётчика адреса v4-v3 мы уже передали, значит, следующий бит v5. Далее следуют биты v2,v1,v0, v7,v6 и аппаратный бит 0.

Выставим обе части 7+7 бит пиксельного адреса в ряд:
0,v7,v6,v2,v1,v0,v5,v4,v3,c4,c3,c2,c1,c0.

Разобъём на две группы по 8 бит, также как биты сгруппированы в регистрах микропроцессора z80:
[0,1,0,v7,v6,v2,v1,v0] [v5,v4,v3,c4,c3,c2,c1,c0]

Наблюдаем знакомую картину экранного адреса. Остаётся открытым вопрос – единственный ли это способ группировки бит? Для видеоконтроллера адресация байт в памяти не особо важна. Однако логическая группировка бит адреса для конкретного микропроцессора может либо хорошо совпадать с его архитектурой, либо вызывать затруднения. При проектировании ZX Spectrum (рабочее название ZX82) учитывался опыт предыдущих продуктов Sinclair ZX81, ZX80, имевших дисплей 32 символа по 24 строки. В итоге остановились на наиболее удобной аранжировке бит для программного отображения одного символа, когда для того чтобы инкрементировать строки достаточно инкрементировать старшую половину адреса. Заметим, что в продуктах ZX80, ZX81 дисплей отображался программно, при помощи Z80, поэтому вопрос производительности был, конечно, понятен. Вот почему, в конечном итоге, ZX Spectrum имеет такую организацию экрана. Исходная причина перестановки бит вызвана требованиями hardware. Но сама аранжировка бит, такая, а не иначе – задана требования software. Замечательная работа инженеров!

Использованная литература: Chris Smith «The ZX Spectrum ULA: How To Design A Microcomputer».

34 комментария

avatar
Товарищ aa-dav настолько шустрый, что пока он задал вопрос и я писал ответную статью, за ночь ему не только успели накидать комментариев, но он успел на их основании выкатить вторую статью. К счастью, мое объяснение более полное, нежели чем «магия». Это потребовало времени.
avatar
Ну, дело тут не в том, что я шустрый, а в том, что вопрос меня реально интересовал и я веду колонку «блеск и нищета 8-битных компьютеров и консолей» на форуме gamedev.ru, откуда сюда многое и принёс тоже. Поэтому я не мог не написать эту статью как только получил ответ на вопрос. :) Вам следовало бы там сразу дать понять, что вы сами занялись целой статьёй — тогда я бы свою и не писал бы. Объяснение действительно более полное, так что держите плюс.
avatar
осень! осень! моар тем про нелинейную раскладку видеопамяти! 8)
avatar
У нас -20° и метель
avatar
вот такая вот суровая осень))
avatar
Blog writing contention.

Стар я стал. Это всё сон и работа. Вот не спал бы как раньше, и не работал — точно бы всё было в срок… ;)
avatar
А по мне так статьи даже дополняют друг друга — моя для тех кто вообще не знает что такое RAS/CAS, а ваша более технически полная. Так что ресурс выиграет от обеих.
avatar
Как принято выражаться, (c) «Я просто оставлю это здесь»
Lord Vader Металлолом — о строении экрана 6912 с аппаратной точки зрения.
Так что в нынешнее время нужно тщательнее искать, тщательнее!
Всё уже сделано до нас.
avatar
Вот блин, далеко не я один это всё искал и не находил ГОДАМИ. Непонятно даже почему. Даже на английском языке.
И главное что версий было много и все годами спорили какая верная. Но ни одна верной не оказалась!
И когда уже всё знаешь — легко находятся объяснения на английском, по ключевым словам, но это когда уже знаешь что искать.
Странная фигня, ведь ВЕСЬ МИР СТРАДАЛ от этой раскладки и (имхо) её структура должна была бы быть в букварях объяснена. :D
Но по факту я вижу что её не знают люди самолично собирающие клоны спектрума.
avatar
Надо было сразу спрашивать у знающих людей. :) Спрашивать надо конечно же у разрабов железа, а не у программистов. Все свои непонятки я развеял сразу же, когда увидел книжку Chris Smith. Хотя раньше и так было понятно что биты контролера перепутаны не из-за софтварной блажи. Ранее я считал что тому виной:

1. Требования legacy (это тоже так, просто это не упомянул.)
2. Недостаток логических элементов ULA или какой-то еще необходимости связанной с дизайном ULA

Мир не страдал. Мне такие адреса весьма по кайфу очень даже. Для программистов структура переставленных битов «объяснена» много-много-много лет назад и много где. Собственно, см. ZX Spectrum ROM 2AA: THE 'PIXEL ADDRESS' SUBROUTINE — там же есть получение адреса атрибутов из экранного, или публикации аж в ZX Review года так 90го. Ну и zxpress.ru рулит, там должно быть обязательно.
Кстати что твоя, что в ROM могут быть написаны более быстро, я имею в виду даже без таблиц.
avatar
«Мир не страдал.»

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

avatar
На самом деле и то и другое — как и мне многим было и интересно да что же за фигня то такая и этим вопросом мучались, так и «ломали голову» как с этим работать в асме. Еще одним косвенным показателем является то, что моя статья про это на другом ресурсе о котором говорил поставила рекорд по лайкам. А это и всё те же мои статьи и здесь — и про денди, и про спектрум и про всякие микропроцессоры. И вот. Абсолютный рекордсмен среди всего этого — статья про то почему у спектрума нелинейная видеопамять. Такие дела…
avatar
Надо понимать, что на этом нашем ресурсе большинство программирующих под ZX не ломает голову по поводу работы с этим в асме 20+ лет, т.к. вопрос давно изучен, разжёван в труху, эффективные техники широко известны. А на непрофильном ресурсе просто кто-то увидел более знакомое слово, и их интерес из области 'у меня тоже был такой компьютер'.
avatar
Так ответ на вопрос то не технику какую то эффективную даёт, а просто даёт ответ почему так перемешаны биты.
Это не даёт «эффективных техник», это просто ответ почему так.
И даже непрограммист на загрузке видеозаставки очередной игры видел эту нелинейность и потому конечно тоже без всякого совершенно ассемблера понимает о чём речь. И это реально оказался вопрос очень интересный людям. Более интересный, чем видеоначинка денди в которую все в детстве играли и так далее.
avatar
Но сама аранжировка бит, такая, а не иначе – задана требования software.
Нисагласин. Насколько помню, сделать лучшую «орионовектороподобную» раскладку с соблюдением требований page mode было реально. Но размером 8k вместо 6.75k. Однако минимизация размера видеопамяти это всё-таки не «требование software». Для эффективного software, напротив, в итоге даже вероятнее экономия — не нужны становятся таблицы и код компактнее.

Замечательная работа инженеров!
Или замечательная недоработка (инженеров, или же начальства, или всех вместе) :P
avatar
Ты слишком широко воспринял мысль, я не про экран в целом. Я про то как биты адреса заданы в данном конкретном случае экрана 32x192. Они заданы самым приятным образом.
Software ты тоже мыслишь очень широко — любое вообще, втч воображаемое :)
avatar
ты не понял, мб и «самым приятным образом» для 6.75k, но не для любого 32x192
и software «в узком смысле» (пзу васика) порой тоже может попортить крови
avatar
«Специалист» я паял, и он у меня был два года, в том возрасте это как сейчас 10 лет. =) Помню, вверх-вниз это INR/DCR L, влево-вправо INR/DCR H. Я понял, что ты мечтал бы о квадратном экране 1:1 с организацией 32 столбца по 256 байт = 8192 байта, пол-памяти. Дальнейшее ведет к милому сердцу обсасыванию техдеталей, с включением хотелок и мечталок на полную мощь, но история не терпит сослагательного наклонения. Увы…
avatar
не квадратном
avatar
Тогда объясняй.
avatar
avatar
кстати, у «векторной» раскладки памяти есть и плюс — сравнительно просто реализовать аппаратный вертикальный скроллинг :)
avatar
Экранчик столбцами весьма интересен, согласен.
У экранчика столбцами есть одно интересное (и я уверен — мало кому известное) свойство. Дело в том, что tearing графики на нём наблюдается весьма интересно, потому что графика «рвётся» лучом не пополам как на построчном экране (что юзеру хорошо заметно глазом), а иначе. Сложно рассказать как, но плюс в том, что заметность «разрывов» или глюков при движении спрайтов гораздо меньше, эти дефекты иного уровня.

На «Специалисте» или «Орионе» прерываний нет вообще. То есть о синхронизации посредством halt/прерывания там никто никогда не знал. А между тем, игрушки выглядят и работают вполне нормально.
avatar
Уточню про прерывания — я рассказываю о ситуации на 1990-92 год. Позже там все могло быть иначе.
avatar
Другой плюс — можно делать произвольную ширину экрана в столбцах, и код работы с экраном при этом не меняется, всегда остаётся inc/dec l для перехода между пиксельными строками и inc/dec h для перехода между столбцами знакомест. Собственно, если вдруг кто не знает, у Специалиста и Ориона довольно необычное разрешение 384x256, т.е. 48 знакомест в ширину.
avatar
Так чё по итогу-то, молодцы они или не молодцы? А то мы 20 с лишним лет это разгребаем. Хотелось бы знать, зря или не зря!
  • sq
  • +1
avatar
Раз мы разгребаем это вот уже 20 с лишним лет — молодцы.
avatar
Сам не знаю. Чето сначала написал, потом стёр, а потом и вовсе завис от таких философских вопросов…
avatar
Молодцы, конечно. Свою задачу они решили — дали процессору работать с видеопамятью во время вывода картинки. Вывод символов ускорили, видеопамять ужали, за счет этого, кстати, работу процессора в нижнем окне памяти ускорили. Бордюр со всех сторон примерно одинаковой ширины, опять же. А то, что спрайты сложно выводить, начиная с произвольной экранной строки — ну так и нечего их выводить так, клешинг устраивать, или в монохроме на цветной машине, надо учитывать ограничения машины и выводить спрайты познакоместно. Самые красивые игры на Спектруме так их и выводят.
avatar
выводить спрайты познакоместно. Самые красивые игры на Спектруме так их и выводят.
Например Rex или Myth.
avatar
Если сузить вопрос до «выполнили задачу или нет», выполнили конечно. В особенности если учесть что R.Altwasser на тот момент было 24 года, делал он всё в одну каску, и сроки стояли весьма сжатые. Про деньги тоже молчу. А ведь это 81й год, карандаш с бумагой, паяльник и макетки.
Кто бы знал что всё это будет жить не благодаря, а вопреки?
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.