Войти
ФлеймФорумЖелезо

Блеск и нищета 8/16-битных консолей и ПК (28 стр)

Страницы: 127 28 29 3046 Следующая »
#405
(Правка: 15:35) 15:30, 9 ноя. 2018

=A=L=X=
> Но конкретно водопад реализован простой подменой палитры - в цикле крутятся
> четыре цвета, сами тайлы водопада остаются неизменными.
> Последняя страница постоянно подменяется в цикле образуя анимацию таких вещей
> как воды и прочих анимированных тайлов фона, поэтому там многоплановая вода.
Дa, это заметно.
Но почему тогда анимация в Феликсе выглядит как-то примитивно, против Скруджа?
McDuck vs Felix | Блеск и нищета 8/16-битных консолей и ПК
Даже наша мама, далёкая от приставочного фана, 20 лет назад посмотрела на экран и сказала, что «кот как-то примитивно смотрится»…

Правда нужно ещё учитывать то, что создатели игры Феликс подгоняли его под стиль мультфильма-оригинала наверное, чтобы соответствовало всё…
А Феликс - много старее Скруджа, как бы странно каламбуром это ни звучало… :-)
Да и музыкальная однотипная тема «пу-пу-пу» из уровня в уровень у Феликса родителей раздражала…

P.S.: К родителям стоит прислушиваться как к критикам: Доживём до их лет, увидим фильмы и игры детства в других тонах…
Это - неизбежно.


#406
5:15, 10 ноя. 2018

gmake

Вот не понял о чём спойлеры - обычный вполне обзор на ретро.
Сам я соглашусь на 200% с обзорщиком - робокоп на спектруме внушал мощное чувство уважения металлической громадине и являлся одной из редких игр, которую можно было пройти.
Сам рассыпаюсь в комплиментах.

0iStalker

Программист на Ruby сталкивается с асмом 6502 :D. Я прям прослезился.

#407
5:16, 10 ноя. 2018

Alikberov
> Но почему тогда анимация в Феликсе выглядит как-то примитивно, против Скруджа?

Имхо у феликса крупнее спрайты и потому в разы меньше анимаций влезает в страницу PPU.
Но есть так же фактор прямых рук создателей игры.

#408
15:52, 10 ноя. 2018

Скачать можно тут: http://www.retrosouls.net/

Грамотное применение мультиколора создаёт вообще впечатление не-спектрума. Но это спектрум! Игрулька - огонь. Пробовал на эмуляторе.

#409
(Правка: 21:44) 20:16, 10 ноя. 2018

=A=L=X=
Скачивaл как-то NES-инструментарий, но не одолел, что даже стыдно…
С другой стороны, не даром бытовало «чем проще микро-ЭВМ, тем больше о ней должен знать потребитель»…
Но как-нибудь нужно будет сделать какую-нибудь фигню…

Была идея сделать «детектор привидений», который 15 лет назад я написал под свой Pentium…
Хотел портировать на Денди, так как схемотехника там простая, лишь две микросхемы подключить.
Но руки не дошли…

+ Идейки
#410
(Правка: 12:43) 4:02, 12 ноя. 2018

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

Если у вас был ZX Spectrum, то даже без навыков программирования графики в ассемблере вы постоянно должны были замечать странную вещь при загрузке игр с магнитофона — линейная заливка видеопамяти данными визуально выглядела нелинейно:

Изображение

Графическое разрешение спектрума — 256x192 пикселей. Визуально экран как бы поделен на три части — так называемые "трети экрана" каждая из которых состоит из восьми строк символов, 32 символа 8x8 пикселей в строке. Строка пикселей описывается 32 байтами монохромного изображения (8 пикселей на байт) идущих в памяти линейно, но вот строки чередуются весьма замысловатым образом. Данные о цвете (таблица атрибутов) хранятся сразу после данных пикселей, являются квадратным массивом 32x24 байт и применяются к блокам 8x8 пикселей по сути описывая какой цвет будет у всех нулевых и какой цвет будет у всех единичных пикселей данного блока (символа), что было продуманным компромиссом между потреблением памяти и графико/цветовыми возможностями компьютера, порождая однако сильную головную боль у всех кто хотел выйти за рамки вывода текста и выводить графические данные в цвете. Но это отдельная песня.

