Если делать растр не 256 пикселей в высоту, а, скажем, 192, а лишние байты в столбце отдать атрибутам, у нас будут в каждом столбце участки неиспользуемой памяти — для атрибутов 8х8 по 256-192-24=40 байт, т.е. в целом для 8x8 — 40*32=1280 байт будут не особо при делах. Ну да, что-то в машинном коде впихнуть туда можно, при большом желании, но для бейсика эта память будет по большей части неиспользуемой. Очень эффективно. Ну и при такой организации видеопамяти про скроллинг единственным LDIR-ом можно забыть.
Наиболее далека от истины третья версия, наиболее близка — первая. Только «дешёвый и доступный компонент» не одной видеосистемы, а всего компа целиком — дешёвая медленная память, читать которую юла успевала с минимальным торможением процессора только в спецрежиме page mode, для чего в адресах пиксельной линии и соответствующего атрибута должны были совпадать семь бит минимум (в спектруме совпадает восемь). Да еще и размер видеопамяти экономили (напомню, спектрум начался с модели 16k). Хотя в 8k вполне можно было уложить вектороподобную раскладку для page mode read (могла, правда, усложниться схема регенерации).
'Некоторое удобство' — возможность вывода спрайтов произвольной высоты без таблицы строк и без down hl. Ну или пиксельного скролла по вертикали и знакоместного по горизонтали единственным LDIR'ом. И никто не заставляет делать растр 256 пикселей в высоту. Напротив, логично иметь нормальные более-менее квадратные пиксели и нормальное соотношение сторон экрана, а лишние байты в строке можно отдать тем же атрибутам, при желании.
Восьмикилобайтная страница видеопамяти Вектора дает черно-белую картинку 256x256. Действительно, программно адресовать нужный байт видеопамяти проще. Но при этом — черно-белая картинка, и на килобайт с лишним больше объем. Раскрашивание атрибутами, как в Спектруме, потребует ещё килобайт. Итого — 9 кб вместо 6.75 в Спектруме. Эффективно обработать такую видеопамять процессор не успевает, он и Спектрумовскую-то не очень. То есть — объем видеоОЗУ увеличивается, отношение частоты процессора к объему видеоОЗУ, или графическая производительность, падает, место под память для программ уменьшается. Так что такая структура видеопамяти эффективна только в плане некоторого удобства программирования, во всех остальных — не очень.
Вспомнилось, что у TMS9918 в Mode 2 довольно похожая организация памяти, с третями, но с атрибутами 8x1 (аналогично мультиколору Timex'а). Следующая линия символа inc l, следующее знакоместо l+8, но порядок следования знакомест можно менять — как бы текстовый режим со своим набором в 256 символов для каждой трети, то есть следующий уровень сложности по сравнению с ZX. Это 1979 год, так что влияние на ход мысли разработчиков ZX вполне возможно.
Мда, тут я ступил. ULA читает 32 байта атрибутов 8 раз подряд, а потом переходит к следующей 32-байтной строке атрибутов. То есть при существующей структуре видеопамяти сначала 8 раз читается первые 32-байтные блоки 128-байтных блоков, потом — вторые, потом — третьи, и так далее. Видимо, для регенерации этого достаточно. Во время вывода верхнего/нижнего бордюра и вертикального обратного хода луча чтения видеоОЗУ вообще не происходит, а это всяко больше по времени, чем переход к следующему 32байтному блоку во время вывода растра.
Скорость работы Бейсика в целом, и редактора в частности, делает даже многократную разницу в скорости отрисовки символов несущественной. И этот Бейсик существовал до начала разработки ZX Spectrum, т.е. было ясно, чего ожидать.
Я назвал более эффективную структуру видеопамяти, реализованную в серийном компьютере.
А причем тут скорость ввода в редакторе Бейсика, если речь идет о скорости вывода текстов Бейсиком?
Подозреваю, что дожимать было некуда — любая другая структура видеопамяти была бы менее эффективной в плане производительности вывода текстов, равно как и в плане объёма видеоОЗУ. Деление экрана на трети — побочный эффект от возможности перехода к следующей пиксельной строке инкрементом старшего байта адреса.
Я тоже не понимаю. Судя по тому, как сделана регенерация динамической памяти процессором с использованием регистра R, для регенерации нужно, чтобы из памяти регулярно, последовательно, и циклично читались ячейки из любого 128-байтового блока ячеек ОЗУ. ULA это обеспечивает регулярным чтением видеоатрибутов при выводе строки картинки, то есть структура пиксельной видеопамяти для регенерации не важна.
Ну, имхо, дело не в самом редакторе бейсика, а в том, что вывод текста был обозначен как приматив.
А вывод текста в основном опирается на print_string и именно для print_string как раз легко делать и вывод одного символа и переход к следующему за ним символу. Я писал процедуры вывода текста на спектруме и нашёл, что и то и другое легко делать при данной раскладке видеопамяти. То что экран побит на трети замедляет переход к следующему символу крайне редко.
А по поводу (2) — я не понимаю чем оно вообще могло бы быть полезно.
Возражения могут быть в мотивации — какой смысл в ускорении вывода текста, когда скорость ввода в редакторе Бейсика невероятно низкая и реально может падать до символа в одну-две секунды. Скорость вывода символов в сравнении со скоростью редактора вообще никакой погоды не делает.
Также возникает вопрос: почему, если прицел был на ускорение вывода, не дожали? Много раз обсуждалось, что можно было сделать, например, как в Векторе: inc l — переход к столбцу, inc h — переход к строке. Или другие варианты, так или иначе обходящие деление экрана на трети, которое скорость вывода символов точно не повышает. Т.е. в ряду оптимальных решений то, что реализовано в ZX, далеко не самое эффективное из возможных.
Точно могут ответить только инженеры, но вероятно на самом деле было больше одного фактора. Возможно включая 2 и 3.
Третья версия рулит. При выводе текста INC H мало того, что быстрее, чем ADD HL,BC, так ещё и не требует целой регистровой пары под константу приращения адреса на следующую строку. Вариант с приращением адреса через аккумулятор ещё (намного) медленнее. Какие тут могут быть возражения?
Только вот, боюсь, Синклер вообще ничего такого не предполагал, ибо вообще был далек от разработки как железа, так и софта.
Офигенная игра. Дело даже не в мультиколоре, который последние года активно развивается западными разработчиками и потому уже не очень удивляет. Помимо технологичности, игра реально очень динамичная, простая по механике, самоочевидная в своём устройстве (не надо читать описание, включил и сразу как дома), но при этом вполне мозголомная. Денис снова сделал это.
В таких постах надо обязательно писать, куда заносить автору.
Хорошо запустить у меня получилось в эмуле EmuZWin, стандартные Unreal у меня почему-то не сработали.
Потому что заходить надо из голого бейсика, БЕЗ предварительного захода в тырдос. Если уже заходил, набери RANDOMIZE USR 0 и потом LOAD"". DenisGrachev Не помешала бы проверка адреса загрузки бейсик программы по системным переменным =)
Не могу сказать, чтобы меня сильно впечатлило обсуждение телевизоров.
Но по демо человек говорит дело, а уж относительно 1994 года такие взгляды — реально впереди планеты всей. Triad.
Я назвал более эффективную структуру видеопамяти, реализованную в серийном компьютере.
Подозреваю, что дожимать было некуда — любая другая структура видеопамяти была бы менее эффективной в плане производительности вывода текстов, равно как и в плане объёма видеоОЗУ. Деление экрана на трети — побочный эффект от возможности перехода к следующей пиксельной строке инкрементом старшего байта адреса.
www.wipo.int/pctdb/en/wo.jsp?WO=1983003916
А вывод текста в основном опирается на print_string и именно для print_string как раз легко делать и вывод одного символа и переход к следующему за ним символу. Я писал процедуры вывода текста на спектруме и нашёл, что и то и другое легко делать при данной раскладке видеопамяти. То что экран побит на трети замедляет переход к следующему символу крайне редко.
А по поводу (2) — я не понимаю чем оно вообще могло бы быть полезно.
Также возникает вопрос: почему, если прицел был на ускорение вывода, не дожали? Много раз обсуждалось, что можно было сделать, например, как в Векторе: inc l — переход к столбцу, inc h — переход к строке. Или другие варианты, так или иначе обходящие деление экрана на трети, которое скорость вывода символов точно не повышает. Т.е. в ряду оптимальных решений то, что реализовано в ZX, далеко не самое эффективное из возможных.
Точно могут ответить только инженеры, но вероятно на самом деле было больше одного фактора. Возможно включая 2 и 3.
Только вот, боюсь, Синклер вообще ничего такого не предполагал, ибо вообще был далек от разработки как железа, так и софта.
В таких постах надо обязательно писать, куда заносить автору.
DenisGrachev Не помешала бы проверка адреса загрузки бейсик программы по системным переменным =)
Но по демо человек говорит дело, а уж относительно 1994 года такие взгляды — реально впереди планеты всей. Triad.