Ладно, если честно я пока понял только то, что чтобы понять надо приложить намного, прям намного больше сил чем я изначально наивно рассчитывал. У меня честно столько на этот проект нету — нет из детства стимулирующего ностальгического элемента. :)
Ощущаю что мы где то рядом с пониманием. :) Поэтому вот такую еще картинку предлагаю глянуть что бы быть уверенным что мы об одном и том же говорим.
Условно я разбил кольцо на пакеты по 42 тетрады каждая. 15 пакетов или еще можно сказать фреймов. Фрейм используется для хранения данных и кода одновременно. Т.е. в одном фрейме-пакете залегает например регистр Р0 и код для шагов 0-7 программы. Либо например регистр стека Х1, регистр Р9 и 64-70 шаг программы.
На что я хочу обратить внимание (сейчас я прям очень грубо представлю) — что за один проход по кольцу сложить X и Y нельзя, ну потому что мы схватили младший разряд X, добрались до следующего фрейма в котором лежит младший разряд Y и уже прошло 42 такта (из 4 фаз). После сложения этих разрядов у нас сформировался перенос CARRY, но применить его к следующему разряду X+Y+CARRY мы сможем только после прокрутки кольца полностью. Но что меня особенно заботит это то что так складывать два числа без учета их порядка занятие совершенно бессмысленное, мантису надо сдвинуть таким образом что бы порядки чисел совпадали. Я специально утрировал ситуацию что бы показать как бы надо было бы действовать если бы не было внутренних регистров колец внутри ИК145, а они есть R и ST, адресация в них привязана к такту, т.е. не независимая, но что характерно меняется по кольцу от 0 до 41, поскольку R и ST это тоже замкнутые кольца величиной 42 тетрады.
С таким буфером как R и ST уже можно себе позволить заглотить мантису и порядок X из магистрального кольца целиком, впрочем поскольку мантиса лежит не подряд то и в буфер она тоже ляжет не подряд а с разрывом. Как правило на этом месте у меня уже начинает дергаться глаз :) поскольку при подходе к Y магистральное кольцо синхронизируются с внутренним регистром R и ST то сложение X[i]+Y[i]+CARRY становится возможным. Но блин надо же еще нормализовать мантису по порядку. :)
Но из схемы выбивается последняя последовательность 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 и обрабатывают сразу три числа одновременно цифра-за-цифрой. Так что ли? Т.е. предполагается «последовательно-параллельная» обработка трёх чисел за раз?
Хмм…
Вот это и есть по сути мой вопрос.
Да вполне резонно утверждаете. Но из схемы выбивается последняя последовательность 0,1,2,3,4,5 — заключительная, следующая после 6-7-8.
В кольце залегают группы тетрад, обратите внимание 1 р-р мантиссы внутренних регистров 0… Е, лежат первой тетрадой в кольце, затем следуют тетрада X1, X, Y, Z, T. Поэтому если к примеру мы работаем с регистром X осуществляя какую то операцию над ним, то выглядит это так:
1 такт из 4 фаз работаем над 1 разрядом мантиссы X- пропуск 2 тактов из 4 фаз каждый — 1 такт из 4 фаз работаем над 2 разрядом мантиссы Х — и так далее. Как тут быть? Мне кажется кольцо гоняется по кругу дикое кол-во раз ради прохождения одной операции к примеру сложения.
Спасибо большое! Не знал про это. Как будет свободное время, поищу аналоги этой микросхемы и поразбираюсь с работой на железе уже. На более распространённых и мощных контроллерах эмулировать их работу не хочется.
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 развивал эту нишу, так что наверняка есть альтернативные чипы.
Насчёт мантиссы я еще примешиваю сведения вот отсюда: 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 действия типа сложить разряд побитово уже как то вписано…
Попытаюсь ответить хотя бы на первую часть вопроса. В ОЗУ кольца на самом деле тетрад нет, там однобитный кольцевой регистр ячейка которого конденсатор и транзистор. Этакий DRAM со сдвигом. Физически там двигается 1 бит в кольце и магистраль на выходе тоже однобитная. Для того что бы обработать тетраду (тетрада удобна для хранения BCD разряда (двоично-десятичного), хотя кое где используется и шестнадцатеричные разряды) в один такт составлен из 4 фронтов сигналов сдвинутых по фазе Ф0, Ф1, Ф2, Ф3. Это физические линии, получается что такт у калькулятора построен из 4 микротактов. Кстати такое в 6502 любили тоже использовать. За 4 этих фронта и происходит обработка тетрады, но строго побитно.
По поводу обработки мантисы я Фролова не понял, возможно потому что он цитирует Я. Трахименко xn--b1aph9d.xn--p1ai/biblioteka/cartochki/0036.htm, а там тоже не все прозрачно, я например не продрался.
В мантисе 8 разрядов, и по программе видно что каждый такт в объект эмулирующий К145ИК13хх посылается дополнительный параметр по которому считывается 32-битная микроинструкция. Каждый бит этой микроинструкции управляет функциональными устройствами К145ИК13хх. Вот следование этого параметра друг за другом.
0,1,2,3,4,5 3,4,5 3,4,5 3,4,5 3,4,5 3,4,5 3,4,5 6,7,8 0,1,2 3,4,5,6,7,8 0,1,2,3,4,5
И таких вызовов 42, за один цикл. В принципе тут усматривается система о которой пишет Фролов. Но последний 3,4,5 идет не подряд. Мантисса 8-разрядная а триады 3,4,5 следуют подряд только 7 раз. А вот такому рисунку,
который я делал когда искал смещение переменных внутри кольца, это больше соответствует. Может я плохо понял, то что Вас интересовало? Давайте попробуем решить этот ребус вместе еще раз :)
Еще вопрос хочется задать — после чтения вот тут: habr.com/ru/post/467501/
Складывается какая то противоречивая картинка. С одной стороны говорится, что каждая инструкция программы исполняется 42 такта по числу _тетрад_ в «кольцах».
С другой говорится что одна тетрада обрабатывается за 1 такт (микрокоманду).
Но с третьей стороны опять же утверждается, что в процессе исполнения инструкции для обработки той же мантиссы нужно по 3 повторяющихся микрокоманды в той же первой фазе команды:
Вот эти вот 3-4-5 вроде как обрабатывают одну цифру/тетраду мантиссы.
Чего то я тут явно недопонимаю, т.к. эти сведения имхо противоречивы.
Да к сожалению алгоритм пока никто не сумел увидеть в потоке команд. Когда мне пришлось для повышения производительности переработать эмуляцию комплекта К145 для msp430, то посыпались ошибки как из рога изобилия. Что бы отловить где я ошибаюсь с пониманием внутренней архитектуры пришлось логировать каждое дыхание msp430 и emu61 на ПК. На один шаг DoStep в логах был выхлоп строк на 1000. А сбоило не всегда на первом DoStep. Я тогда чуть не «позеленел» от поиска несовпадений. :) Но в итоге уперся в то что не могу уже понять что то на уровне алгоритма, не охватываю. Мелочи какие то да, еще могу описать и осознать но что то большее 10-ка тактов выбивает из понимания того что происходит. Это как раз тот случай когда описать аппаратуру можно вплоть до гейта, микрокод снят до последнего бита, а в итоге понимания чуть больше чем 0.01% :) Мало того я ощутил ту черту производительности за которую я уже физически не могу выйти даже если я рассредоточу объекты по разным микроконтроллерам или переложу все в верилог и ПЛИС. Она мягко говоря будет отставать даже от МК161.
P.S. Как всегда надежда на свежую кровь в этом вопросе, может быть иной взгляд со стороны.
Почитал побольше про ИК13xx и всё это дело — две статьи на хабре и прочих ресурсах.
Охренеть! xD Архитектура впечатлила. Интересно — прошивки уже полностью до последнего винтика расковыряли в плане осознания что в них происходит алгоритмически или всё еще там зияют чёрные дыры непоняток «почему оно работает?»?
Условно я разбил кольцо на пакеты по 42 тетрады каждая. 15 пакетов или еще можно сказать фреймов. Фрейм используется для хранения данных и кода одновременно. Т.е. в одном фрейме-пакете залегает например регистр Р0 и код для шагов 0-7 программы. Либо например регистр стека Х1, регистр Р9 и 64-70 шаг программы.
На что я хочу обратить внимание (сейчас я прям очень грубо представлю) — что за один проход по кольцу сложить X и Y нельзя, ну потому что мы схватили младший разряд X, добрались до следующего фрейма в котором лежит младший разряд Y и уже прошло 42 такта (из 4 фаз). После сложения этих разрядов у нас сформировался перенос CARRY, но применить его к следующему разряду X+Y+CARRY мы сможем только после прокрутки кольца полностью. Но что меня особенно заботит это то что так складывать два числа без учета их порядка занятие совершенно бессмысленное, мантису надо сдвинуть таким образом что бы порядки чисел совпадали. Я специально утрировал ситуацию что бы показать как бы надо было бы действовать если бы не было внутренних регистров колец внутри ИК145, а они есть R и ST, адресация в них привязана к такту, т.е. не независимая, но что характерно меняется по кольцу от 0 до 41, поскольку R и ST это тоже замкнутые кольца величиной 42 тетрады.
С таким буфером как R и ST уже можно себе позволить заглотить мантису и порядок X из магистрального кольца целиком, впрочем поскольку мантиса лежит не подряд то и в буфер она тоже ляжет не подряд а с разрывом. Как правило на этом месте у меня уже начинает дергаться глаз :) поскольку при подходе к Y магистральное кольцо синхронизируются с внутренним регистром R и ST то сложение X[i]+Y[i]+CARRY становится возможным. Но блин надо же еще нормализовать мантису по порядку. :)
По сути это и есть мой вопрос из выше — как именно и что обрабатывается в каждом такте — почему Фролов утверждает что каждый разряд одного числа которое хранится вперемешку с двумя другими числами требует трёх микроинструкций при том что уже после первой в разрезе кольца оказывается разряд другого числа, а на следующем такте там опять будет разряд третьего числа. Тут я и не понял чем должны заниматься эти две микроинструкции и поэтому закралось подозрение что чего то не понимаю в общей схеме работы.
Однако снова подумаем — если каждая макроинструкция программы отрабатывает за 42 такта и за эти 42 такта кольцо проворачивается ровно 1 раз, то получается, что в начале следующей инструкции мы снова оказывается в начале X. Тогда следует логичный вроде бы вывод — что для того чтобы обработать два соседних числа в этой «нарезке слайсами», то значит микрооперации 0-1-2 и обрабатывают сразу три числа одновременно цифра-за-цифрой. Так что ли? Т.е. предполагается «последовательно-параллельная» обработка трёх чисел за раз?
Хмм…
Вот это и есть по сути мой вопрос.
В кольце залегают группы тетрад, обратите внимание 1 р-р мантиссы внутренних регистров 0… Е, лежат первой тетрадой в кольце, затем следуют тетрада X1, X, Y, Z, T. Поэтому если к примеру мы работаем с регистром X осуществляя какую то операцию над ним, то выглядит это так:
1 такт из 4 фаз работаем над 1 разрядом мантиссы X- пропуск 2 тактов из 4 фаз каждый — 1 такт из 4 фаз работаем над 2 разрядом мантиссы Х — и так далее. Как тут быть? Мне кажется кольцо гоняется по кругу дикое кол-во раз ради прохождения одной операции к примеру сложения.
Но конкретно Brick Game там почему то нет, зато в другом месте я её нашёл и это литера «L»: www.datasheetarchive.com/pdf/download.php?id=41f9ee0128a8926ce590ad66f8cc9513bb98f2&type=P&term=brick%2520game
В «L» судя по всему прошивался тетрис как раз. И опять таки судя по маркировке ядром везде действительно служил HT-1130 просто уже прошитый чем нужно в конкретных A-шках.
Например по первой ссылке: www.digchip.com/datasheets/parts/datasheet/196/HT1132A.php
И в datasheet www.digchip.com/datasheets/parts/datasheet/196/HT1132A-pdf.php прямо показаны что там должно быть табло по типу «волк ловит яйца» с фиксированными LCD-элементами. Сам datasheet датируется 1998 годом, так что тут явно попахивает ориентацией компании Holtek на игровой рынок с поисками разных реализаций наладонных игр на базе какой то одной архитектуры 4-битного микроконтроллера (что действительно типично для калькуляторов и часов).
И вряд ли конечно только Holtek развивал эту нишу, так что наверняка есть альтернативные чипы.
Здесь автор довольно резонную и звучащую крайне разумно в свете всего сказанного мысль говорит, что команда ИК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 действия типа сложить разряд побитово уже как то вписано…
По поводу обработки мантисы я Фролова не понял, возможно потому что он цитирует Я. Трахименко xn--b1aph9d.xn--p1ai/biblioteka/cartochki/0036.htm, а там тоже не все прозрачно, я например не продрался.
В мантисе 8 разрядов, и по программе видно что каждый такт в объект эмулирующий К145ИК13хх посылается дополнительный параметр по которому считывается 32-битная микроинструкция. Каждый бит этой микроинструкции управляет функциональными устройствами К145ИК13хх. Вот следование этого параметра друг за другом.
0,1,2,3,4,5 3,4,5 3,4,5 3,4,5 3,4,5 3,4,5 3,4,5 6,7,8 0,1,2 3,4,5,6,7,8 0,1,2,3,4,5
И таких вызовов 42, за один цикл. В принципе тут усматривается система о которой пишет Фролов. Но последний 3,4,5 идет не подряд. Мантисса 8-разрядная а триады 3,4,5 следуют подряд только 7 раз. А вот такому рисунку,
который я делал когда искал смещение переменных внутри кольца, это больше соответствует. Может я плохо понял, то что Вас интересовало? Давайте попробуем решить этот ребус вместе еще раз :)
Складывается какая то противоречивая картинка. С одной стороны говорится, что каждая инструкция программы исполняется 42 такта по числу _тетрад_ в «кольцах».
С другой говорится что одна тетрада обрабатывается за 1 такт (микрокоманду).
Но с третьей стороны опять же утверждается, что в процессе исполнения инструкции для обработки той же мантиссы нужно по 3 повторяющихся микрокоманды в той же первой фазе команды:
Вот эти вот 3-4-5 вроде как обрабатывают одну цифру/тетраду мантиссы.
Чего то я тут явно недопонимаю, т.к. эти сведения имхо противоречивы.
Похоже что Кристофер починил проблему.
В архиве вроде есть релизы еще мартовские где файл есть: bintray.com/christopherpow/nesicide/download_file?file_path=nesicide-win-x86-34a7fa6.tar.bz2
P.S. Как всегда надежда на свежую кровь в этом вопросе, может быть иной взгляд со стороны.
Охренеть! xD Архитектура впечатлила. Интересно — прошивки уже полностью до последнего винтика расковыряли в плане осознания что в них происходит алгоритмически или всё еще там зияют чёрные дыры непоняток «почему оно работает?»?
И отдельное спасибо за making of — моя любимая часть в любом демо.