+516.34
Рейтинг
1431.66
Сила
  • 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 и обрабатывают сразу три числа одновременно цифра-за-цифрой. Так что ли? Т.е. предполагается «последовательно-параллельная» обработка трёх чисел за раз?
Хмм…
Вот это и есть по сути мой вопрос.
  • avatar aa-dav
  • 1
Еще немного погуглил. Похоже что кастомизированные под конкретную игру чипы от Holtek имеют маркировку HT113xA, где x — это цифра или буква конкретной игры. Например тут: www.alldatasheet.com/view.jsp?sField=2&Searchword=HT11&list=65 еще более полный ряд таких чипов виден от Space War до Casino.
Но конкретно Brick Game там почему то нет, зато в другом месте я её нашёл и это литера «L»: www.datasheetarchive.com/pdf/download.php?id=41f9ee0128a8926ce590ad66f8cc9513bb98f2&type=P&term=brick%2520game
В «L» судя по всему прошивался тетрис как раз. И опять таки судя по маркировке ядром везде действительно служил HT-1130 просто уже прошитый чем нужно в конкретных A-шках.
  • avatar aa-dav
  • 1
Тоже буквально в этом году натыкался на эту тему на nesdev и натыкался еще вот на какую интересность: www.digchip.com/datasheets/parts/datasheet/196/HT1130.php

HT1132A Space War LCD Game
HT1134A Pin Ball LCD Game
HT1136A Football LCD Game
HT1137A Motorcycle LCD Game
HT113AA Streetfighters LCD Game
...

Например по первой ссылке: www.digchip.com/datasheets/parts/datasheet/196/HT1132A.php
The is a single chip Space War LCD Game designed by HOLTEK. This LCD Game has two modes (mode 1 and mode 2) of playing…
И в datasheet www.digchip.com/datasheets/parts/datasheet/196/HT1132A-pdf.php прямо показаны что там должно быть табло по типу «волк ловит яйца» с фиксированными LCD-элементами. Сам datasheet датируется 1998 годом, так что тут явно попахивает ориентацией компании Holtek на игровой рынок с поисками разных реализаций наладонных игр на базе какой то одной архитектуры 4-битного микроконтроллера (что действительно типично для калькуляторов и часов).
И вряд ли конечно только Holtek развивал эту нишу, так что наверняка есть альтернативные чипы.
  • avatar aa-dav
  • 1
Насчёт мантиссы я еще примешиваю сведения вот отсюда: vak.ru/doku.php/proj/calculator/b3-34
Здесь автор довольно резонную и звучащую крайне разумно в свете всего сказанного мысль говорит, что команда ИК13 разбита на 3 синхропрограммы именно потому что авторы девайса выработали жёсткую схему: первая синхропрограмма в первой фазе команды обрабатывает мантиссу, вторая синхропрограмма (вторая фаза) — экспоненту и, наконец, третья — некие доп-функции главная среди которых — условный переход. Звучит весьма разумно.
Почему первая фаза состоит не из 8 3-4-5? Тут мне кажется тоже всё логично — во первых нужно как то иначе обработать знак (0-1-2), далее обрабатываются 7 знаков экспоненты (3-4-5) и последний разряд по схеме создателей чем то выделяется, поэтому он перескакивает на (6-7-8). Повторюсь — звучит логично.
Мантисса так же состоит из трёх разрядов — знак и две цифры.
Опять видим, что знак во второй фазе соответствует 0-1-2, далее «срединные» 3-4-5 и опять особым образом почему то нужно последнюю цифру замкнуть 6-7-8. По крайней мере в этом усматривается схема, хотя знания того как перенос работает тут немного не вписывается — но возможно как раз потому что я не понимаю почему на каждый разряд отведено 3 микроинструкции, если мы знаем что такт разбит на микротакты и там 4 действия типа сложить разряд побитово уже как то вписано…
  • avatar aa-dav
  • 1
Еще вопрос хочется задать — после чтения вот тут: habr.com/ru/post/467501/
Складывается какая то противоречивая картинка. С одной стороны говорится, что каждая инструкция программы исполняется 42 такта по числу _тетрад_ в «кольцах».
С другой говорится что одна тетрада обрабатывается за 1 такт (микрокоманду).
Но с третьей стороны опять же утверждается, что в процессе исполнения инструкции для обработки той же мантиссы нужно по 3 повторяющихся микрокоманды в той же первой фазе команды:

Вот эти вот 3-4-5 вроде как обрабатывают одну цифру/тетраду мантиссы.
Чего то я тут явно недопонимаю, т.к. эти сведения имхо противоречивы.
  • avatar aa-dav
  • 0
P.S.
Похоже что Кристофер починил проблему.
  • avatar aa-dav
  • 0
Хм, у него последние дни на гитхабе какие то шевеления по багрепортам и видимо чего то в процессе отвалилось. Я там отрепорчу.
В архиве вроде есть релизы еще мартовские где файл есть: bintray.com/christopherpow/nesicide/download_file?file_path=nesicide-win-x86-34a7fa6.tar.bz2
  • avatar aa-dav
  • 1
Почитал побольше про ИК13xx и всё это дело — две статьи на хабре и прочих ресурсах.
Охренеть! xD Архитектура впечатлила. Интересно — прошивки уже полностью до последнего винтика расковыряли в плане осознания что в них происходит алгоритмически или всё еще там зияют чёрные дыры непоняток «почему оно работает?»?