Comments 56
Нда, низкоуровневый доступ к фрейм-буферу в win/linux... А если нельзя, но очень хочется? Есть что-нить наподобие?
Учитывая что в Линуксе всё - файл, то можно подключиться /dev/fb0 через системные вызовы и писать туда данные как в файл, это рабочий способ общаться с кадровым буфером из защищённого режима. Есть программы, которые способны без графического режима сохранять кадровый буфер, когда линукс работает в режиме консоли. Наверное можно и звуки издавать, если отправлять на аудио устройство /dev/audio байтики.
Для Винды же придётся подключить winapi и получить дескриптор нулевого окна - это автоматом даст вам доступ ко всему экрану и вы сможете рисовать пиксели поверх всех окон, я так делал только на C++.
Можно ещё на ассемблере инициализировать окно с помощью SDL2 и получить доступ к фрейм-буферу из OpenGL. Но это всё не то, вот на Досе весь экран принадлежит только вам без программных посредников.
У @w23 (он же provod), которого вы наверняка знаете, давно была неплохая серия статей про написание демок для Linux, где он описывал все эти подводные камни там, почитайте на досуге если интересно, начало здесь: Создание 1k/4k intro для Linux, часть 1.
Помню в детстве, когда в паскале писал свой менеджер текстовых окон (с прямой адресацией в видеопамять), очень удивился, когда увидел, что моя dos-программа, запущенная под виндой (не помню какой, может 95) внезапно корректно отображалась внутри окошка dos-сеанса, а не гадила артефактами поверх графики винды.
Тогда я стал догадываться, что в процессоре есть какое-то колдунство для перехвата прямого обращения к памяти (про защищённый режим я тогда слышал только название)
Можно пойти ещё дальше и набирать COM-файлы под DOS-ом - без использования компилятора - прямо с нуля в редакторе HIEW (он синхронно отображает HEX-коды и ASM-код для них).
Не знаю кто будет так извращаться в наше время, но вдруг захочется получить ачивку "написать программу в машинных кодах без использования компилятора" ¯\_(ツ)_/¯
Добавлял так в прошивку микроконтроллера незнакомой доселе архитектуры одну функцию. Действительно, довольно увлекательное извращение.
Когда-то писал в HEX editor сразу в машинных кодах. Делал это из академического интереса - трудоемко и неудобно в сравнении с человекочитаемым ассемблером, но в целом успешно.
Мы так в ГУАПе писали лабы в эмуляторе pdp-11. Сначала пишешь на асме, потом вручную по табличке переводишь в хекс коды, потом вручную забиваешь байт за байтом.
fill:
stosb ; ES:DI = fill_color value (al)
loop fillРазве простой
'rep stosb' не спасёт Отца Руской Демократии?
Насчёт демосцены. В своё время меня очень впечатлил Kkrieger. Это, конечно, не 32 байта, но очень впечатляет. Как раз, в то время, перед этим я обновил железо и сам увидел этот шедевр, а то тогда мне это казалось каким-то колдунством.
В 90-х, когда я ещё был студентом, такие фокусы мог показать примерно каждый второй, кто подрабатывал на кафедре выч. техники. Не на эмуляторе доса на телефоне тех времен конечно, а на пк. Теперь это конечно ближе к магии.
Кстати, некоторые демки напомнили программу life. А палитра цветов CGA/EGA... когда мне впервые удалось в программе вывести цвета, отличные от 16 стандартных - очень гордился :)
Вот Life от Rrrola в 31 байт
Во времена DOS были популярны такие демки - и .COM, размера до 4Кб и .EXE до 64Кб.
Одна из них - CD2.EXE, как раз около 64Кб
Про демки: Heaven7. Не понимаю только двух вещей: как они это уместили в 64к и как это работает в реальном времени.
Про статью:
; заполнить нулём фрейм-буфер
; далее в цикле:
xor al, al
dec al
out 3C6h, al
xor al, al
out 3C8h, al
mov al, red_color
out 3C9h, al
mov al, green_color
out 3C9h, al
mov al, blue_color
out 3C9h, al
; , где *_color - значения от 0 до 63Что там 64 килобайта... Elevated занимает всего 4066 байт :)
Из 64-килобайтных когда-то очень понравилась Fermi Paradox
Видео
Нельзя перемещать напрямую данные из одной ячейки оперативки в другую, нужно сначала загрузить ячейку из памяти в регистр, а потом в другую ячейку (кому-то было лень добавить ещё одну перегрузку для mov).
Ну в самом деле, добавить удорожающий всю систему (а в 8088 и так пытались удешевить) контроллер, аналогичный DMA - это ж не экономика, а просто лень. Дальше читать не стал.
Году в 1994-1995 было актуально
Отличная статья, спасибо, прочитал с удовольствием! Как вижу с творчеством Řrřola вы уже знакомы.
В своё время меня очень сильно впечатлила 32-байтная демка Dírojed от этого разработчика.
$ echo 'B013CD10C51F380F10276BDBE58A0F0209028FBFFE02483F4BE460FEC875E7C3' \
| xxd -r -p - dirojed.com
$ dosbox dirojed.com
<32-байтная магия!>
Выглядит очень эффектно, а если оставить её на экране подольше, то можно узреть как зарождается жизнь :D
Что-то подобное по графике было в скринсейвере программы DOS Navigator, но за 25 лет уже мог и забыть )
В статье как раз была гифка с другой прогой - dirojedc, я просто не знал кто автор и не подписал, но видимо тоже Rrrola
Даже не верится что такое уместилось в 32b
B013CD10C51F380F10276BDBE58A0F0209028FBFFE02483F4BE460FEC875E7C3Вот так демки распространять и надо, а не ссылками на vk. :-)
Интересные были времена когда пытались сделать что-то как можно сложнее но меньше. Больше всего поражало то как данные для программы превращались в код нужным прыжком на необходимый адрес.
А сейчас вкладка вконтактика в браузере потребляет гигабайт...
веб-амёбам далеко до премудростей оптимизаций
Кстати не совсем верно насчет "Всё описанное здесь имеет мало практической пользы в наше-то время" По сути программирование узкоспециализированных контроллеров происходит( или уже нет, но происходило) на asm подобном языке (только своем). Да и условно ардуино тоже можно слегка считать обобщенным порядком действия между низкоуровневым и тем же С
Ну на микрухах совсем другие приколы, особенно на восьмибитных - там даже не делают команды деления и умножения, приходится их мастерить из суммирований и битовых сдвигов, а чтобы был int32, надо слепить вместе 4 байта и каждый раз при работе с ними обрабатывать каждый байтик и чекать флаги статуса. А компилятор си ещё и умеет работу с дробными числами имитировать софтверно...
В стандартную поставку MSDOS и Windows 9x, 2000 и XP входила программа debug.exe, с помощью которой можно как просматривать 16-битный код, так и компилировать Assembler в COM-файлы. Пример компиляции текста на ассемблере можно посмотреть в статье "МышеOFFка" (https://www.osp.ru/pcworld/2008/04/5095968).
В 200х в определенных кругах было что-то типа соревнования на написание самого маленького резидентного вируса под dos. Там реально годами уменьшали по несколько байт. В начале соревнования было что-то типа 113 байт (точные цифры не помню), под конец 64. Я потратил несколько дней (!) для того чтобы добиться этих самых 64. Это была тяжелейшая головоломка. На всякий случай скажу, что эти вирусы никакой опасности не представляют ибо время доса ушло, это чисто спорт, вирус был фактически на бумаге. К сожалению все исходники этих микро вирусов Гугл потер(
64 байта не смогли сохранить?
Свой вариант сохранил. Мне были интересны других. В частности, по-моему название было viking. Я не думал, что интернет можно "потереть". Остались только упоминания без исходных кодов
Поделитесь хотя бы своим, здесь сохранится.
Я не думал, что интернет можно "потереть". Остались только упоминания без исходных кодов
Есть ссылки? Может, на каком-нибудь веб-архиве найдётся?
Поискал я, максимум что нашел, так это название: Virus.DOS.Small.59.a или Viking.59, что говорит о том, что он 59 байт, значит мой был меньше, наверное 58. Мой валяется где-то в бекапах, искать не буду, потому что и выкладывать не буду - хоть абсолютно понятно, что никакой опасности он не представляет, но часто люди не думают, забанят и все. Могу просто на словах описать основные моменты, почему удалось написать таким маленьким:
долгое время все эти микрики дописывали себя в конец СОМ-файла, а в начало ставили только JMP - так было легко восстанавливать файл уже загруженный в память. До того пока кто-то не додумался "конвейер"! После чего стали писать в начало файла и восстанавливать код в памяти по-живому, т.е записывать прямо поверх выполняющегося кода - это не вредило, потому что он был в конвеере. Хотя прерывания никто не запрещал, так что мог быть сбой, но экономия байтов)
при старте DOS предустанавливает регистры во всем известные значения, это экономило несколько байт
резидентный кол писался прямо в таблицу векторов прерываний, во 2-ю половину, которая обычно не использовалась, но я помню я далекие 90-е у меня EGA использовал какой-то вектор. Так что в моем случае был бы крах
многие константы были взаимосвязанными, например, размер вируса, адрес куда записываеттся резидентая часть, возможно сегмент - деталей уже не помню, помню что играясь с этими параметрами можно было выгадать несколько байт
точно помню что было обсуждение, что ХХХ из всемирно известных разрабов антивирусов "ввязался" в эту гонку и сделал ради спортивного интереса еще на байт меньше. Код никто не видел, а менеджер ХХХ, когда я об этом спросил его через несколько лет, отвечал: нет! нет! нет! такого не могло быть ни в коем случае
как уменьшить на один байт у меня была идея, но я не реализовал ее, поскольку пришла в голову на следующий день как я забил на это и не стал возвращаться. Суть была в том, что первый запуск подготавливает резидента, потом выходит в ДОС, второй запуск запускает все и код-носитель выполняется. Выглядело б это формально как глюк первого запуска. Хз, может ХХХ так и сделал
Недавно вышла статья, где предлагается метод сжатия изображений путём составления текстового описания. Получилось 600 байт из 474КБ.
В нашем случае наоборот, текстовое описание 4220 байт (или 3761 байт, если в UTF-8) кодирует демку ~58 байт. Интересно, когда удастся её восстановить (может быть, это сделает ИИ), это будет та же самая демка или чуть другая...
Похоже что статья вышла интересной и не перевелись ещё деды на хабре. Может быть потом сделаю другую статью по отдельной демке с понятными пояснениями для ассемблера
Ну конечно прикольно, но что-то квело. Спасибо конечно за ссылки на авторов, но вот интереснее было бы посмотреть разбор гуру. Хотя статья может и не задумывалась, как погружение в микро демки, скорее как краткий экскурс. Но даже так, многие недочёты просто убили.
"указывает компилятору что код программы должен грузиться в оперативную память с отступом в 256 байт" - а вот ему не пофиг, вроде он это решает. Эта директива нужна чтобы сместить абсолютные адреса, чтоб при исполнении не хапнуть горя. И ниже тоже про затирание этих несчастных байтиков из префикса доса - ты же не сам дос сотрёшь, а только все его плюшки, вернуться то всегда сможете 20 инт использовать. Но возможно тут речь шла более глобально о всей памяти и там чего не постирать. Код итоговый тоже не ахти, вроде сказали про луп, но вот ещё Inc Al и сохранение сегмента в es вызывают большие вопросы, если память не изменяет, на этом можно сэкономить 2 байта
Надо же! Не перевелись еще умельцы писать напрямую в видеопамять... С этого я когда-то в самом начале 90х и начинал. Помнится, "мой друг и учитель" принес мне программу на ассемблере PDP-11, которая печатает свой собственный исходный текст (известное упражнение -- напиши квайн на любом языке) со словами "напиши тоже самое на x86". Пришлось написать :)
Очень почему то плохо идет написание своей истории.
пишу этот комментарий, т.к. не повезло попасть на мошенников, которые апродвигают моргающие картинки как лечебные, там клиника полная, типа этим моргулисом переписывают ДНК человека.
можно их на ютубе найти.
пример по ссылкеПрограмма Радуга-Еноха Красный-Зеленый-Синий. (youtube.com)
Ультра-маленькие демки под DOS