+516.99
Рейтинг
1433.81
Сила
  • avatar aa-dav
  • 0
Я бы первое и второе места поменял бы местами. Уж больно динамичный ЧП получился, прямо жидкий терминатор. :)
  • avatar aa-dav
  • 1
Есть много суперкачественных картинок для спекки укладывающихся в его систему двухцветных знакомест и максимум 15 цветов на экране…
Но большинство из них изображают что-то, что не выглядит фотографичным.
Здесь Highlights at sunset — это невероятная для спектрума фотографичность изображения!
Прямо наверное как и в Quake 1 тонущая во мраке большая часть изображения + слепящий свет фар оставляют воображению богатейшие возможности по дорисовке и наделению картинки несуществующими деталями.
Хочется разглядывать и разглядывать. :) Максимальная фотографичность для такого уровня графических возможностей!
  • avatar aa-dav
  • 0
Если Вы уж взялись за проектирование архитектур процессоров, то считай катитесь по стенкам воронки.

В любом случае я сперва напишу эмулятор, оформлю архитектуру видеочипа и т.п., а главное — софт разный под это дело напишу — тогда только буду задумываться всерьёз насчёт физических реализаций. У меня в самом деле с детства очень напряжённые отношения с паяльником и сидеть травить платы и подпаивать сотни проводков — не вызывает энтузиазма вообще. Я не железячник, я больше по софту.
  • avatar aa-dav
  • 1
Есть желание перебросить процессор в Verilog, откатать на визуальном симуляторе цепей Digital и потом в FPGA?!
Сам я далёк от паяльника и программатора сильно, но отладив в эмуляторе реализовать в железе — весьма завлекательная идея.
Но лично сам — если только много лет спустя на пенсии, ибо сейчас изучение нового мира схемотехники для меня неподъёмный груз в рамках хобби.
Но если кому то опытному будет любопытно реализовать — я только за. В принципе архитектура open source-ная так что хоть форки делать со своими расширениями команд. :)
  • avatar aa-dav
  • 0
Мне сейчас уже синтаксисом заниматься неохота особо — я реально на нём попробовал как он есть и меня реально устроило. Даже как то понравилось когда ассемблерный текст растягивается в ширину с чётко выделенными пробелами всеми абсолютно местами.
Как я понял это дело привычки, поэтому тратить на это время уже не хочу.
Чем буду в свободное от других хобби время далее заниматься — это миграцией под SDL чтобы сделать прообраз виртуального ПК с клавиатурой и дисплеем и на нём реально пробовать что там со сдвигами применительно к скроллингам всяким и парсер сложных compile-time выражений.
Хотя еще наверное преобразую парсер самого ассемблера к варианту с паттерн-матчингом — при нём проще будет новые синтаксисы внедрять, кстати.
  • avatar aa-dav
  • 1
P.S.
Реализовал псевдорегистр 'void' и поведение с косвенной записью в PC. Теперь освободился еще один опкод — CMP.
Теперь сравнение делается так:

sub void A B ; экивалентно cmp A B во многих других ISA
jnz ...


побитовые тесты (любые в OR/XOR/AND):

and void r0 $0001
jz ...

… или сравнение числа с константой в диапазоне -8..+7 за инструкцию в одно слово (inplace immediate):

addi void r0 -3
jz ... ; r0 равен 3

… или проверка i-ого бита операнда через занос его в CF операцией RRCI:

rrci void r0 3 ; третий бит r0 попадёт в CF
jc ... ; переход если CF=1

Ляпота! Еще раз спасибо за идею! :)
  • avatar aa-dav
  • 0
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
Блин, это прикольная идея! Прям спасибо!
  • avatar aa-dav
  • 1
В процессе обсуждения на другом ресурсе родилась забавная, имхо, идея.
Единственный формат инструкции 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. Это даже что-то новенькое для меня и явно чувствуется, что может послужить источником каких то интересных полухаков. :)
  • avatar aa-dav
  • 0
Вот с чего я окончательно прифигел — так это с того, что на 2:01:00 Джон Ромеро играет в Marsmare: Alienation: youtu.be/tGlK9wnPvJw
:D
  • avatar aa-dav
  • 2
Marsmare: Alienation — огонь! Прошёл и отзыв написал.
  • avatar aa-dav
  • 1
Ясно. Классические аркадно-консольные архитектуры решали все такие проблемы методично ровно по линии меньшего сопротивления:
а) обновлять VRAM можно только во время VBlank
б) слой(и) фона аппаратно скроллируется «с проворотом» так что скроллерам надо лишь раз на 8 пикселей прокрутки обновлять одну полоску тайлов фона(ов)
в) спрайты это отдельный фон из независимых объектов (отчего были всегда лимиты на количество спрайтов отображаемых в одной строке)
г) цвета палетризированы в два этапа — в плитке фона или спрайте есть селектор одной из нескольких разных палитр отчего информация о цвете еще сжимается.
Таково как бы классическое противостояние между Tile/Sprite Engine и Framebuffer render.
  • avatar aa-dav
  • 1
