Немного не в тему, но интересно: является ли, например, формат pt3 оптимальным для компрессии AY-потока?
Чем проверить? (У каких компрессоров нет ограничения на длину файла? =)
Какие-то невозможные демы, да еще и девять штук. Очень хотелось бы обзор почитать с технической составляющей. Да и помимо технической были стилистические прорывы.
GABBA — это просто нечто.
Давно так сильно от демы не вставляло!
Вот за это я и люблю демосцену — за такой отрыв, за такой расколбас!
С первых секунд становится ясно что сейчас что-то будет интересное, а потом — просто взрыв эмоций :)
это нечто! sq, diver, n1ko — спасибо!
Вот это — настоящий дух демосцены!
Я еще демо не смотрел, выходные выдались непростые. Посмотрю — отпишусь где-нибудь кратенько.
Сам факт, что дем девять штук — это очень круто. В графике было на что посмотреть, некоторые работы — моё почтение. Музыку слушал еще не всю, но то, что слышал, было просто отличным.
P.S.
Причесал код и внедрил условия и сделал все ключевые слова в нижнем регистре для консистентности. Ссылка на исходник потому изменилась: yadi.sk/d/fTZqZ1n12dD72A
Условия пишутся в любом месте инструкции:
@@ — всегда
@z или @nz — ноль/не ноль
@c @nc — перенос
@gt @gte — больше и больше-или-равно (пока не реализовано)
теперь работает такое:
r0 = $8
loop [ counter ] =-1 [ counter ]
r0 =-1 r0
pc = loop @nz // эта инструкция перейдёт на loop если не ноль
dw 0
org $0030
counter dw $0010
Проапгрейдил ассемблер Simpleton еще дальше, теперь программа берет внешний файл source.asm, собирает и исполняет его с адреса 0 пока не наткнётся на инструкцию с кодом 0 (R0 = R0).
Теперь поддерживаются ключевые слова =, org и dw с нюансами.
Программа теперь может выглядеть так:
R0 = $FFFF
R1 = $CCCC
R0 -= R1
[ first ] = R0
[ second ] =+1 [ first ]
[ third ] += 16
dw 0 // DEF WORD 0 помещает в текущую ячейку компиляции константу
org $0020 // компилируем теперь начиная с адреса $0020
first dw 0 // first и second теперь заданы
second dw 0 // как два нулевых слова в памяти
org $0030 // смещаем адрес компиляции в $0030
third dw forth // пример что в качестве DEF WORD слова можно указать символ, причём forward
forth = $1000 // через = значение символа задаётся напрямую без записи данных в память
dw 1 // эта единица в памяти программы следует сразу за $1000 (third)
Основные моменты — регистрозависимость всех идентификаторов и ключевых слов.
Имена регистров: R0-R4, R5 (он же SP), R6 (он же PC), R7 (он же FLAGS).
Машинные команды имеют вид
DEST OP SRC
Где SRC это один из регистров, константа/символ или адрес задаваемый как регистр или константа/символ в квадратных скобках.
OP это операторы в стиле Си:
= присваивание
=+1 инкремент
=-1 декремент
<?> сравнение
+=
-=
+c= то же что и += с учетом флага переноса
-c= то же что и -= с учетом флага переноса
DEST может быть всем тем же что и SRC кроме константы/символа (не в квадратных скобках)
Числовые константы/литералы или десятичные или начинаются с $ и тогда являются шестнадцатеричными.
Если строка начинается не с пробельного символа, то создаётся символ.
Если он предшествует машинной инструкции или dw, то в него записывается её адрес.
Если он предшествует знаку =, то в него записывается константа или значение символа по правую часть от знака. Формульная математика пока не поддерживается вообще.
Если он предшествует ключевому слову org, то он будет равнятся адресу куда переводит компиляцию этот org.
org переводит запись генерируемых инструкций на указанный адрес (origin)
dw прописывает в текущую ячейку данное — оно может быть или константой или символом.
В стиле ассемблера Zilog 80 (и не в стиле ассемблера Intel) имя символа в чистом виде означает адрес ячейки памяти если это метка, а не значение в этой памяти. Чтобы адресовать ячейку надо использовать квадратные скобки.
Т.е.
some_addr = $1000
R0 = some_addr // в R0 запишется $1000
R0 = [ some_addr ] // в R0 запишется значение в ячейке с адресом $1000
some_addr = R0 // такое вообще запрещено, т.к. в констансту нельзя писать, надо:
[ some_addr ] = R0 // а вот это запишет R0 в ячейку памяти
Чтобы проверить архитектуру на практике, пусть и виртуальной, решил написать то что доступно — эмулятор машины Simpleton 3.x, текущий исходник, если вдруг кому интересно, что конечно вряд ли, можно качнуть тут: yadi.sk/d/-PGx1pEBf_O6kw
Сейчас довёл его до уже нормально исполняющего простые инструкции ассемблера, так вот такой код на C++:
m.parseStart();
int line = 0;
m.parseLine( line++, "start R0 = $FFFF" ); // в R0 грузим константу $FFFF
m.parseLine( line++, " R1 = $CCCC" ); // в R1 грузим константу $CCCC
m.parseLine( line++, " R0 -= R1" ); // из R0 вычитаем R1 и заносим результат в R0
m.parseLine( line++, " [ first ] = R0" ); // в ячейку памяти по адресу first заносим R0
m.parseLine( line++, " [ second ] =+1 [ first ]" ); // в ячейку памяти по адресу second заносим инкремент ячейки first
m.parseLine( line++, " R0 = R0" ); // NOP и ноль - эмулятор останавливается на команде NOP
m.parseLine( line++, "first R0 = R0" ); // метка first ячейки с данными 0
m.parseLine( line++, "second R0 = R0" ); // метка second ячейки с данными тоже 0 (DW пока не делал)
m.parseEnd();
m.show();
while ( m.mem[ m.reg[ REG_PC ] ] != 0 ) // nop as stop
m.step();
m.show();
генерирует и исполняет следующий очищенный от C++ код на ассемблере Simpleton 3.x:
start R0 = $FFFF // в R0 грузим константу $FFFF
R1 = $CCCC // в R1 грузим константу $CCCC
R0 -= R1 // из R0 вычитаем R1 и заносим результат в R0
[ first ] = R0 // в ячейку памяти по адресу first заносим R0
[ second ] =+1 [ first ] // в ячейку памяти по адресу second заносим инкремент ячейки first
R0 = R0 // NOP и ноль - эмулятор останавливается на команде NOP
first R0 = R0 // метка first ячейки с данными 0
second R0 = R0 // метка second ячейки с данными тоже 0 (DW пока не делал)
Как видно синтаксис этого ассемблера строго подчиняется С-подобному обозначенному в статье синтаксису.
Код сей собирается, успешно исполняется и даёт после выполнения всех команд такую карту регистров и памяти:
Здесь видно что PC дошёл до 000A и остановился — это где первый искуственный NOP (R0 = R0) — check.
В R0 разница между FFFF и CCCC = 3333 — check.
В R1 — CCCC — check.
По адресу 000B хранится 3333 — это метка first — check.
По следующему адресу — метке second хранится увеличенное на 1 значение в first — 3334 — check!
Можно посмотреть в коды инструкций — адреса (а это между прочим forward reference для которых надо было запоминать адреса которые надо поправить после конца парсинга) 000B и 000C явно видно в ячейках с инструкциями по адресам 0006 и 0008-0009.
Забавное ощущение когда свой ассемблер делаешь виртуальной несуществующей машины. :D
Парсер и генератор кода конечно примитивный — лишь бы откровенных ошибок с подстановкой совсем уж неверных типов лексем не на свои места не было. Например косвенная адресация просто как флаг взводится и сбрасывается при встрече символов [ и ] поэтому такой код будет валидным: [ R0 = R1 ] и эквивалентен [ R0 ] = [ R1 ] (строго говоря валидно и [ R0 = R1
Но тем не менее в мнемониках кодировать весьма удобно становится. :)
Когда еще будет время реализую условия и попробую делать циклы.
byuu конечно расстроится, узнав, что он так и не смог понять SA-1.
Вообще забавно заявление, что исправлена игра, хотя она просто запущена на более быстром процессоре, да и весь разговор по сути про SA-1. А ведь можно было бы заморочиться и реально оптимизировать код, чтобы игра перестала тормозить без привлечения дополнительного процессора. Во множестве игр на SNES основные тормоза из-за очень своеобразной организации списка спрайтов (биты координат разбросаны). Если писать в лоб, получается множество сдвигов и битовых операций. Помогает держать в памяти список спрайтов в более удобном формате, а блок для OAM формировать один раз в конце кадра развёрнутым циклом. В Gradius не смотрел, но скорее всего эта проблема присутствует и там.
Чем проверить? (У каких компрессоров нет ограничения на длину файла? =)
Давно так сильно от демы не вставляло!
Вот за это я и люблю демосцену — за такой отрыв, за такой расколбас!
С первых секунд становится ясно что сейчас что-то будет интересное, а потом — просто взрыв эмоций :)
это нечто! sq, diver, n1ko — спасибо!
Вот это — настоящий дух демосцены!
Сам факт, что дем девять штук — это очень круто. В графике было на что посмотреть, некоторые работы — моё почтение. Музыку слушал еще не всю, но то, что слышал, было просто отличным.
Но вот бы 7/9 под кат спрятать =)
Причесал код и внедрил условия и сделал все ключевые слова в нижнем регистре для консистентности. Ссылка на исходник потому изменилась: yadi.sk/d/fTZqZ1n12dD72A
Условия пишутся в любом месте инструкции:
@@ — всегда
@z или @nz — ноль/не ноль
@c @nc — перенос
@gt @gte — больше и больше-или-равно (пока не реализовано)
теперь работает такое:
Теперь поддерживаются ключевые слова =, org и dw с нюансами.
Программа теперь может выглядеть так:
Основные моменты — регистрозависимость всех идентификаторов и ключевых слов.
Имена регистров: R0-R4, R5 (он же SP), R6 (он же PC), R7 (он же FLAGS).
Машинные команды имеют вид
Где SRC это один из регистров, константа/символ или адрес задаваемый как регистр или константа/символ в квадратных скобках.
OP это операторы в стиле Си:
= присваивание
=+1 инкремент
=-1 декремент
<?> сравнение
+=
-=
+c= то же что и += с учетом флага переноса
-c= то же что и -= с учетом флага переноса
DEST может быть всем тем же что и SRC кроме константы/символа (не в квадратных скобках)
Числовые константы/литералы или десятичные или начинаются с $ и тогда являются шестнадцатеричными.
Если строка начинается не с пробельного символа, то создаётся символ.
Если он предшествует машинной инструкции или dw, то в него записывается её адрес.
Если он предшествует знаку =, то в него записывается константа или значение символа по правую часть от знака. Формульная математика пока не поддерживается вообще.
Если он предшествует ключевому слову org, то он будет равнятся адресу куда переводит компиляцию этот org.
org переводит запись генерируемых инструкций на указанный адрес (origin)
dw прописывает в текущую ячейку данное — оно может быть или константой или символом.
В стиле ассемблера Zilog 80 (и не в стиле ассемблера Intel) имя символа в чистом виде означает адрес ячейки памяти если это метка, а не значение в этой памяти. Чтобы адресовать ячейку надо использовать квадратные скобки.
Т.е.
Сейчас довёл его до уже нормально исполняющего простые инструкции ассемблера, так вот такой код на C++:
генерирует и исполняет следующий очищенный от C++ код на ассемблере Simpleton 3.x:
Как видно синтаксис этого ассемблера строго подчиняется С-подобному обозначенному в статье синтаксису.
Код сей собирается, успешно исполняется и даёт после выполнения всех команд такую карту регистров и памяти:
Здесь видно что PC дошёл до 000A и остановился — это где первый искуственный NOP (R0 = R0) — check.
В R0 разница между FFFF и CCCC = 3333 — check.
В R1 — CCCC — check.
По адресу 000B хранится 3333 — это метка first — check.
По следующему адресу — метке second хранится увеличенное на 1 значение в first — 3334 — check!
Можно посмотреть в коды инструкций — адреса (а это между прочим forward reference для которых надо было запоминать адреса которые надо поправить после конца парсинга) 000B и 000C явно видно в ячейках с инструкциями по адресам 0006 и 0008-0009.
Забавное ощущение когда свой ассемблер делаешь виртуальной несуществующей машины. :D
Парсер и генератор кода конечно примитивный — лишь бы откровенных ошибок с подстановкой совсем уж неверных типов лексем не на свои места не было. Например косвенная адресация просто как флаг взводится и сбрасывается при встрече символов [ и ] поэтому такой код будет валидным: [ R0 = R1 ] и эквивалентен [ R0 ] = [ R1 ] (строго говоря валидно и [ R0 = R1
Но тем не менее в мнемониках кодировать весьма удобно становится. :)
Когда еще будет время реализую условия и попробую делать циклы.
Вообще забавно заявление, что исправлена игра, хотя она просто запущена на более быстром процессоре, да и весь разговор по сути про SA-1. А ведь можно было бы заморочиться и реально оптимизировать код, чтобы игра перестала тормозить без привлечения дополнительного процессора. Во множестве игр на SNES основные тормоза из-за очень своеобразной организации списка спрайтов (биты координат разбросаны). Если писать в лоб, получается множество сдвигов и битовых операций. Помогает держать в памяти список спрайтов в более удобном формате, а блок для OAM формировать один раз в конце кадра развёрнутым циклом. В Gradius не смотрел, но скорее всего эта проблема присутствует и там.