Последний билд у меня тоже вылетает, но то что я выложил работает.
Можно еще вот что попробовать — уже после запуска подпапка CPSSoftware содержит ini-файлы создаваемые в момент запуска. В моей сборке там есть пути из моего компьютера. Удалить всю папку и попробовать снова.
хоть из-за неё и страдает быстродействие, но действительно достаточно элегантно и просто можно расширять схему
Имхо они просто попали в «ловушку легаси».
Первые калькуляторы на арифметике +-*/ делались чисто под эти операции — BCD-логика разряд за разрядом — дешевая память в виде shift registers просто просилась в такие алгоритмы. А дальше уже остановится не могли усложняя раз за разом на базе предыдущего опыта.
Спасибо за статью, и особенно за ссылку в комменте на статью Фролова на хабре!
У меня в детстве был МК-61, и я даже неплохо по нему упарывался, но честно говоря никода даже не задумывался как он реализован внутри.
Думал, что в микрухах просто обычные элементы зашиты. А оказалось, что всё по серьёзному и современному — микрокод и всё такое.
Так же интересная архитектура с этим кольцевым буффером, хоть из-за неё и страдает быстродействие, но действительно достаточно элегантно и просто можно расширять схему.
В SNES и N64 местные чипы региональной защиты тоже сделаны на микроконтроллере Sharp SM-5. Также он использовался во множестве LCD-игр не от Nintendo (Tiger, Konami).
Поход на 6502 уже выразился тут в моих статья про программирование на NES/Famicom/Денди: hype.retroscene.org/blog/967.html :)
Кстати на nesdev.com вчера (с этой же статьи по сути) мне рассказали, что похожий чип Sharp SM-59x трудился в NES в чипе региональной защиты CIC в американских картриджах. Т.е. Nintendo с Sharp так сказать совсем даже не прекратила отношения по этой линии тогда. :)
Вот так сукины дети прикрутили CRC вместо счетчика. Так то оно конечно и быстрей и меньше ресурсов сдвигать и хорить. Ай да сукины дети! Примерно такая же идея мне пришла по поводу расчета CRC ключевых слов Форта или Бейсика, для того что бы не проводить поиск по токену, а иметь всегда уникальное смещение в результате расчета по токену из строки полинома CRC-16, да можно даже CRC-8 :)
P.S. Спасибо за статью! Порадовали. Где то в комментах проскакивало, что Вы собираетесь пойти крестовым походом на 6502, буду рад почитать.
Ладно, если честно я пока понял только то, что чтобы понять надо приложить намного, прям намного больше сил чем я изначально наивно рассчитывал. У меня честно столько на этот проект нету — нет из детства стимулирующего ностальгического элемента. :)
Ощущаю что мы где то рядом с пониманием. :) Поэтому вот такую еще картинку предлагаю глянуть что бы быть уверенным что мы об одном и том же говорим.
Условно я разбил кольцо на пакеты по 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 развивал эту нишу, так что наверняка есть альтернативные чипы.
Можно еще вот что попробовать — уже после запуска подпапка CPSSoftware содержит ini-файлы создаваемые в момент запуска. В моей сборке там есть пути из моего компьютера. Удалить всю папку и попробовать снова.
Первые калькуляторы на арифметике +-*/ делались чисто под эти операции — BCD-логика разряд за разрядом — дешевая память в виде shift registers просто просилась в такие алгоритмы. А дальше уже остановится не могли усложняя раз за разом на базе предыдущего опыта.
У меня в детстве был МК-61, и я даже неплохо по нему упарывался, но честно говоря никода даже не задумывался как он реализован внутри.
Думал, что в микрухах просто обычные элементы зашиты. А оказалось, что всё по серьёзному и современному — микрокод и всё такое.
Так же интересная архитектура с этим кольцевым буффером, хоть из-за неё и страдает быстродействие, но действительно достаточно элегантно и просто можно расширять схему.
Кстати на nesdev.com вчера (с этой же статьи по сути) мне рассказали, что похожий чип Sharp SM-59x трудился в NES в чипе региональной защиты CIC в американских картриджах. Т.е. Nintendo с Sharp так сказать совсем даже не прекратила отношения по этой линии тогда. :)
P.S. Спасибо за статью! Порадовали. Где то в комментах проскакивало, что Вы собираетесь пойти крестовым походом на 6502, буду рад почитать.
Условно я разбил кольцо на пакеты по 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 развивал эту нишу, так что наверняка есть альтернативные чипы.