Неистово плюсую и не могу не запостить линкрелейтед: NIH, фатальный недостаток.
И ещё. Писал бмп-вьювер для пентевы и могу сказать, что после того, как формат бмп становится ясен из гугления, вьювер пишется на автомате, почти без напряга. Если у кого-то не так…

Среднее кол-во байт кода для выполнения одной и той же задачи, например.
ADD HL,BC, а на 6502 побайтно складывать ячейки в памяти придётся.

Интересно, как ты сравниваешь числа со знаком на Z80… :)

В Z80 флаг P/V — флаг и чётности, и переполнения. После XOR, например, он флаг чётности, а после ADD — переполнения.

На одинаковой тактовой частоте 6502 в большинстве задач уделает Z80. Но в комодоре частота даже меньше мегагерца. Кроме того, плотность кода 6502 меньше, чем Z80. Ну и наконец, всё же сильно универсальность 6502 ограничивают zero-page и очко стека. То есть для дем оно ОК, но для, например, ОС — это серьёзное ограничение.
В популярности с64 огромную, если не подавляющую роль играет VIC. Почти каждый демоэффект, особенно если он работает в 50фпс, это тот или иной изврат с VICом (эксплуатация его глюков, забавностей и недокументированных фич).

Да, сам указатель стека 8-битный, старшая часть адреса всегда $01. В ц64-демах весьма редко встречаются трюки со стеком, я видел только запушивание данных в табличку, которая потом использовалась как, собственно, табличка.

Кстати, прикольно, в схеме апогея (и многих похожих) обошлись без КР580ВК28/38, ценой чему стало отсутствие адр. пр-ва ввода-вывода (все IO-чипы типа ВВ55 в пространстве памяти — ну чем не 6502?) и без КР580ВН59 ценой отсутствия прерываний (это не Z80, где можно влепить IM 1 и знай подавай себе кадровые стробы, надо выдавать на шину аж целую команду CALL xxyy). В специалисте избавились ещё и от КР580ГФ24, который формировал дурацкие тактовые импульсы амплитудой 12 вольт, сделали врукопашную на ЛА8 и пуллапах на 12в.

А вот это демосцена или уже нет?

Для тех, кто в уме не умеет дизасмить :)
(M видимо включает ввод кодов с нулевого адреса RAM)
LD HL,7; адрес строчки с буквами
CALL #F818 ;(пзушечный вызов, наверное, который печатает)
HALT; процессор виснет, ибо прерываний в апогее не предусмотрено
DB «HELLO WORLD!»,0; строка как раз по адресу 7

Код типа такого:
> MOV E,A
> MVI D,0
> LXI H,SINE180
> DAD D
> MOV B,M
(встречается не менее 3 раз)
можно оптимизировать по скорости и одновременно по размеру (мнемоники Z80):
LD H,TABLE/256
LD L,A
LD B,(HL)
Таблицы, ессно, надо выровнять по 256 байт.

А вообще, зачот. Двигать экран в любое место памяти — на спектруме об этом можно только мечтать :)

Прям комодоре 64 какой-то, только советский.

Парсер — лох. Похерил кавычки.
бейсик следует читать как 20 LOAD КавычкаКавычка CODE

В переводе на русский это означает, что все RANDOMIZE USR 15619:REM:LOAD«name»CODE меняются просто на LOAD«name»CODE и всё работает с дивиде.
Самый простой бейсик-лоадер для многочастёвой выглядит вот так:
10 CLEAR 24575
20 LOAD"«CODE 24576:RANDOMIZE USR 24576:GOTO 20
Соотв-но, нужным образом компонуется .tap, а части затачиваются на загрузку и запуск с адреса 24576 и возврат в васик потом. Дивиде (как и эмуляторы, как и пентева, которая тоже тапки быстро грузит с сдкарты) эмулирует тапку ОЧЕНЬ быстро, потому можно период загрузки представлять как короткая (менее секунды) пауза в музыке и обыгрывать это как-то. Вот вроде музыка прервалась на мгновение, так и задумано, а уже другая часть загрузилась и фигачит.

