P.S.
Я присоединяюсь к корню этой ветки дискуссии: статья отличная, плюсанул её и таких надо больше.
Но этот конкретный момент передан неверно.
Когда в Doom или Duke3D играют мелодии — эталонное их звучание это Sound Blaster, но музыкальный чип Sound Blaster это и есть чип из Adlib, а конкретно: Yamaha YM3812. И огромная куча куча куча всего эксплуатирует музыку этого чипа в хвост и в гриву и вся вина Adlib только в том, что он вышел годом ранее, был по сути адаптацией YM3812 к IBM PC и не имел PCM-канала. Музыкальные же возможности Sound Blaster у него тупо спёр сделав такой же маппинг портов ввода-вывода чтобы убить. И сделал это.
Может объяснишь, почему в 1990-е он использовался чрезвычайно редко?
Его убил Sound Blaster и убил именно тем, что взял за музыкальный чип тот же самый ямаховский чип что стоял в Adlib и замапил его порты на те же порты ввода-вывода что и было в Adlib. Т.е. по сути Sound Blaster 1.0 это был убийца Adlib и… он его успешно убил.
Но когда мы говорим о _музыке_ на Sound Blaster (т.е. FM-синтез), то это Adlib. Вот как есть. Все программы совместимые с Adlib автоматически работали с Sound Blaster без изменений.
Но Adlib убило то, что в нём не было цифрового звука и как следствие криков монстров и так далее — Sound Blaster вышел буквально через год и убил его.
Но музыкальный чип у них одинаковый.
P.S.
Причём, если склероз не изменяет, Sound Blaster 1.0 впаял две FM-микросхемы, но стандартные порты Adlib писали сразу в обе и таким образом была обратная совместимость. Но SB имел порты и для пораздельной записи и таким образом можно было создать стерео.
Но возможно это было сделано в SB 2.0, уже не помню точно.
Так или иначе YM3812 намного круче SID из C64 — 9 каналов, да еще и по два осциллятора в каждом, это было значительно круче.
Плюсую. Adlib по сути своей был микросхемой FM-синтеза звука — Yamaha YM3812 (которая использовалась в синтезаторах этой фирмы-производителя музыкального оборудования), которую воткнули в порты ввода-вывода IBM PC.
Первый Sound Blaster появившийся чуть позднее взял ту же самую микросхему, замапил на точно те же самые порты, но в плюс к тому добавил еще одну микросхему PCM-звука и вуаля — хити сезона был готов. Т.е. Sound Blaster по сути был обратно совместим (причём аппаратно) с Adlib по части музыки, но плюс к тому умел в PCM. И действительно все кто имели в то время программы разработанные для воспроизведения FM-музыки на Adlib без переделки могли запускать их на Sound Blaster.
Видеорежим и тайминги реализованы, нет ввода с клавиатуры так что пока только потыкать палкой, но тыкать уже вовсю можно — файл simple_lib.inc какбы реализует минимальную среду для вывода текста в консоль.
Есть много суперкачественных картинок для спекки укладывающихся в его систему двухцветных знакомест и максимум 15 цветов на экране…
Но большинство из них изображают что-то, что не выглядит фотографичным.
Здесь Highlights at sunset — это невероятная для спектрума фотографичность изображения!
Прямо наверное как и в Quake 1 тонущая во мраке большая часть изображения + слепящий свет фар оставляют воображению богатейшие возможности по дорисовке и наделению картинки несуществующими деталями.
Хочется разглядывать и разглядывать. :) Максимальная фотографичность для такого уровня графических возможностей!
Если Вы уж взялись за проектирование архитектур процессоров, то считай катитесь по стенкам воронки.
В любом случае я сперва напишу эмулятор, оформлю архитектуру видеочипа и т.п., а главное — софт разный под это дело напишу — тогда только буду задумываться всерьёз насчёт физических реализаций. У меня в самом деле с детства очень напряжённые отношения с паяльником и сидеть травить платы и подпаивать сотни проводков — не вызывает энтузиазма вообще. Я не железячник, я больше по софту.
Есть желание перебросить процессор в Verilog, откатать на визуальном симуляторе цепей Digital и потом в FPGA?!
Сам я далёк от паяльника и программатора сильно, но отладив в эмуляторе реализовать в железе — весьма завлекательная идея.
Но лично сам — если только много лет спустя на пенсии, ибо сейчас изучение нового мира схемотехники для меня неподъёмный груз в рамках хобби.
Но если кому то опытному будет любопытно реализовать — я только за. В принципе архитектура open source-ная так что хоть форки делать со своими расширениями команд. :)
Мне сейчас уже синтаксисом заниматься неохота особо — я реально на нём попробовал как он есть и меня реально устроило. Даже как то понравилось когда ассемблерный текст растягивается в ширину с чётко выделенными пробелами всеми абсолютно местами.
Как я понял это дело привычки, поэтому тратить на это время уже не хочу.
Чем буду в свободное от других хобби время далее заниматься — это миграцией под SDL чтобы сделать прообраз виртуального ПК с клавиатурой и дисплеем и на нём реально пробовать что там со сдвигами применительно к скроллингам всяким и парсер сложных compile-time выражений.
Хотя еще наверное преобразую парсер самого ассемблера к варианту с паттерн-матчингом — при нём проще будет новые синтаксисы внедрять, кстати.
1) куча пробелов выглядит хуже пары запятых и занимает больше места в исходнике
Тут забавно — изначально я просто «по быстрячку» (а исходники Simpleton-ов всегда развивались таким путём) воспользовался вводом строк из потоков C++, которые ведут себя именно таким образом — просто вводят от текущей позиции до следующих пробельных символов.
И думал что в режиме теста так проковыляю какое то время, а потом заменю на типовую схему. Однако уже и есть функция extraсtLexem, но… мне так понравилось! :)
Во первых я всегда следую (и в данном случае — всем рекомендую) орфографической традиции — после знаков препинания типа точек или запятых ставить пробелы. Это естественно как дышать и видно даже на этом самом тексте. Поэтому запятые только добавляют один символ к разделителю-пробелу в массе случаев. Их настоящая нужда в мейнстриме — это помощь с отделением друг от друга аргументов со сложными выражениями, что встречается относительно нечасто и может быть разрулено явными скобками.
Ну и просто попробовав я как то втянулся. Функцию extractLexem конечно можно переписать и получить более привычное поведение хотя бы со скобками, но мне после такой практики на это совершенно не хочется тратить время. :)
2) интересный вопрос, как устанавливаются флаги, когда приёмник — psw (как регистр) :)
Действительно отличный вопрос! Сейчас в эмуляторе АЛУ сперва обновляет биты арифметико-логических флагов как бы «напрямую» как если имеет в регистр флагов прямой вход через заднюю дверь (что весьма правдоподобно звучит для схемотехники, не зря он находится «с краю» регистрового файла), а уже после этого основное ядро извлекает результат из АЛУ и пишет его в регистровый файл. Т.е. запись в PSW ведёт себя довольно практично — изменение арифметических флагов будет забыто и операция вида «and psw psw маска» изменит только желаемый бит.
Однако возможно что ради скорости в схемотехнике эти операции могут происходить параллельно и результат сохранения в арфметико-логические флаги будет неопределён. Это может иметь некоторые последствия при обработке прерываний, но обдумав я нахожу что реальных проблем не будет. Поэтому на данный момент наверное лучше исходить из такого предположения.
> 3) не хватает прокрутки ЧЕРЕЗ перенос, а также сдвигов — для ускорения арифметики и возможной битовой графики
Я поэтому замер пока на операциях прокрутки и думаю какие лучше инструкции разместить в оставшейся части.
Во первых — по заветам MSP-430 операции ADD и ADC можно использовать как сдвиг и прокрутку влево:
add r0 r0 r0; сложение само с собой это умножение на 2 и сдвиг на 1 бит влево со вновь входящим нулевым битом
adc r0 r0 r0; сложение с переносом это сдвиг на 1 бит влево со входящим Carry и тут же исходящим Carry, т.е. идёт прокрутка влево через Carry, причём _через_ перенос.
Поэтому тот же MSP-430 не вводил аналогичных команд прокрутки и я не собираюсь.
Но вот прокрутка вправо уже должна быть в явном виде и чтобы побороть несколько проблем я пока решил сделать число прокручиваемых бит настраиваемым, а саму прокрутку — циклической с занесением в Carry, но не ЧЕРЕЗ Carry.
Почему так — потому что можно имитировать еще полезную команду SWAP BYTES просто прокрутив на 8 бит. Байты в слове поменялись местами.
Может быть полезно для упаковки и совместимости с типовыми файлами.
С другой стороны прокрутка вправо на 15 бит это же и прокрутка влево на 1 бит. Появляется взаимозаменяемость.
Далее — если кровь из носа нужен сдвиг влево/вправо на программируемое число бит мы можем подстроить счётчик чтобы нужные биты прокрутились куда требуется, а потом обнулением по «AND маска» занулить ненужные биты.
Так что как минимум беззнаковое деление на степени двойки делается. А если предварительно сделать условный переход по биту знака и в этой ветке сделать «OR маска», то и знаковые числа тоже можно будет делить и сдвигать таким образом.
Вот на этих размышлениях я пока подвис и пока еще думаю. Нужна практика наверное реального программирования на Simpleton 4 чтобы почувствовать что нужно остро и кровь из носу, а что достаточно сэмулировать серией базовых команд.
Тот же Gigatron вообще сдвиги делал через лукап-таблицы (!).
4) хорошо бы еще один регистр с автоинкрементами — для шитого кода (мб включать автоинкременты для регистров спецфлагами?)
Регистров в духе 8-биток тут немного, поэтому специализированного регистра точно не будет. А вот сделать в регистре флагов на первые 4 регистра по два флажка — «пост-инкремент» и «пре-декремент» — это интересная мысль, за неё спасибо. Её надо обдумать, хотя есть минусы. Например при входе в прерывания эти флаги надо обнулять и потом восстанавливать. Но! То как я планирую сделать вход в прерывания с этим похоже что прекрасно справляется. Да да да… Интересно…
5) зачем тратить опкод на отдельную команду cmp? когда можно принять запись в [psw] за игнор результата
А вот это супер-идея! Спасибо! Только и косвенное чтение и косвенная запись в PSW в Simpleton 4 уже заняты — это режим адресации immediate address с помощью которого можно вообще не загрязнять регистры:
[ $1000 ] = [ $1001 ] +s [ $1002 ] ; ни один регистр (включая флаги) кроме PC не изменился
Однако! Еще с Simpleton 3 была запрещена косвенная запись в PC! Здесь этот запрет сохранился, но я его не упомянул.
Пытаться писать прямо в поток выполняемых команд — это как минимум странно. :) Поэтому именно за [ PC ] в поле R и логично закрепить новый смысл — «игнорирование записи результата из АЛУ в файловый регистр или память». Гениально! :D
Действительно высвобождается специализированная инструкция CMP с одной стороны, а с другой стороны появляются булевы тесты и, например, такая экзотичка, как с помощью команды из одного слова — RRCI поместить в Carry любой на выбор бит из операнда. xD
Блин, это прикольная идея! Прям спасибо!
В процессе обсуждения на другом ресурсе родилась забавная, имхо, идея.
Единственный формат инструкции Simpleton (2.0) содержит трёхбитовое поле условности инструкции COND:
И сама инструкция в процессе середины выполнения его в схемотехнических кишках должна отвлечься на его проверку и откинуть результат если условие не сработало.
Но как мы знаем побеждают всё-таки архитектуры где не каждая инструкция может быть условной, а всё-таки небольшое подмножество JMP, а всё остальное как правило работает плотнее если условности нет.
Но идеологическим примативом Simpleton является единственный формат инструкции «взять SRC (и возможно DST), поместить их в АЛУ с кодом операции INSTR и результат записать в DST. Это единственное что этот процессор умеет по своей идеологии и делать отдельный формат инструкций для него ну прям то не ради чего он придумывался.
И вот тут и рождается идея — а что если условность выполнения перенести в АЛУ?
Сделать код инструкции который делает следующее — воспринимает SRC как составную величину — 3 бита код условия и 13 бит знакового данного с расширением до 16 бит. И если код условия срабатывает, то складывает SRC с DST и выдаёт результат наружу — иначе наружу выдаётся неизменённый DST.
Тогда код такой операции „conditional 13-bit addition“ в случае если в качестве DST будет подставлен PC сработает как „relative conditional jump“!
Итого за счёт введения новой такой инструкции мы полностью освобождаем 3 бита COND в инструкции и можем, например, увеличить количество регистров с 8 до 16! И всё равно еще остаётся 1 бит. И при этом главное кредо Simpleton остаётся неизменным — правда АЛУ набухает и набухает, т.к. вся сложность и вариативность заметается в него. :)
Но это уже будет Simleton 3.0 пожалуй, ибо я всё еще в раздумьях как поэффективнее воспользоваться возникшими тремя битами (16 регистров, имхо, процессору в духе 8 бит только вредят).
Что интересно — не встречал ранее такого нигде — что код условия в операции становится частью операнда где хранится смещение условного перехода.
Это довольно необычно для меня и даже странновато. Но получается, что можно, например извлекая смещения переходов из таблицы динамически формировать и условность перехода где то в ключевой точке типа switch. Это даже что-то новенькое для меня и явно чувствуется, что может послужить источником каких то интересных полухаков. :)
Ясно. Классические аркадно-консольные архитектуры решали все такие проблемы методично ровно по линии меньшего сопротивления:
а) обновлять VRAM можно только во время VBlank
б) слой(и) фона аппаратно скроллируется «с проворотом» так что скроллерам надо лишь раз на 8 пикселей прокрутки обновлять одну полоску тайлов фона(ов)
в) спрайты это отдельный фон из независимых объектов (отчего были всегда лимиты на количество спрайтов отображаемых в одной строке)
г) цвета палетризированы в два этапа — в плитке фона или спрайте есть селектор одной из нескольких разных палитр отчего информация о цвете еще сжимается.
Таково как бы классическое противостояние между Tile/Sprite Engine и Framebuffer render.
Такое ощущение, что тут речь не про спрайты как они преимущественно понимаются — массив имеющих независимые координаты объектов на экране где мы выбираем какие тайлы в спрайтах отображаются, но их количество как правило не покрывает все пиксели экрана и главное что они все могут быть выведены хоть в одну координату оставив остальной экран пустой. Тут же больше похоже что речь про тайловые фоны — квадратно-гнездовые сетки из тайлов иногда аппаратно скроллируемые, но как одно целое. Они по определению всегда покрывают весь экран и образуют квадратно-гнездовую сетку. В последнем случае становится понятно почему нужно попиксельно возится со скроллингом «спрайтов» в памяти спрайтов. Но даже если и так, то всё-равно не очень понятно что тут 8-битные процессоры не вывозили — если выводом такой графики заведует отдельная микросхема то они хотя бы небольшое количество тайлов и не вижу куда бы тут танчики не влезли — подвижных там не очень много… Не кажется чем то сверхъестественным.
По ссылке там есть еще вторая часть статьи где описывается трюк с туманом. Я глубоко не вчитывался, так поверхностно текст просканировал глазами и похоже что какие то трюки с лукап-таблицами и вроде тоже непростые.
Последний билд у меня тоже вылетает, но то что я выложил работает.
Можно еще вот что попробовать — уже после запуска подпапка CPSSoftware содержит ini-файлы создаваемые в момент запуска. В моей сборке там есть пути из моего компьютера. Удалить всю папку и попробовать снова.
Я присоединяюсь к корню этой ветки дискуссии: статья отличная, плюсанул её и таких надо больше.
Но этот конкретный момент передан неверно.
Когда в Doom или Duke3D играют мелодии — эталонное их звучание это Sound Blaster, но музыкальный чип Sound Blaster это и есть чип из Adlib, а конкретно: Yamaha YM3812. И огромная куча куча куча всего эксплуатирует музыку этого чипа в хвост и в гриву и вся вина Adlib только в том, что он вышел годом ранее, был по сути адаптацией YM3812 к IBM PC и не имел PCM-канала. Музыкальные же возможности Sound Blaster у него тупо спёр сделав такой же маппинг портов ввода-вывода чтобы убить. И сделал это.
Но когда мы говорим о _музыке_ на Sound Blaster (т.е. FM-синтез), то это Adlib. Вот как есть. Все программы совместимые с Adlib автоматически работали с Sound Blaster без изменений.
Но Adlib убило то, что в нём не было цифрового звука и как следствие криков монстров и так далее — Sound Blaster вышел буквально через год и убил его.
Но музыкальный чип у них одинаковый.
Причём, если склероз не изменяет, Sound Blaster 1.0 впаял две FM-микросхемы, но стандартные порты Adlib писали сразу в обе и таким образом была обратная совместимость. Но SB имел порты и для пораздельной записи и таким образом можно было создать стерео.
Но возможно это было сделано в SB 2.0, уже не помню точно.
Так или иначе YM3812 намного круче SID из C64 — 9 каналов, да еще и по два осциллятора в каждом, это было значительно круче.
Первый Sound Blaster появившийся чуть позднее взял ту же самую микросхему, замапил на точно те же самые порты, но в плюс к тому добавил еще одну микросхему PCM-звука и вуаля — хити сезона был готов. Т.е. Sound Blaster по сути был обратно совместим (причём аппаратно) с Adlib по части музыки, но плюс к тому умел в PCM. И действительно все кто имели в то время программы разработанные для воспроизведения FM-музыки на Adlib без переделки могли запускать их на Sound Blaster.
Чтобы запустить тестовый пример надо выделить в списке файлов test0.asm и выбрать меню Emulator->Compile and run.
Обзорно об таймингах SimpX можно почитать тут: gamedev.ru/flame/forum/?id=249067&page=22&m=5403677#m318
О раскладке памяти (MMU) тут: gamedev.ru/flame/forum/?id=249067&page=20&m=5395740#m287
Об его единственном пока видеорежиме который элегантно сочетает воедино и тайловую и линейную битмапную графику здесь: gamedev.ru/flame/forum/?id=249067&page=19&m=5394557#m281
Видеорежим и тайминги реализованы, нет ввода с клавиатуры так что пока только потыкать палкой, но тыкать уже вовсю можно — файл simple_lib.inc какбы реализует минимальную среду для вывода текста в консоль.
Но большинство из них изображают что-то, что не выглядит фотографичным.
Здесь Highlights at sunset — это невероятная для спектрума фотографичность изображения!
Прямо наверное как и в Quake 1 тонущая во мраке большая часть изображения + слепящий свет фар оставляют воображению богатейшие возможности по дорисовке и наделению картинки несуществующими деталями.
Хочется разглядывать и разглядывать. :) Максимальная фотографичность для такого уровня графических возможностей!
В любом случае я сперва напишу эмулятор, оформлю архитектуру видеочипа и т.п., а главное — софт разный под это дело напишу — тогда только буду задумываться всерьёз насчёт физических реализаций. У меня в самом деле с детства очень напряжённые отношения с паяльником и сидеть травить платы и подпаивать сотни проводков — не вызывает энтузиазма вообще. Я не железячник, я больше по софту.
Но лично сам — если только много лет спустя на пенсии, ибо сейчас изучение нового мира схемотехники для меня неподъёмный груз в рамках хобби.
Но если кому то опытному будет любопытно реализовать — я только за. В принципе архитектура open source-ная так что хоть форки делать со своими расширениями команд. :)
Как я понял это дело привычки, поэтому тратить на это время уже не хочу.
Чем буду в свободное от других хобби время далее заниматься — это миграцией под SDL чтобы сделать прообраз виртуального ПК с клавиатурой и дисплеем и на нём реально пробовать что там со сдвигами применительно к скроллингам всяким и парсер сложных compile-time выражений.
Хотя еще наверное преобразую парсер самого ассемблера к варианту с паттерн-матчингом — при нём проще будет новые синтаксисы внедрять, кстати.
Реализовал псевдорегистр 'void' и поведение с косвенной записью в PC. Теперь освободился еще один опкод — CMP.
Теперь сравнение делается так:
побитовые тесты (любые в OR/XOR/AND):
… или сравнение числа с константой в диапазоне -8..+7 за инструкцию в одно слово (inplace immediate):
… или проверка i-ого бита операнда через занос его в CF операцией RRCI:
Ляпота! Еще раз спасибо за идею! :)
И думал что в режиме теста так проковыляю какое то время, а потом заменю на типовую схему. Однако уже и есть функция extraсtLexem, но… мне так понравилось! :)
Во первых я всегда следую (и в данном случае — всем рекомендую) орфографической традиции — после знаков препинания типа точек или запятых ставить пробелы. Это естественно как дышать и видно даже на этом самом тексте. Поэтому запятые только добавляют один символ к разделителю-пробелу в массе случаев. Их настоящая нужда в мейнстриме — это помощь с отделением друг от друга аргументов со сложными выражениями, что встречается относительно нечасто и может быть разрулено явными скобками.
Ну и просто попробовав я как то втянулся. Функцию extractLexem конечно можно переписать и получить более привычное поведение хотя бы со скобками, но мне после такой практики на это совершенно не хочется тратить время. :)
Действительно отличный вопрос! Сейчас в эмуляторе АЛУ сперва обновляет биты арифметико-логических флагов как бы «напрямую» как если имеет в регистр флагов прямой вход через заднюю дверь (что весьма правдоподобно звучит для схемотехники, не зря он находится «с краю» регистрового файла), а уже после этого основное ядро извлекает результат из АЛУ и пишет его в регистровый файл. Т.е. запись в PSW ведёт себя довольно практично — изменение арифметических флагов будет забыто и операция вида «and psw psw маска» изменит только желаемый бит.
Однако возможно что ради скорости в схемотехнике эти операции могут происходить параллельно и результат сохранения в арфметико-логические флаги будет неопределён. Это может иметь некоторые последствия при обработке прерываний, но обдумав я нахожу что реальных проблем не будет. Поэтому на данный момент наверное лучше исходить из такого предположения.
> 3) не хватает прокрутки ЧЕРЕЗ перенос, а также сдвигов — для ускорения арифметики и возможной битовой графики
Я поэтому замер пока на операциях прокрутки и думаю какие лучше инструкции разместить в оставшейся части.
Во первых — по заветам MSP-430 операции ADD и ADC можно использовать как сдвиг и прокрутку влево:
add r0 r0 r0; сложение само с собой это умножение на 2 и сдвиг на 1 бит влево со вновь входящим нулевым битом
adc r0 r0 r0; сложение с переносом это сдвиг на 1 бит влево со входящим Carry и тут же исходящим Carry, т.е. идёт прокрутка влево через Carry, причём _через_ перенос.
Поэтому тот же MSP-430 не вводил аналогичных команд прокрутки и я не собираюсь.
Но вот прокрутка вправо уже должна быть в явном виде и чтобы побороть несколько проблем я пока решил сделать число прокручиваемых бит настраиваемым, а саму прокрутку — циклической с занесением в Carry, но не ЧЕРЕЗ Carry.
Почему так — потому что можно имитировать еще полезную команду SWAP BYTES просто прокрутив на 8 бит. Байты в слове поменялись местами.
Может быть полезно для упаковки и совместимости с типовыми файлами.
С другой стороны прокрутка вправо на 15 бит это же и прокрутка влево на 1 бит. Появляется взаимозаменяемость.
Далее — если кровь из носа нужен сдвиг влево/вправо на программируемое число бит мы можем подстроить счётчик чтобы нужные биты прокрутились куда требуется, а потом обнулением по «AND маска» занулить ненужные биты.
Так что как минимум беззнаковое деление на степени двойки делается. А если предварительно сделать условный переход по биту знака и в этой ветке сделать «OR маска», то и знаковые числа тоже можно будет делить и сдвигать таким образом.
Вот на этих размышлениях я пока подвис и пока еще думаю. Нужна практика наверное реального программирования на Simpleton 4 чтобы почувствовать что нужно остро и кровь из носу, а что достаточно сэмулировать серией базовых команд.
Тот же Gigatron вообще сдвиги делал через лукап-таблицы (!).
Регистров в духе 8-биток тут немного, поэтому специализированного регистра точно не будет. А вот сделать в регистре флагов на первые 4 регистра по два флажка — «пост-инкремент» и «пре-декремент» — это интересная мысль, за неё спасибо. Её надо обдумать, хотя есть минусы. Например при входе в прерывания эти флаги надо обнулять и потом восстанавливать. Но! То как я планирую сделать вход в прерывания с этим похоже что прекрасно справляется. Да да да… Интересно…
А вот это супер-идея! Спасибо! Только и косвенное чтение и косвенная запись в PSW в Simpleton 4 уже заняты — это режим адресации immediate address с помощью которого можно вообще не загрязнять регистры:
Однако! Еще с Simpleton 3 была запрещена косвенная запись в PC! Здесь этот запрет сохранился, но я его не упомянул.
Пытаться писать прямо в поток выполняемых команд — это как минимум странно. :) Поэтому именно за [ PC ] в поле R и логично закрепить новый смысл — «игнорирование записи результата из АЛУ в файловый регистр или память». Гениально! :D
Действительно высвобождается специализированная инструкция CMP с одной стороны, а с другой стороны появляются булевы тесты и, например, такая экзотичка, как с помощью команды из одного слова — RRCI поместить в Carry любой на выбор бит из операнда. xD
Блин, это прикольная идея! Прям спасибо!
Единственный формат инструкции Simpleton (2.0) содержит трёхбитовое поле условности инструкции COND:
И сама инструкция в процессе середины выполнения его в схемотехнических кишках должна отвлечься на его проверку и откинуть результат если условие не сработало.
Но как мы знаем побеждают всё-таки архитектуры где не каждая инструкция может быть условной, а всё-таки небольшое подмножество JMP, а всё остальное как правило работает плотнее если условности нет.
Но идеологическим примативом Simpleton является единственный формат инструкции «взять SRC (и возможно DST), поместить их в АЛУ с кодом операции INSTR и результат записать в DST. Это единственное что этот процессор умеет по своей идеологии и делать отдельный формат инструкций для него ну прям то не ради чего он придумывался.
И вот тут и рождается идея — а что если условность выполнения перенести в АЛУ?
Сделать код инструкции который делает следующее — воспринимает SRC как составную величину — 3 бита код условия и 13 бит знакового данного с расширением до 16 бит. И если код условия срабатывает, то складывает SRC с DST и выдаёт результат наружу — иначе наружу выдаётся неизменённый DST.
Тогда код такой операции „conditional 13-bit addition“ в случае если в качестве DST будет подставлен PC сработает как „relative conditional jump“!
Итого за счёт введения новой такой инструкции мы полностью освобождаем 3 бита COND в инструкции и можем, например, увеличить количество регистров с 8 до 16! И всё равно еще остаётся 1 бит. И при этом главное кредо Simpleton остаётся неизменным — правда АЛУ набухает и набухает, т.к. вся сложность и вариативность заметается в него. :)
Но это уже будет Simleton 3.0 пожалуй, ибо я всё еще в раздумьях как поэффективнее воспользоваться возникшими тремя битами (16 регистров, имхо, процессору в духе 8 бит только вредят).
Что интересно — не встречал ранее такого нигде — что код условия в операции становится частью операнда где хранится смещение условного перехода.
Это довольно необычно для меня и даже странновато. Но получается, что можно, например извлекая смещения переходов из таблицы динамически формировать и условность перехода где то в ключевой точке типа switch. Это даже что-то новенькое для меня и явно чувствуется, что может послужить источником каких то интересных полухаков. :)
:D
а) обновлять VRAM можно только во время VBlank
б) слой(и) фона аппаратно скроллируется «с проворотом» так что скроллерам надо лишь раз на 8 пикселей прокрутки обновлять одну полоску тайлов фона(ов)
в) спрайты это отдельный фон из независимых объектов (отчего были всегда лимиты на количество спрайтов отображаемых в одной строке)
г) цвета палетризированы в два этапа — в плитке фона или спрайте есть селектор одной из нескольких разных палитр отчего информация о цвете еще сжимается.
Таково как бы классическое противостояние между Tile/Sprite Engine и Framebuffer render.
Можно еще вот что попробовать — уже после запуска подпапка CPSSoftware содержит ini-файлы создаваемые в момент запуска. В моей сборке там есть пути из моего компьютера. Удалить всю папку и попробовать снова.