Такое ощущение, что тут речь не про спрайты как они преимущественно понимаются — массив имеющих независимые координаты объектов на экране где мы выбираем какие тайлы в спрайтах отображаются, но их количество как правило не покрывает все пиксели экрана и главное что они все могут быть выведены хоть в одну координату оставив остальной экран пустой. Тут же больше похоже что речь про тайловые фоны — квадратно-гнездовые сетки из тайлов иногда аппаратно скроллируемые, но как одно целое. Они по определению всегда покрывают весь экран и образуют квадратно-гнездовую сетку. В последнем случае становится понятно почему нужно попиксельно возится со скроллингом «спрайтов» в памяти спрайтов. Но даже если и так, то всё-равно не очень понятно что тут 8-битные процессоры не вывозили — если выводом такой графики заведует отдельная микросхема то они хотя бы небольшое количество тайлов и не вижу куда бы тут танчики не влезли — подвижных там не очень много… Не кажется чем то сверхъестественным.
  • avatar aa-dav
  • 0
если бы было три спрайтовых плана с приоритетом отрисовки
Непонятно что это точно означает.
  • avatar aa-dav
  • 0
По ссылке там есть еще вторая часть статьи где описывается трюк с туманом. Я глубоко не вчитывался, так поверхностно текст просканировал глазами и похоже что какие то трюки с лукап-таблицами и вроде тоже непростые.
  • avatar aa-dav
  • 0
Похоже с моей стороны проблемы.
Последний билд у меня тоже вылетает, но то что я выложил работает.
Можно еще вот что попробовать — уже после запуска подпапка CPSSoftware содержит ini-файлы создаваемые в момент запуска. В моей сборке там есть пути из моего компьютера. Удалить всю папку и попробовать снова.
  • avatar aa-dav
  • 0
Хм, ему отрепортил и чтобы не замедлять выложил вот сюда архив с тем билдом что у меня работал прекрасно когда я писал уроки: yadi.sk/d/ibDehLMrdYSJ3w
  • avatar aa-dav
  • 0
хоть из-за неё и страдает быстродействие, но действительно достаточно элегантно и просто можно расширять схему
Имхо они просто попали в «ловушку легаси».
Первые калькуляторы на арифметике +-*/ делались чисто под эти операции — BCD-логика разряд за разрядом — дешевая память в виде shift registers просто просилась в такие алгоритмы. А дальше уже остановится не могли усложняя раз за разом на базе предыдущего опыта.
  • avatar aa-dav
  • 1
Поход на 6502 уже выразился тут в моих статья про программирование на NES/Famicom/Денди: hype.retroscene.org/blog/967.html :)
Кстати на nesdev.com вчера (с этой же статьи по сути) мне рассказали, что похожий чип Sharp SM-59x трудился в NES в чипе региональной защиты CIC в американских картриджах. Т.е. Nintendo с Sharp так сказать совсем даже не прекратила отношения по этой линии тогда. :)
  • avatar aa-dav
  • 1
Ладно, если честно я пока понял только то, что чтобы понять надо приложить намного, прям намного больше сил чем я изначально наивно рассчитывал. У меня честно столько на этот проект нету — нет из детства стимулирующего ностальгического элемента. :)
  • avatar aa-dav
  • 1
Но из схемы выбивается последняя последовательность 0,1,2,3,4,5 — заключительная, следующая после 6-7-8.
Я не понял почему.
1 такт из 4 фаз работаем над 1 разрядом мантиссы X- пропуск 2 тактов из 4 фаз каждый — 1 такт из 4 фаз работаем над 2 разрядом мантиссы Х — и так далее. Как тут быть?
По сути это и есть мой вопрос из выше — как именно и что обрабатывается в каждом такте — почему Фролов утверждает что каждый разряд одного числа которое хранится вперемешку с двумя другими числами требует трёх микроинструкций при том что уже после первой в разрезе кольца оказывается разряд другого числа, а на следующем такте там опять будет разряд третьего числа. Тут я и не понял чем должны заниматься эти две микроинструкции и поэтому закралось подозрение что чего то не понимаю в общей схеме работы.
Однако снова подумаем — если каждая макроинструкция программы отрабатывает за 42 такта и за эти 42 такта кольцо проворачивается ровно 1 раз, то получается, что в начале следующей инструкции мы снова оказывается в начале X. Тогда следует логичный вроде бы вывод — что для того чтобы обработать два соседних числа в этой «нарезке слайсами», то значит микрооперации 0-1-2 и обрабатывают сразу три числа одновременно цифра-за-цифрой. Так что ли? Т.е. предполагается «последовательно-параллельная» обработка трёх чисел за раз?
Хмм…
Вот это и есть по сути мой вопрос.