Здесь же мы исследуем вопрос о том почему строки изображения идут в видеопамяти таким странным образом. Вопрос этот мучал меня с детства, но ответ на него я нашёл только вчера.
Если бы видепамять в спектруме была бы линейной, то 16–битный адрес каждого её байта (описывающего горизонтальную полоску из 8 пикселей) имел бы следующую битовую маску:

010yyyyy yyyxxxxx

Здесь биты X (от 0 до 32) — это номер полоски в строке, а биты Y (от 0 до 191) — номер строки. Но в спектруме три нижних бита верхнего байта адреса поменяны местами с верхними тремя битами нижнего байта адреса:

010ttwww yyyxxxxx

При этом получается, что биты X по прежнему описывают номер байта в строке, но у других бит возникает новый специфический смысл.
Биты T (от 0 до 2) определяют треть экрана, биты Y (от 0 до 7) — вертикальную позицию знакоместа в этой трети, а биты W (от 0 до 7) вертикальную полоску пикселей внутри знакоместа. В силу такой раскладки заливка видеопамяти и выглядит как на гифке выше.
Так зачем же так сделано?

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

Как ни странно, но для объяснения такого положения вещей придётся вспомнить ключевые особенности динамического ОЗУ или DRAM. ОЗУ реализованное на транзисторах по схеме триггера называется статическим — Static RAM (SRAM) и по природе своей сохраняет информацию до тех пор пока к нему подводится ток. Но оно дорогое и применяется в современных компьютерах в основном в роли кэша процессора. Основное же ОЗУ реализовано как динамическое Dynamic RAM (DRAM) — в нём биты хранятся в виде зарядов микроскопических конденсаторов и эти конденсаторы постоянно "утекают" и теряют заряд, поэтому периодически их надо обновлять в процессе называемом регенерацией. Периодически надо считывать или записывать ячейку памяти — при этом её содержимое в конденсаторе обновляется и начинает "утекать" снова. Обновлять память надо довольно быстро, но обновляются не отдельные биты или байты, а большие блоки называемые "строками" в которых отдельные байты представлены как "столбцы". У чипа памяти сперва запрашивается строка — при этом он извлекает её во внутренний буфер–защёлку всю за раз, а потом опрашивается столбец — и вот здесь уже нужный байт выдаётся наружу. И в этот же момент происходит обновление всей строки из защёлки — происходит регенерация этой строки. Адресные линии памяти спектрума разведены таким образом, что нижние (именно нижние) 7 бит адреса являются номером строки в чипах памяти, а верхние 9 бит выступают в роли столбца (правда после разброски по нескольким чипам).

И вот здесь возникает интересный момент — эти чипы имеют функцию ускорения доступа к памяти — так называемый page mode. Когда адрес строки уже выставлен и строка считана в защёлку, то повторные обращения к столбцам можно делать без выставления строки — экономится время как на выставление адреса строки, так и на считывание самой строки в защёлку.

Когда видеочип спектрума выводит очередную полоску пикселей ему нужно считать два байта — саму полоску из пиксельных данных и её цвета из таблицы атрибутов.

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

Более того, если адрес полоски пикселей имеет битовое представление 010ttwww yyyxxxxx, то адрес его атрибутов равен 010110tt yyyxxxxx — то есть просто откидывается компонента www и некоторые биты преставляются местами с полным сохранением нижнего байта адреса. Это позволяет видеоконтроллеру при отрисовке видеопамяти воспользоваться ускоренным режимом считывания с сохранением адреса строки и считывать пиксели и их атрибуты за 170 нс вместо 320 нс которые нужно было бы тратить на считывание двух байт из разных страниц. И это было важно для инженеров, потому что процессор и видеочип конкурировали за одну и ту же память, приоритет отдавался видеочипу и процессор вынужден был ждать если хотел работать с ней в тот же момент когда видеочип производит отрисовку.

Вот почему у ZX Spectrum такая странная раскладка видеопамяти.

Перед тем как оформил в статью комментарий выглядел так:

Наконец то я нашёл причину по которой у спектрума была такая нелинейная структура видепамяти: http://hype.retroscene.org/blog/889.html (эта тема там создана мной же)
Хаха! Все наши рассуждения здесь на эту тему оказались неправильными.

