Звук не синхронизирован, но полная длительность на 4016 с 32 килобайтами: www.youtube.com/watch?v=XVMzaITzXPM
Также есть сообщения о запуске на 2001 N32K, и кусочек видео на FB — однако, демо идёт там без снега, который я ожидал увидеть.
Очень крутая работа, дневники разработки всегда интересно читать. Единственное пожелание — начинай на три дня раньше чтобы следующий раз приехать на пати :))
> Сразу же после релиза демо проверено на железе, полёт нормальный.
Во, это радует. Было бы классно, если бы человек, который проверял, выложил бы видео на youtube. Увидеть работу на живом железе, пусть и в записи, несопоставимо интереснее, чем на PC. Даже с мерцанием и прочим.
P.S. К слову, как мне кажется, в случае утечки в такой вот ситуации, орги бы пошли навстречу и не посчитали бы это нарушением правил.
Да, это ценный комментарий. Дело в том, что я проворачиваю этот трюк (написание большого проекта без тестов на железе) не в первый и не в десятый раз, на самых разных платформах, уже очень много лет. У меня есть решения, которые были ранее проверены на железе, и если я не выхожу за их рамки, это даёт 99% уверенности, что всё заработает. А если всё же срабатывает неудачный процент — то это абсолютно точно можно исправить. В данном случае я изначально решил не использовать никаких трюков с перепрограммированием видеоконтроллера (народ недавно умудрился одним безумным трюком выжать больше одной градации яркости). В данной демке всюду просто перекладывание байт из одного места в другое, оно никак не может не заработать. Что могло не заработать: звук, но эту часть я отладил пару лет назад, и она была протестирована на железе (благодаря этому в свежих эмуляторах правильный звук, ранее он всюду эмулировался некорректно, что продемонстрировали мои поделки). Ещё могло не заработать: время доступа к видеопамяти, но это также было проверено моим предыдущим релизом для PET. В общем, это был хорошо осознанный и контролируемый риск, на большом опыте.
Конечно, я всё равно нервничал насчёт того возможного процента, мало ли что, железо древнее, плохо эмулируемое и с труднодоступной документацией. Правила запрещают публиковать работы до пати, и я не мог рисковать случайной утечкой, хотя мне было кого попросить провести тест. Сразу же после релиза демо проверено на железе, полёт нормальный.
Как по мне, лучшая работа на этом party. Да и вообще очень высокий уровень, не только в плане кода.
Единственное — не очень понимаю, почему выбрана платформа, которая недоступна живьём. Насколько я понял из статьи, ты не проверял, работает ли эта демка на компьютере, для которого написана. Это, вообще говоря, стрёмный момент. Представь, если работа занявшая первое место в oldskool, на самом деле работает только на современном PC (надеюсь, что это не так, конечно).
Возможно стоит в самом верху написать по-русски, что перевод ниже. Или оформить перевод отдельным постом. Потому что сейчас те, кто не знают английского посчитают, что перевода в посте нет.
В онлайн-эмуляторе aa-dav.github.io/ доступен новый исходник «bitmap noise» — выбираем пункт и нажимаем «Compile and Run».
После выполнения инициализирующего кода в simple_lib.inc раскладка памяти следующая:
С адреса $8000 располагаются 16384 _слов_ (ячейки памяти 16-битные) описывающие 16-цветный битмап 256x256 (на экране без записи в регистры скроллинга видны верхние 192 строки). Т.к. ячейки — слова, то в каждое слово влезает четыре пикселя по 4 бита цветности на каждый. Раскладка линейная.
Но еще с адреса $C000 располагается зона атрибутов размером 32x32 знакоместа. Атрибут имеет маску PPPP00NN NNNNNNNN, где N это номер выводимого знакоместа в соответствующей квадратной сетке, а PPPP — верхние биты палитры из 256 цветов которые будут добавляться к цветам пикселя. Т.е. номер субпалитры в 16 слотов из 16 субпалитр. Чтобы записать в палитру надо записать в ячейку/порт $FFF6 номер слота палитры (0..255), а в $FFF7 RGB-значение в формате 0RRRRRGGGGGBBBBB.
Таким образом на экране может быть одновременно 256 цветов, но не более чем 16 цветов в знакоместе.
Более того — отображение в знакоместах можно перенастраивать на другие знакоместа через таблицу атрибутов реализуя быстро работающие текстовые видеорежимы ну или игровое тайловое поле с аппаратным скроллингом.
Также есть сообщения о запуске на 2001 N32K, и кусочек видео на FB — однако, демо идёт там без снега, который я ожидал увидеть.
Во, это радует. Было бы классно, если бы человек, который проверял, выложил бы видео на youtube. Увидеть работу на живом железе, пусть и в записи, несопоставимо интереснее, чем на PC. Даже с мерцанием и прочим.
P.S. К слову, как мне кажется, в случае утечки в такой вот ситуации, орги бы пошли навстречу и не посчитали бы это нарушением правил.
Да, это ценный комментарий. Дело в том, что я проворачиваю этот трюк (написание большого проекта без тестов на железе) не в первый и не в десятый раз, на самых разных платформах, уже очень много лет. У меня есть решения, которые были ранее проверены на железе, и если я не выхожу за их рамки, это даёт 99% уверенности, что всё заработает. А если всё же срабатывает неудачный процент — то это абсолютно точно можно исправить. В данном случае я изначально решил не использовать никаких трюков с перепрограммированием видеоконтроллера (народ недавно умудрился одним безумным трюком выжать больше одной градации яркости). В данной демке всюду просто перекладывание байт из одного места в другое, оно никак не может не заработать. Что могло не заработать: звук, но эту часть я отладил пару лет назад, и она была протестирована на железе (благодаря этому в свежих эмуляторах правильный звук, ранее он всюду эмулировался некорректно, что продемонстрировали мои поделки). Ещё могло не заработать: время доступа к видеопамяти, но это также было проверено моим предыдущим релизом для PET. В общем, это был хорошо осознанный и контролируемый риск, на большом опыте.
Конечно, я всё равно нервничал насчёт того возможного процента, мало ли что, железо древнее, плохо эмулируемое и с труднодоступной документацией. Правила запрещают публиковать работы до пати, и я не мог рисковать случайной утечкой, хотя мне было кого попросить провести тест. Сразу же после релиза демо проверено на железе, полёт нормальный.
Единственное — не очень понимаю, почему выбрана платформа, которая недоступна живьём. Насколько я понял из статьи, ты не проверял, работает ли эта демка на компьютере, для которого написана. Это, вообще говоря, стрёмный момент. Представь, если работа занявшая первое место в oldskool, на самом деле работает только на современном PC (надеюсь, что это не так, конечно).
После выполнения инициализирующего кода в simple_lib.inc раскладка памяти следующая:
С адреса $8000 располагаются 16384 _слов_ (ячейки памяти 16-битные) описывающие 16-цветный битмап 256x256 (на экране без записи в регистры скроллинга видны верхние 192 строки). Т.к. ячейки — слова, то в каждое слово влезает четыре пикселя по 4 бита цветности на каждый. Раскладка линейная.
Но еще с адреса $C000 располагается зона атрибутов размером 32x32 знакоместа. Атрибут имеет маску PPPP00NN NNNNNNNN, где N это номер выводимого знакоместа в соответствующей квадратной сетке, а PPPP — верхние биты палитры из 256 цветов которые будут добавляться к цветам пикселя. Т.е. номер субпалитры в 16 слотов из 16 субпалитр. Чтобы записать в палитру надо записать в ячейку/порт $FFF6 номер слота палитры (0..255), а в $FFF7 RGB-значение в формате 0RRRRRGGGGGBBBBB.
Таким образом на экране может быть одновременно 256 цветов, но не более чем 16 цветов в знакоместе.
Более того — отображение в знакоместах можно перенастраивать на другие знакоместа через таблицу атрибутов реализуя быстро работающие текстовые видеорежимы ну или игровое тайловое поле с аппаратным скроллингом.