Спасибо за статейку! Читать такие вещи очень интересно, на хабре читал про 6809 с огромным интересом и продолжение про apple вполне себе дополняет. Особенно интересно было узнать что у 65С816 есть такие инструкции и DP.
Как то с другом мы обсуждали возможности в разрезе Clear reander engine vs Sprite/Tile Engine. Ну и закусились на тему, а что было бы если бы у бабушки были бы… если бы было три спрайтовых плана с приоритетом отрисовки (подобие Z-буфера). Было бы мол тогда интересней программить в ЯВУ те же танчики? Ну сказано сделано, примерно недели две возни с верилогом и готовый адаптер для отрисовки такой графики появился. Повозится конечно пришлось, что бы выйти на времянки 1024х768 (ЕМНИП). 12 стадий в конвейере устройства, причем регистры на стадии в ФУ конвейера, вовсе нет — простенькие мультиплексоры даже пришлось огораживать. Какое то время мне казалось что я не вывожу на этой ПЛИС задачу и как бы вообще на голую шину не пришлось ставить регистры в отрезки между ФУ. Но нет обошлось 12 стадиями. Жуткое чудо юдо.
Да, но это я к тому что вот это вот убер устройство хотели повесить на корку 6502, ну и оно не потянуло. Потом я рассматривал 6809 и тоже нет, не потянуло :) Потому что, если бы только проблемы отрисовки спрайтов поверх других спрайтов с аппаратным перекрытием, а ведь еще и скроллинг этих спрайтов попиксельно в памяти самих спрайтов. После этого как то утвердился в мысли о том что такого рода аппаратура мало что даст для программера, нужен именно прокаченный процессор и желательно такой который может за такт не одну инструкцию, и при это еще бы и асинхронно.
По ссылке там есть еще вторая часть статьи где описывается трюк с туманом. Я глубоко не вчитывался, так поверхностно текст просканировал глазами и похоже что какие то трюки с лукап-таблицами и вроде тоже непростые.
Ссылку на пост на Хабре мне прислали товарищи, и хотя читать её было весело, по сути ничего нового для квалифицированного Z80 кодера там не сообщалось. А вот этот трюк со вторым планом я пока нигде не встречал, спасибо за пересказ. Нужно будет прочесть первоисточник целиком, похоже что там у ребят всё очень благополучно с креативным мышлением.
Последний билд у меня тоже вылетает, но то что я выложил работает.
Можно еще вот что попробовать — уже после запуска подпапка 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 становится возможным. Но блин надо же еще нормализовать мантису по порядку. :)
Как то с другом мы обсуждали возможности в разрезе Clear reander engine vs Sprite/Tile Engine. Ну и закусились на тему, а что было бы
если бы у бабушки были бы… если бы было три спрайтовых плана с приоритетом отрисовки (подобие Z-буфера). Было бы мол тогда интересней программить в ЯВУ те же танчики? Ну сказано сделано, примерно недели две возни с верилогом и готовый адаптер для отрисовки такой графики появился. Повозится конечно пришлось, что бы выйти на времянки 1024х768 (ЕМНИП). 12 стадий в конвейере устройства, причем регистры на стадии в ФУ конвейера, вовсе нет — простенькие мультиплексоры даже пришлось огораживать. Какое то время мне казалось что я не вывожу на этой ПЛИС задачу и как бы вообще на голую шину не пришлось ставить регистры в отрезки между ФУ. Но нет обошлось 12 стадиями. Жуткое чудо юдо.Да, но это я к тому что вот это вот убер устройство хотели повесить на корку 6502, ну и оно не потянуло. Потом я рассматривал 6809 и тоже нет, не потянуло :) Потому что, если бы только проблемы отрисовки спрайтов поверх других спрайтов с аппаратным перекрытием, а ведь еще и скроллинг этих спрайтов попиксельно в памяти самих спрайтов. После этого как то утвердился в мысли о том что такого рода аппаратура мало что даст для программера, нужен именно прокаченный процессор и желательно такой который может за такт не одну инструкцию, и при это еще бы и асинхронно.
Можно еще вот что попробовать — уже после запуска подпапка 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 становится возможным. Но блин надо же еще нормализовать мантису по порядку. :)