http://www.zxdesign.info/harlequinDRAM.shtml
Поясню для тех кому некогда читать это вкратце. Сперва напомню как работает DRAM — этот дешевый вариант памяти требует периодического обновления своего содержимого — во времена спектрума для этого некий внешний чип должен был инициировать чтение (или запись) памяти. Но не каждой ячейки, а каждой страницы памяти — память состояла из страниц довольно большого объёма. По факту при чтении (и записи) байта из заданного адреса чип DRAM извлекал во временный буфер содержимое целой страницы памяти, брал из него нужный байт и перезаписывал/обновлял содержимое всей страницы. При этом важно заметить, что селектор страницы в микросхемах применяемых в памяти спектрума содержался в нижнем байте адреса, а селектор байта внутри страницы — в верхнем (даже в семи битах, но неважно).
Это и является ключём к режиму page mode — залочив память на чтение с адреса можно было получив результат не снимать лок, а требовать отдать еще один байт, при условии что он лежит внутри той же страницы памяти — пока она удерживалась во временном буфере можно было значительно сэкономить на операции чтения.
А далее — магия — организация видеопамяти спектрума такова, что у адресов битового паттерна знакоместа и его атрибута один и тот же нижний байт адреса!
Этим и пользовался ULA (видеочипная составляющая) спектрума, чтобы читать и битовый паттерн и его цвет в один присест за 170нс вместо полагающихся 320нс на чтение двух разрозненных байт из памяти.
То, что раскладка получилась удобной для текстового вывода являлось логичным следствием этой оптимизации, но не причиной всего этого безобразия. Сама причина — скорость извлечения памяти.
Вот такие дела. Всем спасибо, я бурно кончил.

#411
(Правка: 9:10) 9:04, 12 ноя. 2018

=A=L=X=
> Этим и пользовался ULA (видеочипная составляющая) спектрума, чтобы читать и
> битовый паттерн и его цвет в один присест за 170нс вместо полагающихся 320нс на
> чтение двух разрозненных байт из памяти.

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

https://www.silicon-ark.co.uk/datasheets/tms4464-datasheet-texas-… struments.pdf

Изображение

И спектрумовская ULA, как и полагается вычитывает байт аттрибутов и байт пикселей в 2 приёма
Нужно учитывать, что у оной оперативки нет халявного линейного адреса, а нужный байт выбирается указанием строки/столбца  (сигналы RAS/CAS, один из них дот-клок, другой его инверсия -получается сдвиг на 1/2 такта дот/клока).  Из-за чего , собственно, в моделях 16/48 - есть медленная/быстрая память для доступа процессора.

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

Вот, для иллюстрации, из симуляции спектрума из моего виртуального клона. Ну, правда, тут используется статическая память (но по сигналу CLK7 можно прикинуть моменты выбора строки/адреса если бы была DRAM) и прозрачный доступ к видеопамяти без торможения CPU, но растеризатор почти аналогичен арлекиновскому (там даже те же самые регистры/мультиплексоры).

Изображение


Вкратце, на что тут смотреть,  -

Дотклок (CLK7) равен удвоенной тактовой частоте, и прерывать процесс вывода пикселей на экран вообще никак нельзя, поэтому в схеме спектрума есть 2 регистра, - один защёлка, для хранения аттрибутов, другой сдвиговый - для рендеринга очередного пикселя - т.е. каждый такт дотклока происходит right shift содержимого и подача на выход младшего разряда, - потом хитрым образом содержимое этого разряда и выходов буфера аттрибутов замешивается на мультиплексоре и формируется RGB сигнал.  Во всём этом важно то, что  на каждые 8 пикселей обращение к памяти происходит ровно 2 раза (а установка адреса DRAM 4 раза).  Итак, - при лог. 0 на сигнале Vacc (разрешение доступа видеоадаптеру) формируется адрес ячейки памяти, при лог. 1 на сигнале S0  на выходе ОЗУ появляется байт аттрибутов и сохраняется в защёлке аттрибутов, на следующем лог. 0 на Vacc формируется адрес для байта пикселей и на лог. 1. для сигнала S1 байт пикселей с ОЗУ записывается в сдвиговый регистр, - одновременно лог. 1 появляется на сигнале VidEnable и мультиплексоры на которые подаются аттрибуты/пиксели начинают выдавать в виде RGB содержимое видеопамяти (а когда VidEnable  в состоянии лог. 0 - они выдают в виде RGB содержимое защёлки в которой хранится цвет бордюра).

