Assembler *

В первой части статьи мы разобрали загрузчик оригинальной версии и выяснили, куда загружается код игры и как он запускается. Теперь нужно перенести файлы на диск.

Обычно это делается простым копированием файлов, но есть одна проблема. Дело в том, что оригинальный файл содержит картинку и код игры целым куском и, следовательно, затирает собой область бейсика и системных переменных, которые находятся сразу за экранной областью. Такой файл можно загрузить с ленты, но нельзя загрузить с дискеты. TR-DOS резервирует область определённую памяти под свои нужды, и если загрузить туда данные, в процессе загрузки всё сломается.

В отличие от современных компьютеров, на спектрумах понятия файловой системы не было как такового. Это значит, что загрузка с каждого типа носителя требовала отдельной реализации и в большинстве случаев программу нельзя было просто так скопировать с кассеты на дискету. В случаях, когда загрузчик программы был написан на бейсике, его можно было адаптировать к TR-DOS довольно простой доработкой. Однако ситуация осложнялась тем, что во многих играх (как фирменных так и взломанных) загрузчики были написаны в машинных кодах и иногда содержали защиту от копирования.

Несмотря на наличие «волшебной кнопки», которая просто делала полный дамп памяти компьютера и позволяла хоть как-то сохранить программу на дискету, среди специалистов считалось хорошим тоном создавать дисковые версии игр с сохранением оригинальной загрузочной картинки и прочих атрибутов.

В этой статье я расскажу, как выполнить такую адаптация на примере игры Pac-Man, а именно, оригинального образа Pac-Man.tzx.

Раз уж прошлая моя статья, к моему большому удивлению, вас заинтересовала. Я решил дополнить её результат, хакнутую версию игры "Contra (J) [T+Rus_Chronix]", небольшим функционалом, заодно показав "code injection" на NES. В этот раз я сделаю так, чтоб игроки начинали игру с прокачанным Spreadgun, для его получения в игре нужно подобрать иконку "S", а за ней "R".

Все заинтересовавшиеся welcome под кат.

Поскольку некоторая японская компания, до сих пор тщательно бдит свои авторские права. Я не могу предоставить вам ни мою версию рома ни использованный мною исходник. Скажу лишь, что нашёл его в торрент сборнике "Все игры на Dendy". Взяв оттуда переведённую на русский язык японскую версию игры "Contra (J) [T+Rus_Chronix]" я несколько раз её прошёл и будучи крайне любознательным человеком решил немного расковырять ROM образ, в частности подарить немного жизней игрокам.

Первая часть
Вторая часть

Тема сегодняшнего разговора — работа с памятью. Я расскажу про инициализацию директории страниц, маппинг физической памяти, управление виртуальной и мою организацию кучи для аллокатора.

Как я уже говорил в первой статье, я решил использовать страницы размером 4 МБ, чтобы упростить себе жизнь и не иметь дела с иерархическими таблицами. В дальнейшем я надеюсь перейти на страницы размером 4 КБ, как большинство современных систем. Я мог бы использовать готовый (например, такой блочный аллокатор), но написать свой было чуть интереснее и хотелось чуть больше понять, как живет память, так что мне есть, что вам рассказать.

Введение

Предмет исследования

Первая часть

Первая статья еще не успела остыть, а я решил не держать вас в интриге и написать продолжение.

Итак, в предыдущей статье мы поговорили о линковке, загрузке файла ядра и первичной инициализации. Я дал несколько полезных ссылок, рассказал, как размещается загруженное ядро в памяти, как соотносятся виртуальные и физические адреса при загрузке, а так же как включить поддержку механизма страниц. В последнюю очередь управление перешло в функцию kmain моего ядра, написанного на Rust. Пришло время двигаться дальше и узнать, насколько глубока кроличья нора!

В этой части заметок я кратко опишу свою конфигурацию Rust, в общих чертах расскажу про вывод информации в VGA, и детально о настройке сегментов и прерываний. Всех заинтересованных прошу под кат, и мы начинаем.

Я решил написать статью, а если получится — то и серию статей, чтобы поделиться своим опытом самостоятельного исследования как устройства Bare Bone x86, так и организации операционных систем. На данный момент мою поделку нельзя назвать даже операционной системой — это небольшое ядро, которое умеет загружаться из Multiboot (GRUB), управлять памятью реальной и виртуальной, а также выполнять несколько бесполезных функций в режиме многозадачности на одном процессоре.

При разработке я не ставил себе целей написать новый Linux (хотя, признаюсь, лет 5 назад мечтал об этом) или впечатлить кого-либо, поэтому особо впечатлительных прошу дальше не смотреть. Что мне на самом деле захотелось сделать — разобраться, как устроена архитектура i386 на самом базовом уровне, и как именно операционные системы делают свою магию, ну и покопать хайповый Rust.

В своих заметках я постараюсь поделиться не только исходными текстами (их можно найти на GitLab) и голой теорией (ее можно найти на многих ресурсах), но и тем путем, который я прошел, чтобы найти неочевидные ответы. Конкретно в этой статье я расскажу о компоновке файла ядра, его загрузке и инициализации.

Мои цели — структурировать информацию у себя в голове, а так же помочь тем, кто идет похожим путем. Я понимаю, что аналогичные материалы и блоги уже есть в сети, но чтобы прийти к моему текущему положению, мне пришлось долго собирать их воедино. Всеми источниками (во всяком случае, которые вспомню), я поделюсь прямо сейчас.

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

Введение

Предмет исследования

Итак, сразу к делу. Писать будем под Linux, на NASM и с использованием QEMU. Установить это легко, так что пропустим этот шаг.

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

function CPU_support_RDRAND: Boolean;
asm
  mov rax, $01
  cpuid
  test ecx, 40000000h //тестируем 30-й бит
  setne al
end;

function CPU_support_RDSEED: Boolean;
asm
  mov rcx, 0
  mov rax, $07 //страница №7
  cpuid
  test ebx, 40000h //тестируем 18-й бит
  setne al
end;

const
  REX_RDRAND32: Byte = $F0; //(11b:REG, 110b:OPCODE, 000b:EAX) 
  REX_RDSEED32: Byte = $F8; //(11b:REG, 111b:OPCODE, 000b:EAX)
  REX_W_RDRAND64: Byte = $48; //(11b:REG, 110b:OPCODE, 000b:RAX)
  REX_W_RDSEED64: Byte = $48; //(11b:REG, 111b:OPCODE, 000b:RAX)

Предыдущая часть вызвала бурную дискуссию, в ходе которой выяснилось, что AVX/AVX2 на самом деле есть в десктопных CPU, нет только AVX512. Поэтому продолжаем знакомиться с SIMD, но уже с современной его частью — AVX. А так же разберём некоторые комментарии:

• медленнее ли _mm256_load_si256, чем прямое обращение к памяти?
• влияет ли на скорость использование AVX команд над SSE регистрами?
• действительно ли так плохо использовать _popcnt?

Есть неупорядоченный массив arr с числами типа uint16_t. Необходимо найти количество вхождений числа v в массив arr.

int64_t cnt = 0;
for (int i = 0; i < ARR_SIZE; ++i)
    if (arr[i] == v)
        ++cnt;

------------------------------------------------------------
Benchmark                     Time           CPU Iterations
------------------------------------------------------------
BM_Count                   2084 ns       2084 ns     333079