Из статьи может сложиться впечатление, что адреса битмапа, атрибутов и колор рама на комоде зафиксированные. Хотя это не так. Во-1 VIC отображает картинки из любого из 4 кусков памяти по 16к (при этом, ессно, можно в нужной строчке ему переключить этот кусок). В двух из этих 4 кусков в какой-то области всего 16к куска вику видна char ROM, в других 2 кусках везде RAM. Во-2, внутри такого куска битмап размером в 8000 байт может иметь одно из двух положений (+0, +$2000). Атрибуты размером 1000 байт — одно из 16 положений (+0, +$400 и т.д.). А color RAM вообще отдельное адресное пространство, состоит из 1024 нибблов по 4 бита, подключено к вику отдельньной шиной данных (но сидит на общей шине адреса), и вик в него лезет независимо и параллельно от залаза в 64к основную память. Исключительно для процессора color RAM подключается по смещению $d800 (т.е. можно отключить и иметь там свою родную РАМ).

В общем, про комодур можно продолжать бесконечно. Референсная дока на VIC тут: www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt

Также для понимания архитектуры и философии комода можно читать журнал C= Hacking csbruce.com/cbm/hacking/

Замечательное описание всех команд 6510: www.oxyron.de/html/opcodes02.html

Ну и вообще, эмулятор с дебаггером тоже полезная вещь, чтобы понять, как они делают какой-нибудь эффект (именно так, например, я понял, как делать 3D scroll).

ps: и да, самое главное. unbeliever всё врёт. На комоде доступны все 64 килобайта ОЗУ, без 2 байт. А не 37.

Да, го выглядит как эдакий универсальный комбайн — и качать сорцы умеет, и мейкать, и линковать, ну и даже компилировать. И все либы в ехешник пихает. Видимо, гугляры в него напихали все то, чего наелись в обычном рекурсивном make && make install

Вот только машинный код выглядит как gcc -O0 — не особо-то и оптимизированным.

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

Сделал этому бинарнику objdump -dS — оказывается, он 32битный. А 64битный оно умеет? :)

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

Хоть я к ААА отношусь не очень хорошо (и отнюдь не из-за дем, которые он делаетклепает творит), но тем не менее это просто ЗОЧОД — сделать дему вместо комментария. Пусть и запилятором.

В принципе, с такой моделью уже нельзя говорить 'вот мол понаделали эмуляторов в своих ФПГА'. Если появятся Z80 и ВГ93, то уже как минимум пентагон можно сделать НЕэмулятором в ФПГА :)
Для фирменного спектрума ещё и УЛА понадобится отреверсенная.

Так вот, ты же сам говоришь, что по твоему методу видео получается лучше. Вот тут самое место и приложить скриншоты — вот мол, что будет, если просто нажать ctrl-f8 в унреале, а вот так — гораздо лучше, если ещё обработать, а вот так — если накрутить параметры ффмпега сразу в унреале.
Видео для патей (не виртуальных, дихальт, мм) для некоторых работ я делал именно таким методом — ctrl-f8, и ничего, орги плохого слова не сказали.

И да, раз всплыл вопрос сравнения видео в разных браузерах и осях, значит это тоже влияет на качество видео, в каком оно доходит с ютуба до пользователя, и тоже должно как-то отражаться. Например, вот так видео лучше делается для просмотра под виндой, а вот так — под планшет с разрешением 2560х1600, и т.д. Не делать же ВСЕГДА видео в 4к, чтобы пиксели были почётче?

Отвечаю сразу на оба комментария.
1. В статье и вправду никаких скриншотов, никаких примеров видео, кроме демы с апогея, что же тебя удивляет?
2. В предыдущем комменте 2 картинки, на одной вообще только менюшка выбора битрейта/разрешения, без самого видео. Что сравнивать — количество пунктов в меню?
3. Вот скриншот видео: i.steppic.com/8/d/2/d/8d2ddf64b92d00c4d6daf7fac273efa6/0.png
Предлагаю тебе сделать так же, ну или хотя бы выложить ссылки на свои видео, и добавить в статью, как правильно, а как неправильно. Меня вполне устраивает то, что по ссылке.