Ну, и собственно, никак нельзя с 8 битной шины прочитать в один присест 2 байта.  Ну да, по идее, можно сэкономить одну выборку строки DRAM, но это ничего не даст, кроме усложения схемы ради экономии 1/2 такта дотклока, да и кусок схемы, который линейный адрес разбивает на 2 части - он общий и для видеоконтроллера и для CPU

#412
9:07, 12 ноя. 2018

=A=L=X=
> Наконец то я нашёл причину по которой у спектрума была такая нелинейная
> структура видепамяти:

да, помню эту байду - тоже не мог понять как так можно было сделать :)
на ровном месте попоболь
помогло только табличка от Pete Cook :)

#413
(Правка: 10:26) 10:14, 12 ноя. 2018

0iStalker
> там обычная DRAM память, без магической выборки из той же строки.

Нет, смотри в середину списка фич - данная описана там и называется PAGE-MODE OPERATION FOR FASTER ACCESS
Это вот оно.

> только лишь из-за совмещения видеоконтроллером функций рефреша оперативки

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

Вот еще по второй ссылке маппинг памяти из знакоместа в атрибуты:

Изображение

Вот она магия - просто выкидывается кусок бит и адрес атрибута готов. Готовенький на выданье сразу с тех же линий адреса, просто извлекай, причём не меняя как раз адрес страницы извлекай вдвое быстрее.
Вообще по ссылке это всё пишет создатель хардварного клона.
case closed

#414
(Правка: 10:41) 10:35, 12 ноя. 2018

=A=L=X=
> Это вот оно.

Ну да, это оно,... 1 RAS и 2 CAS подряд.  И откуда там 170нс? Я насчитал  280, - 2 такта CLK7  (1/10^6 = 142,85*10-7).

>[b]=A=L=X=[/b]
> Вот она магия - просто выкидывается кусок бит и адрес атрибута готов.

А для этой магии вообще пофиг смещение, оно через мультиплексор делается, просто переключаются нужные входы на нужные выходы. На моей диаграмме это сигнал S2

#415
(Правка: 10:58) 10:40, 12 ноя. 2018

0iStalker

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

> И откуда там 170нс?

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

P.S.

Ну да, на вики почитал про DRAM - всё верно, когда строка считывается она вся считывается в защёлку (latch) и в дальнейшем выборка по столбцу считывает данные уже из защёлки, исключается не просто выставление адреса страницы, но и само считывание страницы.

#416
12:17, 12 ноя. 2018

Да, теперь уже доходит, что видимо и сам дизайн маппинга памяти когда страницы заметены в нижние биты адреса было сделано для этой же логики.
Вообще забавно, т.к. такая память (называемая PM-DRAM от Page Mode) была весьма популярна в те годы, то видимо этот дизайн можно найти еще много где.
Вероятно это одна из причин почему любили делать видеорежимы, где цвета были разделены по разным bit plane-ам. С одной стороны можно по разным микросхемам разбросать, а с другой стороны - через page mode хапать с повышенной скоростью.

#417
12:32, 12 ноя. 2018

=A=L=X=
> Вообще забавно, т.к. такая память (называемая PM-DRAM от Page Mode) была весьма
> популярна в те годы, то видимо этот дизайн можно найти еще много где.
На самом деле, выглядит как просто ещё одно кэширование.

#418
12:46, 12 ноя. 2018

Delfigamer
> На самом деле, выглядит как просто ещё одно кэширование.

Ну это технология DRAM-памяти, весьма просто вытекающая из её принципов, и её называют page mode, но если даже википедию читать, то там иногда проскакивает, что "...теперь строка закеширована...", да. Это когда она попала в защёлку.

8<-------------

Оформил комментарий в статью.

#419
13:57, 12 ноя. 2018

Забыли… :-))

Страницы: 127 28 29 3046 Следующая »
ФлеймФорумЖелезо