Комментарии 8
Фото из начала статьи весит 604 КБ, примерно в 4,7 раза больше, чем весь объём памяти этой машины 1984 года.
Как мне это развидеть?
двавидеть
то, что здесь описано как "Тайминги CPU", или не совсем верно, или совсем неточно: процессор не тратил треть своего времени на обновление экрана, он этим обновлением вообще не занимался, для того и существовал фрейм графической памяти, чтобы графическая подсистема брала данные оттуда. Видеопотоков в то время еще не существовало, картинка была с точки зрения графической подсистемы достаточно статичной, как минимум покадровое обновление не ожидалось.
На производительность графической подсистемы в первую очередь влияла скорость доступа к микросхемам DRAM: для монохромного режима требовалась частота серизлизации видеопотока порядка 6MHz, доступные DRAM в основном эту частоту не вытягивали, или на пределе. Но эта проблема решалась достаточно просто - сериализацию делали сдвиговым регистром с параллельной записью, сразу 8 бит, соответственно 8x раз падала необходимая частота выборки из DRAM.
На общую производительность тогдашних машинок в первую очередь влияла организация взаимного доступа CPU и графической подсистемы к графической памяти, и вот тут были возможны варианты: с одной стороны, разработчикам приходилось идти на определённые компромисы между производительностью и стоимостью; с другой, не все факторы удавалось учесть и не все архитектурные решения оказывались удачными, у некоторых производительность сильно проседала в сравнении с задуманной. Но, надо думать, в Apple в то время разработкой занимались достаточно опытные люди, чтобы уже учитывать все эти факторы, да и не первый уже продукт они разрабатывали.
Видеопотоков в то время еще не существовало, картинка была с точки зрения графической подсистемы достаточно статичной, как минимум покадровое обновление не ожидалось.
за Apple не скажу, но например в ATARI XL/XE экран обновлялся с частотой 50 Гц PAL и 60 Гц NTSC, так что фактически у вас были гарантированные 50/60 fps от системы. Но конечно занимался этим не ЦПУ, а графический чип, который по прерыванию брал из определенных участков ОЗУ задание на прорисовку - Display List и исходя из этого задания рисовал то, что ему сказали. Если упростить его работу - то просто формировал ТВ сигнал исходя из настроек оборудования и значений в памяти. Так же нужно понимать, что у всего этого был запас по времени, иначе вы просто не смогли бы писать софт и игры, которые нормально выводят картинку.
Вот что можете прочитать про ATARI и его вывод изображения:
Для NTSC скорость была выбрана на основе использования широко распространённого аппаратного компонента, применяемого в телевизионных дисплеях, — кварцевого генератора NTSC. Этот компонент генерирует импульс с частотой 14,31818 МГц. Затем эта частота была разделена на восемь, чтобы получить частоту 1,7897725 МГц, на которой работает 6502. Если один цикл процессора соответствует двум цветным тактовым импульсам, то на одну строку сканирования приходится 114 машинных циклов. 262 строки сканирования в кадре дают 29868 машинных циклов на каждый кадр. При частоте 1,7897725 МГц это означает, что каждую секунду происходит 1789772,5 машинных цикла, что даёт частоту кадров 59,92 Гц, которую можно отобразить на телевизоре (даже если она не совсем совпадает с вещанием NTSC).
Системы PAL используют те же 228 цветовых тактов и 114 машинных циклов на строку, но отображают 312 строк сканирования. Это приводит к 35568 циклам на кадр. Кристалл PAL работает с частотой 14,18757 МГц, которая делится на 8, чтобы получить частоту процессора 1,77344625 МГц, а 35568 циклов на кадр дают частоту 49,86 Гц; опять же, это не совсем совпадает с вещанием в формате PAL, но в пределах допустимых отклонений.
Списки отображения: как Atari генерирует отображение
ANTIC — это специальный сопроцессор, который отвечает за отрисовку экрана в компьютерах Atari. Он тесно связан с процессором 6502 и фактически может рассматриваться как драйвер 6502, поскольку ANTIC может останавливать работу 6502 при необходимости. Поскольку только один чип может считывать данные из памяти в любой момент времени, ANTIC должен останавливать 6502, когда ему требуется доступ к памяти, поэтому из-за прямого доступа к памяти (DMA) инструкции 6502 могут занимать больше тактов, чем указано в документации к 6502. На самом деле, количество времени, которое «крадёт» ANTIC, зависит от многих факторов: графического режима, используемых игроков/ракет, размера игрового поля и многого другого.
Поскольку на одну строку сканирования приходится 228 цветовых тактов и 114 машинных циклов, это означает, что за один машинный цикл на экране отображаются два цветовых такта. Типичная машинная инструкция может занимать 5 машинных циклов, поэтому за время обработки одной инструкции на экране может отображаться 10 цветовых тактов! Это означает, что на одну строку сканирования у нас остаётся не так много времени, поэтому DLI, которые пытаются изменить графику в середине строки, должны быть хорошо оптимизированы.
Это также означает, что 6502-я модель слишком медленная, чтобы самостоятельно рисовать на экране, и здесь на помощь приходит специальный «набор инструкций» ANTIC. Вы программируете сопроцессор ANTIC с помощью списка отображения, и ANTIC берёт на себя построение строки за строкой, не требуя вмешательства со стороны кода 6502-й модели. (Если только вы не попросите о вмешательстве! Вот что такое DLI.)
Список отображения — это специальная последовательность байтов, которую ANTIC интерпретирует как список инструкций. Каждая инструкция заставляет ANTIC отображать определённое количество строк определённым образом. Список отображения можно задать для любой инструкции ANTIC.
ANTIC поддерживает списки отображения, в которых не более 240 строк сканирования (даже в системах PAL, где доступно гораздо больше строк сканирования), а интервал вертикального гашения всегда начинается после 248 строк сканирования. При отрисовке строк сканирования ANTIC пропускает 8 строк в верхней части дисплея, поэтому вывод из списка отображения начинается с 9-й строки сканирования. Стандартный список отображения начинается с 24 пустых строк и 192 строк отображения данных. Это означает, что телевизор увидит 32 пустые строки (8 автоматически пропущенных плюс 24 в стандартном списке отображения), за которыми следуют 192 строки отображения, затем 24 пустые строки и, наконец, вертикальная полоса, которая занимает оставшиеся 14 строк в NTSC (или 64 в PAL).
так и есть, и я об точно об этом: для графики отводился участок памяти на полный кадр (позже его стали называть framebuffer), и графическая подсистема брала оттуда данные для каждого пикселя, а CPU туда обращался только по мере надобности. Просто из статьи можно было было понять что именно CPU занимался отрисовкой и тратил на это треть времени, что в корне не верно.
Вопервых, производительность самой графической подсистемы от CPU никак не зависила, хотя простые реализации работали синхронно, использовали общий clock и не могли легко перестраиваться на режимы с различным разрешением или частотой кадра.
Асинхронные системы уже имели свой clock, но требовали более хитрой блокировки доступа CPU в определённые моменты, чтобы не создавать артефакты кадра. От того, на сколько удачно эта синхронизация решалась, и зависела производительность CPU на конкретных операциях работы с графической памятью, хотя и не влияла на него в остальное время.
Более простые синхронные системы могли использовать свободные такты процессора для обновления видеопамяти, если они там были, от архитектуры зависило, у 8080 например они были всегда, у Z80 вроде бы не обязательно, (про 6502 к сожалению не знаю). Поэтому и графика там и там по разному реализовывалась: более примитивные реализации у всяких домостроевских архитектур реально могли подтормаживать CPU на каждый третий такт без всякой пользы, более умные уже умели этого не делать. Но очень сомнительно что Apple стал бы применять такой домострой для нового продукта.
Просто из статьи можно было было понять что именно CPU занимался отрисовкой и тратил на это треть времени, что в корне не верно.
Для многих систем именно ЦПУ тратил время на генерацию ТВ сигнала. Как конкретно с этим яблоком - не скажу, но такое поведение вполне могло быть. Если судить по статье, то важным было отсутствие мерцания на экране, а значит на заполнение буфера тратилось время и для обеспечения 60 кадров именно ЦПУ его и тратил, так как не было видеочипа, вот цитата из статьи:
Для минимизации мерцания ЭЛТ-экрана Apple стремилась достичь частоты обновления 60 Гц. Это означало, что CPU тратил треть своего времени на отрисовку дисплея. У первого Mac не было отдельного графического процессора, поэтому CPU приходилось тратить время на загрузку упомянутых выше 22 КБ ОЗУ, использовавшихся в качестве буфера дисплея. Схемы обработки видео компьютера считывали эти 22 КБ и отображали их содержимое на экране.
Пока я не вижу противоречий в статье о которых пишете вы. Например в приставке ATARI 2600 выводом изображения занимается сам ЦПУ 6502, а логика игры по жестким таймингам располагается между командами по генерации ТВ сигнала. Если для плавности интерфейса яблоко пошло по этому пути, то нет ничего удивительного что они отдали время ЦПУ на это. Так как это был 1980-ый год, то память стоила очень дорого, например для советского Микро-80 в 1987 году уже не было проблемой сделать логику из кучи микросхем, которая заменяла видеокарту и не трогала основной ЦПУ, там даже память под фреймбуффер была отдельная от ОЗУ.
Статическая картинка рисовалась сама. CPU ничего для этого не делал. Речь тут идет о том, что всю отрисовку - шрифты, окна, итп - делал проц. В других компах того времени, чтобы это ускорить, бывало специализированное железо - спрайты, аппаратный скроллинг, блочные/текстовые режимы. В маке все это не стали делать, в пользу простоты и понятности - комп не про игры, а для интерфейсов плюс-минус хватало.
По поводу таймингов тут возможно имелось ввиду прерывания для опроса перифирии как на ZX Spectrum. И грамотное управление прерыванием действительно давало плавную картинку. Но это предположение.
Почему у первого Macintosh разрешение экрана было 512×342, а не 512×384