Молодцы, конечно. Свою задачу они решили — дали процессору работать с видеопамятью во время вывода картинки. Вывод символов ускорили, видеопамять ужали, за счет этого, кстати, работу процессора в нижнем окне памяти ускорили. Бордюр со всех сторон примерно одинаковой ширины, опять же. А то, что спрайты сложно выводить, начиная с произвольной экранной строки — ну так и нечего их выводить так, клешинг устраивать, или в монохроме на цветной машине, надо учитывать ограничения машины и выводить спрайты познакоместно. Самые красивые игры на Спектруме так их и выводят.
Но сама аранжировка бит, такая, а не иначе – задана требования software.
Нисагласин. Насколько помню, сделать лучшую «орионовектороподобную» раскладку с соблюдением требований page mode было реально. Но размером 8k вместо 6.75k. Однако минимизация размера видеопамяти это всё-таки не «требование software». Для эффективного software, напротив, в итоге даже вероятнее экономия — не нужны становятся таблицы и код компактнее.
Замечательная работа инженеров!
Или замечательная недоработка (инженеров, или же начальства, или всех вместе) :P
А по мне так статьи даже дополняют друг друга — моя для тех кто вообще не знает что такое RAS/CAS, а ваша более технически полная. Так что ресурс выиграет от обеих.
Ну, дело тут не в том, что я шустрый, а в том, что вопрос меня реально интересовал и я веду колонку «блеск и нищета 8-битных компьютеров и консолей» на форуме gamedev.ru, откуда сюда многое и принёс тоже. Поэтому я не мог не написать эту статью как только получил ответ на вопрос. :) Вам следовало бы там сразу дать понять, что вы сами занялись целой статьёй — тогда я бы свою и не писал бы. Объяснение действительно более полное, так что держите плюс.
Товарищ aa-dav настолько шустрый, что пока он задал вопрос и я писал ответную статью, за ночь ему не только успели накидать комментариев, но он успел на их основании выкатить вторую статью. К счастью, мое объяснение более полное, нежели чем «магия». Это потребовало времени.
И, похоже, это правильный ответ! :) www.zxdesign.info/harlequinDRAM.shtml
Почитал интернеты по этим ключевым словам и да — похоже это была главная причина.
Поясню для тех кому некогда читать это вкратце. Сперва напомню как работает DRAM — этот дешевый вариант памяти требует периодического обновления своего содержимого — во времена спектрума для этого некий внешний чип должен был инициировать чтение (или запись) памяти. Но не каждой ячейки, а каждой страницы памяти — память состояла из страниц довольно большого объёма. По факту при чтении байта из заданного адреса чип DRAM извлекал во временный буфер содержимое всей страницы памяти, брал из него нужный байт и перезаписывал/обновлял содержимое всей страницы. При этом важно заметить, что селектор страницы в микросхемах применяемых в памяти спектрума содержался в нижнем байте адреса, а селектор байта внутри страницы — в верхнем (даже в семи битах, но неважно).
Это и является ключём к режиму page mode — залочив память на чтение с адреса можно было получив результат не снимать лок, а требовать отдать еще один байт, при условии что он лежит внутри той же страницы памяти — пока она удерживалась во временном буфере можно было значительно сэкономить на операции чтения.
А далее — магия — организация видеопамяти спектрума такова, что у адресов битового паттерна знакоместа и его атрибута один и тот же нижний байт адреса!
Этим и пользовался ULA (видеочипная составляющая) спектрума, чтобы читать и битовый паттерн и его цвет в один присест за 170нс вместо полагающихся 320нс на чтение двух разрозненных байт из памяти.
То, что раскладка получилась удобной для текстового вывода являлось логичным следствием этой оптимизации, но не причиной всего этого безобразия. Сама причина — скорость извлечения памяти. Спасибо за наводку!
Ок. При 224 пиксельных строках, и 28 атрибутах 8х8 на столбец неиспользуемые участки в памяти на столбец будут по 4 байта. 4*32=128 байт. Можно раскидать в них системные переменные Бейсика, или какие-нибудь палитры для атрибутов в столбце задавать. Действительно, неплохо.
Или замечательная недоработка (инженеров, или же начальства, или всех вместе) :P
Стар я стал. Это всё сон и работа. Вот не спал бы как раньше, и не работал — точно бы всё было в срок… ;)
Почитал интернеты по этим ключевым словам и да — похоже это была главная причина.
Поясню для тех кому некогда читать это вкратце. Сперва напомню как работает DRAM — этот дешевый вариант памяти требует периодического обновления своего содержимого — во времена спектрума для этого некий внешний чип должен был инициировать чтение (или запись) памяти. Но не каждой ячейки, а каждой страницы памяти — память состояла из страниц довольно большого объёма. По факту при чтении байта из заданного адреса чип DRAM извлекал во временный буфер содержимое всей страницы памяти, брал из него нужный байт и перезаписывал/обновлял содержимое всей страницы. При этом важно заметить, что селектор страницы в микросхемах применяемых в памяти спектрума содержался в нижнем байте адреса, а селектор байта внутри страницы — в верхнем (даже в семи битах, но неважно).
Это и является ключём к режиму page mode — залочив память на чтение с адреса можно было получив результат не снимать лок, а требовать отдать еще один байт, при условии что он лежит внутри той же страницы памяти — пока она удерживалась во временном буфере можно было значительно сэкономить на операции чтения.
А далее — магия — организация видеопамяти спектрума такова, что у адресов битового паттерна знакоместа и его атрибута один и тот же нижний байт адреса!
Этим и пользовался ULA (видеочипная составляющая) спектрума, чтобы читать и битовый паттерн и его цвет в один присест за 170нс вместо полагающихся 320нс на чтение двух разрозненных байт из памяти.
То, что раскладка получилась удобной для текстового вывода являлось логичным следствием этой оптимизации, но не причиной всего этого безобразия. Сама причина — скорость извлечения памяти. Спасибо за наводку!
про скроллинг лдиром лучше вообще забыть)))