Как я понял по видео, сейчас в игре процессор работает хоть и приближенно к реальным камням, но с кучей игровых условностей. Например, то что проц "склеивает" разные виды памяти в одну ОЗУ и др. Я предлагаю сделать более реалистичную реализацию процессора. Это сложнее чем придумывать свою систему, но в долгосрочной перспективе я уверен это будет лучше. Вот как я вижу это. ================================================= Архитектура очевидно будет x86, но важно определиться какая будет разрядность проца. Для начала думаю лучше будет начать с 16-битного проца (на подобии i8086). Так же, в оригинальном 16-битном x86 есть такая штука как сегменты, которые позволяют адресовать не 64 КБ памяти, а целый 1 МБ. Но они сложны для понимания и реализации, поэтому легче будет просто не делать их. По факту дальше всё делается очень просто. Создаем массив для оперативной памяти byte[] memory. В процессоре есть 16-битный регистр IP (Instruction Pointer), в нем храниться адрес следующей инструкции для выполнения. В нашем случае адрес в регистре является индексом элемента в массиве. Кстати, беспокоится об оптимизации памяти в данном случае не нужно, т.к. в IP не поместиться число больше 65535, а соответственно максимальный размер памяти не будет превышать 64 КБ, что для современных ПК крайне мало. Далее, мы в бесконечном цикле читаем байт по адресу из IP и пытаемся его выполнить. Делаем внутри цикла switch case и проверяем байт на соответствие каждой инструкции, и дальше логика самой инструкции. Если у инструкции есть операнды (аргументы), то пихаем их в следующий байт и считываем его тоже (тоесть инструкции могут быть разной длины). Когда инструкция выполнена увеличиваем регистр IP на длину инструкции и цикл начинается заново. Также, нам нужен стек в котором можно сохранять всякие временные данные. Стек будет также располагаться в оперативной памяти. В регистре SP находится адрес вершины стека (не забываем что стек растет вниз). Реализация логики инструкции PUSH будет примерно такой: взять из указанного регистра данные (байт или 2 байта) и записать их по адресу из SP, уменьшить SP на размер записанных данных. POP тоже самое, но в обратном порядке: прочитать данные по адресу из SP и записать их в указанный регистр, после чего увеличить SP на размер данных. Прерывания так же в идеале не должны быть захардкожены в скрипт процессора. Процессор вообще не в курсе что именно он должен сделать при прерывании возникновении прерывания. Тогда как оно работает? Процессор (в 16-битном режиме x86) при выполнении инструкции INT 2 сначала обращается в таблицу IVT (Interrupt Vector Table) которая располагается по адресу 0x0000, читает элемент с индексом 2 и берет из него адрес обработчика прерывания. После чего он "прыгает" на него, предварительно сохранив адрес возврата (т.е. адрес следующей инструкции после INT 2) в стек. Прыжок осуществляется с помощью изменения регистра IP. В конце кода обработчика прерывания стоит инструкция RET которая берет из стека адрес возврата и прыгает на него. ================================================= ВАЖНО! Процессор никак не определяет является ли байт инструкцией или данными. Он по умолчанию считает любой байт к которому он обращается с помощью регистра IP именно инструкцией. Что бы процессор не выполнял данные он просто никогда не должен на них переходить. Например, все данные можно размещать в конце программы, после инструкций "CLI" и "HLT" и проц попросту не доберется до секции с данными. Что бы работать с видеопамятью её можно типа "проецировать" в оперативную память. Например адреса 0x8000 - 0xFFFF оперативной памяти будут на самом деле является не адресами ОЗУ, а адресами видеопамяти. BIOS из памяти микросхемы в оперативную память может записать например скрипт материнки. Также если не хардкодить прерывания, а сделать их через таблицу IVT то получается что BIOS должен самостоятельно реализовать в себе обработчики прерываний и записать их адреса в IVT. Соответственно нужны механизмы общения программ с внешними устройствами (дисплеем, жестким диском и т.д.). Это конечно будет явно сложнее, поэтому я думаю пока прерывания можно тупо захардкодить в проц в виде отдельных инструкций.
