Насчёт мантиссы я еще примешиваю сведения вот отсюда: 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 Архитектура впечатлила. Интересно — прошивки уже полностью до последнего винтика расковыряли в плане осознания что в них происходит алгоритмически или всё еще там зияют чёрные дыры непоняток «почему оно работает?»?
Воруй палитры у художников на zxart.ee. Просто любой объект у них бери объёмный, ляжка там какая-нибудь, и смотри как идут от самого тёмного цвета к самому яркому цвету.
В гигаскрине цветов больше, палитры рисовать легче.
Технически, то что тебе нужно называется не палитрой, а «color ramp». Мы привыкли плюс-минус менять яркость одного и того же цвета, поэтому у нас на спектруме выходит очень мало вариантов. А художники умеют прямо в голове, по мере тего как они меняют яркость, менять ещё и hue. Если изменения hue более-менее последовательные, выходит не хуже чем если бы мы просто меняли яркость.
Подробнее, конечно, лучше художников расспрашивать.
Кстати про палитры. Может знаешь в каких демках лучше посмотреть референсы, или может где-то есть какие-то наработки, которыми не жалко поделиться? Мне приходит в голову только две, синяя (0, 1, 5, 7) и красная (2, 6, 7), и то в красной очень мало переходов. А ведь можно и смешанные какие-нибудь красивые, а можно ж и в гигаскрине… Эх :)
Если что — пишите спрашивайте, я стараюсь быть в теме подобных штук, мне всегда любопытно их подержать в руках да пощупать — поэтому могу что-нибудь да рассказать.
Spartan-6 XC6LX16 и старенький ACEX EP1K50 совсем в разных весовых категориях, у LX16 2278 слайсов, а слайс Xilinx грубо в 4 раза больше чем LE у Альтеры. При том что у Spartan-6 LUT — 6 входовой, а у ACEX 4-х. Ну и блочная память, тут совсем все неважно у ACEX. Даже если представить себе, что часть нововведений Z80N можно «пришить» сбоку имеющегося в Evo Z80, то скорее всего всю остальную часть логики засунуть уже будет некуда.
Спасибо за подробный рассказ! Некоторые эффекты были для меня новыми (например, интерполяцию я не встречал, и про капли я не заметил что они были из целых квадратов, на глаз казалось что сделано пикселями). Ну и в целом, всегда интересно какие технические решения были приняты и почему. Мне не понравилась палитра, поэтому отдельное спасибо за честное объяснение почему именно такая :)
Всё вместе получилось, ОК, я согласен что не восторг, но сделано крепко. Мне было интересно увидеть демо в чём-то очень олдскульное, но в чём-то ещё и с элементами ньюскула (хотя, как я сейчас понял из пояснений, фикса в ней было меньше чем мне тогда показалось). Но любое успешное «надурил» — всегда в плюс авторам и в плюс демо.
Здесь автор довольно резонную и звучащую крайне разумно в свете всего сказанного мысль говорит, что команда ИК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 — моя любимая часть в любом демо.
В гигаскрине цветов больше, палитры рисовать легче.
Технически, то что тебе нужно называется не палитрой, а «color ramp». Мы привыкли плюс-минус менять яркость одного и того же цвета, поэтому у нас на спектруме выходит очень мало вариантов. А художники умеют прямо в голове, по мере тего как они меняют яркость, менять ещё и hue. Если изменения hue более-менее последовательные, выходит не хуже чем если бы мы просто меняли яркость.
Подробнее, конечно, лучше художников расспрашивать.
Если что — пишите спрашивайте, я стараюсь быть в теме подобных штук, мне всегда любопытно их подержать в руках да пощупать — поэтому могу что-нибудь да рассказать.
Там можно завести уже сейчас и ZXUno, и Next, я думаю скоро можно будет и TSConf.
esxDOS там доступен и на zxuno, и на next ядре.
А ZXDOS+ хорош тем, что там жирная ПЛИС, 4мб SRAM, нормальный VDAC(6 бит на канал), ну и можно просто взять и купить.
Всё вместе получилось, ОК, я согласен что не восторг, но сделано крепко. Мне было интересно увидеть демо в чём-то очень олдскульное, но в чём-то ещё и с элементами ньюскула (хотя, как я сейчас понял из пояснений, фикса в ней было меньше чем мне тогда показалось). Но любое успешное «надурил» — всегда в плюс авторам и в плюс демо.